[2008.09] resolv.conf

[Sarton O'Brien]

On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote:
> On Thu, 25 Sep 2008 18:45:32 +1000, roguemoko at roguewrt.org wrote:
> > Joel Newkirk wrote:
> >> So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver,
> >
> > but
> >
> >> does it by executing resolvconf.  Then eth0 comes up and tells
> >
> > resolvconf
> >
> >> its nameserver(s) - resolvconf decides which to use, likely eth0 will be
> >> set a higher priority than usb0.  Later eth0 goes down.  Now resolvconf
> >> automatically restores the nameserver settings from usb0.  (presuming it
> >
> > is
> >
> >> still up)  If usb0 went down already, but ppp0 over gprs came up in the
> >> meantime, nameservers for ppp0 go live.
> >
> > OK, so this resolvconf thing is inherited from debian and has been
> > implented obviously without much thought to general functionality. I say
> > this in the context of normal (non-debian) services functioning as
> > expected when not massaged by resolvconf.
> >
> > I understand the intention, don't get me wrong, and it is indeed a nice
> > idea. But when all people want to do is gain connectivity with their
> > chosen method, this resolvconf facility seems to be more of a hinderence
> > and is unlike a lot of linux distros. Shouldn't this, at least
> > currently, be optional?
> >
> > If something as fundamental as _core_ network services are going to be
> > overlayed with something like this, it should really be working first,
> > rather thaan people editing files left and right without understanding
> > why.
> >
> > This is just what I think, take it as you will. In the end I am the
> > master of my device ;)
> >
> > I've actually just done a bit of research before posting and it
> > _appears_ this was implemented with good intention, just without the
> > required software support. It seems to be very much of debian origins
> > and a little bit of overkill for managing the facilities on the
> > freerunner, but that's just my opinion. If I was currently using usb0,
> > eth0 and a tun/tap interface simultaneously, that all flapped or had
> > dynamic dns requirments (sounds more like a router) it would make sense
> > to me. I imagine the end goal is to consolidate gprs and wifi dns but
> > currently no resolvconf is going to teach people how to get that going.
> >
> > When om2008 is mature and these kind of connections can be made easily,
> > without much knowledge, this utility would be a godsend ... as it stands
> > you currently need basic linux knowledge to understand why things don't
> > work and then you need to know how to manipulate resolvconf.
> >
> > Maybe it's my BSD upbringing, thanks for the clarification however. :)
> >
> > Sarton
>
> 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