> On 8 Aug 2023, at 10:58, Shumon Huque <shu...@gmail.com> wrote: > > 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.
You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard matches nor are NSEC3 records or their RRSIGs returned for * queries at the hashed name. They are pure metadata. NSEC3 records and their RRSIGs exist in their own namespace. > Shumon. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
