Re: [DNSOP] [Ext] Compact DoE sentinel choice
>… I do want to point out that Compact DoE handles wildcards quite differently, >and this may not be readily apparent to the casual observer. FWIW, I noticed. (Not meaning to say “I’m not a casual observer” but…). This is something that was playing in my mind when reviewing the proposal. In basic DNS, if a name has no records and no descendants, then the responder looks for a relevant source of synthesis. Relevant means that it is “up the tree”, owner first label is “*” and there is no “blocking” name. (I won’t define “blocking here, there’s an RFC for that.) If a relevant source found, a response is cobbled from that. In year 2004 DNSSEC, the same process is followed, but the responder will add DNSSEC records to support the work it is doing. In essence, DNSSEC is “proving” that the responder followed the protocol faithfully in answering as it is. For zones using NSEC, this means showing the query name does not have records or descendants (NXDOMAIN) but there is a relevant source of synthesis and there is no blocking name. That can be done in one or two NSEC resource record sets. For zones using NSEC3, this means showing the name doesn’t exist, the showing the source of synthesis exists, and then showing there is no blocking - the three steps may each need their own NSEC3 resource record set. (Sorry, now I’m on a roll…) All of this is because of the way DNS has opted to implement synthesized responses. It was pointed out during the writing of the “Clarifications of Wildcards” there are many other ways to synthesize a response, “wildcards” was just one, the one publicly defined, method. This argument was from Dan Bernstein. For those who recall his years of participation, there was often frustration in understanding his points. He was correct in this instance. It just took a long time to understand what he meant. Instead of “wildcards are the way to synthesize” he wanted “wildcards are a way to synthesize”. I’m including this because the point is germane here. If a server is synthesizing responses on the fly according to other algorithms, then the NSEC/NSEC3 proofs do not apply. The server isn’t following the “standard” synthesis method. The server then just needs to figure out how to express its response. For a positive response, the label count has to be “right”. For negative responses, the server needs to decide how it wants to answer. In a purely on-the-fly, synthesizing responder, there may be no difference in response between a name not having any records nor descendants and a name not having what the query is seeking. For some part of me, I don’t understand why the original protocol distinguishes between name error (NXDOMAIN) and no error/no data. It’s been said that the DNS matching process has two phases, matching name first and then matching resource records. This is apparent in the protocols basic design. But why it is this way, I don’t know. I don’t see this as terribly significant - except when you try to understand how answer synthesis (“wildcards”) is done. Based on that, I can see that Compact denial of existence handles “wildcards” differently. I don’t think wildcards are integral elements of the protocol, but it is a defined mechanism. A zone administrator can elect to fully enumerate the names in the zone, and this can be implemented either by rote (explicitly listing all the names in a file) or by function (fully synthesizing). If the zone administrator elects either, and implements the protocol fully, they won’t have wildcards and no incidence of Name Error (NXDOMAIN). For any application relying on NXDOMAIN - such a zone has all names “existing” (in some sense), there simply will never be an NXDOMAIN. (There can be empty non-terminals, but if the zone is properly defined, all the leaf names - those without in-zone descendants - would have to own some record set.) So…that Compact Denial of Existence handles wildcards “differently” - this is significant… ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Tue, Aug 8, 2023 at 9:13 AM Edward Lewis wrote: > On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis > wrote: > > >You've probably stumbled across Cloudflare's differential behavior for > DO=0 vs > > >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned > > >NXDOMAIN response. With DNSSEC enabled queries, it provides the > > >Compact Answer NODATA response. > > > > Stumbled isn’t the right word - I purposely went looking for it, found it > as had I expected. This is what was “feared” in the section in “Protocol > Modifications for the DNS Security Extensions” titled “Including NSEC RRs > in a Zone“ [a.k.a. RFC 4035, 2.3] - the divergence of the unsecured and > secured view of a zone. > Ah, I stand corrected on "stumbling" :) Note however that Cloudflare quite deliberately implemented this differential behavior (to preserve NXDOMAIN visibility for pre DNSSEC clients I suspect). Some other implementations of Compact DoE return a uniform (NOERROR) RCODE for either case. So, I do not think this is a result of divergence in the contents of the signed vs unsigned zone. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis wrote: > [...] > In some sense, this proposal is establishing a (set of) wildcard(s) > (source[s] of synthesis) that owns just an NSEC record when it applies to > otherwise NXDOMAIN responses. Mulling this over, it becomes apparent that > the next name field in the NSEC record is a problem - wildcards allow for > the inclusion of an owner name pulled from the query (and DNSSEC > accommodates that via the label count) but there is no process for > modifying the RDATA in a synthesized record. The lack of a process for > modifying the RDATA means that "this is something entirely new". > > I think that signing on the fly is a great idea. But when DNSSEC was > defined, and specifically here the NSEC record, it was assumed that DNSSEC > records would be generated on machines air-gapped from the network because > the state of the art in host security was simply poor. This forced the > design to take on an approach of showing the querier "here's what I do > have, you can deduce that your request has no answer (NXDOMAIN)". With > signing on the fly, that approach makes no sense - you should be able to > send a tailored response. > > A tailored response, i.e., "there's no name matching the QNAME", means > there's no need to mention the next name. This would be great - no need to > sort the zone, no need to assist zone walking, etc. The NSEC record is > just not built for that though, it's an entirely ill-fit. > Yes, certainly a different design would have been possible if online signing was a primary use case. But I think NSEC and its minimally covering variant(s) probably do a reasonable job of catering to both pre-computed and online signing models today. I doubt there is an appetite for a larger redesign at this point. In regard to your observations on wildcards, I don't have a direct comment to add -- but I do want to point out that Compact DoE handles wildcards quite differently, and this may not be readily apparent to the casual observer. In this system, a wildcard is not a DNS protocol element that is exposed in the wire protocol, but just an internal response provisioning instruction. Compact DoE implementations pretend that every name that matches a wildcard explicitly existed in the zone and generate an on-the-fly proof for that. This obviates the need to provide an NSEC record in the response that proves that no closer match than the wildcard is possible, and is a simplification enabled by online signing. Some details in: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-compact-denial-of-existence-00#name-responses-for-wildcard-matc Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Tue, Aug 8, 2023 at 9:21 AM Edward Lewis wrote: > >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. > > > > NSEC3 is different. Because NSEC3 hashes the labels into a flat space, it > hides the in-zone structure, which is something a multi-label deep zone > [rather uncommon] would need. The impact is that empty non-terminals must > by represented in the NSEC3 chain to adequately prove a name does not have > records or subordinates (NXDOMAIN). > > > > Due to NSEC resource record exposing the full name involved, the resolver > can infer where empty, non-terminal names exist in the zone. This is the > reason behind the notion that at most two NSEC resource record sets are > needed to answer negatively, whereas up to three NSEC3 resource record sets > may be needed. > > > Thanks Ed. I have in-depth familiarity with all of this :) My original comment about NSEC3 was preceded by "arguably", and I probably should not have brought it up, as Compact DoE doesn't use NSEC3 and none of its subtle properties are relevant. I suggest we go back to focusing on NSEC and the relevant impacts. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
>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. NSEC3 is different. Because NSEC3 hashes the labels into a flat space, it hides the in-zone structure, which is something a multi-label deep zone [rather uncommon] would need. The impact is that empty non-terminals must by represented in the NSEC3 chain to adequately prove a name does not have records or subordinates (NXDOMAIN). Due to NSEC resource record exposing the full name involved, the resolver can infer where empty, non-terminal names exist in the zone. This is the reason behind the notion that at most two NSEC resource record sets are needed to answer negatively, whereas up to three NSEC3 resource record sets may be needed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis mailto:edward.le...@icann.org>> wrote: >You've probably stumbled across Cloudflare's differential behavior for DO=0 vs >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned >NXDOMAIN response. With DNSSEC enabled queries, it provides the >Compact Answer NODATA response. Stumbled isn’t the right word - I purposely went looking for it, found it as had I expected. This is what was “feared” in the section in “Protocol Modifications for the DNS Security Extensions” titled “Including NSEC RRs in a Zone“ [a.k.a. RFC 4035, 2.3] - the divergence of the unsecured and secured view of a zone. Backwards compatibility was one of the chief concerns in designing DNSSEC as it was expected that it would take it a very long time to achieve full deployment - and it was anticipated that “islands of security” would emerge before top-down. (I don’t think there are many “islands of security”, especially the way the DNS service economy has emerged this century.) >Your 1st query probably was DO=0. For your 2nd query, I assume the recursive >server that you used sent DO=1 queries upstream by default. Yep. Well, not “by default” - I diddled the DiG run time parameters to make sure I did that… >Yes, this is kind of confusing, and I'm not particularly a fan of this >differential >behavior. “Confusing” situations ought to be avoided. Confusing is a problem in situations when “mean time to repair” matters. My general concern is that although things may “work” in practice today and there’s a desire for expediency, but the way in which this pleases or displeases operations will be a large factor in whether deployment is achieved. As has been the case in other finer points of the extension definitions, the rule against names only having an NSEC (and RRSIG) emerged in the context of developing the signing process. At the time, the prevailing winds would have justified preparing an NSEC resource record set for each name in the zone, including empty non-terminals and possible even those that did not exist (no data and no descendants). I can’t think of a negative impact on a validator verifying that a name had only an NSEC record, but that wasn’t the concern at the time. What wasn’t done was disallowing queries for NSEC, by the time NSEC3 was derived, this was “fixed” (meaning, explicitly barred). Buried in here is the notion that we want to tailor the response to match the query. The only time this is done in base DNS is in answer synthesis (wildcards) and the only field modified there is the owner field. DNSSEC accommodates this (and any decrement to the TTL). We don’t have any precedent in the protocol for modifying the RDATA field based on the query, and DNSSEC was not built anticipating that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
> On 8 Aug 2023, at 11:27, Shumon Huque wrote: > > On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote: > > 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. > > I'm well aware. > > My comment was specifically related to the constraint that NSEC records > cannot be the sole record type owned by a domain name. That constraint was in > 4035 though, and perhaps cannot even be extrapolated to NSEC3. The different namespaces preclude there being such a record additionally it is noted that NSEC3 will never appear in the types bit map. Similarly RRSIG can’t appear by itself. o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps. > Shumon. > -- 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
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote: > > 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. > I'm well aware. My comment was specifically related to the constraint that NSEC records cannot be the sole record type owned by a domain name. That constraint was in 4035 though, and perhaps cannot even be extrapolated to NSEC3. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
> On 8 Aug 2023, at 10:58, Shumon Huque wrote: > > On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis wrote: > On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" > 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
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis wrote: > > E.g., while preparing this message I tried these two dig messages: > > dig somename.cloudflare.com a @ns3.cloudflare.com. > and > dig somename.cloudflare.com a > > The first returned NXDOMAIN, the later NoError/NoData. If I were a human > trying to figure out a problem with a wildcard not matching, the difference > between these two responses would be significant. (The reason existence is > defined in the wildcard document is that existence matters when applying > the synthesis rules.) > You've probably stumbled across Cloudflare's differential behavior for DO=0 vs DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned NXDOMAIN response. With DNSSEC enabled queries, it provides the Compact Answer NODATA response. Your 1st query probably was DO=0. For your 2nd query, I assume the recursive server that you used sent DO=1 queries upstream by default. Yes, this is kind of confusing, and I'm not particularly a fan of this differential behavior. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis 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
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On 7/28/23, 1:48 PM, "DNSOP on behalf of Viktor Dukhovni" wrote: >We rolled out NSEC3 by introducing new algorithm code points, and >eventually these weere widely enough deployed to allow zones to be >signed with 7/8/10/13/14 without being seen as insecure by a significant >fraction of resolvers. I don't expect CDoE to wait for the ~5 years or >more that this would take. "Minimally Covering NSEC Records and DNSSEC On-line Signing" is referenced in the Compact Denial of Existence draft, it was published in 2004 (aka RFC 4470). I can't determine which internet draft led to that document so I can't tell when discussions on this topic began. Suffice it to say, this has been hanging around a very long time - enough time for a person to be born, raised and graduate from public schools (~18 years). Persuasively I'll claim that this is the result of trying to be pragmatic when updating a protocol. (Meaning - "what's another few years"?.) I also think that software is updated more quickly, when motivated. That's one lesson from the 2018 root zone KSK roll. But I won't concentrate on that here. What's pragmatic for protocol engineering may not be suitable for operations. I'm concerned with the low deployment of DNSSEC, 25 years since the first meeting to spur adoption. Having sat through years of messaging that "operators need to be informed" and "we need to present the business case" without much success has led me to think inward. My hypothesis (note-hypothesis) is that DNSSEC is not (entirely) suitable for operations. My theory is that we need to be driving towards a simpler protocol, and as part of that, we need to avoid trying to retrofit "what is needed in the world now" into "what was designed for the world we anticipated in 1990." This is the reason I'm objecting to this approach. One of my objections is that this approach will make names that are non-existent (per the definition in "The Role of Wildcards in the Domain Name System") and reply to queries with records owned by the name. In replies without DNSSEC records, the response code would be NXDOMAIN and in replies with DNSSEC records, the answer appears to be a no error but no data response. This means the zone would be seen differently depending on whether the recipient reads DNSSEC or not. Another objection is in the redefining of fields. While the implementation of signing and validation may be able to accommodate using "dummy resource record types" (such as meta types designed to be in the range 128-255), whether management tools will be able to keep up needs to be kept in mind as well as the increasing skillset needed by the operations staff (who will be called in when customers do not get what they expect). E.g., while preparing this message I tried these two dig messages: dig somename.cloudflare.com a @ns3.cloudflare.com. and dig somename.cloudflare.com a The first returned NXDOMAIN, the later NoError/NoData. If I were a human trying to figure out a problem with a wildcard not matching, the difference between these two responses would be significant. (The reason existence is defined in the wildcard document is that existence matters when applying the synthesis rules.) I encourage updating DNSSEC to fit into the modern world. The result ought to lead towards higher adoption - by making DNSSEC a "no brainer" to deploy and operate. I'm urging that this be done in the (unquantified here) right way. I have my doubts that fitting new meanings into old formats is the way to go. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On Thu, Jul 27, 2023 at 03:04:37AM +, Edward Lewis 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. It is decidedly pragmatic. Negative responses (NODATA or NXDOMAIN) require presenting NSEC or NSEC3 RRs to extant resolvers. Introducing a new flavour of denial existence would require a fresh batch of DNSSEC algorithms (just like NSEC3 required adding algorithm 7 to supplment algorithm 5). Requiring broad support for a new algorithm would make CDoE impractical for quite some time. > # 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. That's admirable for pre-signed zones, but for on-the-fly signing with zones that may not even have a well-defined whole zone point in time snapshot (loosely coherent, eventually consistent, across various authoritative copies) that text has little relevance. > With signing on the fly, that approach makes no sense - you should be > able to send a tailored response. The cleanest solution is to use an *EMPTY* type bitmap for NXDOMAIN responses. It likely works just fine in extant resolvers. The apparent denial of the very NSEC and RRSIG records that evidence the denial of existence is unlikely to be an issue. In particular, (and I believe this to be a feature), even for a qtype "NSEC" query, the answer section remains empty (the name does not exist), and the type bitmap denies the existence of the NSEC RRset. ; ; QUESTION nxdomain.example. IN NSEC ? ; AUTHORITY example. IN SOA ... example. IN RRSIG SOA ... nxdomain.example. IN NSEC \0.nxdomain.example. ; (EMPTY type bitmap) nxdomain.example. IN RRSIG NSEC ... The NSEC RRs in the authority section are not answer records, and don't constitute an answer to the request for the NSEC records associated with the qname. It would be greate to see some interop testing of this or a similar variant of pruned type bitmaps. We already know that the unexpected "NSEC RRSIG" is working out OK, can we prune the bitmap even more? > A tailored response, i.e., "there's no name matching the QNAME", means > there's no need to mention the next name. This would be great - no > need to sort the zone, no need to assist zone walking, etc. The NSEC > record is just not built for that though, it's an entirely ill-fit. This is entirely impractical with extant algorithm codepoints. > We have the NSEC record, it's implemented and deployed. (I'm just not > considering NSEC3 as it's similar in approach despite it working on > hashes and not names.) Rolling out a new approach (say "NSEC17") > would be an uphill battle (although we did roll out NSEC3...), assumed > to be more work that force-fitting on-the-fly signing into NSEC. We rolled out NSEC3 by introducing new algorithm code points, and eventually these weere widely enough deployed to allow zones to be signed with 7/8/10/13/14 without being seen as insecure by a significant fraction of resolvers. I don't expect CDoE to wait for the ~5 years or more that this would take. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Compact DoE sentinel choice
On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" 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). In some sense, this proposal is establishing a (set of) wildcard(s) (source[s] of synthesis) that owns just an NSEC record when it applies to otherwise NXDOMAIN responses. Mulling this over, it becomes apparent that the next name field in the NSEC record is a problem - wildcards allow for the inclusion of an owner name pulled from the query (and DNSSEC accommodates that via the label count) but there is no process for modifying the RDATA in a synthesized record. The lack of a process for modifying the RDATA means that "this is something entirely new". I think that signing on the fly is a great idea. But when DNSSEC was defined, and specifically here the NSEC record, it was assumed that DNSSEC records would be generated on machines air-gapped from the network because the state of the art in host security was simply poor. This forced the design to take on an approach of showing the querier "here's what I do have, you can deduce that your request has no answer (NXDOMAIN)". With signing on the fly, that approach makes no sense - you should be able to send a tailored response. A tailored response, i.e., "there's no name matching the QNAME", means there's no need to mention the next name. This would be great - no need to sort the zone, no need to assist zone walking, etc. The NSEC record is just not built for that though, it's an entirely ill-fit. We have the NSEC record, it's implemented and deployed. (I'm just not considering NSEC3 as it's similar in approach despite it working on hashes and not names.) Rolling out a new approach (say "NSEC17") would be an uphill battle (although we did roll out NSEC3...), assumed to be more work that force-fitting on-the-fly signing into NSEC. But I'm not so sure - because of the potential problems with inconsistencies introduced. I'm not saying "this can't work" - I'm raising a concern...and hoping some thought/work is done to come up with a new approach that is built to support the modern world. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
