Queries for NSEC3 hashed owner names

Alexander Gall gall at switch.ch
Thu Feb 4 13:27:55 UTC 2010


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
03-Feb-2010 17:36:15.643 client 88.255.31.53#54974: query: 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch IN DS -EDC
03-Feb-2010 17:40:11.408 client 200.35.168.138#37389: query: IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91.ch IN DS -EDC
03-Feb-2010 17:40:11.410 client 200.35.168.138#57176: query: N8I22P5H55EVKCDRAGI720L3UNSTQBBC.ch IN DS -EDC
03-Feb-2010 17:40:45.819 client 213.157.167.28#33669: query: FLJCTHUJNK4DH1JQRQ3N73N7HB6417AB.ch IN DS -EDC
03-Feb-2010 17:40:45.819 client 213.157.167.28#33669: query: N8I22P5H55EVKCDRAGI720L3UNSTQBBC.ch IN DS -EDC
03-Feb-2010 17:40:59.318 client 189.28.158.34#8053: query: IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91.ch IN DS -EDC
03-Feb-2010 17:41:12.764 client 213.85.147.51#32810: query: K9QROA3TFOTNC3SLUEH135NTUB5GOFNH.ch IN DS -EDC
03-Feb-2010 17:36:15.368 client 213.157.167.28#33669: query: 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch IN DS -EDC
03-Feb-2010 17:36:15.643 client 88.255.31.53#54974: query: 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch IN DS -EDC

The qtype and flags are always the same.  Here are some stats over a
20 hour period on one particular server

- 12445 queries

- 60 distinct IP source addresses

- 369 distinct qnames

- 276 names were queried only once

- 5 names account for 85% of all queries

  2550 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch
  2485 K9QROA3TFOTNC3SLUEH135NTUB5GOFNH.ch
  2412 IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91.ch
  1991 N8I22P5H55EVKCDRAGI720L3UNSTQBBC.ch
  1242 FLJCTHUJNK4DH1JQRQ3N73N7HB6417AB.ch

Two of these are special:

IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91 is the hash of the apex (ch.) and the
NSEC3 of 4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK covers the wildcard (*.ch.).
The NSEC3 records of both of these names occur in all Name Error
responses as part of the closest encloser and non-existance of
wildcard proofs.

My guess is that the iterative resolvers issuing these queries are
somehow confused by th NSEC3 records.  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.

-- 
Alex




More information about the bind-users mailing list