New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emoji domain name resolver #1023

Open
rewanth1997 opened this Issue Oct 1, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@rewanth1997
Contributor

rewanth1997 commented Oct 1, 2017

The existing idna library can resolve the emoji domain names as well - @dmiller-nmap

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 4, 2017

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:

  1. You run a command like nmap -sL i❤.ws in your terminal.
  2. 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).
  3. Nmap passes this directly to getaddrinfo, which is part of libc.
  4. 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.
  5. 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.

dmiller-nmap commented Oct 4, 2017

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:

  1. You run a command like nmap -sL i❤.ws in your terminal.
  2. 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).
  3. Nmap passes this directly to getaddrinfo, which is part of libc.
  4. 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.
  5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment