-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
DNS resolution fails for internationalized domain names #25558
Comments
All supported versions of Node are affected. I'm looking into it. |
Possible fix in #25559 |
I'm quite surprised that this affects so many version. I'm pretty sure IDN did work at least at some point in time. |
@santigimeno and I opened PRs but now that I think about it, this issue should be fixed once v10.x upgrades to libuv v1.24.0 because that's the first libuv release that includes libuv/libuv#2046. Landing the PRs would still be useful for:
|
@silverwind If you'll allow me to self-quote from #25679 (comment):
In other words, Node's behavior is currently platform-dependent (bad.) |
Before this commit, Node.js left it up to the system resolver or c-ares. Leaving it to the system resolver introduces platform differences because: * some support IDNA 2008 * some only IDNA 2003 (glibc until 2.28), and * some don't support IDNA at all (musl libc) c-ares doesn't support IDNA either although curl does, by virtue of linking against libidn2. Upgrading from libidn1 to libidn2 in order to get proper IDNA 2008 support was the fix for curl's CVE-2016-8625. libidn2 is not an option (incompatible license) but ICU has an IDNA API and we already use that in one place. For non-ICU builds, we fall back to the bundled punycode.js that also supports IDNA 2008. Fixes: nodejs-private/security#97 Fixes: nodejs#25558
Before this commit, Node.js left it up to the system resolver or c-ares. Leaving it to the system resolver introduces platform differences because: * some support IDNA 2008 * some only IDNA 2003 (glibc until 2.28), and * some don't support IDNA at all (musl libc) c-ares doesn't support IDNA either although curl does, by virtue of linking against libidn2. Upgrading from libidn1 to libidn2 in order to get proper IDNA 2008 support was the fix for curl's CVE-2016-8625. libidn2 is not an option (incompatible license) but ICU has an IDNA API and we already use that in one place. For non-ICU builds, we fall back to the bundled punycode.js that also supports IDNA 2008. Fixes: https://github.com/nodejs-private/security/issues/97 Fixes: #25558 PR-URL: #25679 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Saúl Ibarra Corretgé <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Currently the DNS module seems to utf-8 encode the names passed to c-ares for DNS resolution:
node/src/cares_wrap.cc
Line 1803 in 2c0a751
That doesn't work for internationalized domain names, which need to be IDNA encoded.
DNS is pretty much all ASCII, so IMHO Node shouldn't utf-8 encode on input.
Here is a list of international domain names to test.
This will produce an error:
Whereas the proper IDNA encoded version works:
The text was updated successfully, but these errors were encountered: