Re: boot ordering and resolvconf

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Ian Jackson writes ("Re: boot ordering and resolvconf"):
...
> 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 difficulty with plan A is probably [this requirement:]
...
>     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.

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

I think this is probably easier than updating every dns consumer.

Ian.