[2008.09] resolv.conf

[roguemoko at roguewrt.org]

On Fri, Sep 26, 2008 at 12:07:17AM -0400, Joel Newkirk wrote:
> 
> 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?


I've been discussing this with a mate who showed some interest in the
dillema.

Every time we thought we had something there was a small gotcha,
primarily that the requirement for the dns/metric change stems from 
the aquisition of a dhcp lease and in turn the addition of new routing
and dns info. As the aquisition can occur outside of linkstate, 
meaning the link can be active but no dhcp client associated, actioning
based on interface status didn't seem valid, or at least a little
premature or a little too assuming.

So to us, the primary flag for action was the aquisition of a lease.

Seeing as we are generally dealing with on the fly network association
we didn't bother taking into account static assignment.

We also figured that the general rule of thumb for metric would be:

1 - wired
2 - wireless
3 - vpn/tap/tun

Which should be configurable anyway. Something easy to implement that
can be expanded on is the idea.

With that in mind and without altering udhcpc to populate an alternate
resolv.conf (avoiding modifications to generic network tools completely),
it seems the process should go something like:

* obtain lease
* read resolv.conf
* create lookup (iface, ip, metric, searchdomain, dns1, dns2)
* recreate resolv.conf from lookup and config file
* modify routing table

We avoided dealing with a cache purely because it will generally
conflict with generic dhcpc function, we were trying to wrap rather
than reconfigure. In saying that, a config file could determine
whether 127.0.0.1 is written/rewritten and an alternate resolv.conf
updated. So the caching daemon could be easily incorporated.

Removal from the lookup should possibly be based on linkstate.

As with any detailed process, the hardest part was trying to figure
out just how to start ... where and how to watch for the change and
the most cost effective way. The process is relatively simple.

I don't suppose there is dhcp client dbus integration as standard?

Being notified rather than polling would be good.

Anyway ... that's where we got to. The overall benefit from our
perspective was that we could use something like this on any
*nix-like operating system that we have. Also the typical ifwatchd
and wpa_supplicant delays would not have any effect.

Outside of all that, I know netbsd has had some work done to the
dhcp client to allow multiple instances to communicate via a socket,
so maybe something like this is actually being incorporated into the
dhcp client code, which would make sense as it really is, all-in-all, a
side effect of using dhcp in the first place. It would be nice to see
something provided by ISC.

I think I've rambled on long enough ... :)

Sarton