Re: dnsmasq integration?

[Paul Smith <paul mad-scientist net>]

On Fri, 2011-01-07 at 22:37 +0100, Michael Biebl wrote:
> Am 07.01.2011 17:13, schrieb Uwe Geuder:
> > 
> > On Ubuntu Lucid I solved the dnsmasq - nm integration as follows:
> > 
> > - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1
> > 
> > - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf
> >   (I'm willing to share the patch if anybody is interested. I haven't
> >   done so, because it's not 100% perfect, see below) 
> > 
> > - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never
> >   be changed (*)
> 
> Or you can simply install resolvconf + dnsmasq without any patching.
> 
> Should basically work the same way: /etc/resolv.conf contains 127.0.0.1
> and remains static. NM pushes DNS updates to resolvconf, which in turn
> pushes those updates to dnsmasq.

Sure... but the problem with resolvconf is it only works if ALL the
facilities that manipulate /etc/resolv.conf are modified to use
resolvconf instead.

Sadly, this is not the case; not even all the NetworkManager components
grok resolvconf (for example, openconnect doesn't work properly with
resolvconf).

And beyond that there's a whole suite of proprietary VPN solutions which
certainly don't know to do anything except "overwrite /etc/resolv.conf".

Plus, resolvconf is only available in Debian and derived distros like
Ubuntu; there's no support in Red Hat/Fedora/etc. that I can find, which
means that it will never (IMO) be a complete solution.

In short, there's no really robust (in the face of all the different
network utilities and their idiosyncracies) way to handle this today.

What I attempted to do was write a script (Perl) that used inotify to
watch /etc/resolv.conf and whenever it was changed my script would swoop
in, figure out what changes were made, and rework my dnsmasq-based local
proxy DNS server configuration to represent those changes, then write a
new simplified /etc/resolv.conf.

This works, actually... until it doesn't.  It turns out that too many
utilities are just too badly behaved to allow this to work automatically
in a robust way.  And yes, this includes NetworkManager (see my bug
where, when an interface goes down, NetworkManager recreates the
resolv.conf file completely from scratch based only on the interfaces it
knows about... destroying any resolv.conf elements like search domains
that were added by other tools such as proprietary VPN tools).

I do think that resolvconf has absolutely the right CONCEPT, where it
segregates individual resolv.conf-style files for each interface.  The
idea that each interface has its own search paths, nameservers, etc. is
spot-on; I wish NetworkManager kept that kind of distinction internally.
But the requirement that /etc/resolv.conf be a symlink is simply not
workable in the face of proprietary tools that feel entitled to stomp
resolv.conf as they like.  We can say that we don't care about that kind
of software... except that people wanting to switch to Linux almost
never have any kind of say into the VPN solutions that their companies
choose.


If you want to REALLY know what I think, I think that the best solution
is to rewrite libresolv so that instead of reading /etc/resolv.conf, it
reads a list of files in /etc/resolv.d (for example), one for each
interface, each of which was a resolv.conf-style formatted file.  It
could also read /etc/resolv.conf for backward-compatibility.  Each of
these would be maintained separately internally to the resolver, not
combined into one big list, so that hostnames associated with a given
search domain would be resolved only by the nameservers associated with
the /etc/resolv.d file containing that domain, etc.  There are still
issues, of course, such as ordering of nameservers used for reverse
lookups and what happens if search domains overlap, but these are
solvable.

This would remove the need for resolvconf, it would remove the need to
run a local dnsmasq proxy server, etc.  Even then, though, we'll need a
method for handling legacy applications.  But I think it could be done
and if Linux could just get to one true, complete solution for this
problem rather than a lot of different "kind of" solutions it would be a
lot easier to get the proprietary vendors to help out.