expected covering NSEC3, got an exact match

[Alexander Gall]

On 22 Sep 2011 22:57:17 +0100, Chris Thompson <cet1 at cam.ac.uk> said:

> There was some correspondence last year about this warning message, but
> this seems to be caused by something new.

Back then it was due to a bug in dnssec-signzone that caused NSEC3
records to remain in the zone during incremental signing when the
corresponding record had been removed (Bug #20478).  This was fixed in
9.7.0 or thereabout.

> Since 2011-09-02 we have been seeing messages like this

>  Sep 22 16:38:52 authdns1.csx.cam.ac.uk named[646]: dnssec: warning:
>  client 149.20.58.131#52557: expected covering NSEC3, got an exact match

Sigh, BIND is still not logging the qname that caused this, which
makes debugging really hard (I asked about that when I reported the
old bug).

> on both our main authoritative-only (recursion no) nameservers. Our own
> zones don't use NSEC3, but we do officially slave two that do (srcf.net
> and srcf.ucam.org) so I have been assuming that they are responsible in
> some way. But we didn't change anything in the server configuration at
> the time the messages started, and the zone administrator (hi, Malcolm!)
> says the same about the contents of the two zones.

> We were running BIND 9.7.4 at that stage, but upgrading to 9.8.1 hasn't
> caused the messages to go away, as I had rather hoped.

> Has anyone any clues about this one? Or observed anything similar?

No.  But since actual hash-collisions can be ruled out, I don't see
any other way of triggering this message than by the presence of stale
NSEC3 records.  This would be caused on the host doing the signing, so
updating the software on a slave wouldn't help.

This could be easily verified *if* we knew the qnames involved.  As it
is, you'd have to create the hash-chain yourself and compare it with
what's in the zone.  You could also count the number of NSEC3 records
and check wheter it matches what's expected (the number would be
bigger if stale NSEC3 records are present).

-- 
Alex