Skip to content

DNS server caching breaks changing networks in runtime #14086

Description

@elad
  • Version: 8.1.3
  • Platform: macOS Sierra
  • Subsystem: DNS

I'm experiencing an odd issue when resolving AAAA hostnames using the dns module as the network changes "below".

Consider the following program:

const dns = require('dns');

setInterval(() => {
  dns.resolve('www.google.com', 'AAAA', (err, records) => { console.log(err, records); });
}, 1000);

If I run this program while connected to an IPv6 network, it works. If I run this program while connected to an IPv6 VPN, it also works.

However, if I run this program while connected to an IPv6 network and while it runs connect to the IPv6 VPN, I get the following output:

$ node test.js
null [ '2a00:1450:400e:800::2004' ]
[...a lot of these...]
{ Error: queryAaaa ECONNREFUSED www.google.com
    at errnoException (dns.js:50:10)
    at QueryReqWrap.onresolve [as oncomplete] (dns.js:235:19)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'queryAaaa',
  hostname: 'www.google.com' } undefined
[...a lot of these...]

This happens because DNS servers are cached. I'm not too familiar with the code, but from briefly skimming through src/cares_wrap.cc it seems that AresEnsureServers() -- which is called before each query to ensure DNS servers are available -- immediately returns under certain circumstances that are true in the above case and probably many other.

While I don't suggest disabling DNS server caching, it seems that there's no way to get DNS working in the scenario I described. At the very least, maybe there should be a function to force flushing of the DNS server cache? (e.g. dns.flush()) Alternatively, am I missing something and there is a way to get this to work?

Activity

  1. addaleax commented on Jul 5, 2017

    @addaleax
    Member

    Can you check, does this happen with versions prior to Node 8 as well?

  2. added
    caresIssues and PRs related to the c-ares dependency or the cares_wrap binding.
    on Jul 5, 2017
  3. elad commented on Jul 5, 2017

    @elad
    Author

    This happens on Node 7.7.3 as well.

  4. XadillaX commented on Jul 7, 2017

    @XadillaX
    Contributor

    In fact, AresEnsureServers() will check a flag by env->cares_query_last_ok() first. If your query is succeeded, next checking steps won't be executed.

  5. elad commented on Jul 7, 2017

    @elad
    Author

    @XadillaX I don't understand your reply. Are you confirming what I said? Or are you saying there's no problem?

  6. XadillaX commented on Jul 7, 2017

    @XadillaX
    Contributor

    @elad I mean that maybe the problem is not occurred by AresEnsureServers

  7. elad commented on Jul 7, 2017

    @elad
    Author

    Oh I didn't mean to imply there's a problem with it, just that maybe we need a way to "force" it to run.

  8. elad commented on Jul 9, 2017

    @elad
    Author

    @addaleax @XadillaX I'd really like to move forward with fixing this issue. It's big enough that unless fixed we'll have to switch language. :) I'm willing to write the necessary code, but need to know first if there's a consensus this is indeed a bug and what an acceptable fix would be...

  9. addaleax commented on Jul 9, 2017

    @addaleax
    Member

    @elad I’m not sure anybody has strong opinions on this. If I understand you, basically what you want is to extend dns.setServers() to allow (re)seting to the current default server list, which seams like a reasonable feature to me.

  10. elad commented on Jul 10, 2017

    @elad
    Author

    @addaleax this problem might deserve a bit more attention... I tested the same program (loop of DNS queries) while switching WiFi networks, and the DNS queries just stop returning (that is, the callback is never called).

    I'm not sure what I want is to extend dns.setServers() because I'd argue we don't really know what the servers should be and ideally we shouldn't if Node/c-ares can figure that on its own.

    I'll clear some time and see if the fix I have in mind will help either of the issues.

  11. added
    dnsIssues and PRs related to the dns subsystem.
    feature requestIssues requesting new Node.js features.
    on Aug 12, 2018
  12. added
    stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.
    on Dec 14, 2021
  13. added
    stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.
    and removed
    stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.
    on Dec 14, 2021
  14. github-actions commented on Dec 14, 2021

    @github-actions
    Contributor

    This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

  15. github-actions commented on Jan 14, 2022

    @github-actions
    Contributor

    Closing this because it has stalled. Feel free to reopen if this issue/PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    caresIssues and PRs related to the c-ares dependency or the cares_wrap binding.dnsIssues and PRs related to the dns subsystem.feature requestIssues requesting new Node.js features.stalledIssues and PRs manually marked as stalled and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions