dns.resolve fails when the io/node process starts without an active network connection

[johnthedebs]

To reproduce:

1. Disable your Internet connection (this needs to be done first)

2. Start a io/node repl

3. Enter the following into the repl and note that it fails with ECONNREFUSED:

   var dns = require("dns");
   dns.resolve("google.com", function(err) { if (err) { console.log(err); } else { console.log("online"); }})

4. Re-enable your Internet connection

5. Run dns.resolve("google.com", function(err) { if (err) { console.log(err); } else { console.log("online"); }}) again, and note that it still fails

If the process starts before the Internet connection is disabled, it will work as expected once the connection is re-enabled.

For what it's worth, this bug doesn't affect dns.lookup (which according to the docs is implemented differently than dns.resolve).

[bnoordhuis]

I speculate that's because c-ares (the C library that powers dns.resolve()) reads /etc/resolv.conf once at start-up. If you start iojs when the network is disabled, /etc/resolv.conf is going to be empty.

I'm not sure if it's fixable. iojs doesn't know when the network comes back up and even if it did, it may not be trivial to reinitialize c-ares.

[silverwind]

I thought that /etc/resolv.conf thing was OS X only (in removes the symlink when network is down). Does Linux/BSD do that too?

[johnthedebs]

@silverwind Just tested on Ubuntu 14.04 64-bit with the same failure (original test was OS X 10.10.3).

[silverwind]

@johnthedebs What's the content of /etc/resolv.confwhen all interfaces are down? Does that file even exist?

[johnthedebs]

@silverwind It exists when all interfaces are disconnected, the contents are:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

[silverwind]

Right, thanks!

[imyller]

ares_reinit() has been on c-ares TODO list for a while (c-ares/c-ares@d2f21d3)

ares_reinit()
To allow an app to force a re-read of /etc/resolv.conf etc, pretty much
like the res_init() resolver function offers

[silverwind]

This might be another motivation for #1013

[yorkie]

ares_reinit might not address this issue, the problem is when we need to update the servers from resolv.conf file.

[imyller]

Yes, someone would have to call ares_reinit and know when to do it. By itself it solves nothing but is a prequisite feature for complete solution.

[yorkie]

Yup, without implemented ares_reinit() by current c-ares, we just can use setServers() to update servers for now, so it might be necessary :)

[silverwind]

Yeah, poll /etc/resolv.conf and use setServers if it's empty (Linux) or not there (OSX). I'm pretty sure such a hack wouldn't be accepted into core ;)

[bnoordhuis]

Correct, because parsing /etc/resolv.conf is not the only thing c-ares does.

[imyller]

I just published a package resolvmon to partially address this issue (https://www.npmjs.com/package/resolvmon, https://github.com/imyller/node-resolvmon).

It can be used to automatically monitor /etc/resolv.conf changes and updates Node runtime DNS server configuration accordingly. The package has no dependencies and requires io.js or Node.js 0.12+.

var resolvmon = require('resolvmon');
resolvmon.start(); // start monitoring
resolvmon.update(); // trigger manual update

Some features of resolvmon:

• Configurable location of resolv.conf (defaults to /etc/resolv.conf)
• Detect create, delete, modify/append, rename of resolv.conf
• Allows triggering manual update of DNS configuration with update() function
• The resolv.conf file does not have to exist at startup (for OSX) (missing file = no servers)
• All functions can be used synchrononously or asychronously (supports callback fns)
• resolvmon instance is also EventEmitter (emits any, update, error, stop, start events)

Obviously this does not replace full c-ares resolver configuration during ares_init(), but is helpful when running io.js in some cloud server instances with slow /etc/resolv.conf initialization after boot.

/cc @johnthedebs