[Unbound-users] Strange TTL of the SOA record for a noexist domain query

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Likun,

On 05/09/2011 01:10 PM, Likun Zhang wrote:
> Hi,
> 
> Bortzmeyer Sent On Friday, May 06, 2011 9:31 PM
> 
> 
>>> When I dig example.com soa, I got the following answer:
>> ...
>>> example.com.            86400   IN      SOA  NS1.example.com.
>> root.example.com. 2010091701 3600 900 604800 3600
>>
>> Fresh from the authoritative name server so TTL is the original value.
>>
>>> Then I dig noexist.example.com a, I got this:
>> ...
>>> example.com.            3600    IN      SOA     NS1.example.com.
>> root.example.com. 2010091701 3600 900 604800 3600
>>
>> "Artificial" value for the TTL, per RFC 2308, section 3. Nothing to do
>> with the value Unbound has in its cache.
>>
>>> I dig noexist.example.com again, the ttl of the soa record changed:
>> ...
>>> example.com.            86292   IN      SOA     NS1.example.com.
>> root.example.com. 2010091701 3600 900 604800 3600
>>
>> Original TTL of the SOA record, minus the 108 seconds elapsed between
>> the two tests. Not normal, should be 3600 again.
> 
> According section 5 in RFC2308, it should be a bug of unbound, especially when the TTL and minimal of soa are different.

Yes, there seems to be a bug.  Unbound picks up the SOA from the
positive answer, with its longer TTL, and uses that to answer the
negative answer as well, mixing the positive-answer-SOA with the
negative-answer-SOA and getting the TTL wrong.

The negative answer does not get a longer cache time because of this.
That time is administered on its own, for the NXDOMAIN.

The TTL reported to downstream requestors, is then not correct.  I am
not sure how to fix this, as unbound puts information in the RRset and
in the message cache.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNx+NMAAoJEJ9vHC1+BF+NQQEQAK5Tq80OKMwsQ+E4/tURZf2c
lVWB2F18qwK7FivpfLFY58Urrcp5aBr/gGjOA8+hvZMQk0rnnjmh9b/0YiAl2ion
jTJA5kP7bVCJ+EFCI8tCOe6ePIX7lrQa3iJIHURNLqwXDJVkISfeZVMKZJ644uaj
f64BTUBL8a/+7iB+Ry3hlyxE1BSZSVsUlvKNlr0bILvlCn2S1uD5vWK+50u+CHG0
Hx+BtjEBDUfgu60UnZOZRud2H2RmOQf3iD+MXCwYGMAcEEPCXx3B0+JhD2xU3Tqd
+OlCxVduffRxq0mVUoyr5izAyVtiwaGEW3cC9qGyVdsy/JDOm0nEPqU5PXKVtoSC
eK7kSXypWWT/k5T9r890uP31JTm+y8fv68GU/JmKoCHCnp20nrfzv6B+nFKWvv1+
svw2NMz0Or6ECQ+HEcIrDR0mpghxKCFAWLsCVgFKpSjGp7t//39QsecLZLjHpWyo
XTpsscsWqDNeZwS1NkCkCqtZ/blgDOr7YtCsDVMhiUILwPNTkiUc/jDU3FLFssZy
tDCe6N4qgmvmvHIJ9Ov6tzL3GD7HnPTkmXi7U3izTXEDUDogxO0aeXnDqXaZRoAq
H2yva97rTaS/PH65yeXPF3Lnga67Wass1LPEiibbMq3/H7hx0Dfyj4JeSP9rNskP
VhRcofksMVOa/rfYkFAu
=Foza
-----END PGP SIGNATURE-----