unbound NXDOMAIN TTL shared between records

Unbound
1

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:

The first lookup (which also suspiciously seems to use the SOA TTL of 7200
rather than the NXDOMAIN TTL of 18000):

2

RFC 2308 section 5

   Like normal answers negative answers have a time to live (TTL). As
   there is no record in the answer section to which this TTL can be
   applied, the TTL must be carried by another method. This is done by
   including the SOA record from the zone in the authority section of
   the reply. When the authoritative server creates this record its TTL
   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.

Tony.

3

Hi, Patrik -

which also suspiciously seems to use the SOA TTL of 7200
rather than the NXDOMAIN TTL of 18000

That is how negative cache TTL is calculated (by authoritative server).
RFC2308 reads:

  (Negative cache) TTL is taken from the minimum of the SOA.MINIMUM field
   and SOA's TTL.

Regards,
Daisuke HIGASHI

4

Hi Patrik,

Yes I can confirm that unbound have a "domain wide" NXD caching. As long as the returned TTL for your second query is lower than the max TTL for the record this (IMHO) is not a violation of RFC2308. However there are domains out there that return a higher TTL for EMPTY NOERROR vs NXDOMAIN and this can trick unbound into cache the value longer than expected. This issue was reported to unbound.

Using the SOA TTL is expected see RFC 2308 section 3.
The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer.

For more info watch the video from the DNS OARC workshop in Amsterdam about 39 minutes in https://www.youtube.com/watch?v=UcAygzNSxlI

Thanks, Stephan Lagerholm

5

Thanks for pointing that out, it explains the length of the initial TTL.

6

Yes I can confirm that unbound have a "domain wide" NXD caching. As
long as the returned TTL for your second query is lower than the max
TTL for the record this (IMHO) is not a violation of RFC2308.

Interesting... Is it documented somewhere where why it is done this way?
I was actually worried that it could be a symptom of getting close to
my configured msg-cache-size or something like that.

However
there are domains out there that return a higher TTL for EMPTY NOERROR
vs NXDOMAIN and this can trick unbound into cache the value longer
than expected. This issue was reported to unbound.

For more info watch the video from the DNS OARC workshop in Amsterdam
about 39 minutes in https://www.youtube.com/watch?v=UcAygzNSxlI

Thanks a lot for pointing out your presentation. I just looked through
it and it was very informative.

I had specifically scratched my head looking at nonexistant1.google.com
returning a TTL of 600 to my client which matched neither the 86400 SOA
TTL or the 300 minimum TTL.

It was interesting to hear that the 600 came from the NXDOMAIN response
for the equivalent AAAA lookup of nonexistant1.google.com.

7

Correction: the TTL of 600 comes from the NOERROR result from looking up AAAA
records for the google NS hostnames, not NXDOMAIN for nonexistant1.google.com.

8

Hi Patrik,

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

9

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:

10

Hi Patrik,

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