-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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, src: add --preserve-dns-order flag with NODE_OPTIONS whitelist #17793
Conversation
Added flag with NODE_OPTIONS whitelist to allow preserving lookup order as retrieved from resolver. Still allows individual lookup requests with verbatim flag assigned explicitly to override the config flag. Open for suggestions on how to craft a test for this. Refs: nodejs#14731 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documented whitelisted options for NODE_OPTIONS
located in doc/api/cli.md
should also be updated. Probably also test/parallel/test-cli-node-options.js
.
@@ -3848,6 +3854,9 @@ static void ParseArgs(int* argc, | |||
} else if (strcmp(arg, "--expose-http2") == 0 || | |||
strcmp(arg, "--expose_http2") == 0) { | |||
// Keep as a non-op through v9.x | |||
} else if (strcmp(arg, "--preserve-dns-order") == 0 || | |||
strcmp(arg, "--preserve_dns_order") == 0) { | |||
config_preserve_dns_order = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most Node.js command line options only support the -
variants (i.e. --preserve-dns-order
). As this stands the other variant, --preserve_dns_order
, would be allowed on the command line but not in NODE_OPTIONS
.
@@ -3626,6 +3631,7 @@ static void CheckIfAllowedInEnv(const char* exe, bool is_env, | |||
"--pending-deprecation", | |||
"--no-warnings", | |||
"--napi-modules", | |||
"--preserve-dns-order", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need discussion for whether this should be added to --help output
Note the comments for the whitelist:
// Node options, sorted in `node --help` order for ease of comparison.
so if it's decided not to add this option to --help
then this option should be moved into another commented block (e.g. // Node options, not listed in 'node --help'
) before the V8 options.
I strongly dislike adding flags that override default behavior of API methods. I would have added it in the original PR if I thought a flag was a good idea. Strictly speaking it's not needed either because it can be monkey-patched with |
I can see the rationale for this but I'm also leaning against it for the same reason as @bnoordhuis. Specifically, providing command line args that override core API behavior is a bit of an anti-pattern. We've been forced to do it in a few other cases but there was strong reluctance there also. Using a preload script is a very under-appreciated and not-well-understood approach to handling the same issue. |
I can understand that you'd argue that having such args is kind of a anti-pattern since it switches default node behaviour. But on the other hand there should be a mechanism to switch dns resolution to an RFC3484 and host resolution compliant way without explicitily passing the family within all layers of libraries/application.
At least on linux glibc the dns reordering is already done by getaddrinfo based on ipv6 interface availability. |
The plan is to make |
Even if it lands in node 10 which is planned for Q2/2018 (when I get it right) there's So couldn't be the short term solution: |
May I ask... is the idea to conform to RFC3484 based on an enhancement, or just a behavior change to match the adoption of an emerging technology? In other words... might that behavior adjustment itself be backport-able? |
Is there any alternative for this patch? @bnoordhuis mentions some monkey patching. I'm a little bit unsure if/how it's easily possible. |
@asbachb Pretty easy: // Run like this: `node -r ./preload.js app.js`
'use strict';
const dns = require('dns'), {lookup} = dns;
dns.lookup = function(name, opts, cb) {
if (typeof cb !== 'function') return lookup(name, {verbatim:true}, opts);
return lookup(name, Object.assign({verbatim:true}, opts), cb);
}; |
Ping @jkantr |
@BridgeAR yep, still here. I can rewrite this PR but it seems that monkey patching In fact we should probably close this unless there's more to be discussed? @bnoordhuis |
I'll close it out. Thank you for taking the time to put together a pull request. |
Added flag with NODE_OPTIONS whitelist to allow preserving lookup order
as retrieved from resolver. Still allows individual lookup requests with verbatim
flag assigned explicitly to override the config flag.
Open for suggestions on how to craft a test for this.
Need discussion for whether this should be added to --help output
I will follow up with commit for documentation changes for dns.lookup(),
but not sure where else might require updating.
Refs: #14731 (comment)
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
dns, src