<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
I'm running unbound 1.0.2 on FreeBSD (7/amd64) without any problems,
except this one.<br>
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):<br>
; <<>> DiG 9.4.1-P1 <<>>
dsl51B6D492.pool.t-online.hu.<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10905<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0<br>
<br>
;; QUESTION SECTION:<br>
;dsl51B6D492.pool.t-online.hu. IN A<br>
<br>
;; ANSWER SECTION:<br>
dsl51B6D492.pool.t-online.hu. <b>4294966839 </b>IN A 81.182.212.146<br>
<br>
;; AUTHORITY SECTION:<br>
pool.t-online.hu. 86400 IN NS ans1.t-online.hu.<br>
pool.t-online.hu. 86400 IN NS ans0.t-online.hu.<br>
<br>
;; Query time: 2 msec<br>
;; SERVER: 172.16.1.55#53(172.16.1.55)<br>
;; WHEN: Fri Oct 10 14:55:48 2008<br>
<br>
Wireshark says:<br>
Answers<br>
dsl51B6D492.pool.t-online.hu: type A, class IN, addr
81.182.212.146<br>
Name: dsl51B6D492.pool.t-online.hu<br>
Type: A (Host address)<br>
Class: IN (0x0001)<br>
Time to live: <b>-7 minutes, -37 seconds</b><br>
Data length: 4<br>
Addr: 81.182.212.146<br>
<br>
But it can be clearly seen that there is a signedness issue in
wireshark, because the packet dump contains:<br>
0030 00 01 00 02 00 00 0b 64 73 6c 35 31 42 36 44 34 .......dsl51B6D4<br>
0040 39 32 04 70 6f 6f 6c 08 74 2d 6f 6e 6c 69 6e 65 92.pool.t-online<br>
0050 02 68 75 00 00 01 00 01 c0 0c 00 01 00 01 <b>ff ff</b>
.hu.............<br>
0060 <b>fe 37</b> 00 04 51 b6 d4 92 c0 18 00 02 00 01 00 01
.7..Q...........<br>
<br>
The error doesn't always pop up, but -according to the user- can be
reproduced, because he could find some other occurances as well.<br>
<br>
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.<br>
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.<br>
<br>
Any ideas about this?<br>
<br>
Thanks,
</body>
</html>