]> ICANN

paul.hoffman@icann.org

Akamai Technologies

rweber@akamai.com

The DELEG base protocol allows a DNS zone operator to specify servers to be used when delegating zones to other DNS nameservers. This document extends the base protocol to allow zone operators to specify secure transports for those delegations.

Introduction In the DELEG base protocol (), a DNS zone operator uses the DELEG resource record to delegate zones to other DNS nameservers. In the base protocol, that delegation is always assumed to be using classical DNS on port 53. Some operators want to use secure transports for their name service, and want DELEG-aware resolvers to use those transports for name resolution. This document defines extensions to the DELEG record to allow such specification.

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.

Extensions for Secure Transports This document defines new DelegInfo DelegInfoKey values: secure-transport, no-do53, and tlsa. The DelegInfoValue for secure-transport is an unordered collection of names of transports. There is no DelegInfoValue for no-do53. The DelegInfoValue for tlsa-desc is a string reprinting an TLSA record.

The secure-transport Key The secure-transport DelegInfoKey lists the secure transports that are supported for a particular delegation target. It MUST only appear in a DelegInfos with a server-ipv4, server-ipv6 orserver-name DelegInfoKey. (This restriction might change if future specifications add new types of delegation targets.) A DELEG-enabled resolver MAY use one or more of the listed values to choose a secure transport for its communications with the given delegation target. If no secure-transport key is given, the DELEG-aware resolver MUST use classical DNS over port 53 (Do53). The values for the elements of the DelegInfoValue for the secure-transport DelegInfoKey are adot and adoq. Additional values may be defined in the future; see for rules on how such values might be defined. adot indicates that the delegation target from the server-ipv4, server-ipv6, or server-name DelegInfoKey supports DNS over TLS (DoT) . adoq indicates that the delegation target from the server-ipv4, server-ipv6, or server-name DelegInfoKey supports DNS over QUIC (DoQ) . Note that DNS over HTTPS (DoH) is not supported by this document. This is because DoH adds no security over DoT, while adding complexity to both the client (the recursive resolver) and the server (the authoritative server). In addition, using DoH requires knowing the URI template, which would further complicate the DELEG RRset.

The no-do53 Key The no-do53 DelegInfoKey indicates that the delegation target does not support Do53; it supports only secure transports. The no-do53 DelegInfoKey, which takes no value, MUST only appear in a DelegInfos with a secure-transport DelegInfoKey.

The tlsa Key The tlsa DelegInfoKey indicates certificate authority (CA) and public key information that a DELEG-aware resolver MAY use for authenticating a DoT or DoQ connection. The value is a string that is a TLSA () Rdata in presentation format. It MUST only appear in a DelegInfos with a secure-transport key. At the time that this document is written, ADoT and ADoQ servers use a variety of issuers for their TLS certificates: self-issued (often mistakenly called "self-signed"), a bespoke CA created for ADoT, and Web PKI issuers. All of these can be indicated in a tlsa value. If there is no tlsa key, the resolver is free to choose any authentication mechanism, including accepting any certificate.

Examples

IANA Considerations

Additions to "DELEG Delegation Information" Registry IANA is requested to add the following values to the "DELEG Delegation Information" registry as described in .

Registry for the secure-transport Values IANA is requested to create the "secure-transport DelegInfoKey values" registry. This is to be a sub-registry under the "DELEG Delegation Information" registry. A registration MUST include the following fields:

To enable code reuse from SVCB parsers, the requirements for registered Name exactly copy requirements set by section 14.3.1: The characters in the registered Name field entry MUST be lowercase alphanumeric or "-". The registration policy for new entries is Expert Review (). The designated expert MUST ensure that the reference is stable. The reference MAY be any individual's Internet-Draft or a document from any other source with similar assurances of stability and availability. Initial values for this registry are:

Security Considerations Although this document defines an authentication mechanism , it does not require that DoT or DoQ sessions be authenticated. Of course, this reduces the normal level of TLS and QUIC security from "fully authenticated" to "not authenticated at all".

&RFC2119; &RFC7858; &RFC8174; &RFC9250; &I-D.ietf-deleg; &RFC6698; &RFC8126; &RFC8484; &RFC9460;

Acknowledgements Many people in the DELEG Working Group contributed early suggestions for this document.