8000 dns: idna encode hostnames before resolution by santigimeno · Pull Request #25559 · nodejs/node · GitHub
[go: up one dir, main page]
Skip to content

dns: idna encode hostnames before resolution #25559

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.

Sign up for GitHub

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

Jump to bottom
Closed
santigimeno wants to merge 4 commits into from
Closed

dns: idna encode hostnames before resolution #25559

santigimeno wants to merge 4 commits into from

Conversation

@santigimeno
Copy link
Member
@santigimeno santigimeno commented Jan 18, 2019

Fixes: #25558

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot
Copy link
Collaborator
nodejs-github-bot commented Jan 18, 2019

@santigimeno build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2281/pipeline

@nodejs-github-bot nodejs-github-bot added the dns Issues and PRs related to the dns subsystem. label Jan 18, 2019
@santigimeno santigimeno mentioned this pull request Jan 18, 2019
Closed
targos
targos reviewed Jan 18, 2019
View reviewed changes
lib/dns.js Outdated
throw new ERR_INVALID_CALLBACK();
}

name = toASCII(name, true);
Copy link
Member
@targos targos Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function can theoretically throw in

node/lib/punycode.js

Line 335 in 2c0a751

error('overflow');
. Do we need to handle it?

Copy link
Member Author
@santigimeno santigimeno Jan 18, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk, if so, shouldn't we also handle it here to be lenient whether it uses icu or punycode?

Copy link
Member
@targos targos Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

url.parse is synchronous so it's less of an issue. Here the error could only lead to an uncaught exception.

Copy link
Member Author
@santigimeno santigimeno Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to ignore exceptions. Thanks

@targos
Copy link
Member
targos commented Jan 18, 2019

/cc @saghul @cjihrig @bnoordhuis

saghul
saghul reviewed Jan 18, 2019
View reviewed changes
Copy link
Member
@saghul saghul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple of comments. I think the C++ code which does the utf-8 decoding also needs to go, it should assume ASCII, and throw on failure.

lib/dns.js

const cares = internalBinding('cares_wrap');
const { toASCII } = internalBinding('config').hasIntl ?
internalBinding('icu') : require('punycode');
Copy link
Member
@saghul saghul Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the policy here, considering punycode is deprecated?

Copy link
Member Author
@santigimeno santigimeno Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know 🤷‍♂️

Copy link
Contributor
@cjihrig cjihrig Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, we do the same thing in lib/url.js, so it's probably fine.

Copy link
Member
@jasnell jasnell Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using punycode is the fallback if Node.js is compiled without ICU.

Copy link
Contributor
@silverwind silverwind Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's only deprecated for userland.

lib/dns.js
throw new ERR_INVALID_CALLBACK();
}

try {
Copy link
Member
@saghul saghul Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be needed if we were only using the ICU based toASCII?

Copy link
Member Author
@santigimeno santigimeno Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My guess is no

@saghul
Copy link
Member
saghul commented Jan 18, 2019

Thanks for picking this up @santigimeno ❤️

@santigimeno
Copy link
Member Author
santigimeno commented Jan 18, 2019

I think the C++ code which does the utf-8 decoding also needs to go, it should assume ASCII, and throw on failure

I'm not sure you can remove the node::Utf8Value name(env->isolate(), string); code as it's needed to convert a Local<String> into a const char*

@saghul
Copy link
Member
saghul commented Jan 18, 2019

I'm not sure you can remove the node::Utf8Value name(env->isolate(), string); code as it's needed to convert a Local<String> into a const char*

Isn't there an equivalent that does the job in ASCII instead?

@santigimeno
Copy link
Member Author
santigimeno commented Jan 18, 2019

Isn't there an equivalent that does the job in ASCII instead?

I don't know, but what's the issue being ASCII a subset of UTF-8?

silverwind
silverwind reviewed Jan 18, 2019
View reviewed changes
test/common/internet.js
// An accessible IPv4 DNS server
DNS6_SERVER: '2001:4860:4860::8888'
DNS6_SERVER: '2001:4860:4860::8888',
IDNA_HOST: 'españa.icom.museum'
Copy link
Contributor
@silverwind silverwind Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

domaintest.みんな might be a better testing domain name, info here.

Copy link
Member
@saghul saghul Jan 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 also, I'd say a comment is missing.

8000

@bnoordhuis
Copy link
Member
bnoordhuis commented Jan 21, 2019

@santigimeno Do you have access to node-private? Because this PR is a spiritual duplicate of https://github.com/nodejs-private/node-private/pull/147 :)

@santigimeno
Copy link
Member Author
santigimeno commented Jan 21, 2019

Do you have access to node-private?

Not really, first time I hear about that repo. Feel free to close this if it's already handled there.

@bnoordhuis bnoordhuis mentioned this pull request Jan 24, 2019
Closed
@bnoordhuis
Copy link
Member
bnoordhuis commented Jan 24, 2019

@santigimeno Sorry for the delay, Santi. I've moved it to #25679.

@santigimeno
Copy link
Member Author
santigimeno commented Jan 24, 2019

Closing in favor of #25679. Thanks for the heads up Ben.

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

Reviewers

@targos targos targos left review comments

@cjihrig cjihrig cjihrig left review comments

@jasnell jasnell jasnell approved these changes

+2 more reviewers

@silverwind silverwind silverwind left review comments

@saghul saghul saghul left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

dns Issues and PRs related to the dns subsystem.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

DNS resolution fails for internationalized domain names

8 participants

@santigimeno @nodejs-github-bot @targos @saghul @bnoordhuis @silverwind @jasnell @cjihrig
0