Helmut Grohne writes ("boot ordering and resolvconf"):
> Why is this assumption problematic?
>
> A number of DNS caches (dnsmasq, pdns-server, pdnsd, and unbound) employ
> a technique to update /etc/resolv.conf with themselves. This updating
> happens after the respective cache is started. 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.
I think this is a somewhat different problem to the one you originally
state. The real problem here is that resolv.conf is changing and
programs don't have the means to cope.
This is the result of a conflict in the system design. Either (A)
resolv.conf is a static file, changeable only rarely and with much
restarting of services or rebooting. Or (B) it is a dynamic file and
everyone who reads it needs the ability to detect when it changes and
perhaps some kind of push-update protocol.
The design used to be (A). For convenience, some programs providing
DNS service have retrospectively decided that the design will be (B).
> What options do exist, besides adding update-libc.d scripts for each and
> every service?
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.
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 ?
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 ?
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20918.158.894717.79...@chiark.greenend.org.uk
