]> ICANN

paul.hoffman@icann.org

The DELEG Working Group is soon going to be choosing a base protocol that describes how resolvers will be able to get a new DNS resource record to create a new process for DNS delegation. After a resolver gets this new type of record, it needs to know how to process the record in order to get a set of nameservers for a zone. This document lists many of the considerations for that process, including many open questions for the DELEG Working Group. More considerations and open questions might be added in later versions of this draft. Note that this draft is not intended to become an RFC. It is being published so that the DELEG Working Group has a place to point its efforts about how resolvers get nameservers for a zone while it continues to work on choosing a base protocol. The work that results from this might be included in the base protocol specification, or in a new draft authored by some of the many people who have done earlier work in this area.

Introduction The DELEG Working Group is choosing a base protocol for "a new DNS signaling mechanism that allows parents to return additional DNS delegation information about their children". This document specifies how that information will appear in the new resource records from the base protocol, and what resolvers that receive those records will do with them. According to the working group charter, after it has chosen the base protocol, it will specify "new DNS authoritative signaling mechanisms for alternative DNS transports". of this document gives some ideas for what those extensions might include, and how they related to the mechanisms in this document.

Assumptions about the Eventual Base Protocol The WG is making a choice between (called "W" here) and (called "H" here). W and H are quite different in their requirements for operation of the new delegation mechanism. After the WG comes to consensus on W or H as the base protocol, it will work on fixes and clarifications for many topics that came up during the consensus process, such as for root zone priming and interactions with DNSSEC. W and H agree on using the same display and wire format as SVCB for records returned to the resolver in delegation responses. In SVCB, the first field in the RR is called the "SvcPriority", and different values cause the resolver to go into "AliasMode" or "ServiceMode". The result of using this field in resolution is a set of "alternative endpoints". The second field is called "TargetName". The third field is optional, and is called "SvcParams"; it has a lot of sub-fields, some of which are useful for the DNS delegation use cases. In order to not confuse this with specifics that W (DELEG) and H (IDELEG) gave beyond the base protocol, the new record type returned in delegation responses is called "DD" here. (Of course, the name can be whatever the WG chooses in the eventual base protocol.) DD has different semantics from SVCB because SCVB assumed a base protocol of HTTPS. W gives different names to values for the first field in the RR, and for sub-fields in the optional third field. Other names from W and H and SVCB are renamed here for clarity; the eventual names might be completely different. The base protocol will allow for later extensions in the third field. Those extensions might reuse entries in the IANA SVCB registry, they might add new extensions to that registry, or there might be a new registry for the DD record.

BCP 14 Language 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.

Getting Nameserver Names for a Zone The goal of the DELEG Working Group effort is to give resolvers a better way create a set of nameservers for a zone when making DNS queries to authoritative servers. For both W and H, when a resolver makes one or two queries that get a delegation response, the resolver may get back one or more DD records and NS records that it can further process to create the set of nameservers for the zone. This eventual set of nameservers can be called the "DD_nameservers"; this is quite different from the set of DD records it received. In DD, the first field can be thought of as indicating the action to find names for the DD_nameservers other than the NS records that might be at the apex, using the second field as a domain name where to look. The first field can be called "DD_action" and the second "DD_where". The third field, which holds metadata about the DD_where, can be called "DD_metadata"

