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