Maintained by: NLnet Labs

unbound NXDOMAIN TTL shared between records

Patrik Lundin
Sat Aug 22 07:27:05 CEST 2015


On Fri, Aug 21, 2015 at 11:13:34PM +0200, Wouter Wijngaards via Unbound-users wrote:
> 
> 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.
> 

Thanks for the explanation. Just knowing that this is by design and not
due to me triggering some bug or memory starvation issue is comforting.

One of the domains that were confusing me further was looking up stuff under
google.se where the TTL would sometimes be shared and sometimes not. But now
that I know what to look for I notice that there seem to be discrepancies in
the SOA serial, below is an example of running +nssearch a few times in a row:

===
$ dig +nssearch google.se    
SOA ns2.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns1.google.com in 10 ms.
SOA ns1.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns3.google.com in 11 ms.
SOA ns3.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns2.google.com in 24 ms.
SOA ns3.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns4.google.com in 25 ms.

$ dig +nssearch google.se 
SOA ns2.google.com. dns-admin.google.com. 101275644 900 900 1800 60 from server ns1.google.com in 11 ms.
SOA ns2.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns3.google.com in 11 ms.
SOA ns1.google.com. dns-admin.google.com. 101275644 900 900 1800 60 from server ns2.google.com in 24 ms.
SOA ns1.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns4.google.com in 25 ms.

$ dig +nssearch google.se 
SOA ns1.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns1.google.com in 10 ms.
SOA ns2.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns3.google.com in 10 ms.
SOA ns4.google.com. dns-admin.google.com. 101275644 900 900 1800 60 from server ns2.google.com in 24 ms.
SOA ns1.google.com. dns-admin.google.com. 101273744 900 900 1800 60 from server ns4.google.com in 25 ms.
===

While on the topic of corner cases, was the TTL of 600 for a google.com NXDOMAIN
(being a result of AAAA NOERROR for the NS hostnames) expected as well?
===
$ dig nonexistant1.google.com 

; <<>> DiG 9.4.2-P2 <<>> nonexistant1.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nonexistant1.google.com.       IN      A

;; AUTHORITY SECTION:
google.com.             600     IN      SOA     ns1.google.com. dns-admin.google.com. 101273744 7200 1800 1209600 300

;; Query time: 621 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Aug 22 07:24:13 2015
;; MSG SIZE  rcvd: 91
===

-- 
Patrik Lundin