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

(v6.x backport) dns: fix resolve failed starts without network #14434

Closed
wants to merge 5 commits into from

Conversation

XadillaX
Copy link
Contributor

@XadillaX XadillaX commented Jul 23, 2017

Refs: #13076

Fix the bug that you start process without network at first, but it connected lately, dns.resolve will stay failed with ECONNREFUSED because c-ares servers fallback to 127.0.0.1 at the very beginning.

If c-ares servers "127.0.0.1" is detected and its not set by user self, and last query is not OK, recreating ares_channel operation will be triggered to reload servers.

You can test with this script:

const dns = require("dns");

function test() {
    dns.resolve("google.com", function(err, ret) {
        console.log(err, ret, dns.getServers());
        setTimeout(test, 10000);
    });
}

test();

Turn off your network at first before starting this script. Then try to open the network and then turn off. Make the steps above in a loop and you will get the result.

Fixes: #1644

refack: added ref to original PR

Checklist
Affected core subsystem(s)

dns

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. cares Issues and PRs related to the c-ares dependency or the cares_wrap binding. v6.x labels Jul 23, 2017
Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

sam-github and others added 3 commits August 1, 2017 02:08
For consistency with 4.x and 8.x.

This commit also contains a forward port of
nodejs#14232 to confirm that 4.x and 6.x
behave identically with respect to the port argument.

PR-URL: nodejs#14234
Refs: nodejs#14205
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Sam Roberts <[email protected]>
root_cert_vector currently has file scope and external linkage, but is
only used in the NewRootCertsStore function. If this is not required to
be externally linked perhaps it can be changed to be static and function
scoped instead.

PR-URL: nodejs#12788
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Shigeki Ohtsu <[email protected]>
root_cert_store is defined as extern in node_crypto.h but only used in
node_crypto.cc. It is then set using SSL_CTX_set_cert_store. The only
usages of SSL_CTX_get_cert_store are in node_crypto.cc which would all
be accessing the same X509_STORE through the root_cert_store pointer as
far as I can tell. Am I missing something here?

This commit suggests removing it from the header and making it static
in node_crypto.cc.

PR-URL: nodejs#13194
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Sam Roberts <[email protected]>
hashseed and others added 2 commits August 3, 2017 14:28
Original commit messages:
v8/v8@a2ab135
  [snapshot] Rehash strings after deserialization.

  See https://goo.gl/6aN8xA

  Bug: v8:6593
  Change-Id: Ic8b0b57195d01d41591397d5d45de3f0f3ebc3d9
  Reviewed-on: https://chromium-review.googlesource.com/574527
  Reviewed-by: Camillo Bruni <[email protected]>
  Reviewed-by: Jakob Gruber <[email protected]>
  Reviewed-by: Ulan Degenbaev <[email protected]>
  Commit-Queue: Yang Guo <[email protected]>
  Cr-Commit-Position: refs/heads/master@{nodejs#46732}

v8/v8@182caaf
  Do not track transitions for built-in objects.

  Objects created during bootstrapping do not need
  a transition tree except for elements kind transitions.

  Bug: v8:6596
  Change-Id: I237b8b2792f201336e1c9731c815095dd06bc182
  Reviewed-on: https://chromium-review.googlesource.com/571750
  Reviewed-by: Igor Sheludko <[email protected]>
  Commit-Queue: Yang Guo <[email protected]>
  Cr-Commit-Position: refs/heads/master@{nodejs#46693}

Fixes: nodejs#14171
PR-URL: nodejs#14385
Fix the bug that you start process without network at first, but it
connected lately, `dns.resolve` will stay failed with ECONNREFUSED
because c-ares servers fallback to 127.0.0.1 at the very beginning.

If c-ares servers "127.0.0.1" is detected and its not set by user self,
and last query is not OK, recreating `ares_channel` operation will be
triggered to reload servers.

Fixes: nodejs#1644
@XadillaX XadillaX force-pushed the backport-13076-to-6.x branch from 93a64de to b706569 Compare August 10, 2017 06:47
@XadillaX
Copy link
Contributor Author

@addaleax @refack I've rebased the code.

@XadillaX
Copy link
Contributor Author

@MylesBorins
Copy link
Contributor

MylesBorins commented Aug 11, 2017

quick CI of v6.x-staging to compare windows failures

https://ci.nodejs.org/job/node-test-commit/11715/

@MylesBorins
Copy link
Contributor

landed in 3d052ca80c

MylesBorins pushed a commit that referenced this pull request Aug 14, 2017
Fix the bug that you start process without network at first, but it
connected lately, `dns.resolve` will stay failed with ECONNREFUSED
because c-ares servers fallback to 127.0.0.1 at the very beginning.

If c-ares servers "127.0.0.1" is detected and its not set by user self,
and last query is not OK, recreating `ares_channel` operation will be
triggered to reload servers.

Fixes: #1644
Backport-PR-URL: #14434
PR-URL: #13076
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@MylesBorins
Copy link
Contributor

landed in 4967e93

MylesBorins pushed a commit that referenced this pull request Aug 14, 2017
Fix the bug that you start process without network at first, but it
connected lately, `dns.resolve` will stay failed with ECONNREFUSED
because c-ares servers fallback to 127.0.0.1 at the very beginning.

If c-ares servers "127.0.0.1" is detected and its not set by user self,
and last query is not OK, recreating `ares_channel` operation will be
triggered to reload servers.

Fixes: #1644
Backport-PR-URL: #14434
PR-URL: #13076
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
MylesBorins pushed a commit that referenced this pull request Aug 16, 2017
Fix the bug that you start process without network at first, but it
connected lately, `dns.resolve` will stay failed with ECONNREFUSED
because c-ares servers fallback to 127.0.0.1 at the very beginning.

If c-ares servers "127.0.0.1" is detected and its not set by user self,
and last query is not OK, recreating `ares_channel` operation will be
triggered to reload servers.

Fixes: #1644
Backport-PR-URL: #14434
PR-URL: #13076
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. cares Issues and PRs related to the c-ares dependency or the cares_wrap binding.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants