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

[Kurt Roeckx]

On Tue, Aug 28, 2012 at 10:06:16AM +0200, Helmut Grohne wrote:
> On Tue, Aug 28, 2012 at 09:22:41AM +0200, Kurt Roeckx wrote:
> > There are existing bugs to relevant software already about how
> > they misbehave where I know about it.
> 
> Please add affects indications to those bugs, to make it easier to catch
> duplicates.

They're probably from before the time affects existed, or solved.

> > Can you reproduce this problem with the server normally started
> > but unbound stopped?
> 
> Note that I am running resolvconf. Stopping unbound will change
> /etc/resolv.conf. I currently cannot tell how the resolv.conf looks like
> during boot. Maybe it is initially empty? So to track down the issue I
> did something else. I added iptables -A OUTPUT -p udp -d 127.0.0.1 -j
> DROP to simulate a stopped name server, started ntp and then atfer some
> time removed the iptables rule. As you claimed before, ntp works as
> expected in this case and retries the resolving until it succeeds. So
> more likely the cause is related to the late changing of
> /etc/resolv.conf.

I'm using bind9 with resolvconf on my laptop without issues. so I
don't think it's related to resolvconf.

> Another option for it would
> be to contain some value received from dhcp. It then would contain a
> possibly broken name server I have no control about.

You should be able to find which dhcp server you got somewhere in
/var/lib/dhcp/.  Placing that in resolv.conf manually and
restarting ntp should then have the same effect.

But I'm not conviced this is caused by an external nameserver.
Your iptables rule only blocked udp over localhost.  Or this
wasn't during the boot process?

> So arguably this issue stems from different assumptions on
> /etc/resolv.conf (by resolvconf and ntp). You could say that resolvconf
> is broken by design. I am not sure on how to proceed here.
[...]
> As far as I can see you need:
> 
> 1) A name server that is started after ntp.
> 2) resolvconf
> 3) Maybe also a broken upstream name server.

I don't really agree to that.  What I see is that there is a time
window where _something_ is broken, and by changing the
Required-Start you move that time window around and it's not
causing problems for you (and ntp) anymore.

I still want to find the root cause of this.

The biggest difference I see between your setup and mine
is that I use bind9 and you use unbound.  So my first
reaction is to blame unbound here.

Would it be possible to log the dns traffic over
localhost during boot?


Kurt