Drop --strict-order; dnsmasq is intelligent enough to ask nameservers in
an order that makes the best of possibly slow nameservers (or broken ones),
and interrogating them in strict order breaks this.
Add --no-hosts: by default dnsmasq will read /etc/hosts as a list of things
to resolve statically; this is something we want to avoid as nsswitch.conf
already lists files as the first data store to look at; where the entries
in /etc/hosts will already have been returned if that's what the user wants
to see. If the /etc/hosts file then changes, dnsmasq would have to be restarted
before the user would get the new value resolved externally. Avoid this, let
/etc/hosts override DNS entries normally through the resolver and show
changes as soon as the file is updated.
All of the information in the configuration files for local caching
dnsmasq or BIND servers are accessible already over the D-Bus
interface, so there's no sensitive information here.
inet_ntop() either returns 'address%interface' or just 'address'. In the first
case, we replace '%' with '@' since dnsmasq supports '%' only since version
2.58. In the second case, we append '@interface' to make it work.
(small fixes by dcbw)
If any ethernet devices were left up (because we can assume control
over them seamlessly when NM starts up again) make sure we write
out a usable resolv.conf for the device on shutdown, otherwise the
users networking is broken with an empty resolv.conf. This only
happened when DNS plugins were active, in which case the user
would be left with a localhost-pointing resolv.conf but no
local caching nameserver running since NM shut it down when NM
terminated.
When split DNS is used for a local caching nameserver, make sure
that reverse DNS queries for hosts within the VPN tunnel are directed
to the VPN's nameservers, not to the public upstream nameservers.
config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii. So wherever we use those, we need
to make sure config.h is included.
It's still got a bunch of issues that need debugging, like when VPN
nameservers exist but no domain and thus not doing split DNS, sometimes
hosts outside the VPN don't resolve correctly, which was previously
masked by having the non-VPN nameservers in /etc/resolv.conf where
glibc would erroneously use them instead of asking BIND. To be fixed
in a subsequent patch.
The dnsmasq plugin seems to work great though.
If all nameservers are listed in resolv.conf, glibc apparently
tries them all (even if 'options rotate' isn't specified??). Leading
to queries for internet hosts being directed to VPN-specific DNS
servers in split-DNS situations. I've verified this with wireshark;
I see queries going out over the tunnel to VPN nameservers for
non-internal addresses, while BIND itself never logs anything about
queries to VPN nameservers for that same address. Thus the only
thing left is to blame glibc...
Despite most guides saying that without restricting to port 53 queries
won't get through a firewall, I cannot make it work with this option.
DNS queries through a WRT54G just time out even when the WRT54G isn't
caching anything itself (ie, explicit upstream nameservers are the
forwarders in the bind config).
This was supposed to hook up to the bits Adam Langley did last year
for his local-dns-cache DBus service, but I misunderstood the
architecture. It was a separate service, not Chromium itself. But
it's unclear what happened to his local-dns-cache since the project
doesn't seem to have any commits in a year and I'm unsure if it's
actually being used. So remove this stuff for now.
Use a pseudo-hash to quickly check whether the DNS config has really
changed or not. This is certainly better than the 500 line patch I
did then scrapped in favor of this approach... yay. This helps ensure
that we don't kill then respawn caching DNS servers more often than
we have to.
If the VPN client didn't provide a domain we still want to use the
VPN nameservers first, we just can't do split DNS. Also use
--strict-order to ensure VPN nameservers are always chosen first.
