Queries for NSEC3 hashed owner names

Chris Thompson cet1 at cam.ac.uk
Thu Feb 4 15:39:55 UTC 2010


On Feb 4 2010, Alexander Gall wrote:

>Our authoritative servers for the signed TLD ch (NSEC3, no opt-out)
>are receiving queries whose qnames are the NSEC3 hashed owner names of
>existing delegeations.  I suspect that this is a BIND issue (see
>below), hence my post to this list.
>
>What I'm seeing is stuff like this:
>
>03-Feb-2010 17:36:15.368 client 213.157.167.28#33669: query: 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch IN DS -EDC
[...]
>The qtype and flags are always the same.  
[...]

>My guess is that the iterative resolvers issuing these queries are
>somehow confused by th NSEC3 records.  

It looks as though they are trying to *validate* them!

>                                      Of the 60 sources in my sample,
>26 responded to version queries.  All of them identified themselves as
>some version of BIND
>
>   5 "9.5.0-P2"
>   3 "9.4.2-P2.1"
>   3 "9.4.2-P2"
>   3 "9.4.2-P1"
>   3 "9.3.4-P1"
>   1 "9.5.1-P3"
>   1 "9.5.0b3"
>   1 "9.4.1-P1"
>   1 "9.4.1"
>   1 "9.3.5-P2"
>   1 "9.3.5-P1"
>   1 "9.3.4-P1.2"
>   1 "9.3.4-P1.1"
>   1 "9.3.4"
>
>All of those are NSEC3-agnostic.  They should not do any DNSSEC
>processing for the ch zone, because they don't support algorithm #7.

Most of the above versions will not have this fix

2579.   [bug]           DNSSEC lookaside validation failed to handle unknown
                        algorithms. [RT #19479]

which could lead to all sorts of confusion if they are validating
via dlv.isc.org (say).

But the solitary 9.5.1-P3 is a counter-example (2579 was fixed in
9.5.1-P2). Maybe its version number is faked ...

-- 
Chris Thompson
Email: cet1 at cam.ac.uk



More information about the bind-users mailing list