DNS server caching breaks changing networks in runtime

[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?

[addaleax]

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

[elad]

This happens on Node 7.7.3 as well.

[XadillaX]

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.

[elad]

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

[XadillaX]

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

[elad]

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.

[elad]

@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...

[addaleax]

@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.

[elad]

@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.

[github-actions]

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.

[github-actions]

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.