[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: boot ordering and resolvconf



On Fri, Jun 28, 2013 at 05:02:51PM +0200, Thomas Hood wrote:
> 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,

The issue here is not resolvconf being inflexible. The issue at hand is
that different packages expect different and incompatible modes of
operation.

In addition resolvconf does not properly support mode (A), due to the
"local forwarding nameserver is running" requirement. It can leave
/etc/resolv.conf empty until the name server is actually started. In the
context of systemd this will break socket activation as a means of
avoiding dependencies and either make Debian broken (like ntpd) or
incompatible (due to added dependencies) with the rest of the world.

> I am not aware that there is anything (except perhaps ntpd) that needs to be fixed.

It is true, that ntpd can work around this issue. Still it appears like
a bad design to treat EAI_SYSTEM as a temporary error. Sometimes it is,
other times it is not. How many upstreams will handle this correctly and
try again? Searching codesearch.d.n for EAI_SYSTEM and EAI_AGAIN can
give you a rough idea.

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

As far as I can tell the unbound part works very well on wheezy already.
Well except for ntpd not noticing.

Helmut


Reply to: