Re: boot ordering and resolvconf
Ian Jackson wrote:
> The two designs lead to different sets of fixes.
>
> A. resolv.conf is a static file which changes only very rarely.
> Implications:
> 1. Existing DNS client applications do not need to change.
> 2. DNS service should always be provided at a fixed address
> 3. Therefore in the default installation this address should
> refer to localhost. Otherwise it cannot be redirected later
> as the network environment or installed package set changes.
> 4. Therefore in most installations there should be a local
> proxy or cache. It should use DHCP-provided, PPP-provided or
> similar, as a forwarder. The local DNS provider address
> should be owned by whatever proxy or cache is installed.
>
> B. resolv.conf is not static and may change due to network
> environment changes.
> Implications:
> 1. All existing DNS applications must be modified to notice
> changes to resolv.conf.
> 2. Corollary: all existing DNS resolver libraries must be
> so modified.
> 3. This will be impractical unless a common mechanism with
> a convenient interface (and low impact on the rest of a
> program) is provided. Hopefully resolvconf fits this bill.
>
> I don't know exactly how impractical B2 is. The libc's resolver is
> probably a hard case because of the libc's low level in the protocol
> stack. Can we make it aware of resolvconf ?
Resolvconf supports both mode A and mode B and allows switching between them. With resolvconf installed, (A) so long as a local forwarding nameserver is running, resolv.conf points to this nameserver and thus rarely changes; but (B) if no
local forwarding nameserver is running and the network environment changes then resolv.conf is updated and client applications are notified via resolvconf hook scripts in /etc/resolvconf/update.d/ and /etc/resolvconf/update-libc.d/. Even
clients without resolvconf hook scripts make use of the latest resolv.conf information because eglibc was enhanced two years ago to watch the mtime of /etc/resolv.conf and re-initialize the resolver state when it changes. Because of this,
I am not aware that there is anything (except perhaps ntpd) that needs to be fixed.
> The difficulty with plan A is probably B4. Do we have a suitable
> minimal proxy we can install, a way to reconfigure it based on dhcp
> etc., and a means to displace it when something more substantial like
> unbound is installed ?
Resolvconf supports the use of dnsmasq, pdnsd and djbdns dnscache as local forwarding nameservers and reconfigures them based on input from DHCP clients, ifup and NetworkManager. Support for bind9 and unbound could easily be added (see
bug report #483098).
--
Thomas Hood
resolvconf maintainers
Reply to: