]> Google, LLC

ietf@tapril.net

ISC

pspacek@isc.org

Akamai Technologies

rweber@akamai.com

Salesforce

tale@dd.org

Internet Internet-Draft A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace.

Introduction In the Domain Name System , subdomains within the domain name hierarchy are indicated by delegations to servers which are authoritative for their portion of the namespace. The DNS records that do this, called NS records, contain hostnames of nameservers, which resolve to addresses. No other information is available to the resolver. It is limited to connect to the authoritative servers over UDP and TCP port 53. This limitation is a barrier for efficient introduction of new DNS technology. The proposed DELEG record type remedies this problem by providing extensible parameters to indicate capabilities and additional information, such as glue that a resolver may use for the delegated authority. It is authoritative and thus signed in the parent side of the delegation making it possible to validate all delegation parameters (names and glue records) with DNSSEC. This document only shows how DELEG can be used instead of or along side a NS record to create a delegation. Future documents can use the extensible mechanism for more advanced features like connecting to a name server with an encrypted transport.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
BCP 14 when, and only when, they appear in all capitals, as shown here. Terminology regarding the Domain Name System comes from , with addition terms defined here:

• legacy name servers: An authoritative server that does not support the DELEG record.
• legacy resolvers: A resolver that does not support the DELEG record.

DELEG Record Type The DELEG record uses a new resource record type, whose contents are identical to the SVCB record defined in . For extensions SVCB and DELEG use Service Parameter Keys (SvcParamKeys) and new SvcParamKeys that might be needed also will use the existing IANA Registry.

Differences from SVCB

• DELEG can only have two priorities 0 indicating INCLUDE and 1 indicating a DIRECT delegation. These terms MUST be used in the presentation format of the DELEG record.
• INCLUDE and DIRECT delegation can be mixed within an RRSet
• The final INCLUDE target is an SVCB record, though there can be further indirection using CNAME or AliasMode SVCB records.
• There can be multiple INCLUDE DELEG records, but further indirections through SVCB records have to comply with in that there can be only one AliasMode SVCB record per name.
• In order to not allow unbound indirection of DELEG records the maximum number of indirections, CNAME or AliasMode SVCB is 4.
• The SVCB IPv4hint and IPv6hint parameters keep their key values of 4 and 6, but the presentation format with DELEG MUST be Glue4 and Glue6.
• Glue4 and Glue6 records when present MUST be used to connect to the delegated name server.
• The target of a DELEG record MUST NOT be '.' and for INCLUDE must be outside of the delegated domain and for DIRECT in domain delegations below the zone cut.

Use of DELEG record The DELEG record creates a zone cut similar to the NS record so all data at or below the zone cut has to be resolved using the name servers defined in the DELEG record. A DELEG RRset MAY be present at a delegation point. The DELEG RRset MAY contain multiple records. DELEG RRsets MUST NOT appear at a zone's apex. A DELEG RRset MAY be present with or without NS or DS RRsets at the delegation point. An authoritative server that is DELEG aware MUST put all DELEG resource records for the delegation into the authority section when the resolver has signalled DELEG support. It SHOULD NOT supply DELEG records in the response when receiving a request without the DE bit. If the delegation does not have DELEG records the authoritative server MUST send the NS records and, if the zone is DNSSEC signed, prove the absence of the DELEG RRSet. A resolver that is DELEG aware MUST signal its support by sending the DE bit when iterating and MUST use the DELEG records in the referral response.

Signaling DELEG support 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. 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): Setting the DE bit to one in a query indicates to the server that the resolver is able to accept delegations using DELEG only. 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. The DE bit of the query MUST be copied in the response.

DNSSEC As the DELEG record is authoritative in the parent zone of a zone cut similar to DS it has to be signed in the parent zone. In order for the validator to understand that the delegation uses DELEG this draft introduces a new DNSKEY flag TBD. When this flag is set for the key that signs the DS or DELEG record, usually the zone signing key (ZSK), and the request has signalled that it understands DELEG an authenticated denial of existence MUST be send with the referral response, so that a DELEG aware validator can prove the existence or absence of a DELEG record and detect a downgrade attack. 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 this has to be security and DELEG aware as well.

IANA Considerations IANA is requested to allocate the DELEG RR in the Resource Record (RR) TYPEs registry, with the meaning of "enchanced delegation information" and referencing this document. IANA is requested to assign a new bit in the DNSKEY RR Flags registry () for the DELEG bit (N), with the descripion "DELEG" and referencing this document. IANA is requested to assign a bit from the EDNS Header Flags registry (), with the abbreviation DE, the description "DELEG enabled" and referencing this document. For the RDATA parameters to a DELEG RR, the DNS Service Bindings (SVCB) registry () is used. This document requests no new assignments to that registry, though it is expected that future DELEG work will.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Akamai Technologies Within the DNS, there is no mechanism for authoritative servers to advertise which transport methods they are capable of. If secure transport methods are adopted by authoritative operators, transport signaling would be required to negotiate how authoritative servers would be contacted by resolvers. This document provides two new Resource Record Types, NS2 and NS2T, to facilitate this negotiation by allowing zone owners to signal how the authoritative nameserver(s) for their zone(s) may accept queries.

Examples The following example shows an excerpt from a signed root zone. It shows the delegation point for "example." and "test." The "example." delegation has DELEG and NS records. The "test." delegation has DELEG but no NS records. The "test." delegation point has a DELEG record and no NS record.

Responses The following sections show referral examples:

DO bit clear, DE bit clear

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

Query for foo.test ;; Header: QR AA RCODE=3 ;; ;; Question
foo.test. IN MX ;; Answer
;; (empty) ;; Authority
. 300 IN SOA ... ;; Additional
;; (empty)

DO bit set, DE bit clear

Query for foo.example

Query for foo.test

DO bit clear, DE bit set

Query for foo.example

Query for foo.test

DO bit set, DE bit set

Query for foo.example

Query for foo.test

Acknowledgments {:unnumbered} This document is heavily based on past work done by Tim April in and thus extends the thanks to the people helping on this which are: John Levine, Erik Nygren, Jon Reed, Ben Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, Gordon Marx and Brian Wellington.

TODO

RFC EDITOR:

PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

• Write a security considerations section
• Change the parameters form temporary to permanent once IANA assigned. Temporary use:
  • DELEG QType code is 65432
  • DELEG EDNS Flag Bit is 3
  • DELEG DNSKEY Flag Bit is 0

Change Log

RFC EDITOR:

PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

since draft-wesplaap-deleg-00

• Clarified SVCB priority behaviour
• Added section on differences to draft-homburg-deleg-incremental-deleg

since draft-wesplaap-deleg-01

• Reorganised and streamlined the draft to the bare mininum for DELEG as an NS replacement
• Defined codepoints for temporary testing
• Added examples

Contributors Cloudflare

christian@elmerot.se

ICANN

edward.lewis@icann.org

ICANN

roy.arends@icann.org

Salesforce

shuque@gmail.com

nic.at

klaus.darilion@nic.at

CZ.nic

libor.peltan@nic.cz

CZ.nic

vladimir.cunat@nic.cz

NS1

shane@time-travellers.org

Verisign

davidb@verisign.com

APNIC

ggm@algebras.org

Meta

bemasc@meta.com

NS1

jvcelak@ns1.com

PowerDNS

peter.van.dijk@powerdns.com

NLnet Labs

philip@nlnetlabs.nl

Akamai Technologies

erik+ietf@nygren.org

Team Internet

vandan@adhvaryu.uk

Meta

chantr4@gmail.com

Cloudflare

bhalley@cloudflare.com