Repository navigation
DNS server caching breaks changing networks in runtime #14086
Description
Activity
Can you check, does this happen with versions prior to Node 8 as well?
- addedcaresIssues and PRs related to the c-ares dependency or the cares_wrap binding.Issues and PRs related to the c-ares dependency or the cares_wrap binding.
on Jul 5, 2017 This happens on Node 7.7.3 as well.
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.@XadillaX I don't understand your reply. Are you confirming what I said? Or are you saying there's no problem?
@elad I mean that maybe the problem is not occurred by
AresEnsureServersOh 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 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.@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.
- addeddnsIssues and PRs related to the dns subsystem.Issues and PRs related to the dns subsystem.feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Aug 12, 2018 - addedstalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.
on Dec 14, 2021 - addedstalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.and removedstalledIssues and PRs manually marked as stalled and scheduled for automatic closure.Issues and PRs manually marked as stalled and scheduled for automatic closure.
on 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.
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.
I'm experiencing an odd issue when resolving AAAA hostnames using the
dnsmodule as the network changes "below".Consider the following program:
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:
This happens because DNS servers are cached. I'm not too familiar with the code, but from briefly skimming through
src/cares_wrap.ccit seems thatAresEnsureServers()-- 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?