> On 19 Oct 2026, at 12:29, Libor Peltan <[email protected]> > wrote: > > Hi, > > I'm delighted that the delext document gained maturity and I'd love to see it > moving forward.
Thanks Libor! > I also concur with Petr's findings and here are some mine: > > 1) I feel a lack of proper description of the situation when > Delegation-Extension-unaware (DE=0) validating resolver queries a name > at/below NS-Omitting type. It can believe it is a NODATA/NXDOMAIN proof. Section 4.1: Note that when the DE flag is clear (i.e., set to 0), and no NS RRset exists at a delegation point, there is no referral from the perspective of a non-Delegation-Extension-aware resolver and the server returns a negative response. > Should it follow section 6.3 despite its unawareness, No. An unaware client is unaware of the clarifications in 6.3 > or should it keep believing there is nothing below? There is nothing below from its perspective. > In any case, it should be mentioned more explicitly in the doc (I guess Petr > complained the same in different words). I’m not sure about that. There is nothing we can specify for unaware resolvers, as they are unaware of this spec. > 2) From an implementer's perspective, the subranges of the Delegation Types > range could be rearranged to be more handy: > - NS Preserving and Private types should be in adjacent ranges (to form a > single bigger subrange) as they're pretty equal in properties > - NS-Omitting, NS-Preserving, and Private types should be adjacent as > well and form a bigger subrange because those share the requirement to be > present in delegation responses Historical convention. Many protocol registries follow this pattern where private types are at the end of a range. > 3) It should be made clear that the DE bit not only signals (commits to) > Delegation-Extension-awareness, but also DELEG-awareness. Ack. In section 2. Conventions and Definitions, I’ve added the last sentence: Delegation-Extension-aware name server, resolver, forwarder, or stub resolver: A client or server that implements this specification, and the [I-D.ietf-deleg] specification. A Delegation-Extension-aware implementation also understands type DELEG. I’ve also added to 5.1: 5.1. Setting the EDNS(0) DE Flag A resolver that implements this specification and [I-D.ietf-deleg] sets the Delegation Extensions (DE) flag to 1 in the EDNS(0) Flags field when sending a DNS request message. A resolver MUST NOT set the DE flag to 1 unless it implements both specifications. > 4) Compact Denial of Existence: §4.1.1 seems not precise enough. First, it > doesn't clearly say that the considerations are regarding queries _below_ the > non-NS delegation point. Second, it doesn't say how the non-NXNAME NXDOMAIN > answer should look like (especially, how the "next name" field in the NSEC is > crafted). Good points. Regarding your first points, I’ve updated the text in 4.1.1 to: This document updates Compact Denial of Existence (CDOE) [RFC9824]. For queries with DE=0 and a QNAME below a delegation point containing an NS-Omitting Delegation Type RRset but no NS RRset, authoritative servers implementing Compact Denial of Existence (CDOE) [RFC9824] MUST NOT use the CDOE method when the DE flag is clear. Instead, they MUST return a conventional negative response with the corresponding DNSSEC denial-of-existence proof as specified in [RFC4035] or [RFC5155], regardless of whether the Compact Answers OK (CO) flag is set. For an NSEC zone, a single NSEC record whose owner name matches the delegation point and whose Next Domain Name is formed by prepending the label \043 to the delegation point satisfies both components of the Name Error proof. It covers both the queried name and the wildcard at the closest encloser, while its Type Bit Maps field indicates the types present at the delegation point. The label \043 sorts after the wildcard label (\042) in canonical ordering. For an NSEC3 zone, the proof follows the closest-encloser construction specified in [RFC5155]: an NSEC3 record matching the delegation point, whose Type Bit Maps field indicates the types present at the delegation point; an NSEC3 record covering the next closer name; and an NSEC3 record covering the wildcard at the closest encloser. All three NSEC3 records use a Next Hashed Owner Name formed by incrementing the corresponding hash value by one. For the two covering NSEC3 records, the Hashed Owner Name is formed by decrementing the hash value being denied by one. These operations are performed on the unencoded binary hash values, before Base32hex encoding. > 5) First paragraph if Section 4.2 is weird. Isn't it roughly already a > consequence of other stuff in the document? I don’t think so. > And anyway, does it really say that for qtype=DELEG and qname being a > non-existent name (not a delegation), the server MUST NOT return NXDOMAIN?? > Doesn't it even forbid other rcodes like SERVFAIL, FORMERR etc for > qtype=DELEG? No, it doesn’t say that. > 6) Queries for type ANY (4.4) is underspecified. Either improve, or remove > this section whatsoever. I’ve improved it, I think. It now reads: 4.3. Queries for type ANY When the QNAME matches a delegation point, queries with QTYPE=ANY MUST apply the same handling to Delegation Type RRsets as is applied to other parent-side types (such as DS). > X) In general, I lack enough considerations about DE-rrtypes without DNSSEC. > Yes, their security properties are obviously weak, but they're not forbidden > or unuseful. Although not all, most of the paragraphs assume DNSSEC. Okay. What more is there to say about DE-rrtypes without DNSSEC? > Y) Question. Assume a hybrid delegation with both legacy NS and NS-Omitting > DELEG. Within the given Threat Model, should we consider the attack surface > where for a legacy resolver, the attacker _injects_ a malicious DE bit into > the resolver's queries, so that the resolver obtains cachable de-facto > NXDOMAIN proofs of stuff below the delegation? I guess the defence is the > presence of NSEC which uncovers the existence of NS, but this is not > mentioned in the doc. It isn’t mentioned here, as this is covered by RFC6840 section 4.1, but I’m happy to add the following after the first paragraph of Section 8.4: An on-path attacker may set the DE flag in queries sent by a non-Delegation-Extension-aware resolver, causing an authoritative server to return Delegation Type RRsets instead of an NS RRset. At a delegation point containing both NS and NS-Omitting Delegation Type RRsets, the NSEC or NSEC3 record matching the delegation point indicates the presence of the NS RRset. As specified in [@!RFC6840] Section 4.1, a validating resolver cannot use such an ancestor delegation proof to establish nonexistence below the delegation point. Consequently, injecting the DE flag cannot cause a non-Delegation-Extension-aware validating resolver to accept an authenticated denial of existence for names below the delegation. Thanks Libor, Please find the latest (not yet submitted) version here: https://royarends.github.io/draft-ietf-dnsop-delext/draft-ietf-dnsop-delext.html Warmly, Roy > > Thanks, > > Libor > > On 09. 10. 26 15:06, Petr Špaček wrote: >> Hi everyone. >> >> I'm attempting to read both drafts in lockstep before we send it to WGLC. >> >> I feel more people need to do this before we rubber stamp both documents. >> >> >> Here are my notes, ordered by perceived severity: >> >> >> ## DELEG 5.1. Resolvers vs. DELEXT 5.1 >> >>> A resolver that is DELEG-aware MUST signal in queries that it supports the >>> DELEG protocol by setting the DE bit to 1 (see Section 4). This indicates >>> that the resolver understands the DELEG semantics and does not need NS >>> records to follow a referral. >> >> I've generalized DELEG to "Delegation-Extension-aware": >> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/215 >> >> >> This highlighted an implicit assumption: >> >> Client which implements DELEXT/DE=1 must also support DELEG. I.e. sending >> DE=1 while NOT implementing DELEG will cause interop problems because DELEG >> is in NS-omitting range, so DE=1 client will not see NS anymore. >> >> I guess we need to add sentence or two to both documents saying - if you >> implement this, implement the other protocol as well. >> >> Future extensions might need to invent their own signal if they want to >> _replace_ (as opposed to augment) DELEG. >> >> Opinions? >> >> ------------------------------ >> >> ## 3.2. NS-Preserving Delegation Types >> >>> The NS-Preserving Delegation Type segment contains types for delegation >>> mechanisms that are used alongside the existing NS RRset. >> >> I think this is wrong. We don't know what these types might do in future, >> but I there already were proposals for "DSver2" record type. Such type is >> equally applicable to NS and DELEG, too. >> >> Besides that, I guess all three NS-Preserving/On-Demand/Private Delegation >> Types could use something like ~ 'MUST NOT exist on name without NS or a >> NS-Omitting Delegation Types'. >> >> This is similar to DS: It cannot exist without an actual delegation. (It >> would open can of worms for DNSSEC.) >> >> Or said yet differently, only NS and NS-Omitting Types create a delegation. >> The others just ride on that delegation. >> >> >> ## DELEXT 5.3. Algorithm for "Finding the Best Servers to Ask" >> >>> 2.2.2. If a given SNAME is proven to not have NS-Omitting Delegation Type >>> RRsets but does have an NS RRset, the resolver MUST copy the NS RRset into >>> SLIST. The resolver MUST process any NS-Preserving or Private Delegation >>> Type RRsets according to the specification defining those types. >> >> I think "The resolver MUST process any NS-Preserving or Private Delegation >> Type RRsets according to the specification defining those types." should get >> it's own step, like 2.2.3. Now it can be read as if it applies only to cases >> with fallback to NS, which I don't think was intended. >> >> The same remark applies to 5.2. Referrals: >> >>> NS-Preserving and Private Delegation Type RRsets present in the referral >>> supplement the delegation information provided by the NS RRset. >> >> I think it can generally apply to all NS-Omitting types as well. >> >> Same for 9.4. Additional Expert Review Criteria: >> >>> A type that supplements the NS RRset should be allocated from the >>> NS-Preserving segment. >> >> Perhaps "A type that supplements the delegation should be allocated from the >> NS-Preserving segment." ? >> >> >> Nit in 5.3: >> >>> This is the same recommendation to bound the amount specified in [RFC1034] >>> Section 5.3.3. >> >> A missing word? "bound the amount of work"? >> >> ------------------------------ >> >> ## DELEXT 4.1.1. Compact Denial of Existence >> >>> This document updates Compact Denial of Existence (CDOE) [RFC9824]. For >>> CDOE enabled servers, the negative response required above is an exception >>> to the CDOE method, i.e., it MUST be generated as a conventional Name Error >>> proof ([RFC4035], or [RFC5155] for NSEC3) rather than as an NXNAME-based >>> NODATA response, and it MUST be returned regardless of whether the query >>> sets the Compact Answers OK (CO) flag [RFC9824]. >> >> I find this confusing. "Name Error" is defined in 4035 3.1.3 as> Name Error: >> The zone does not contain any RRsets that match <SNAME, SCLASS> either >> exactly or via wildcard name expansion. >> I.e. the name does not exist. >> >> What if the QNAME=delegation point? In that case it should be "No Data" with >> the accurate type bitmap, right? >> >> ------------------------------ >> >> ## DELEXT 4. Name Server Requirements >> >>> When the value of the EDNS(0) DE flag is 0, the server behaves as a server >>> that does not implement this specification, i.e., Delegation Types are >>> processed as ordinary Data Types. >> >> This needs a clarification. 'Delegation Types' are not entirely ordinary >> even for DE=0. >> >> On auth side, they still have to cause occlusion of data underneath them, >> even for DE=0. That's needed so the server can have only a single NSEC chain >> for the zone, and that's really a design requirement for sane implementation. >> >> (Perhaps mention single-NSEC-chain rule in 6. DNSSEC Requirements, too?) >> >> On the other hand, if auth is configured with both parent and child zones, >> then for DE=0 query the zone lookup needs to return *child* zone so the >> generated proof of nonexistence can be validated by unaware client. >> >> On client side, they look like ordinary records, the magic is restricted to >> auth. >> >> Compare with DELEG sections A.1 and A.4.1.3. >> >> DELEG text around this is in 5.2. Authoritative Servers and 5.2.2 needs to >> carry over to DELEXT. >> >> ------------------------------ >> >> ## DELEXT 6.2. Validating a Referral >> >>> When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY >>> RRset of the delegating zone, the validator MUST check the NS-Omitting, >>> NS-Preserving, and Private Delegation Type RRsets in the Authority section >>> of the referral against the Type Bit Maps of the NSEC or NSEC3 record that >>> matches the delegated name. If any are absent, the referral MUST be >>> considered tampered with, and the response MUST be ignored. >> >> NSEC3 Opt-out is not covered (sic). If none of the types are present at all >> (i.e. delegation only with NS and nothing else) then there is no "NSEC3 >> record that _matches_ the delegated name", only a covering NSEC3. >> >> I think we better make this clear. >> >> Secondly: >> >>> If any are absent, the referral MUST be considered tampered with, and the >>> response MUST be ignored. >> >> Some types might be legally omitted, and what about extra types present in >> response but not in the bitmap? >> >> I suggest wording like this: >> """ >> When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY >> RRset of the delegating zone, the validator MUST check the Delegation Type >> RRsets in the Authority section of the referral as follows: >> >> - If an NSEC or NSEC3 RR matching the delegated name is present, the set of >> NS-Omitting, NS-Preserving, and Private Delegation Types present in the >> Authority section MUST be equal to the set of these types in its Type Bit >> Maps field. On-Demand Delegation Types are disregarded in this comparison. >> >> - If the delegated name is covered by an NSEC3 RR with the Opt-Out flag set >> ([RFC5155] Section 8.9), the Authority section MUST NOT contain any >> Delegation Type RRsets. >> >> - Otherwise, the referral lacks the required proof. >> >> If any of these checks fails, the referral was tampered with. >> """ >> >> I also omitted the trailing "response MUST be ignored" because that's not >> what resolvers actually do. They act in an implementation defined way, but >> generally not "ignore" it. >> >> >> Thirdly: >> This triggered a thought that we did not mention TC=1 handling anywhere. I >> think it can be reasonably derived from existing spec, just saying it out >> loud in case people feel differently. >> >> ------------------------------ >> >> ## DELEXT 6.4. Insecure Delegation Proofs >> >>> Alternatively, the validator must make sure that the delegation with an NS >>> record is covered by an NSEC3 RR with the Opt-Out flag set. >> >> I suggest adding word "only", e.g.: >> Alternatively, the validator must make sure that the delegation with only an >> NS record is covered by an NSEC3 RR with the Opt-Out flag set. >> >> Just to make less likely someone will read this incorrectly. >> >> ------------------------------ >> >> ## DELEXT 4.1. Including Delegation Types in a Referral Response >> >>> For DNSSEC-signed zones, the response MUST include DNSSEC proof of the >>> existence or non-existence of Delegation Type RRsets at the delegated name. >> >> I guess it should say "For DNSSEC-signed zones and queries with DO=1," at >> the beginning. Or reference RFC 4035 section 3.1 which explains this, maybe. >> >> ------------------------------ >> >> ## DELEXT 4.2. Explicit Queries for Delegation Types >> >>> When the DE flag is set to 1, a query for a Delegation Type MUST result in >>> an authoritative answer if the queried Delegation Type exists, or a NODATA >>> response (AA flag set, RCODE=0, empty answer section). >> >> I would add a sentence to clarify this section applies only to >> "QNAME=delegation point" queries. If QNAME is longer then response can also >> be referral, NXDOMAIN etc. >> >> ------------------------------ >> >> ## DELEXT 4.3. Queries for type ANY >> >>> Queries for type ANY where the QNAME matches a delegation point with >>> Delegation Types present MUST behave the same way as if a DS record was >>> present at the delegation point. >> >> I think we misunderstood each other when we discussed this in Vienna. The >> ask is: Special handling of Delegation Types for QTYPE=ANY should be >> consistent with special handling already implemented for DS. (Either >> implementation omits it, or includes it - but please please make it >> consistent for all parent-side types incl. DS.) >> >> ------------------------------ >> >> ## DELEG 5.2.1.2. DELEG-aware Clients with NS RRs Present but No DELEG RRs >> >>> According to specification in [I-D.ietf-dnsop-delext], if the delegation >>> does not have a DELEG RRset, the authoritative server puts the NS RRset >>> into the authority section of the referral. >> >> Generalized to range: >> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/214 >> >> ------------------------------ >> >> ## DELEXT 3.5.1. Criteria for Delegation Type Allocation >> >>> The RR type carries information associated with the delegation that is >>> intended to be processed by a resolver. >> >> I suggest generalizing to mere "information associated with the delegation" >> period. I think On-Demand Delegation Types might see non-DNS usage as well. >> Made up examples: DBOUND, maybe a new flavor of CAA, perhaps parent-side >> RP-equivalent so you can contact domain admin if the delegation is down etc. >> (BTW this might be a nice use for DNS Error reporting - right now it cannot >> report that all auths seem to be down, but if it were in parent it could ...) >> >> ------------------------------ >> >> ## DELEXT 5.1. The EDNS(0) DE Flag >> Nit: >> The diagram and bit definition appears only in section 5.1 but the bit is >> referenced already from section 4. >> >> ## DELEXT 6.1. The DNSKEY-ADT Flag >> >>> The DNSKEY Flags field for Authoritative Delegation Types (ADT) consists of >>> 16 bits shown in Figure 2. >> >> Huh, I find this formulation really weird. Perhaps something like this? >> >> "The DNSKEY Flags field consists of 16 bits shown in Figure 2. The >> Authoritative Delegation Types (ADT) flag is bit 14." >> >> ------------------------------ >> >> ## DELEXT 4.1. Including Delegation Types in a Referral Response >> >>> The server SHOULD include the Delegation Extension Required INFO-CODE 34 >>> ("New Delegation Only") Extended DNS Error [RFC8914] specified in >>> [I-D.ietf-deleg] absent a local policy requiring otherwise. >> >> "the Delegation Extension Required" looks like leftover from previous >> version. The registered name is "New Delegation Only". >> >> BTW deleg draft is now referenced as Informative but this reference probably >> upgrades it to normative, I think? >> >> ---------- >> >> ## DELEG examples >> >> I've noticed numerous errors and fixed them: >> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/217 >> >> I feel there must be more! >> >> >> Congratulations if you made it this far. Now, where's YOUR review?! >> > _______________________________________________ > dd mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
