You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this is in reference to my tweet where I said that you can't nmap emoji domains directly. Depending on what libc you are using, you may get a "Failed to resolve" message or a resolution to an address that is incorrect. There's a good article about this on Daniel Stenberg's blog that is worth a read. Here's what happens:
You run a command like nmap -sL i❤.ws in your terminal.
Nmap receives the domain name in whatever encoding your terminal uses. Mine is UTF-8, but it's possible it would be something else. So the string is i\226\157\164.ws (octal escapes).
Nmap passes this directly to getaddrinfo, which is part of libc.
If libc allows non-ASCII hostnames, it will try to resolve it, building a DNS packet with the raw bytes given to it. In the case of the .ws domain, their nameserver answers with the wildcard record, since the records are not for the raw bytes but for the Punycoded version. Nmap continues to scan that IP.
If libc does not allow non-ASCII hostnames, getaddrinfo will give an error (I'm getting EAI_NONAME here). Nmap prints Failed to resolve "i❤.ws".
So in neither case is everything working properly, even if it seems like Nmap is getting a good resolution. We really need to put this through a punycoding library like libidn. Interestingly, these emoji domains are only allowed under IDNA 2003. This means that our IDNA 2008 implementation in idna.lua would reject them; maybe we should be using the older mapping for backwards compatibility.
The existing idna library can resolve the emoji domain names as well - @dmiller-nmap
The text was updated successfully, but these errors were encountered: