expected a exact match NSEC3, got a covering record

2009-05-24 Thread 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.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: expected a exact match NSEC3, got a covering record

2009-05-24 Thread Mark Andrews 

In message 20090524194358.ga21...@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 360 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@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_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named querylog, cache hit

2009-05-24 Thread Chris Buxton 

On May 19, 2009, at 2:12 AM, Anatoly Pugachev wrote:

Hello!

This is a request to enhancement.

Is it possible to make named querylog log somehow if clients query hit
the server cache or not, not regarding to other logged query options
(like +EDC).


In the absence of such logging from BIND, this can be deduced from the  
traffic, if a traffic sniffer is used and the results processed and  
analyzed. The query and the response can be matched up based on the  
query ID. If the 'aa' flag is not set in the response, the intervening  
traffic can be examined looking for outbound queries with matching  
name, class, and type. If there are none, then the query was answered  
from cache.


3rd party traffic analysis software exists, including a commercial  
offering from Men  Mice. If it does not already look for this  
specific correlation, I'm pretty sure it would not too difficult to add.


Chris Buxton
Professional Services
Men  Mice

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users