Greetings again. Duane Wessels' message from yesterday focused on errors in the Authority section for some queries for <tld>/NSEC where the TLD exists:
> The incorrect responses from Verisign's root server instances > provided an empty owner name in the Authority section records of a > delegation response to the NSEC query. The empty owner name > corresponds to the root label. A recursive name server that processed > one of these incorrect responses could change its cached root NS > RRset, meaning that future queries to be resolved in the context > of the root zone could be sent to incorrect names servers which are > not authoritative for the root zone. After that was reported, folks from ICANN's Technical Engagement team started looking into the problem in order to help explain things in the many courses that they regularly give to operators about DNSSEC. As they started doing comparisons, something confusing popped out: many RSOs respond to <tld>/NSEC with empty Answer sections. Note that this problem is different than the one reported about incorrect Authority sections. As Duane said: > Additionally, we expect this may bring some new attention to the > way in which authoritative name servers respond to queries of type > NSEC. Some implementations respond with referrals, while others > respond with an NSEC RR in the Answer section. Verisign will be > pleased to work with the community if there are ambiguities in the > relevant RFCs (e.g. 4035) that would benefit from clarification, > as current behavior beyond this subset of our name servers suggests. The text in Section 3 of RFC 4035 is: A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. The "treat ... as it would any other RRset" seems to say that if an authoritative server gets a query for <tld>/NSEC for a name that has an NSEC record in the zone, that NSEC record should appear in the Answer section. According to the RFC index, RFC 4035 has been updated by RFCs 4470, 6014, 6840, and 8198. I don't see anything in any of those that modify the above sentence. In doing a quick, incomplete survey, I find some RSOs responding to <tld>/NSEC with the appropriate NSEC record in the Answer, some responding without anything in the Answer. The result does not seem to change with setting or not setting the DO bit. This is not likely to be a high priority to fix (either in various authoritative software, configurations, or in a clarification to RFC 4035), but the differing responses between RSOs with the same zone file seems worthy of discussion. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
