[pkg-ntp-maintainers] Bug#683061: Bug#683061: ntp: diff for NMU version 1:4.2.6.p5+dfsg-2.1

[Helmut Grohne]

Hi Kurt,

On Wed, Aug 29, 2012 at 10:11:00AM +0200, Helmut Grohne wrote:
> On Tue, Aug 28, 2012 at 06:37:41PM +0200, Kurt Roeckx wrote:
> > Your iptables rule only blocked udp over localhost.  Or this
> > wasn't during the boot process?
> 
> The idea was to simulate an unreachable name server. Since my
> resolv.conf only contains 127.0.0.1, that essentially means that all DNS
> traffic originating from ntp is dropped. So to answer your second
> question: No, I did not reboot the machine yet.

There is bit I missed thus far. I concluded earlier, that resolvconf was
required to reproduce the issue. Just why?

Now unbound[1] is a bit special when it comes to resolvconf (the
package). It drops a file in /etc/resolvconf/update.d that causes it to
be listed as the sole nameserver in /etc/resolv.conf. During boot
/etc/resolv.conf is initially empty, because I didn't specify any name
servers in /etc/network/interfaces. So at the time ntp starts, it likely
find that there are no name servers. Only after unbound has started, the
file is populated.

Can you tell me what ntp does when it fails to find any name servers?

A quick attempt to reproduce this theory had interesting results. When
the ping utility is run with an empty resolv.conf, it will for some
reason contact 127.0.0.1 and succeed. Only if I stop unbound and empty
my resolv.conf, ping will fail to resolv hosts. A ntp restarted in this
setting appears to drop all time servers, even if a better resolv.conf
is provided at a later time.

I guess nowadays you need to depend on $named if you expect a working
/etc/resolv.conf.

Does this reasoning make any sense to you? If so, please remove the
moreinfo tag.

Helmut

[1] Other packages with similar behaviour are pdns, pdns-server and
    dnsmasq. bind9 (the one you were using) is notably absent here.