Extensible Delegation for DNS

3.1.1. Signaling DELEG support

A resolver that is DELEG-aware MUST signal its support by sending the DE bit when iterating.¶

This bit is referred to as the "DELEG" (DE) bit. In the context of the EDNS0 OPT meta-RR, the DE bit is the TBD of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows (to be updated when assigned):¶

            +0 (MSB)                +1 (LSB)
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  0: |   EXTENDED-RCODE      |       VERSION         |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2: |DO|CO|DE|              Z                       |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Setting the DE bit to one in a query indicates the resolver understands new DELEG semantics and does not need NS records to follow a referral. The DE bit cleared (set to zero) indicates the resolver is unprepared to handle DELEG and hence can only be served NS, DS and glue in a delegation response.¶

Motivation: For a long time there will be both DELEG and NS needed for delegation. As both methods should be configured to get to a proper resolution it is not necessary to send both in a referral response. We therefore purpose an EDNS flag to be use similar to the DO Bit for DNSSEC to be used to signal that the sender understands DELEG and does not need NS or glue information in the referral.¶

3.1.2. Referral

The DELEG record creates a zone cut similar to the NS record.¶

If one or more DELEG records exist at a given delegation point, a DELEG-aware resolver MUST treat the name servers from those DELEG records as authoritative for the child zone. In such case, a DELEG-aware resolver MUST NOT use NS records even if they happen to be present in cache, even if resolution using DELEG records have failed for any reason. Such fallback from DELEG to NS would invalidate security guarantees of DELEG protocol.¶

If no DELEG record exists at a given delegation point, DELEG-aware resolvers MUST use NS records as specified by [RFC1034].¶

3.1.3. Parent-side types, QTYPE=DELEG

Record types defined as authoritative on the parent side of zone cut (currently DS and DELEG types) retain the same special handling as described in Section 2.6 of [RFC4035].¶

Legacy resolvers can get different types of answers for QTYPE=DELEG queries based on the configuration of the server, such as whether it is DELEG-aware and whether it also is authoritative for subdomains.¶

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

This document updates instructions for finding the best servers to ask. That information currently is 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." Section 3.1.4.1 of [RFC4035] should have explicitly updated Section 5.3.3 of [RFC1034] for the DS RRtype, but failed to do so; this was remedied by [RFC6672]. This document simply extends this existing behavior to DELEG RRtype as well, and makes this special case explicit.¶

When a DELEG RRset exists in a zone, DELEG-aware resolvers ignore the NS RRset for that zone. This means that the DELEG-aware resolver ignores the NS RRset in the zone's parent as well as any cached NS RRset that the resolver might have gotten by looking in the apex of the zone.¶

DELEG and NS RRtypes can be used differently at each delegation level, and DELEG-aware resolvers MUST be able follow chains of delegations which combines both types in arbitrary ways.¶

An example of a valid delegation tree:¶

; root zone with NS-only delegations
. SOA ...
test. NS ...

; test. zone with NS+DELEG delegations
test. SOA ...
sld.test. NS ...
sld.test. DELEG ...

; sld.test. zone with NS-only delegation
sld.test. SOA ...
nssub.sld.test. NS ...

; nssub.sld.test. zone with DELEG-only delegation
delegsub.sub.sld.test. DELEG ...

TODO: after the text below, refer back to this figure and show the order that a DELEG-aware resolver would take when there is a failure to find any good DELEG addresses at sub.sld.test, then any usable nameservers at sub.sld.test, and then maybe a good DELEG record at test.¶

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

SNAME is the domain name we are searching for.¶

SLIST is a structure which describes the name servers and the zone which the resolver is currently trying to query. Neither [RFC1034] nor this document define how a resolver uses SLIST; they only define how to populate it.¶

A DELEG-aware SLIST needs to be able to hold two types of information: delegations defined by NS records and delegations defined by DELEG records. DELEG and NS 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 damage even if someone has incorrectly configured some of the data used to create an SLIST.¶

