Hi Tim,
That is indeed the plan!
Thanks
Roy 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
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 <[email protected]> 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 <[email protected]> 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 [email protected]
> 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] [datatracker.ietf.org [datatracker.ietf.org]]
> [2] https://datatracker.ietf.org/doc/bcp79/ [datatracker.ietf.org] [datatracker.ietf.org [datatracker.ietf.org]]
> [3] https://datatracker.ietf.org/doc/rfc6701/ [datatracker.ietf.org] [datatracker.ietf.org [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] [datatracker.ietf.org [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] [ietf.org [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] [author-tools.ietf.org [author-tools.ietf.org]]
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
|
