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: c...@cam.ac.uk
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