This leads to a modified description of find the best servers to ask" from earlier documents for DELEG-aware resolvers. That description becomes:¶

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

   1. Start with SNAME equal to QNAME.¶

   2. If QTYPE is a type that is authoritative at the parent side of a zone cut (currently, DS or DELEG), remove the leftmost label from SNAME. For example, if the QNAME is "test.example." and th eQTYPE is DELEG or DS, set SNAME to "example.".¶

2. Look for locally-available DELEG and NS RRsets, starting at current SNAME.¶

   1. For given SNAME, check for existence of a DELEG RRset. If it exists, the resolver MUST use its content to populate SLIST. However, if the DELEG RRset is known to exist but is unusable (for example, if it is found in DNSSEC BAD cache), the resolver MUST NOT instead use an NS RRset, even if it is locally available; instead, the resolver MUST treat this case as if no servers were available.¶

   2. If a given SNAME is proven to not have a DELEG RRset but does have NS RRset, the resolver MUST copy the NS RRset into SLIST.¶

   3. If SLIST is now populated, stop walking up the DNS tree. However, if SLIST is not populated, remove leftmost label from SNAME and go back to the first step, using the new (shortened) SNAME. Do not go back to the first step if doing so would exceed the amount of work that the resolver is configured to do when processing names; see Section 4.1.¶

The rest of the Step 2's description is not affected by this document.¶

(TODO: Determine what to do about ". DELEG" or ". DS" queries, which by definition do not exist.)¶

3.1.5. Actions in Delegation Information

The DELEG and DELEGI records have four keys that describe actions the resolver takes. The purpose of these actions is to populate the SLIST with IP addresses of the nameservers for a zone. The actions defined in this document are:¶

• server-ip4: a set of IPv4 addresses for nameservers of the given zone¶

• server-ip6: a set of IPv6 addresses for nameservers of the given zone¶

• server-name: the domain name of a nameserver of the given zone; the addresses must be fetched¶

• include-name: the domain name of a zone that has more information about the nameservers of the given zone¶

The presentation values for server-ip4 and server-ip6 are comma-separated list of one or more IP addresses of the appropriate family in standard textual format [RFC5952] [RFC4001]. The wire formats for server-ip4 and server-ip6 are a sequence of IP addresses in network byte order (for the respective address family).¶

The presentation values for server-name and include-name are as full-qualified domain names. The wire formats are the same as the wire formats for domain names, and MUST NOT be compressed.¶

If any of these keys are used, it MUST have a value (that is, it cannot be a key with a zero-length value).¶

A DELEG or DELEGI record SHOULD have only one of the following:¶

• one server-ip4 key¶

• one server-ip6 key¶

• one server-ip4 and one server-ip6 key¶

• one server-name key¶

• one include-name key¶

3.1.6. Populating the SLIST from DELEG and DELEGI Records

Each individual DELEG record inside a DELEG RRset, or each individual DELEGI record in a DELEGI RRset, can cause the addition of zero or more entries to SLIST.¶

A resolver processes each individual DELEG record within a DELEG RRset, or each individual DELEGI record in a DELEGI RRset, using the following steps:¶

1. If one or more server-ip4 or server-ip6 actions are present inside the record, copy all the address values from either key into SLIST. Ignore any server-name or include-name keys that are (erroneously) present in the same record. Stop processing this record.¶

2. If a server-name action is present in the record, resolve it into addresses from the resolver cache or using A and AAAA queries. Copy these addresses into SLIST. Ignore any include-name keys that are (erroneously) present in the same record. Stop processing this record.¶

3. If a include-name action is present in the record, resolve it into a DELEGI RRset from the resolver cache or by sending queries for the domain name in the value of the include-name pair. Go through these same steps with the result of the DELEGI RRset, after checking that the maximum loop count described in Section 4.1 has not been reached.¶

4. If none of the above applies, SLIST is not modified by this particular record.¶

A DELEG-aware resolver MAY implement lazy filling of SLIST, such as by deferring processing remaining records if SLIST already has what the resolver considers a sufficiently large pool of addresses to contact.¶

3.2.1. DELEG-unaware Clients

DELEG-unaware clients do not use DELEG records for delegation. When a DELEG-aware authoritative server responds to a DELEG-unaware client, any DELEG record in the response does not create zone cut, is not returned in referral responses, and is not considered authoritative on the parent side of a zone cut. Because of this, DELEG-aware authoritative servers MUST answer as if they are DELEG-unaware. Please note this instruction does not affect DNSSEC signing, i.e. no special handling for NSEC type bitmap is necessary and DELEG RRtype is accurately represented even for DELEG-unaware clients.¶

Two specific cases of DELEG-aware authoritative responding in DELEG-unaware manner are described here.¶

3.2.2. DELEG-aware Clients

When the client indicates that it is DELEG-aware by setting DE=1 in the query, DELEG-aware authoritative servers treat DELEG records as zone cuts, and the servers are authoritative on parent side of zone cut. This new zone cut has priority over legacy delegation with NS RRset.¶

3.4.1. Clarifications on Nonexistence Proofs

This document updates Section 4.1 of [RFC6840] to include "NS or DELEG" types in type bitmap as indication of a delegation point, and generalizes applicability of ancestor delegation proof to all RRtypes that are authoritative at the parent (that is, both DS and DELEG). The text in that section is updated as follows:¶

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

• the NS and/or DELEG bit 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 parent-side of zone cut (DS and DELEG), and all RRs below that owner name regardless of type.¶

3.4.2. Insecure Delegation Proofs

This document updates Section 4.4 of [RFC6840] to include secure DELEG support, and explicitly states that Opt-Out is not applicable to DELEG. 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 bitmap. The validator also MUST check for the presence of the NS or the DELEG bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation). Alternately, the validator must make sure that the delegation with NS record is covered by an NSEC3 RR with the Opt-Out flag set. Opt-Out is not applicable to DELEG RRtype because DELEG records are authoritative at the parent side of a zone cut in the same way that DS RRtypes are.¶

3.4.3. Referral downgrade protection

When DNSKEY flag ADT is set to 1, a DELEG-aware validator MUST prove the absence of a DELEG RRset in referral responses for a zone.¶

Without this check, an attacker could strip the DELEG RRset from a referral response and replace it with an unsigned (and potentially malicious) NS RRset. A referral response with an unsigned NS and signed DS RRsets does not require additional proofs of nonexistence according to pre-DELEG DNSSEC specification, and it would have been accepted as a delegation without DELEG RRset.¶

3.4.4. Chaining

A Validating Stub Resolver that is DELEG-aware has to use a Security-Aware Resolver that is DELEG-aware and, if it is behind a forwarder, that forwarder has to be security-aware and DELEG-aware as well.¶

5.2.1. Procedure

A registration MUST include the following fields:¶

Number: Wire-format numeric identifier (range 0-65535) Name: Unique presentation name Meaning: A short description Reference: Location of specification or registration source Change Controller: Person or entity, with contact information if appropriate¶

The characters in the registered Name field entry MUST be lowercase alphanumeric or "-". The name MUST NOT start with "key".¶

The registration policy for new entries is Expert Review ([RFC8126]). The designated expert MUST ensure that the reference is stable and publicly available and that it specifies how to convert the delegation information's presentation format to wire format. The reference MAY be any individual's Internet-Draft or a document from any other source with similar assurances of stability and availability. An entry MAY specify a reference of the form "Same as (other key name)" if it uses the same presentation and wire formats as an existing key.¶

This arrangement supports the development of new parameters while ensuring that zone files can be made interoperable.¶

5.2.2. Initial Contents

The "DELEG Delegation Information" registry should be populated with the following initial registrations:¶

Number:  1
Name:  server-ip4
Meaning:  A set of IPv4 addresses of nameservers
Reference:  {{actions}} of this document
Change Controller:  IETF

Number:  2
Name:  server-ip6
Meaning:  A set of IPv6 addresses of nameservers
Reference:  {{actions}} of this document
Change Controller:  IETF

Number:  3
Name:  server-name
Meaning:  The fully-qualified domain name of a nameserver
Reference:  {{actions}} of this document
Change Controller:  IETF

Number:  4
Name:  include-name
Meaning:  The fully-qualified domain of a DELEGI record
Reference:  {{actions}} of this document
Change Controller:  IETF

The registration for number 0 is reserved.
The registration for numbers 65280-65535 is reserved for private use.

A.2.1. Query for foo.example

;; Header: QR RCODE=0
;;

;; Question
foo.example.  IN MX

;; Answer
;; (empty)

;; Authority
example.   300 IN NS    a.example.
example.   300 IN NS    b.example.net.
example.   300 IN NS    c.example.org.

;; Additional
a.example. 300 IN A     192.0.2.1
a.example. 300 IN AAAA  2001:DB8::1

A.2.2. Query for foo.test

;; Header: QR AA RCODE=3
;;

;; Question
foo.test.   IN MX

;; Answer
;; (empty)

;; Authority
.   300 IN SOA ...

;; Additional
;; OPT with Extended DNS Error: New Delegation Only

A.3.1. Query for foo.example

;; Header: QR DO RCODE=0
;;

;; Question
foo.example.   IN MX

;; Answer
;; (empty)

;; Authority

example.   300 IN NS    a.example.
example.   300 IN NS    b.example.net.
example.   300 IN NS    c.example.org.
example.   300 IN DS    65163 13 2 5F86F2F3AE2B02...
example.   300 IN RRSIG DS 13 4 300 20250214164848 (
                        20250207134348 21261 . O0k558jHhyrC21J..= )
;; Additional
a.example. 300 IN A     192.0.2.1
a.example. 300 IN AAAA  2001:DB8::1

A.3.2. Query for foo.test

;; Header: QR DO AA RCODE=3
;;

;; Question
foo.test.      IN MX

;; Answer
;; (empty)

;; Authority
.          300 IN SOA ...
.          300 IN RRSIG SOA ...
.          300 IN NSEC  aaa NS SOA RRSIG NSEC DNSKEY ZONEMD
.          300 IN RRSIG NSEC 13 4 300
test.      300 IN NSEC  a.test. RRSIG NSEC DELEG
test.      300 IN RRSIG NSEC 13 4 300  20250214164848 (
                        20250207134348 21261 . aBFYask;djf7UqlK..= )

;; Additional
;; OPT with Extended DNS Error: New Delegation Only

A.4.1. Query for foo.example

;; Header: QR DE RCODE=0
;;

;; Question
foo.example.  IN MX

;; Answer
;; (empty)

;; Authority
example.   300 IN DELEG server-name=a.example.
example.   300 IN DELEG include-name=ns2.example.net.
example.   300 IN DELEG include-name=ns3.example.org.

;; Additional
;; (empty)

A.4.2. Query for foo.test

;; Header: QR AA RCODE=0
;;

;; Question
foo.test.   IN MX

;; Answer
;; (empty)

;; Authority
test.      300 IN DELEG include-name=ns2.example.net

;; Additional
;; (empty)

A.5.1. Query for foo.example

;; Header: QR DO DE RCODE=0
;;

;; Question
foo.example.  IN MX

;; Answer
;; (empty)

;; Authority

example.   300 IN DELEG server-name=a.example.
example.   300 IN DELEG include-name=ns2.example.net.
example.   300 IN DELEG include-name=ns3.example.org.
example.   300 IN RRSIG DELEG 13 4 300 20250214164848 (
                        20250207134348 21261 . HyDHYVT5KcqWc7J..= )
example.   300 IN DS    65163 13 2 5F86F2F3AE2B02...
example.   300 IN RRSIG DS 13 4 300 20250214164848 (
                        20250207134348 21261 . O0k558jHhyrC21J..= )

;; Additional
a.example. 300 IN A     192.0.2.1
a.example. 300 IN AAAA  2001:DB8::1

A.5.2. Query for foo.test

;; Header: QR DO DE AA RCODE=0
;;

;; Question
foo.test.      IN MX

;; Answer
;; (empty)

;; Authority
test.      300 IN DELEG include-name=ns2.example.net.
test.      300 IN RRSIG DELEG 13 4 300 20250214164848 (
                        20250207134348 21261 . 98Aac9f7A1Ac26Q..= )
test.      300 IN NSEC  a.test. RRSIG NSEC DELEG
test.      300 IN RRSIG NSEC 13 4 300  20250214164848 (
                        20250207134348 21261 . kj7YY5tr9h7UqlK..= )

;; Additional
;; (empty)