DNS Protocol Modifications for Delegation Extensions

2.1. Relationship with the Extensible Delegation for DNS

[I-D.ietf-deleg] specifies a new type (DELEG) that is authoritative at a delegation point, allocated from the Delegation Type range (Section 3).¶

2.2. Relationship with NS and DS Records

The use of DS and delegation point NS records is orthogonal to the use of Delegation Types. NS and DS records MAY coexist with Delegation Types.¶

Although the DS RR type has similar semantics, it is not classified as a Delegation Type for the purposes of this document.¶

2.3. The EDNS(0) DE Flag

EDNS(0) [RFC6891] defines 16 bits as extended flags in the OPT record. These bits are encoded into the TTL field of the OPT record.¶

            +0 (MSB)                            +1 (LSB)
                                              1   1   1   1   1   1
      0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 0: |         EXTENDED-RCODE        |            VERSION            |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 2: | DO| CO| DE|                   Z                               |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: OPT Record TTL Field with DE Flag

The descriptions of the EXTENDED-RCODE, VERSION, DO, and Z are provided in [Section 6.1.3 of @!RFC6891]. The description of the CO flag is provided in [RFC9824].¶

The Delegation Extensions (DE) flag is Bit 2 (Section 9.1).¶

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.¶

3.2. NS-Preserving Delegation Types

The NS-Preserving Delegation Type segment contains types for delegation mechanisms that do not suppress the existing NS RRset. These types supplement, rather than replace, the delegation information provided by the NS RRset or NS-Omitting Delegation Types. NS-Preserving Delegation Types MUST NOT appear at non-delegation points.¶

3.3. On-Demand Delegation Types

The On-Demand Delegation Type segment contains types that are not ordinarily needed in referral responses and can instead be queried for explicitly. This avoids increasing referral response sizes with information that is not required during normal delegation processing. On-Demand Delegation Types MUST NOT appear at non-delegation points.¶

3.4. Private Delegation Types

The Private Delegation Type segment is reserved for Private Use as defined in [Section 4.1 of @!RFC8126]. Private Delegation Types have the same referral behavior as NS-Preserving Delegation Types. This allows Private Delegation Types to be used in referral responses without replacing the delegation information provided by the NS RRset. Private Delegation Types MUST NOT appear at non-delegation points.¶

3.5. Updates to Allocation Policy

[RFC6895] establishes the allocation policy for DNS Resource Record type numbers. Section 3.5.1 defines the criteria for determining whether an RR type is eligible for allocation as a Delegation Type. Section 9.4 specifies additional Expert Review criteria for allocation requests within the range 0xF000-0xF1EF.¶

4.1. Including Delegation Types in a Referral Response

When the EDNS(0) DE flag is set to 1, an authoritative server constructs a referral response according to the segment of each Delegation Type RRset present at the delegated name.¶

NS-Omitting, NS-Preserving, and Private Delegation Type RRsets present at the delegated name MUST be included in the referral response. On-Demand Delegation Type RRsets MUST NOT be included unless explicitly queried for, as described in Section 4.2.¶

If one or more NS-Omitting Delegation Type RRsets are present at the delegated name, the server MUST NOT include the NS RRset in the referral response, regardless of whether NS-Preserving or Private Delegation Type RRsets are also present and regardless of whether QTYPE=NS.¶

If no NS-Omitting Delegation Type RRsets are present, the server MUST include the NS RRset in the referral response. The presence of an NS-Omitting Delegation Type takes precedence over the NS-preserving behavior of an NS-Preserving Delegation Type.¶

For DNSSEC-signed zones, responses to queries with the DO bit set to 1 MUST include DNSSEC proof of the existence or nonexistence of Delegation Type RRsets at the delegated name.¶

Note that when the EDNS(0) 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. The server SHOULD include the INFO-CODE 34 ("New Delegation Only") Extended DNS Error [RFC8914] specified in [I-D.ietf-deleg] absent a local policy requiring otherwise.¶

If future Delegation Types require extended error codes with new semantics, those Delegation Types must define their own codes.¶

4.2. Explicit Queries for Delegation Types

When the EDNS(0) 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).¶

Note that when the EDNS(0) DE flag is clear, the presence of an NS RRset at the delegation point occludes other types, as clarified in [Section 7.18 of @!RFC2136], i.e., if an NS RRset exists at the delegation point, a query for a Delegation Type will result in a referral containing the NS RRset, regardless of whether the queried Delegation Type RRset exists at that delegation point.¶

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).¶

4.4. Delegation Types at a Wildcard Domain Name

Wildcard expansion, as defined in [RFC4592], does not create delegation points, as it was left undefined. Consequently, a wildcard owner name MUST NOT have Delegation Types.¶

5.1. Setting the EDNS(0) DE Flag

A resolver that implements this specification and [I-D.ietf-deleg] sets the EDNS(0) DE flag to 1 when sending a DNS request message. A resolver MUST NOT set the DE flag to 1 unless it implements both specifications.¶

A Delegation-Extension-aware recursive resolver that receives a query with the EDNS(0) DE flag set to 1 MUST set the DE flag to 1 in its response to indicate that Delegation Types are supported.¶

5.2. Referrals

The presence of one or more NS-Omitting Delegation Type RRsets or an NS RRset in the Authority section identifies the response as a referral.¶

When one or more NS-Omitting Delegation Type RRsets are present in a referral, the resolver MUST use the information provided by those Delegation Type RRsets to process the delegation. Any NS records present in the referral MUST be ignored and MUST NOT be validated or cached.¶

When no NS-Omitting Delegation Type RRsets are present, the resolver MUST use the NS RRset to process the delegation. NS-Preserving and Private Delegation Type RRsets present in the referral supplement the delegation information provided by NS-Omitting Delegation Type RRsets or by the NS RRset.¶

The purpose of ignoring NS records in the presence of NS-Omitting Delegation Types is to avoid leakage of DNS messages over unencrypted transport (i.e., Do53) when servers, indicated by Delegation Types, fail to respond.¶

When a signed Delegation Type RRset is the result of a wildcard domain name expansion, the delegation MUST NOT be used. Treat such a delegation point as if all servers were unusable. The label counter in the RRSIG RDATA will be less than the number of labels observed in the owner name.¶

When the referral contains no Delegation Type RRsets, the resolver MUST use NS records. Note that DNSSEC can prove the presence and absence of Delegation Types at a delegation.¶

5.3. Algorithm for "Finding the Best Servers to Ask"

This document updates instructions for finding the best servers to ask, covered in [Section 5.3.3 of @!RFC1034] and [Section 3.4.1 of @!RFC6672] with the text "2. Find the best servers to ask." These instructions were informally updated by [Section 4.2 of @!RFC4035] for the DS RR type.¶

This document applies the behavior for DS RR types to Delegation Types.¶

Each delegation level can have a mixture of Delegation Types and NS RR types, and Delegation-Extension-aware resolvers MUST be able to follow chains of delegations which combine both types in arbitrary ways.¶

The terms SNAME and SLIST used here are defined in [Section 5.3.2 of @!RFC1034]:¶

• SNAME is the domain name a query is searching for.¶

• SLIST is a structure which describes the name servers and the zone which the resolver is currently trying to query.¶

This document defines SLIST to be a set. Each individual value MUST be represented only once in the final SLIST even if it was encountered multiple times during SLIST construction.¶

Neither [RFC1034] nor this document defines how a resolver uses SLIST. They only define how to populate it.¶

A Delegation-Extension-aware resolver's SLIST needs to be able to hold multiple types of information, delegations defined by an NS RRset, and delegations defined by Delegation Type RRsets.¶

Delegations can create cyclic dependencies and/or lead to duplicate entries which point to the same server.¶

Resolvers need to enforce suitable limits to prevent runaway processing even if someone has incorrectly configured some of the data used to create an SLIST.¶

This is the same recommendation to bound the amount of work specified in [Section 5.3.3 of @!RFC1034].¶

Step 2 of [Section 5.3.3 of @!RFC1034] is "2. Find the best servers to ask."¶

For Delegation-Extension-aware resolvers, this description becomes:¶

2. Find the best servers to ask:¶

2.1. Determine the deepest possible zone cut which can potentially hold the answer for a given (query name, type, class) combination as follows:¶

2.1.1. Start with SNAME equal to QNAME.¶

2.1.2. If QTYPE is a type that is authoritative at the delegation point (DS or the range defined in this document), remove the leftmost label from SNAME.¶

For example, if the QNAME is "test.example." and the QTYPE is a Delegation Type or DS, set SNAME to "example.".¶

2.2. Look for locally available Delegation Types and NS RRsets, starting at the current SNAME.¶

2.2.1. For a given SNAME, check for the existence of NS-Omitting Delegation Type RRsets.¶

If they exist, the resolver MUST use their content to populate SLIST.¶

However, if the Delegation Type RRsets are known to exist but are unusable (for example, if they are found in the DNSSEC BAD cache, or the content of individual RRs is unusable for any reason), the resolver MUST NOT use an NS RRset; the resolver MUST treat this case as if SLIST is populated with unreachable servers.¶

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.¶

2.2.3. The resolver MUST process any NS-Preserving or Private Delegation Type RRsets according to the specification defining those types.¶

2.2.4. If a given SNAME is proven to not have any Delegation Type RRsets or an NS RRset, remove the leftmost label from SNAME and go back to step 2.2, using the newly shortened SNAME. Note the existence of these RRsets stops this algorithm even if the SLIST is empty or if servers referenced by SLIST are unusable for any reason.¶

The rest of Step 2's description in [Section 5.3.3 of @!RFC1034] is not affected by this document.¶

Note that a query for QNAME="." and QTYPE=DS (or a Delegation Type) is nonsensical, as there is no zone that delegates to the root zone.¶

6.1. The DNSKEY-ADT Flag

The DNSKEY Flags field consists of 16 bits shown in Figure 2.¶

                                           1   1   1   1   1   1
   0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 |                           |ZON|REV|                   |ADT|SEP|
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: DNSKEY Flags Field

The descriptions of the ZONE (ZON) and Secure Entry Point (SEP) flags are provided in [RFC4034]. The description of the REVOKE (REV) flag is provided in [RFC5011].¶

The Authoritative Delegation Types (ADT) flag is bit 14 of the DNSKEY Flags field (Section 9.2).¶

When the ADT flag is set to 1, it indicates to a validator that a referral MUST contain an NSEC or NSEC3 record to prove the presence or absence of types for the delegated name.¶

6.2. Validating a Referral

On receiving a referral from a DNSSEC-signed delegating zone, a validating resolver MUST determine the authenticated state of the ADT flag from a validated DNSKEY RRset for that zone.¶

When the 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 corresponding types indicated by 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 ([Section 8.9 of @!RFC5155]), the Authority section MUST NOT contain any Delegation Type RRsets.¶
• Otherwise, the referral must be considered tampered with.¶

On-Demand Delegation Types indicated by the Type Bit Maps are not required to be present in a referral response.¶

When the ADT flag is clear, this consistency check does not apply. To be explicit, it means that a positive response with a DELEG RRset MUST NOT be treated as DNSSEC-bogus due to a clear ADT flag. The resolver processes the referral according to the procedures defined in Section 5.¶

6.3. Clarifications on Nonexistence Proofs

This document updates [Section 4.1 of @!RFC6840] to include "NS or Delegation Types" in the Type Bit Maps as an indication of a delegation point, and generalizes applicability of ancestor delegation proof to all RR types that are authoritative at a delegation point.¶

The text in that section is updated as follows:¶

An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:¶

• the NS and/or Delegation Type bits set,¶

• the Start of Authority (SOA) bit clear, and¶

• a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR.¶

Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that original owner name, other than types authoritative at the delegation point (DS and Delegation Types), and all RRs below that owner name regardless of type.¶

6.4. Insecure Delegation Proofs

This document updates [Section 4.4 of @!RFC6840] to include securing delegation point RRsets. The first paragraph of that section is updated to read:¶

[Section 5.2 of @!RFC4035] specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) Type Bit Maps; this was clarified in [Section 4.1 of @!RFC6840].¶

This document updates [RFC4035] and [RFC6840] to specify that the validator MUST check for the presence of the NS or Delegation Type bits in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation).¶

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.¶

Opt-Out is not applicable to delegations with Delegation Type RRsets because Delegation Type RRsets are authoritative at the delegation point.¶

8.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.¶

8.2. Downgrade Attacks

Two classes of downgrade attack are relevant to this specification.¶

8.3. Injection of Delegation Types

Section 5.2 specifies that when NS-Omitting Delegation Type RRsets are present in a referral response, accompanying NS records are ignored. An attacker capable of injecting or forging a referral response could exploit this rule by introducing fabricated Delegation Type RRsets into the response, causing the resolver to ignore legitimate NS records and use only the attacker-supplied NS-Omitting Delegation Type RRsets, 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 6. A validating resolver will reject responses containing unsigned or incorrectly signed Delegation Type RRsets.¶

In unsigned zones, no cryptographic protection against this attack is available.¶

8.4. Denial-of-Service via DE Flag Manipulation

Section 4.1 notes that when the DE flag is clear and no NS RRset exists at a delegation point, the authoritative name server must return a negative response. This behavior is intended to prevent a non-Delegation-Extension-aware resolver from exhausting other authoritative name servers for information it cannot act upon.¶

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 [Section 4.1 of @!RFC6840], 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.¶

