]>

ietf@tapril.net

ISC

pspacek@isc.org

Akamai Technologies

rweber@akamai.com

Salesforce

tale@dd.org

Internet Internet-Draft This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in , with ability to specify transport protocols and authentication parameters supported by name servers.

Introduction The new delegation mechanism based on DELEG record type allows to specify attributes a resolver can use when talking to a delegated authority. This document introduces parameters specific to different transport mechanism than the default udp/53 protocol. Legacy DNS resolvers unaware of DELEG mechanism would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch to new transports.

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 transport name servers: An authoritative name server that only supports unencrypted DNS via UDP/TCP port 53

New DNS transports There has been a lot of work defining new ways to transport DNS over new encrypted protocols. While most of this work was focusd on the client/stub resolver to recursive resolver connection the protocols will remain the same for an recursive to authoritative connections when iterating for a name. These are:

• DNS over TLS as defined in
• DNS over HTTPS as defined in
• DNS over Dedicated QUIC Connections

While the DNS over HTTPs recommends HTTP/2 as the minimum version there are no differences when using to over HTTP/3 .

Selecting transport protocols The selection of the transport protocol to use to connect to an authoritative server for a delegation is done by the ALPN parameter as defined in . If there is no ALPN parameter the connection MUST be established using unencrypted DNS over UDP/TCP on port 53. If there is an ALPN parameter up to 4 protocols in the list MUST be tried to connect to the authoritative server. The following ALPN are allowed to be used and may need the additional parameters as defined in this table: | ALPN | parameters | |-------|------------| | dot | | | doq | | | h2 | dohpath | | h3 | dohpath |

Authenticating transport protocols As all defined transport protocols here rely on TLS the authentication for the authentication of them is identical. When no TLSA parameter is present authentication is MUST be done using the normal PKI infrastructure of the recursive resolver. The name used for the authentication is the target name of the DELEG or SVCB record. When a TLSA paramert is present the authentication MUST be done using the digests in that record

"TLSA" parameter The "TLSA" SvcParamKey is a transport parameter representing a TLSA RRset to be used when connecting to TargetName using a TLS-based transport. The SvcParamValue is a non-empty value-list. The presentation and wire format of each value is the same as the presentation and wire format described for the TLSA record as defined in , sections 2.1 and 2.2 respectively. To avoid wasting resources in the parent zone parents MAY reject RRSets containing "tlsa" SvcParams that use matching type 0 (exact match).

Authentication Failures When a resolver attempts to access nameserver delegated by a DELEG or SVCB record, if a connection error occurs, such as a certificate mismatch or unreachable server, the resolver SHOULD attempt to connect to the other nameservers delegated to until either exhausting the list or the resolver's policy indicates that they should treat the resolution as failed.

Privacy Considerations All of the information handled or transmitted by this protocol is public information published in the DNS.

Security Considerations TODO: Fill this section out

IANA Considerations

New SvcParamKey Values This document defines new SvcParamKey values in the "Service Binding (SVCB) Parameter Registry".

SvcParamKey	NAME	Meaning	Reference
TBD1	tlsa	TLSA RRset	(This Document)

Informative References 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. 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. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. 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. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]

Acknowledgments This draft is heavily based on past work (draft-tapril-ns2) done by Tim April 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 Log

RFC EDITOR:

PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

~~~ 01234567890123456789012345678901234567890123456789012345678901234567891

Contributors Cloudflare

christian@elmerot.se

ICANN

edward.lewis@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