[Unbound-users] Very large TTLs

[Attila Nagy]

Hello,

I'm running unbound 1.0.2 on FreeBSD (7/amd64) without any problems, 
except this one.
Occasionally, unbound gives back very high TTLs, as can be seen here 
(reported by one of our users, while querying a local ISP's DSL pool 
addresses randomly from the server in question):
; <<>> DiG 9.4.1-P1 <<>> dsl51B6D492.pool.t-online.hu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10905
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;dsl51B6D492.pool.t-online.hu.  IN      A

;; ANSWER SECTION:
dsl51B6D492.pool.t-online.hu. *4294966839 *IN A   81.182.212.146

;; AUTHORITY SECTION:
pool.t-online.hu.       86400   IN      NS      ans1.t-online.hu.
pool.t-online.hu.       86400   IN      NS      ans0.t-online.hu.

;; Query time: 2 msec
;; SERVER: 172.16.1.55#53(172.16.1.55)
;; WHEN: Fri Oct 10 14:55:48 2008

Wireshark says:
Answers
        dsl51B6D492.pool.t-online.hu: type A, class IN, addr 81.182.212.146
            Name: dsl51B6D492.pool.t-online.hu
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: *-7 minutes, -37 seconds*
            Data length: 4
            Addr: 81.182.212.146

But it can be clearly seen that there is a signedness issue in 
wireshark, because the packet dump contains:
0030  00 01 00 02 00 00 0b 64 73 6c 35 31 42 36 44 34   .......dsl51B6D4
0040  39 32 04 70 6f 6f 6c 08 74 2d 6f 6e 6c 69 6e 65   92.pool.t-online
0050  02 68 75 00 00 01 00 01 c0 0c 00 01 00 01 *ff ff*   .hu.............
0060  *fe 37* 00 04 51 b6 d4 92 c0 18 00 02 00 01 00 01   .7..Q...........

The error doesn't always pop up, but -according to the user- can be 
reproduced, because he could find some other occurances as well.

The server itself has two (Opteron) CPUs, and unbound runs without 
threading enabled (--without-pthreads). The server also runs openntpd, 
which should call adjtime to skew the clock if needed.
Another aspect, which can be relevant is that the host has 
kern.timecounter.hardware: TSC set, and TSC is said to be not 
synchronized across the CPUs, but I don't think this could cause such a 
difference.

Any ideas about this?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20081016/e74e107d/attachment.htm>