Re: boot ordering and resolvconf
No need to CC me here, see Mail-Followup-To.
On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
> 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.
Thanks for your analysis and pointing to the actual issue underneath.
> 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.
As far as I can see, most of what resolvconf does is assuming (B) and
turning /etc/resolv.conf into a dynamic file. What would be left from
resolvconf when dropping assumption (B)?
> 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.
So here we would likely introduce a virtual package, local-dns-resolver.
Likely resolvconf would depend on it. It would be provided by name
servers, that bind to localhost by default.
Shuffled the quotes:
> 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 ?
I think that unbound actually might be that minimal proxy. When you
install it along with resolvconf, it will currently place itself in
/etc/resolv.conf (via resolvconf) as the sole nameserver and it will use
the name servers that were reported to resolvconf from dhcp or ppp as
upstream name servers. Another cache with similar capabilities in terms
of resolvconf integration is pdnsd. (Note that pdnsd doesn't do DNSSEC.)
For chroots we would likely need a i-know-that-there-is-a-cache package.
Strange thought: Would it be possible (on Linux) to add an iptables rule
to DNAT the local dns port? That would avoid the need for a proxy
altogether.
> 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 ?
Actually the backend of getaddrinfo (from eglibc) already does a stat on
/etc/resolv.conf for every name resolution attemptd. (Correct me if I'm
wrong.) So programs will already use changed DNS servers in some cases.
It should be a matter of fixing the other resolvers here.
This would not solve the issue observed with ntp, because ntp treats the
EAI_SYSTEM returned by getaddrinfo as a permanent error. Kurt Roeckx
already indicated, that probably ntp should treat it as a temporary
error. Maybe resolvconf should mention 127.0.0.1 in the absence of any
other name server to avoid this situation?
As far as I can tell, we mostly are in the (B) situation. Anyway
clarification on which of these describes the system design to be
implemented would help. Where would we document this? Would it be part
of the policy?
How can we test programs to determine their compliance with the chosen
system design?
Helmut
Reply to: