>> [...] 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.)
Hm. 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. Regards, - HÃ¥vard _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users