unbound NXDOMAIN TTL shared between records

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Patrik,

On 22/08/15 07:27, Patrik Lundin wrote:
> 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?

I think this may be an issue that is fixed in (the most recent) 1.5.4
release.  It would have TTL 300 like it says in the rdata (because
that is lower).

Best regards, Wouter

> === $ 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 ===
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV2sNRAAoJEJ9vHC1+BF+NFnYP/3P3nHYEJD06uwTJ4/F5sjFc
o+bEIwAAdfspo66R31kgzmgnmaI/OAZ+Q6tZyGxMhZc78C9zikkupTinAFKeTyYh
HD0uCP3WvyRXuB/UL6ylO5jlOlEDcq5HbSGYo7Of12XgPwzPTM4ghlg2e87c4GcR
IlIrqu/3go/x2sOTYFlPRcsGQdbwZzUaY5uNWDVdEEIleQcUQNbiaxuuCTzONKYM
ay17LdsqGo0DE6mPDgZ5TY3qGCQ2iBFmgMuU3+A8yWmJPc1ZIWqNiJV3uCQ8DOAK
9dB4D1A3OZXJED4ZAnMvwq78krVtMTCdyd0F90Hg0i4veE6kUm4W3RazseDmwDI/
1Vo0JwFPaXWSyZ4p9fHvyQ81lSVfwpQTQgjt+zzPoCNgdJoqviv4e73vL54ReY03
8yFS1BA96tKUltKH/L9uLpbGgYvFU9FZ4VimG0W5uW43gIXfjtvUiQvGZ0zC/OaB
vKPVpsAE+hVjAxoijlv56FigEkjMcGZvGLUJERFRNVDEHMxJ0z5a1VCsrhEFSpPZ
19sZXfA8hpemHBdSwCFSEQt3cfsb15VxIaxJwONQ8Vvmw2mujPQ9hNgk7oGLTcSB
r/lnhp4+Gn28uRUQqnP/1t5Db+0YZjX6j99+ufdcDfOA8kkIsZjigxE1WJ/csmAl
WRxJjhgTUry+VKUO9App
=pYqP
-----END PGP SIGNATURE-----