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

Mon May 25 00:14:47 UTC 2009

In message <20090524194358.GA21157 at frell.ambush.de>, Hauke Lampe writes:
> 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 NSEC
> 3, got a covering record

> the resolver complains
> 
> | lame-servers: info: no valid RRSIG resolving '216.spamtraps.bl.openchaos.org/DS/IN': 213.9.7
> 3.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.

; <<>> DiG 9.6.1rc1 <<>> +dnssec 216.spamtraps.bl.openchaos.org DS @nsig3.hauke-lampe.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37840
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;216.spamtraps.bl.openchaos.org.	IN	DS

;; AUTHORITY SECTION:
spamtraps.bl.openchaos.org. 64	IN	SOA	nsig3.hauke-lampe.de. hostmaster.hauke-lampe.de. 572308 3642 7123 3600000 64
spamtraps.bl.openchaos.org. 64	IN	RRSIG	SOA 7 4 64 20090528000252 20090524230252 15572 spamtraps.bl.openchaos.org. mV3xGVACjP+AoqM2V2y9SHA14JCPA8mfMcrzjrwoV2cDbxp1eiXyQCl5 CEnxYdXTO23hDuyAWGxwuJUjUrOucWWgbUy2Qlbhkz2i/URLlC78H3iE tNizcxkJm2agt1PYvKRZ5r0xVKGGVKwCSN/QHq4dV41RTf5Wfq5zn1h8 mUk=
6L37ENRJ8BJ0PN8JQVTM4DIQI2U5O9UC.spamtraps.bl.openchaos.org. 64	IN NSEC3 1 0 100 7CE55460E7151E99FE4044321D705881FED8A602E8CD861EA89394E8814459964402E98530F8ACB5DC166E5068653D6AA8D1C7D030E753A2D545BB5C6B84B1DF 6LCAJDAMT1M3EG0P1JA8P4L1PCN2VF71
6L37ENRJ8BJ0PN8JQVTM4DIQI2U5O9UC.spamtraps.bl.openchaos.org. 64	IN RRSIG NSEC3 7 5 64 20090527232409 20090524222409 15572 spamtraps.bl.openchaos.org. l9saVQaI1UYOf0OytUrZRLswkVuM/YRCQUpxYERDovDVqaAySHMcNqIF E6bbqUZXw6jfkoQnIdXfoTpr68d3ga+LeDYg8ikh/yrmyVYxco7bv+a2 zLv8eSjnchXVeqXWhQ/OizKV/7OHPYrDp7PBazwmSvn8uX6E/NQl3AFa z38=

;; Query time: 322 msec
;; SERVER: 213.9.73.106#53(213.9.73.106)
;; WHEN: Mon May 25 10:02:58 2009
;; MSG SIZE  rcvd: 633

drugs:tests 10:03 {2703} % ./nsec3hash 7CE55460E7151E99FE4044321D705881FED8A602E8CD861EA89394E8814459964402E98530F8ACB5DC166E5068653D6AA8D1C7D030E753A2D545BB5C6B84B1DF 1 100 216.spamtraps.bl.openchaos.org
6L4MLDH19VC0EEJF4O0NQRB62ENOG4GE (salt=7CE55460E7151E99FE4044321D705881FED8A602E8CD861EA89394E8814459964402E98530F8ACB5DC166E5068653D6AA8D1C7D030E753A2D545BB5C6B84B1DF, hash=1, iterations=100)
drugs:tests 10:03 {2704} % 

The error messages matches what it being returned.  6L4MLDH19VC0EEJF4O0NQRB62ENOG4GE is 
between 6L37ENRJ8BJ0PN8JQVTM4DIQI2U5O9UC and 6LCAJDAMT1M3EG0P1JA8P4L1PCN2VF71 and there
is no OPTOUT flag bit set.

Now 216.spamtraps.bl.openchaos.org is a empty node so it is possible that you have found a bug
in the generation of the NSEC3 chain.

I would add data at 216.spamtraps.bl.openchaos.org or switch to using NSEC while this is
investigated.

Mark

> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org