[2008.09] resolv.conf

Joel Newkirk freerunner at newkirk.us
Thu Sep 25 05:33:07 CEST 2008

On Thu, 25 Sep 2008 11:21:08 +1000, "Sarton O'Brien"
<roguemoko at roguewrt.org> wrote:
> On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote:
>> On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 <flyin.bbb8 at gmail.com>
>> wrote:
>> >>  In 2008.8 resolvconf didn't populate it
>> >> with the nameserver supplied by dhcp when the wifi interface was
> brought
>> >> up.
>> >> I don't know if this is still the case in 2008.9.
>> >
>> > hmm actually it always filled it in for me from DHCP when connectin to
>> > wifi
>> > using "ifdown eth0 && ifup eth0"  both in 2008.8 and in 2008.9
>> Both correct, actually, as it DOES fill it in from DHCP (if used)
>> connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do
> it,
>> it just overwrites resolv.conf.  The idea behind resolvconf (the bin) is
>> that IT manages changes to the resolv.conf file, doing things like
> removing
>> eth0-related DNS nameservers when eth0 goes down, going back to
>> usb0-related nameservers automatically.  ifup should feed DNS info to
>> resolvconf and let it manage.
>> Right now, I think DNS and default route changes when interfaces change
>> up/down need some attention from the 'just-works' dept.
> I still don't quite understand this confusion.
> udhcpc modifies /var/run/resolv.conf, as do I when needed. Any
> changing value/file should reside in volatile, in my opinion.
> /etc/resolv.conf has, for as long as I've been playing, symlinked to
> /var/run/resolv.conf.
> Except for the backend stuff not agreeing on this location, I have no
> issues,
> so long as udhcpc is used and an 'ip r d default' is issued prior to
> invocation.
> If the plan is that these values will be written to the filesystem, I'd
> say
> I'll be modifying mine to the contrary.
> Sarton

The program "resolvconf" is intended to work as follows: When an interface
comes up, resolvconf should be called to "-a" add new nameserver(s)
associated with the network connection on that interface.  When an
interface goes down resolvconf should get a "-d" delete nameserver(s) for
the specified interface.  

The program resolvconf itself is supposed to make any/all changes to
resolv.conf (wherever the actual file resides - the debian standard
location is /etc/resolvconf/run/resolv.conf, actually) NOT the script or
subsystem or network manager or whatever handles the up/down.  Based on its
configuration (notably /etc/resolvconf/interface-order - debian location)
it uses whatever nameserver settings are needed, but remembers the others.

So for example, usb0 coming up stuffs 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.


More information about the community mailing list