]> ICANN

paul.hoffman@icann.org

The DELEG Working Group has chosen 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 charter says that the WG is choosing a base protocol, a "specification defining the new delegation information distribution mechanism". 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 a "specification for how to use the new delegation information to perform aliasing of delegation information" and "new DNS authoritative signaling mechanisms for alternative DNS transports". and of this document gives some idea for what those extensions might include, and how they related to the mechanisms in this document. The charter does not specify whether these two specifications need to be in different standards-track documents or can be in the same document.

The Base Protocol The WG chose as the starting point for 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. In this document, the base protocol is called "DELEG_base". DELEG_base uses 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 DELEG_base gives beyond the base protocol, the new record type returned in delegation responses is called "DELEG_rr" here. (Of course, the name can be whatever the WG chooses in the eventual base protocol.) DELEG_rr has different semantics from SVCB because SCVB assumed a base protocol of HTTPS. DELEG_base gives different names to values for the first field in the RR, and for sub-fields in the optional third field. Other names from DELEG_base and SVCB are renamed here for clarity; the eventual names might be completely different. The base protocol will allow for 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 DELEG_rr record.

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. In DELEG_base, when a resolver makes a query that gets a delegation response, the resolver may get back one or more DELEG_rr 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 "DELEG_nameservers"; this is quite different from the set of DELEG_rr records it received. In the DELEG_rr, the first field can be thought of as indicating the action to find names for the DELEG_nameservers other than the NS records that might be at the apex, using the second field as a target domain name where to look. The first field can be called "DELEG_action" and the second "DELEG_target". The third field, which holds metadata about the DELEG_target, can be called "DELEG_metadata" The rest of this section describes how a resolver processes the DELEG_rr record, based on proposals made in , , and various discussions in the DELEG Working Group. The WG discussion so far has led to general agreement a DELEG_action of value 0 means an action like "find a nameserver to be included in DELEG_nameservers elsewhere based on the value in the DELEG_target", and a value of 1 means something like "the name in DELEG_target is a nameserver for DELEG_nameservers". Thus, when a resolver receives one or more DELEG_rr records with a DELEG_action of 0, it needs to do more processing to complete the DELEG_nameservers set. When it receives one or more DELEG_rr records with a DELEG_action of 1, it copies the DELEG_target from those records and puts them into the DELEG_nameservers (possibly with additional information from the DELEG_metadata, such as from ). There has been much discussion in the WG about what action a resolver take when it gets a DELEG_action of 0. Some proposals include following chains of SVCB records, with some limits to prevent loops or excessive processing; others include following CNAME records, while others include querying DELEG_target for DELEG_rr records.

Additional Considerations for the WG on Filling the DELEG_nameservers Set The resolver [[ MAY / SHOULD / SHOULD NOT / MUST / MUST NOT ]] use the NS records that were returned with the query to expand the DELEG_nameservers. (If SHOULD or SHOULD NOT is chosen by the WG, the exceptions need to be listed.) If there are DELEG_rr records but the resolver ends up with nothing in the DELEG_nameservers, does it fall back to using the NS records in the original query? Is the addition to the DELEG_nameservers different if following a DELEG_action of 0 leads to signed vs. unsigned responses? Asked another way, if the DELEG_nameservers contains some results that were signed and some that were unsigned, does the DELEG_nameservers become an ordered list or are the unsigned results discarded? What is the TTL of the records in DELEG_nameservers? A likely answer (but not the only possible one) is the TTL on the DELEG_rr record that had a DELEG_action of 1. If so, this could mean that different delegation records in the DELEG_nameservers for the same zone might have different TTLs.

Addresses and Transports When Filling the DELEG_nameservers Set Address and transport information in the DELEG_metadata can affect the addressed added to the DELEG_nameservers. Thus, these might become part of whatever document describes filling the DELEG_nameservers set, or these might be in a separate document that is referenced from the main addressing document. The DELEG_metadata field in the DELEG_rr record will have a subfield to indicate the IPv4 and IPv6 address(es) associated with the DELEG_target. The subfield can be called "DELEG_ips". The DELEG_metadata field in the DELEG_rr record will have a subfield to indicate the transport(s) associated with the DELEG_target. The subfield can be called "DELEG_transports".

Addresses Can a DELEG_rr with a DELEG_action of 0 have a DELEG_ips in the record? In SVCB they cannot, but the SVCB spec allows other specs to allow them. Is the value for the DELEG_ips a single address or potentially a list? If the former, how are multiple DELEG_rr records with the same DELEG_action and DELEG_target combined? What happens if some of the discovered name/address pairs have different addresses? Does that disagreement in the DELEG_nameservers cause the removal of something from the DELEG_nameservers?

Transports Can a DELEG_rr with a DELEG_action of 0 have a DELEG_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 DELEG_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? If authentication fails during a lookup, should the resolver fall back to unauthenticated encrypted transport, or should it retry on Do53, or should the DELEG_rr that contained this secure transport be ignored?

Priming the Root Zone The current proposal for DELEG_base cannot be used to prime the root zone because the root zone is not its own parent. Different proposals have been made informally how to make a special case of the DELEG_base protocol to allow a DELEG_rr record to be legally served by root server operators to allow the advantages of DELEG_base (can be signed; can include IP addresses and transports) to cover the root zone. Should such proposals be considered?

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. 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. IDELEG RRsets containing delegation information will be returned in the authority section in referral responses from supportive authoritative name servers. Lack of support in the authoritative name servers, forwarders or other components, does not obstruct obtaining the delegation information for resolvers, as it is originally authoritative information that can be queried for directly. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed on the authoritative name servers. 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.