[DNSOP] Re: [Ext] WG Last Call: draft-ietf-dnsop-delext-02 (Ends 2026-05-07)

[Tim Wicinski <[e-mail]>]

Roy

Thanks for this ! at first read it looks good.   Also thanks for adding in
the Operational Consideration and section 2.1.

I take it you plan to push a new document update when last call is over?

thanks

tim


On Mon, May 4, 2026 at 7:39 PM Roy Arends <[e-mail]> wrote:

> Hi Tim,
>
> I’ve just now added a security section:
>
> 6.  Security Considerations
>
>    This section discusses the security properties of the mechanisms
>    defined in this document, identifies attack surfaces, and describes
>    the mitigations provided or required.
>
> 6.1.  Threat Model
>
>    The threat model assumed by this document includes an on-path
>    attacker capable of intercepting, modifying, dropping, and injecting
>    DNS messages in transit between a resolver and an authoritative name
>    server.  Off-path attackers capable of response forgery (e.g., via
>    birthday attacks on UDP) are also considered.  Attackers may attempt
>    to cause a resolver to use unencrypted transport, to resolve names
>    incorrectly, or to be denied service entirely.
>
> 6.2.  Downgrade Attacks
>
> 6.2.1.  Stripping of Delegation Types from Referrals
>
>    An on-path attacker may remove Delegation Types and associated NSEC
>    or NSEC3 records from a referral response, leaving only unsigned NS
>    records.  A resolver that accepts such a modified referral would
>    proceed to resolve the delegated name using unencrypted transport,
>    defeating the purpose of Delegation Types such as those indicating
>    encrypted transport parameters.
>
>    The DNSKEY-ADT flag defined in Section 5.1 provides a mitigation
>    against this attack for validating resolvers.  When the ADT flag is
>    set in any DNSKEY of the delegating zone's DNSKEY RRset, a validating
>    resolver MUST verify that the referral contains NSEC or NSEC3 records
>    proving the presence or absence of Delegation Types for the delegated
>    name.  A referral lacking this proof MUST be treated as tampered with
>    and MUST be ignored.
>
>    This mitigation is effective only when all of the following
>    conditions hold:
>
>    *  The delegating zone is signed with DNSSEC.
>    *  The ADT flag is set in the delegating zone's DNSKEY RRset.
>    *  The resolver performs DNSSEC validation.
>    *  The resolver enforces the ADT requirement as specified in
>       Section 5.2
>
>    Operators of zones that publish Delegation Types MUST set the ADT
>    flag in their DNSKEY RRset to ensure that validating resolvers can
>    detect this form of tampering.  Zones that have not set the ADT flag
>    provide no cryptographic protection against this attack.
>
> 6.2.2.  Stripping of the DE Flag from Queries
>
>    The DE flag is carried in the EDNS(0) OPT record of query messages
>    sent by resolvers.  An on-path attacker may remove this flag from a
>    query before it reaches the authoritative name server.  A server that
>    receives a query with DE clear will respond without Delegation Types,
>    returning NS records only.
>
>    However, when the ADT flag is set in the delegating zone's DNSKEY
>    RRset, a validating resolver expects that NSEC or NSEC3 proof of
>    Delegation Types MUST accompany any referral from that zone.  This
>    obligation is established by the DNSKEY, not negotiated per-query via
>    the DE flag.  Consequently, a referral response lacking the required
>    NSEC or NSEC3 records MUST be rejected by a validating resolver,
>    whether or not the DE flag was stripped from the outgoing query.  In
>    this case, the ADT mechanism defeats the DE-stripping attack.
>
>    This mitigation is subject to the same conditions as those listed in
>    Section 6.2.1: the delegating zone must be signed, ADT must be set,
>    and the resolver must validate.  In the absence of these conditions,
>    no cryptographic protection against DE-flag stripping is available,
>    and the considerations in Section 6.5 apply.
>
> 6.2.3.  Interaction Between Flag Stripping Attacks
>
>    The two downgrade attacks described above may be attempted in
>    combination.  An attacker who strips the DE flag from a query causes
>    the authoritative server to respond with NS records only and no
>    Delegation Types.  Without Delegation Types in the response, the
>    resolver cannot apply the NS-ignoring rule defined in Section 3.2,
>    and would ordinarily follow the NS records to resolve the delegated
>    name, potentially over unencrypted transport.
>
>    As described in Section 6.2.2, the ADT flag defeats this combined
>    attack for validating resolvers in zones where ADT is set.  The
>    resolver's obligation to require NSEC or NSEC3 proof derives from the
>    previously validated DNSKEY RRset, not from the contents of the
>    referral itself.  A referral containing only NS records, with no NSEC
>    or NSEC3 proof, will be rejected regardless of whether Delegation
>    Types were present.
>
>    The residual risk in both Section 6.2.2 and this section therefore
>    reduces to the same condition: zones in which ADT is not set, or in
>    which DNSSEC is not deployed, provide no cryptographic protection
>    against either attack.  This is a deployment risk, addressed in
>    Section 6.5.
>
> 6.3.  Injection of Delegation Types
>
>    Section 3.2 specifies that when Delegation Types are present in a
>    referral response, accompanying NS records MUST be ignored.  An
>    attacker capable of injecting or forging a referral response could
>    exploit this rule by introducing a fabricated Delegation Type into
>    the response, causing the resolver to ignore legitimate NS records
>    and use only the attacker-supplied Delegation Type, which may point
>    to an attacker-controlled server.
>
>    This attack is mitigated by DNSSEC.  In a DNSSEC-signed zone,
>    Delegation Type RRsets MUST be signed as specified in Section 5.  A
>    validating resolver will reject responses containing unsigned or
>    incorrectly signed Delegation Types.
>
>    In unsigned zones, no cryptographic protection against this attack is
>    available.
>
> 6.4.  Denial of Service via NXDOMAIN for Legacy Resolvers
>
>    Section 4.1 specifies that when the DE flag is clear and no NS
>    records exist for a referral, the authoritative name server SHOULD
>    return a Name Error (NXDOMAIN) response.  This behavior is intended
>    to prevent a legacy resolver from exhausting other authoritative
>    servers for information it cannot act upon.
>
>    An attacker may attempt to exploit this behavior by stripping the DE
>    flag from a query directed at a zone that publishes only Delegation
>    Types and no NS records, causing the server to return NXDOMAIN for a
>    name that legitimately exists.
>
>    However, a resolver that set the DE flag expects NSEC or NSEC3 proof
>    in any NXDOMAIN response, demonstrating that the queried name does
>    not exist or that no Delegation Types are present at or above it.  A
>    bare NXDOMAIN response lacking such proof is therefore detectable by
>    a validating resolver.  When the ADT flag is set in the delegating
>    zone's DNSKEY RRset, the resolver MUST reject an NXDOMAIN response
>    that does not include the required NSEC or NSEC3 records, as the
>    absence of proof indicates tampering.
>
>    As with the attacks described in Section 6.2, this mitigation depends
>    on the delegating zone being DNSSEC-signed, ADT being set, and the
>    resolver performing validation.  In zones where these conditions do
>    not hold, a DE-stripping attack may result in an NXDOMAIN response
>    that the resolver cannot distinguish from a legitimate one, causing a
>    denial of service for the queried name.  This residual risk is
>    addressed in Section 6.5.
>
>    Authoritative servers SHOULD include an Extended DNS Error [RFC8914]
>    code in NXDOMAIN responses returned when the DE flag is clear and no
>    NS records exist, to assist in diagnosing misconfiguration or attack.
>
> 6.5.  Partial Deployment and Transition Risks
>
>    The mechanisms defined in this document are effective only when
>    deployed end-to-end.  During the transition period in which some
>    resolvers, authoritative servers, and zones have adopted this
>    specification and others have not, a number of residual risks apply.
>
>    The ADT flag provides protection against the downgrade attacks
>    described in Section 6.2 only when the delegating zone is DNSSEC-
>    signed, ADT is set in the zone's DNSKEY RRset, and the resolver
>    performs validation.  In zones that publish Delegation Types but have
>    not set ADT, or that are not signed, no cryptographic protection
>    against referral-stripping or DE-flag-stripping attacks is available.
>
>    Zone operators that publish Delegation Types in signed zones are
>    REQUIRED to set the ADT flag upon deployment.  Zones relying on
>    Delegation Types for security properties such as encrypted transport
>    MUST be DNSSEC-signed.
>
> Warmly
>
> Roy
>
>
>
> > On 4 May 2026, at 21:02, Tim Wicinski <[e-mail]> wrote:
> >
> > Hi
> >
> > I had a question on the "Security Considerations" section
> >
> >    This section discusses security considerations, including downgrade
> >    attacks and resolver behavior.  Further details will be added.
> >
> > Do we have any idea when this will come together?
> >
> > thanks
> >
> > tim
> >
> >
> > On Thu, Apr 23, 2026 at 3:53 PM Ondřej Surý via Datatracker <
> [e-mail]> wrote:
> > Dear dnsop WG,
> >
> > the authors of the document said the document is ready for the WGLC
> > and the dnsop WG chairs have considered the discussions on the mailing
> > list and the state the document and we consider the document to be
> > ready for the WGLC.  Hence this message starts a WG Last Call for:
> > draft-ietf-dnsop-delext-02
> >
> > This Working Group Last Call ends on 2026-05-07
> >
> > Abstract:
> >    The Domain Name System (DNS) protocol permits Delegation Signer (DS)
> >    records at delegation points.  This document describes modifications
> >    to the Domain Name System (DNS) protocol to permit a range of
> >    resource record types at delegation points.  These modifications are
> >    designed to maintain compatibility with existing DNS resolution
> >    mechanisms and provide a secure method for processing these records
> >    at delegation points.
> >
> > File can be retrieved from:
> >
> > Please review and indicate your support or objection to proceed with the
> > publication of this document by replying to this email keeping
> [e-mail]
> > in copy. Objections should be explained and suggestions to resolve them
> are
> > highly appreciated.
> >
> > Authors, and WG participants in general, are reminded of the Intellectual
> > Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> > Appropriate IPR disclosures required for full conformance with the
> provisions
> > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> > Sanctions available for application to violators of IETF IPR Policy can
> be
> > found at [3].
> >
> > Thank you.
> >
> > [1] https://datatracker.ietf.org/doc/bcp78/ [datatracker.ietf.org]
> > [2] https://datatracker.ietf.org/doc/bcp79/ [datatracker.ietf.org]
> > [3] https://datatracker.ietf.org/doc/rfc6701/ [datatracker.ietf.org]
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-delext/ [
> datatracker.ietf.org]
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-dnsop-delext-02.html [
> ietf.org]
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-delext-02 [
> author-tools.ietf.org]
> >
> > _______________________________________________
> > DNSOP mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>