Skip to content
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
rewanthtammana opened this issue Oct 1, 2017 · 2 comments
Open

Emoji domain name resolver #1023

rewanthtammana opened this issue Oct 1, 2017 · 2 comments

Comments

@rewanthtammana
Copy link
Contributor

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

@dmiller-nmap
Copy link

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
Copy link

Support for this added in e3ab972, implemented only for glibc with AI_IDN support. We will keep this issue open until Windows support is added.

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

No branches or pull requests

2 participants