"expected a exact match NSEC3, got a covering record"

[Hauke Lampe]

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.