unbound NXDOMAIN TTL shared between records

[Wouter Wijngaards]

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

Hi Patrik,

On 08/21/2015 05:14 PM, Patrik Lundin via Unbound-users wrote:
> Hello,
> 
> I recently noticed what to me is a strange caching behaviour for 
> NXDOMAIN results.
> 
> This has been seen both on Ubuntu 14.04 with unbound 1.4.22 and on 
> OpenBSD with unbound 1.5.2.
> 
> I noticed that for some domains, the cache TTL for NXDOMAIN
> results seemed to be shared for all nonexistant replies under that
> domain:

This is because the RRset cache is shared between answers.  The SOA
record is in that cache.  When you query the second time, unbound
detects that the SOA record has not changed, and therefore keeps
timing out the existing SOA record.  And then you get a lower TTL, of
that SOA record, when you query again.

This is because of cache update rules, which are complicated.  We want
to time out existing records, so that we look them up again when they
expire.  If the newer SOA record was different (i.e. contained
different data), it would have been updated.  These cache update rules
are set to stop eg. cache poisoning, and the resolver sticking to an
old nameserver after a nameserver change.

(the exact negative TTL has seen fixes recently, eg. with a max
negative ttl unbound.conf setting, and depends on what the authority
server sent).

Best regards, Wouter

> 
> The first lookup (which also suspiciously seems to use the SOA TTL
> of 7200 rather than the NXDOMAIN TTL of 18000): === dig
> nonexistant1.unbound.net
> 
> ; <<>> DiG 9.4.2-P2 <<>> nonexistant1.unbound.net ;; global
> options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: NXDOMAIN, id: 35933 ;; flags: qr rd ra; QUERY: 1, ANSWER:
> 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION: ;nonexistant1.unbound.net.      IN      A
> 
> ;; AUTHORITY SECTION: unbound.net.            7200    IN      SOA
> ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200
> 604800 18000
> 
> ;; Query time: 474 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;;
> WHEN: Fri Aug 21 16:51:23 2015 ;; MSG SIZE  rcvd: 104 ===
> 
> The second lookup for that same name, which as one would expect has
> a decremented TTL: === $ dig nonexistant1.unbound.net
> 
> ; <<>> DiG 9.4.2-P2 <<>> nonexistant1.unbound.net ;; global
> options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: NXDOMAIN, id: 9365 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
> AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION: ;nonexistant1.unbound.net.      IN      A
> 
> ;; AUTHORITY SECTION: unbound.net.            7195    IN      SOA
> ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200
> 604800 18000
> 
> ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;;
> WHEN: Fri Aug 21 16:51:28 2015 ;; MSG SIZE  rcvd: 104 ===
> 
> Now we look up another nonexistant domain, which I would expect to
> have a TTL of 7200 (18000?), but this one shares the reported TTL
> with my previous lookup: === $ dig nonexistant2.unbound.net
> 
> ; <<>> DiG 9.4.2-P2 <<>> nonexistant2.unbound.net ;; global
> options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: NXDOMAIN, id: 27898 ;; flags: qr rd ra; QUERY: 1, ANSWER:
> 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION: ;nonexistant2.unbound.net.      IN      A
> 
> ;; AUTHORITY SECTION: unbound.net.            7189    IN      SOA
> ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200
> 604800 18000
> 
> ;; Query time: 32 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;;
> WHEN: Fri Aug 21 16:51:34 2015 ;; MSG SIZE  rcvd: 104 ===
> 
> Does anyone else see this? Is it by design? What makes this even
> more confusing to me is that I see different results for different
> domains. I believe I am even seeing different results inside the
> same domains possibly depending on what I have looked up before
> that.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJV15R+AAoJEJ9vHC1+BF+NJHEP/RDSz0zGIE8pTRHoZ2osjeoA
G/IjstXLQgEk4cFawsH5gEwUAJ7tJx4FiGUJJhfy9IG0W+mSOJw/MDECKwb/Ad39
AwXO+ZJ+h24+QfTWAO/I9tyJwbD9+BOVtKv/i580R8p7Y42l2M3FdBgAqkkLH8Vc
O7GyO6AWJNulXAfLSwG+QTk8z7HJj0YHWVxAFcJQV4q2N+kqZpOpoffASWqSWtkC
k7rSWRD2qLKdYX5+CDK99xKw1LHVL9Ncczp/vaUZHul9++e/RRvmoBqbjbUeo0Ar
NXPWaAYHWuwswN6o4D0pc78O11kSz8GzVAHVCOi0E4ovBUA1Z4cTnHvhmuKMXZZH
wYGaFeLd+MhZOAU5Y4+JtNgq5LTsOeUjfSt8FTrAArAPJj9z9yIa9pWAEMdDEPYg
YInb9x5vo2BQ9KBdyZngSU/bQ1Oyu317Gcfp5WygD0FyLAIT0pVLAN7UVVJMHqy2
Btl5kh9OhH85oYEuRIKX2IBSf4EIP3NHyo9pGPp+U81vknkYdyQFPyrxUOooX4B4
OoYafObLkOzAsE4WF3+kdZ+h1g0Q12FIzGvuW2wFiQudrC5/101QT8wVSs75gH7J
xDf7KRIhld0DtDcfXP2or/fVNi1yI3zTboNA0IW6hOdnnxu2ouPSt4Cus1ersMmx
fIo4PDhO89uHCS8OVfi4
=6ERn
-----END PGP SIGNATURE-----