Currently awe number of services assume the following setting.
A service that retries DNS lookups, does not need to declare a boot
ordering relation on a name server.
I am currently aware of two examples of this assumption:
1) When using systemd, the DNS server is a socket service, so no
relation ship is expressed at all. Instead socket activation is used.
2) The ntp package does not declare a dependency on $named, because in
theory this is not needed. (#683061)
There likely are more cases of this assumption. If you know one, please
mention it here.
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.
There are actually two sub-problems here.
1) If /etc/resolv.conf is initially empty, getaddrinfo returns
EAI_SYSTEM. Some daemons (e.g. ntp) currently treat this as a
permanent error. This usually results in a user visible issue. It is
nasty to track down, because it is usually unreproducible once the
system is started (i.e. a simple daemon restart will fix it).
2) If /etc/resolv.conf initially contains some other DNS server (e.g.
from dhcp or from /etc/network/interfaces), some services will bypass
the local DNS cache resulting in a higher load on remote DNS servers.
This problem in general is mostly invisible.
Both cases are in general hard to observe and hard to reproduce. This is
due to $named usually being started early. In a systemd world, it might
show up a bit more often.
What options do exist, besides adding update-libc.d scripts for each and
every service?
Helmut
--
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/20130608110918.ga1...@alf.mars
