Re: boot ordering and resolvconf

[Thomas Hood <jdthood@gmail.com>]

Ian Jackson wrote:

I think the first thing to do is recognise the underlying problem.  To
fix this problem properly we need a coherent system design.  The two
designs lead to different sets of fixes.
 
A. resolv.conf is a static file which changes only very rarely.

B. resolv.conf is not static and may change due to network
environment changes.

The only underlying problem I know of is that ntpd is broken (#683061).
Other applications work fine in mode B.  And the reason that ntpd
doesn't work properly is NOT that resolv.conf is dynamic. Ntpd doesn't
work properly because it treats any name resolution failure as
equivalent to "host does not exist" and treats "host does not exist" as
a fatal error.  So ntpd will also fail in mode A unless you manage to get
name service fully operational before ntpd starts.  Merely pointing
/etc/resolv.conf at a local nameserver does not rule out the possibility
of name service failures; it just ensures that applications can access
some nameserver once the local nameserver has started.  That's nice
but it doesn't fix ntpd. Lookups will still fail, e.g., if ntpd starts before the
nameserver or if the nameserver doesn't have a forwarding address yet.

Applications have to be able to deal with temporary name service failures.

The assumptions that got this thread started were made here:
Helmut Grohne wrote:

Usually any program reads
/etc/resolv.conf once on the first DNS lookup. So all daemons started
before the local DNS cache will either use a different server, or fail
DNS resolution in all cases. A minority of services (avahi-daemon,
fetchmail, postfix, sendmail, squid, and squid3) hook into resolvconf to
reload their daemons when /etc/resolv.conf is changed by resolvconf.
These daemons will not be affected by this problem. Many other services
on the other hand will.

This is an as-yet unsubstantiated claim. Libc resolver clients generally
re-read resolv.conf every time it changes. Are there known examples
of programs that fail to do so?


Ian Jackson wrote:

Is there some reason not to use dnsmasq for this ?

To do this we would have to:
  * install dnsmasq by default
  * teach resolvconf to update dnsmasq's config rather than
     resolv.conf (but apparently Ubuntu have done this work)
  * make sure that the full-on DNS servers all conflict with
    dnsmasq and listen on 127.0.0.1

Policy would say:
  * By default resolv.conf should contain only 127.0.0.1
  * No package may update resolv.conf's nameserver settings
  * All nameserver packages should conflict with dnsmasq (perhaps
    via a specified virtual-package) and must provide general
    nameservice on 127.0.0.1.
  * Nameserver packages and network configuration packages should
    use resolvconf to communicate the actual nameservers, if they wish
    to do this.  (Support for this is not required by policy, but
    if support is provided this is how it should be done.)

It's worth discussing what Debian should install and run by default.
Ubuntu Server installs resolvconf by default. Ubuntu Desktop
installs resolvconf, NetworkManager and dnsmasq-base by
default: NetworkManager runs an instance of dnsmasq as a
forwarding nameserver.

But there is no need to introduce new restrictions and policy
unless, perhaps, it does turn out that large numbers of libc
resolver clients need to be modified, which so far as I know is
not the case.
--
Thomas Hood