[2008.09] resolv.conf

[Joel Newkirk]

On Fri, 26 Sep 2008 10:24:18 +1000, "Sarton O'Brien"
<roguemoko at roguewrt.org> wrote:
> On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote:

>> IMHO the "simplest effective solution" should always head the list.  In
>> this instance I think that is to run dnscache or a similar service on
> the
>> Freerunner itself, pointing somewhere like opendns.com's servers. (ok,
>> maybe not simplest, though the local cache has various benefits.
> Pointing
>> resolv.conf at opendns.com or wherever is simplest, assuming no network
>> connection actually requires use of it's own DNS - corporate intranet
> wifi
>> might, to reach 'private' records for example)  If needed,
> newly-connected
>> network connections that come equipped with new DNS servers (IE, wifi
> with
>> DHCP) can insert/remove their DNS servers from the list used by
> dnscache,
>> while resolv.conf permanently points at 127.0.0.1.  This is what I've
> had
>> running for a few weeks, but I hadn't yet attempted to get ifup/ifdown
>> manipulating /etc/dnscache/root/servers/@. (which will essentially
> require
>> a resolvconf-like manager ;)
> 
> That all makes sense. Typically I've seen dnsmasq fulfill this function.
> 
> My point was merely that the current solution is added complexity to a
> rather
> neat base filesystem. If this was a package I wouldn't have the same
> gripe.
> 
> Using dnsmasq, pointing at localhost, including opendns and using helper
> scripts to insert and remove dns servers sounds less complex and less
> confusing, with the added benefit of caching and less modification to the
> base
> system. It also means not having to incorporate something that doesn't
> appear
> to have had the modifications needed _to_ incorporate it.
> 
> I don't like the requirement that all the software modifying network
> settings
> needs to be resolvconf aware. If we had a generic central solution people
> could use whatever they want and not incur breakage ...
> 
> Worst case, something like a resolv.conf pipe to a daemon that updates
> resolv.conf.auto for dnsmasq would be better. Something central!
> 
> Looking at the way resolvconf works, it almost seems like we should be
> patching libc :S ...so we have a generic interface.
> 
> Anyway ... I can feel fork coming on :P
> 
> Sarton

hmmm.  I've been thinking on the situation, and have a proposal, as yet
incomplete but IMHO promising - and it's nowhere near as drastic as
forking.  I see basically two approaches:  One is an overarching network
manager directly handling all the details, the other (my preferred) is to
let DNS take care of itself independently, and address the
multiple-default-route issue - probably with route metrics, though more
advanced routing setup (requiring full "ip" binary instead of busybox) with
multiple routing tables and rules is probably the "better" solution there.

It starts with dnscache.  Postinst in dnscache ipk removes the symlink
/etc/resolv.conf and replaces it with a real file, pointing always at
nameserver 127.0.0.1.  (what I had going already)

On my Ubuntu desktop, there's a possibly-useful file:
/etc/resolvconf/update.d/dnscache - its purpose is to alter
/etc/dsncachce/root/servers/@ (the list of servers dnscache is to query for
anything uncached) automatically whenever resolvconf is triggered.  This
would be the way to hook in if resolvconf were working on the Freerunner as
intended, which currently appears not to be the case.

Alternately (or additionally), /etc/network/if-up.d/ and
/etc/network/if-post-down.d/ allow us to perform the same changes
automatically whenever an interface is brought up or taken down using ifup
and ifdown.

I've altered my /etc/init.d/dnscache script to include a 'refresh' feature,
that first wipes /etc/dnscache/root/servers/@, then stuffs in any
non-localhost nameservers presently listed in /etc/resolv.conf, then adds
any nameservers found in /etc/resolvconf/run/resolv.conf, finishing up with
any IPs listed in /etc/default/dnscache (default contents opendns.com IPs),
wipes /etc/resolv.conf back to localhost only, then finally kicks dnscache
so it uses the new servers/@ contents.

Once my freerunner is back in front of me I'll test the init script changes
- if it works as I hope, I can add a script to the ipk in each of
/etc/network/if-up.d/ and /etc/network/if-post-down.d/ that simply call
"/etc/init.d/dnscache refresh", and/or in /etc/resolvconf/update.d/.  That
makes the whole thing "just work" as a single ipk installing dnscache and
all the support to override resolvconf AND 'manual' nameserver updates
implemented by ifup/ifdown. If resolvconf is discarded it will work fine,
just need added logic in the postrm script in the dnscache ipk to recognize
resolvconf's absence and restore a basic /etc/resolv.conf instead of trying
to restore the symlink.

BTW: dnscache vs dnsmasq. I'm far more familiar with dnscache, so I'd lean
toward it for that reason, but additionally dnsmasq incorporates a dhcp
server - seems a waste for a more-or-less default setup.  If dhcp server on
the Freerunner is actually desired, it would likely be accompanying support
for use of the Freerunner as a gateway router, so IMHO dhcp-server can be
dealt with in that specific context.  (until DJ Bernstein recently recanted
the license on dnscache/djbdns it wasn't an option, but now distributing
binaries is permitted)

Comments?  Suggestions?  Flames?

j