On 12/26/24 15:43, Shumon Huque wrote:
I've proposed the following new section of text to cover how this
protocol can accommodate NSEC3. Please review.
[...]
[...] In responses for non-existent names, the
Type Bit Maps field will contain only the NXNAME meta-type. In
responses to Empty Non-Terminal names, the Type Bit Maps field will
be empty.
I think that is the usual case, but in fact the NSEC3 hashed names could also
be owner names of other record sets.
Therefore, RFC 5155 Section 3.1.8 specifies
The Type Bit Maps field identifies the RRSet types that exist at the
original owner name of the NSEC3 RR.
The compact-DoE draft should have similar language, and not assume that NSEC3
records don't collide with other RRsets with the same owner name.
Related sentences in other sections that need fixing (pasted here so you can
find them more easily when editing):
1. (and in the case of NSEC3 there will be an empty Type Bit Maps field)
2. If NSEC3 is being used, this RR type is the sole
entry in the Type Bit Maps field.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