Conversely, an on-path attacker may strip the DE flag from a query sent by a Delegation-Extension-aware resolver to a zone that publishes only Delegation Types and no NS RRsets, causing the server to return a negative response for a name that legitimately exists.¶

However, a resolver that sets the DE flag expects NSEC or NSEC3 proof in any negative response, demonstrating that the queried name does not exist or that no Delegation Types are present at or above it. A bare negative 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 a negative response that does not include the required NSEC or NSEC3 records, as the absence of proof indicates tampering. Authoritative name servers for a delegating zone that employ Compact Denial of Existence [RFC9824] MUST NOT satisfy this proof with an NXNAME-based response matching the queried name, because such a response omits the Delegation Type bits at the delegation point on which this detection relies. They MUST instead return a conventional Name Error proof as described in Section 4.1.1.¶

As with the attacks described in Section 8.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-flag-stripping attack may result in a negative 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 8.5.¶

Authoritative name servers SHOULD include an Extended DNS Error [RFC8914] code in negative responses returned when the DE flag is clear and no NS RRset exists, to assist in diagnosing misconfiguration or attack, absent a local policy requiring otherwise.¶

8.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 name 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 8.2 only when the delegating zone is DNSSEC-signed, the ADT flag is set in the zone's DNSKEY RRset, and the resolver performs validation. In zones that publish Delegation Types but have not set the ADT flag in the DNSKEY RRset, or that are not DNSSEC-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.¶

9.1. The EDNS(0) DE Flag

IANA is requested to assign Bit 2 in the "EDNS Header Flags (16 bits)" registry under the "Domain Name System (DNS) Parameters" registry group to "DE Delegation Extensions", available at https://www.iana.org/assignments/dns-parameters with this document as the Reference as follows:¶

Bit     Flag   Description                  Reference
Bit 2    DE    Delegation Extensions        This-document

9.2. The DNSKEY-ADT Flag

IANA is requested to assign bit 14 of the 16-bit flags field in the "DNSKEY RR Flags" registry under the "DNSKEY FLAGS" registry group available at https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml as follows:¶

Number   Description                        Reference
  14     Authoritative Delegation Types     This-document

9.3. Changes to the DNS Parameters RR Types Registry

IANA is requested to update reservations in the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group, available at https://www.iana.org/assignments/dns-parameters with this document as the Reference.¶

Decimal  Hex       Registration Procedures  Note
61440-   0xF000-   Expert Review or         NS-Omitting
61567    0xF07F    Standards Action         Delegation TYPEs

61568-   0xF080-   Expert Review or         NS-Preserving
61695    0xF0FF    Standards Action         Delegation TYPEs

61696-   0xF100-   Expert Review or         On-Demand
61935    0xF1EF    Standards Action         Delegation TYPEs

61936-   0xF1F0-   Private Use              Private
61951    0xF1FF                             Delegation TYPEs

Allocation requests in the range 0xF000-0xF1EF require Expert Review or Standards Action. The allocation must be made from the segment corresponding to the referral behavior of the Delegation Type as defined in Section 3. The Designated Experts for this range are drawn from the RFC6895 Experts Pool.¶

9.4. Additional Expert Review Criteria

In addition to the general Expert Review criteria established by [RFC6895], the Designated Experts should evaluate allocation requests for Delegation Types against the criteria in Section 3.5.1. The Designated Experts should also consider:¶

• Whether the requested segment is appropriate for the referral behavior of the proposed Delegation Type. A type that provides sufficient information to process a delegation without the NS RRset should be allocated from the NS-Omitting segment. A type that supplements the delegation should be allocated from the NS-Preserving segment. A type that is not ordinarily required in referral responses should be allocated from the On-Demand segment.¶

• Whether the proposed Delegation Type requires protocol modifications beyond those defined in this document, and if so, whether those modifications have been or are being specified in an appropriate Standards Track document.¶

• Whether the proposed Delegation Type can be processed safely by Delegation-Extension-aware implementations that do not specifically implement the proposed type, in particular with respect to the requirements in Section 5.2 and Section 4.1.¶

• Whether the security properties of the proposed Delegation Type are compatible with the DNSSEC signing requirements of Section 6, and whether any additional security considerations apply.¶

The Designated Experts may approve allocation requests accompanied by a stable, publicly available specification that need not be an RFC, provided that the specification is sufficiently detailed to allow independent interoperable implementation.¶

Allocation requests for Delegation Types that introduce new protocol behaviors or that interact with the mechanisms defined in Section 4, Section 5, or Section 6 of this document must be accompanied by, or integrated into, a Standards Track document.¶