On 24/10/12 18:59, Dan Williams wrote: > > One problem we ran into with NM, and why I posted the patch for the new > D-Bus interface call, was that updated DNS configuration is *not* > re-read on HUP. That means that whenever we change nameservers as a > result of DHCP renewal, connection of a VPN, or some other thing that > updates DNS, we need to either (a) use the D-Bus interface or (b) > respawn dnsmasq. Unfortunately there's a small window when respawning > dnsmasq where name queries could get lost or prematurely terminated, and > that's actually been a problem in the real world. In these cases we're > running dnsmasq as a local caching nameserver, so > re-reading /etc/resolv.conf would only ever return 127.0.0.1 and thus > that part isn't relevant. > > Obviously if we're using D-Bus now this isn't a problem, but might be > worthwhile to re-read DNS server/domain info on HUP to for other users.
This is a good example of the pitfalls: it possible to specify the local address and port used to contact a server, thus: server=192.168.0.1@192.168.100.1#800 which ensures that queries sent to 192.168.0.1 have a source address 192.168.100.1 port 800. 192.168.100.1 has to be an address in local machine obviously. Clearly adding a new server spec of this type has the potential to fail: 192.168.100.1 might not exist on a local interface, or something else may be listening on port 800. There's an additional problem: if the port is <1024, then the configuration will work fine when dnsmasq first starts and the bind() calls are done as root, but fail if the configuration is re-read, since the bind() calls then are done as an unprivileged user. Just to add to the noise, on some platforms (Linux, Solaris) bind() won't fail, because dnsmasq retains the CAP_NET_ADMIN capability. Other platforms don't allow this, so it breaks. It would be possible to add the equivalent of dhcp-optsfile and dhcp-hostsfile, which get re-read on SIGHUP but source-addresses should not be supported in those. They should probably not be provided in the new DBus call either, for the same reason. Cheers, Simon. > > Dan > > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
