Hello. I run a NSEC3-signed zone with many dynamic updates per day where mailservers add RBL records and an hourly cronjob removes old entries.
Several times a day I see queries for nonexistent names in the zone fail. A typical query might start like this: | resolver: debug 1: createfetch: 17.245.207.216.spamtraps.bl.openchaos.org A | resolver: debug 1: createfetch: spamtraps.bl.openchaos.org DNSKEY | resolver: debug 1: createfetch: 216.spamtraps.bl.openchaos.org DS The authoritative server then logs | dnssec: warning: client 85.10.240.254#63666: view authoritative: expected a exact match NSEC3, got a covering record the resolver complains | lame-servers: info: no valid RRSIG resolving '216.spamtraps.bl.openchaos.org/DS/IN': 213.9.73.106#53 | lame-servers: info: no valid DS resolving '17.245.207.216.spamtraps.bl.openchaos.org/A/IN': 213.9.73.106#53 and returns SERVFAIL. The failing names vary over time, as records are added and deleted. A snapshot of the zone can be downloaded from https://www.hauke-lampe.de/temp/spamtrapsbl-20090523.zone (although its RRSIGs expire soon), that, loaded into another BIND 9 server, shows the same problem as on my authoritative servers when queried for 17.245.207.216.spamtraps.bl.openchaos.org. So I don't think it has to do with caching of NSEC3 records as I suspected at first. I have tested this with several versions of BIND 9 (9.5.1-P1, 9.6.0, 9.6.1b1/rc1) on the authoritative side as well as BIND (9.5.1-P1, 9.6.1b1) and Unbound 1.2.1 resolving. What could be the cause of these failures? Hauke. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users