How a Resolver Processes the DD Record Both W and H agree that a DD_action of value 0 means an action like "find the DD_nameservers elsewhere based on the value in the DD_where", and a value of 1 means something like "the name in DD_where is an entry in DD_nameservers". Thus, when a resolver receives one or more DD records with a DD_action of 0, it needs to do more processing. When it receives one or more DD records with a DD_action of 1, it takes the DD_where from those records and puts them into the DD_nameservers (possibly with additional information from the DD_metadata, such as from ). What action does a resolver take when it gets a DD_action of 0? When talking about the DELEG Working Group work beyond the base protocol, W and H have similar but different actions for finding eventual additions to the DD_nameservers. W and H follow chains of CNAME, DNAME, and SVCB records, with some limits to prevent loops or excessive processing. %% The previous sentence might be wrong; it's the best I could determine from the drafts. %% Does chasing DD_action of 0 need to change the query to SVCB, or would "just send the same request, but send it to the DD_where" suffice? That is, why change to SVCB when the resolver already knows how to get DD records just by resolution requests? Should the resolver follow CNAME and DNAME, or are straight chains sufficient? Is the addition to the DD_nameservers different if following a DD_action of 0 leads to signed vs. unsigned responses? Asked another way, if the DD_nameservers contains some results that were signed and some that were unsigned, does the DD_nameservers become an ordered list or are the unsigned results discarded? What is the TTL of the records in DD_nameservers? A likely answer (but not the only posslbe one) is the TTL on the DD record that had a DD_action of 1. If so, this could mean that different delegation records in the DD_nameservers for the same zone might have differnt TTLs. The resolver [[ MAY / SHOULD / SHOULD NOT / MUST / MUST NOT ]] use the NS records that were returned with the query to expand the DD_nameservers. (If SHOULD or SHOULD NOT is chosen by the WG, the exceptions need to be listed.) If there are DD records but the resolver ends up with nothing in the DD_nameservers, does it fall back to using the NS records in the original query? Can the DD RRset contain records with different values for DD_action? SVCB says no, but W and H say yes (but differently).

Addresses and Transports According to the working group charter, after it has chosen the base protocol, it will specify "new DNS authoritative signaling mechanisms for alternative DNS transports". This section has some brief ideas about what those might entail and what questions might need to be answered.

Addresses The DD_metadata field in the DD record will have a subfield to indicate the IPv4 and IPv6 address(es) associated with the DD_where. The subfield can be called "DD_ips". Can a DD with a DD_action of 0 have a DD_ips in the record? In SVCB they cannot, but the SVCB spec allows other specs to allow them. Is the value for the DD_ips a single address or potentially a list? If the former, how are multiple DDs with the same DD_action and DD_where combined? What happens if some of the discovered name/address pairs have different addresses? Does that disagreement in the DD_nameservers cause the removal of something from the DD_nameservers?

Transports The DD_metadata field in the DD record will have a subfield to indicate the transport(s) associated with the DD_where. The subfield can be called "DD_transports". Can a DD with a DD_action of 0 have a DD_transports in the record? In SVCB they cannot, but the SVCB spec allows other specs to allow them. Some specific DNS transports will be allowed or required with DD_transports. Which secure transport(s), if any, will be mandory to implement? Does supporting both TLS and QUIC make operational or security sense? Does supporting DOH make operational or security sense if other secure transport is allowed? If either or both TLS and DoH are allowed, which versions of TLS are allowed? Does Do53 need to be specified every time it is available?

Authentication of Secure Transports How will clients deal with authenticating TLS? Should they just use the web PKI pile of CAs, or will something else be specified? Should certificates with IP addresses be supported? Should clients ignore PKIX Extended Key Usage settings? Should clients fall back to unauthenticated encrypted transport, all the way to Do53, or fail to resolve?

IANA Considerations %% There may be IANA considerations when the working group finishes this work. %%

Security Considerations %% There will certainly be security considerations when the working group finishes this work. %%

Google, LLC ISC Akamai Technologies Salesforce 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. NLnet Labs Cox Communications University of Amsterdam NLnet Labs This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with resource record sets placed below a _deleg label in the apex of the delegating zone. This authoritative delegation point can be aliased to other names using CNAME and DNAME. This document proposes a new DNS resource record type, IDELEG, which is based on the SVCB and inherits extensibility from it. Support in recursive resolvers suffices for the mechanism to be fully functional. The number of subsequent interactions between the recursive resolver and the authoritative name servers is comparable with those for DNS Query Name Minimisation. Additionally, but not required, support in the authoritative name servers enables optimized behavior with reduced (simultaneous) queries. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed. 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. 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.