On Mon, 5 Mar 2007, Roy Arends wrote:
According to the rules in 5.2, the validator needs to check for the absence of DS and SOA in this NSEC record. This check passes. Obviously, the validator needs to check for presence of the NS bit, but the section does not mention that.
Added, using Roy's text.I still don't fully understand the wildcard no data issue (below). I'll repeast my request for more discussion and/or suggested text.
-- Sam
(4) expanding wildcards/wildcard no data response Both response types need a proof that the wildcard is at the closest encloser. The closest encloser can be determined by comparing QNAME to both ownername and nxtdname of the NSEC and take the nearest common ancestor. Every NSEC in a response MUST have the same closest encloser (this is fact, not a requirement). i.e. validator must check this waythatthere is no closer wildcard match.I'm vaguely remembering some discussion of why we didn't need anything more and why 4035's text was, in fact, sufficient. Since I don't fully recall the details, I'd like someone else to confirm this before we add it, and preferably to write the text on it. Can we have some more discussion on this item?Here is an example: zone: example.com NSEC *.example.com *.example.com A 192.0.2.1 bar.example.com NSEC *.bar.example.com *.bar.example.com A 192.0.2.2 alfa.bar.example.com NSEC gamma.bar.example.com Query: foo.bar.example.com A Spoofed response: foo.bar.example.com A 192.0.2.1 foo.bar.example.com RRSIG (labelcnt=2) alfa.bar.example.com NSEC gamma.bar.example.com Real response: foo.bar.example.com A 192.0.2.2 foo.bar.example.com RRSIG (labelcnt=3) alfa.bar.example.com NSEC gamma.bar.example.com
-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>