On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis <edward.le...@icann.org> wrote:
> On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" < > dnsop-boun...@ietf.org on behalf of ietf-d...@dukhovni.org> wrote: > > 2. That said, there are multiple ways to *distinguish* ENT vs. > NXDOMAIN > > responses: > > > > a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for > ENT. > > b. Sentinel RTYPE for ENT with just NSEC + RRSIG for > NXDOMAIN. > > c. Distinct sentinel RTYPEs for both ENTs and NXDOMAIN. > > > > Presently, the draft is proposing option "a". My point is that with > "a" > > we get a response that is promising the existence of an RRset for a > name > > that does not exist: > > Launching off this observation (and realizing there's a whole thread > following it), I wanted to register some discomfort with this approach. > > The definition of DNSSEC in RFC 4035 contains this paragraph: > > # An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > # RRset at any particular owner name. That is, the signing process > # MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not > # the owner name of any RRset before the zone was signed. The main > # reasons for this are a desire for namespace consistency between > # signed and unsigned versions of the same zone and a desire to reduce > # the risk of response inconsistency in security oblivious recursive > # name servers. > > What is most significant in that text is the "desire for namespace > consistency between signed and unsigned versions of the same zone". With > this proposal providing an answer that says "yes the name exists but it > doesn't have what you want" contradicts the unsigned response that would > indicate NXDOMAIN, there is an inconsistency in what is seen in the signed > and unsigned zone. > > Note: I'm not trying to say "we have to stick to the old rules", I'm > trying to look at the environment in which the DNSSEC was born and how we > went from concept to reality (then). > Hi Ed, It might be time to revise the spec to remove this constraint, which I personally don't find very compelling. And besides, as a practical matter, resolvers in the field don't appear to enforce this constraint in any way that I can detect. Compact DoE, and RFC4470 already appear to violate it for ENT responses. And it was (arguably) already violated by pre-computed NSEC3 (5155), where an empty non-terminal name (or rather the hash of it) does solely own an NSEC3 record. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
