validating ... bad cache hit
he at uninett.no
Fri Apr 24 14:16:16 UTC 2020
>> [...] There are two invocations of dns_resolver_addbadcache() in
>> lib/dns/resolver.c, with fairly complicated preconditions to reach
>> each of those two points.
> I've had a very quick look at the code, and it looks to me like one
> case is due to lack of authoritative server IP addresses, and one is
> due to validation failure. I think you could work out whether it is
> the first case by dumping the cache and looking for relevant adb
> entries for the zone's nameservers. (But you might have to do so
> within the 10 minute lame TTL.)
I find both of these quite unlikely. norid.no is seved by 4 name
servers with 8 addresses (v4 + v6), and the TTLs for the addresses are
typically quite staggered.
If it was due to validation failure, I would have thought that it
would be more persistent than only last for 10 minutes. The current
RRSIGs over the CNAME in question has validity-start 20200422025456
(two-days-ago-ish) and for the pointed-to A record, validity-start is
20200423055129 (one-day-ago-ish), so it seems to me to be likely that
they were published in that state in the DNS also this morning. Plus
the signer (OpenDNSSEC) last re-signed the zone 06:51 this morning,
and then next on 08:51.
So I'm still quite confused as to why this happened.
More information about the bind-users