> On 9 Oct 2026, at 14:06, Petr Špaček <[email protected]> wrote:
>
> ## 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?
I’ve added the following in Section 2. Conventions and Definitions:
* 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 RR type
DELEG.
> ------------------------------
>
> ## 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.
Ack. I’ve changed the wording into:
3.1. NS-Omitting Delegation Types
The NS-Omitting Delegation Type segment contains types for delegation
mechanisms that provide sufficient information for processing a
delegation without the NS RRset. Separating these types allows
referral responses to avoid carrying redundant delegation
information, thereby reducing response size. An NS-Omitting
Delegation Type RRset creates a delegation point. Other Delegation
types do not create a delegation point.
> 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.
Good point, I’ve integrated that in the 3.1 text above, and I’ve added the
following to 3.2, 3.3 and 3.4:
3.2. NS-Preserving Delegation Types
.... NS-Preserving Delegation Types MUST NOT appear at
non-delegation points.
3.3. On-Demand Delegation Types
… On-Demand Delegation Types MUST NOT appear at
non-delegation points.
3.4. Private Delegation Types
… Private Delegation Types MUST NOT appear at
non-delegation points.
> ## 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.
Good catch. I’ve made that sentence its own step (2.2.3) and renumber the
original 2.2.3 to 2.2.4
>
> 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.
Fixed.
>
> 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." ?
Perfect. Done.
>
>
> 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"?
Yup. Amount of work. Added.
>
> ------------------------------
>
> ## 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.
It should read “negative response” instead of Name Error. Will fix.
> What if the QNAME=delegation point? In that case it should be "No Data" with
> the accurate type bitmap, right?
Ack. I’m going to use the generic “negative response” for that.
> ------------------------------
>
> ## 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.
There won’t be data underneath them. The server is DELEG aware, but the client
isn’t, so the server treats the DELEG type as an ordinary data type, for the
purpose of generating a response. The NSEC/NSEC3 chain has nothing to do with
it. I’m probably misunderstanding the issue.
> 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.
Why would there be multiple NSEC chains?
> (Perhaps mention single-NSEC-chain rule in 6. DNSSEC Requirements, too?)
Why would there be multiple NSEC chains?
> 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.
Ack, nothing new here.
> On client side, they look like ordinary records, the magic is restricted to
> auth.
Yep.
>
> 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.
Please kindly provide text to help me out, as I don’t know what I’m missing.
> ------------------------------
>
> ## 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).
Indeed. NSEC3 Opt-out range only covers names that are not signed. Since DELEG
records are authoritative in the delegating zone, they are signed, and thus
can’t be opted out.
> 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.
Ack.
> 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.
I have adopted your text.
> 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.
Added.
>
> ------------------------------
>
> ## 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.
Ack. Now reads:
For DNSSEC-signed zones, responses to queries with the DO bit set to 1 MUST
include DNSSEC proof of the existence or non-existence of Delegation Type
RRsets at the delegated name.
>
> ------------------------------
>
> ## 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.
How about:
When the DE flag is set to 1 and the QNAME matches a delegation point, 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) otherwise.
>
> ------------------------------
>
> ## 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.)
Gotcha. Is this better?
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) .
> ------------------------------
>
> ## 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 ...)
Okay. Updated.
(and made a mental note about dns-error-reporting)
>
> ------------------------------
>
> ## 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.
I moved the diagram and bit definition to section 2.3.
>
> ## 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."
Oh dear. Good catch.
> ------------------------------
>
> ## 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".
Yep, removed the “the Delegation Extension Required” part.
>
> BTW deleg draft is now referenced as Informative but this reference probably
> upgrades it to normative, I think?
Absolutely! Done.
Thanks Peter, brilliant work.
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
