bind says 'clocks are unsynchronized' but they are not

[Niklas Jakobsson]

I assume this has to do with the transfer-format option set to
'many-answers' (this is the default of bind), so what decides how many
records goes into one DNS packet? Since it is a tcp-stream I assumed
there would be only one TSIG signature in the end, I guess I assumed
wrong. 

So, if there a single TSIG signed "DNS packet" inside the tcp stream
would take longer then 5 minutes to transfer, the whole zone transfer
would fail. 

What are the security implications of increasing the the fudge time to
say 1 hour? Is there some danger other then replay attacks? Is replay
attacks even a problem when you are running IXFR?

 /Nico

On tor, 2010-07-08 at 10:20 -0400, Shumon Huque wrote:
> Not necessarily. A zone transfer is composed of a sequence of
> DNS response messages, each of which may have a TSIG signature
> record (from what I've seen BIND adds a signature to every
> response message). If each of those response messages is 
> generated, delivered, and verified within the fudge window, it 
> should work.
> 
> Not to say that there might not be bugs. I've encountered a TSIG
> verification bug in BIND (going back many releases) which only
> seems to manifest itself on one particular platform that I run 
> (Sun USPARC T1 with Solaris 10) where part way through the zone 
> transfer, BIND reports a TSIG verification failure. Clocks are 
> synchronized, and the transfers complete in a fraction of the 
> fudge. And running other software on the same box (eg. NSD or my 
> own AXFR+TSIG code) doesn't have any problems with the zone transfers. 
> I haven't bothered to report this problem because we're planning 
> to phase out that platform, but maybe this thread will prompt me
> to collect some debug info and send it out ..
> 
> -- 
> Shumon Huque
> University of Pennsylvania.
> 
> On Thu, Jul 08, 2010 at 10:43:47AM +0200, Niklas Jakobsson wrote:
> > Hello,
> > 
> > This was my first guess as well, but since the TSIG fudge is set to 300
> > seconds then all zonetransfers which take more the 5 minutes would fail
> > if this was true. 
> > 
> >  /Nico
> > 
> > On tor, 2010-07-08 at 10:28 +0200, Gilles Massen wrote:
> > > Hi Nico,
> > > 
> > > Could it be that the signature of the AXFR message is created at request
> > > time on the master (actually when the answer is build), but the
> > > validation on the client side is obviously only made at the end of the
> > > transfer?
> > > 
> > > The RFC2845 suggests that this is possible, but I'm not fluent enough in
> > > bind source to confirm or deny...
> > > 
> > > Best,
> > > Gilles
> > > 
> > > 
> > > Niklas Jakobsson wrote:
> > > > Hello,
> > > > 
> > > > I have some problems with our bind servers complaining that 'clocks are
> > > > unsynchronized' when doing zone transfers with TSIG. The problem is the
> > > > clocks are correct, synced with ntp and everything. 
> > > > 
> > > > The problems seems to occur mostly on zone transfers that take a long
> > > > time (ie. hours). 
> > > > 
> > > > Anyone seen had any similar problems or have an idea what is going on?
> > > > 
> > > > I'm running bind 9.6.1-P3 on debian/lenny. 
> > > > 
> > > >  /Nico
> > > > 
> > > 
> > 
> > 
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>