[2008.09] resolv.conf

Joel Newkirk freerunner at newkirk.us
Thu Sep 25 14:06:29 CEST 2008


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 ;)

j






More information about the community mailing list