Repository navigation
DNS server caching breaks changing networks in runtime #14086
Description
- 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
addaleax commentedon Jul 5, 2017
Can you check, does this happen with versions prior to Node 8 as well?
elad commentedon Jul 5, 2017
This happens on Node 7.7.3 as well.
XadillaX commentedon Jul 7, 2017
In fact,
AresEnsureServers()will check a flag byenv->cares_query_last_ok()first. If your query is succeeded, next checking steps won't be executed.elad commentedon Jul 7, 2017
@XadillaX I don't understand your reply. Are you confirming what I said? Or are you saying there's no problem?
XadillaX commentedon Jul 7, 2017
@elad I mean that maybe the problem is not occurred by
AresEnsureServerselad commentedon Jul 7, 2017
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 commentedon Jul 9, 2017
@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 commentedon Jul 9, 2017
@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 commentedon Jul 10, 2017
@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 commentedon Dec 14, 2021
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 commentedon Jan 14, 2022
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.