Implying the cache is working as expected. (cache-max-negative-ttl: 120)
However, after about ~9 seconds, the query goes back to taking 3-4 seconds, implying its not. Sure enough a tcpdump on the host running unbound shows it trying to access the jhmnet.net Auth server(s)
Why is unbound not respecting the 2 (120second) min max-negative-ttl?
In the interests of testing, this server is not serving any other dns traffic at all.
Negative ttls are for negative answers, like NXDOMAIN and NOERROR/NODATA
answers. This is where that configuration option applies. The max neg
ttl setting reduces TTL values from the authority. It does not increase
them.
But this response is not an NXDOMAIN or NOERROR/NODATA, so these
configuration options actually do not apply to it. It is a failure to
get data, and Unbound has a fixed TTL of a couple seconds for that. I
think it is called NORR_TTL in util/data/msgparse.h.
In this example, trying to lookup a CAA record for a domain:
...
# time host -t CAA jhmnet.net 192.168.136.181
...
real 0m3.876s
Run this again, immediately after:
..
real 0m0.016s
Implying the cache is working as expected. (cache-max-negative-ttl: 120)
However, after about ~9 seconds, the query goes back to taking
3-4 seconds, implying its not. Sure enough a tcpdump on the
host running unbound shows it trying to access the jhmnet.net
Auth server(s)
Why is unbound not respecting the 2 (120second) min max-negative-ttl?
The situation with jhmnet.net is that it's completely off the
air, because neither of the two delegated-to name servers serve
the zone, so you have a "double lame delegation".
Negative caching revolves around negative authoritative answers,
and this isn't that -- the resolver simply wasn't able to get any
answer whatsoever.