]> The Swedish Internet Foundation

Sweden johan.stenstam@internetstiftelsen.se

NLnet Labs

Netherlands philip@nlnetlabs.nl

Internet DNSOP Working Group Internet-Draft DNS SVCB transport This document defines a new Service Parameter Key (SvcParamKey), "oots" ("Opportunistic Operator-led Transport Signal"), for use in Service Binding (SVCB) and HTTPS resource records as defined in RFC 9460. The "oots" parameter allows the operator of an authoritative DNS nameserver to advertise, per DNS transport protocol (such as DNS over UDP/TCP, DNS over TLS, DNS over HTTPS, and DNS over QUIC), the operator's own assessment of the share of the nameserver's total query load that it is confident it can serve over that transport. The per-transport values are independent capability estimates rather than a distribution of queries across transports; they are opportunistic hints that a resolver MAY use to inform transport selection and MAY ignore entirely. This document provides the specification required by Section 14.3.1 of RFC 9460 for registration of the "oots" SvcParamKey in the IANA "Service Parameter Keys (SvcParamKeys)" registry.

Introduction The DNS is increasingly served over multiple transport protocols. In addition to traditional DNS over UDP and TCP on port 53 (Do53), authoritative and recursive servers may offer DNS over TLS (DoT) , DNS over HTTPS (DoH) , and DNS over QUIC (DoQ) . These encrypted transports differ from Do53 and from one another in their resource costs, connection-establishment overhead, and operational maturity at a given deployment. A resolver choosing how to reach an authoritative nameserver today has limited information about which transports that nameserver actually supports, and even less about how well the operator believes each transport will perform under load. A resolver can discover that a transport is offered at all (for example, via the "alpn" SvcParamKey defined in , or simply by attempting a connection), but the mere presence of a listener says nothing about the operator's confidence in serving production query volume over that transport. An operator may, for instance, fully support Do53 for its entire query load while being able to absorb only a small fraction of that same load over DoT or DoQ, perhaps because encrypted-transport capacity is still being built out, or is reserved for particular clients, or is simply more expensive per query. This document defines a mechanism by which a nameserver operator can communicate exactly that: a per-transport, operator-assessed indication of the fraction of the nameserver's total query load that the operator is confident it can serve over each transport. It does so by defining a new SVCB Service Parameter Key, "oots" ("Opportunistic Operator-led Transport Signal"). The signal is deliberately opportunistic and advisory. A resolver MAY use the values to inform transport selection, or MAY ignore them entirely; a missing, unrecognized, or even hostile "oots" value can only degrade transport selection back to a resolver's normal behavior and can never prevent resolution. This property is preserved throughout the processing rules in this document. The primary purpose of this document is to serve as the specification referenced by the "oots" entry in the IANA "Service Parameter Keys (SvcParamKeys)" registry, as required by Section 14.3.1 of . The "oots" SvcParamKey defined here is also used as one building block of a broader operator-led DNS transport signaling framework described in a separate, in-progress document ; that framework is not required in order to implement or use the "oots" SvcParamKey, and this document is self-contained.

Requirements Notation 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.

The "oots" SvcParamKey The "oots" SvcParamKey conveys, per DNS transport protocol available at a nameserver, the operator's assessment of the share of the nameserver's total query load that it is confident it can serve over that transport, expressed as a percentage. Its wire and presentation formats are defined below.

Wire Format The wire-format value for the "oots" SvcParamKey consists of one or more DNS transport protocol entries concatenated without separators between entries. Each entry is encoded as: a 1-octet unsigned integer length L (1 <= L <= 255), giving the length in octets of the protocol identifier string that follows, then the protocol identifier string itself (L octets of ASCII), then a 1-octet unsigned integer weight value in the range 0-100 inclusive. The total length of each entry is thus L + 2 octets. The SvcParamValue contains at least one entry (N >= 1). Protocol identifier strings are defined as follows: Protocol Identifier string Description do53 "do53" DNS over UDP/TCP (traditional, port 53) dot "dot" DNS over TLS doh "doh" DNS over HTTPS doq "doq" DNS over QUIC The identifier strings "dot" and "doq" are identical to the ALPN protocol identifiers registered for the corresponding DNS transports ( and respectively) and used in the "alpn" SvcParamKey . The identifiers "do53" and "doh" have no ALPN equivalent and are defined here for use in the "oots" SvcParamKey only. "do53" denotes plaintext DNS service over UDP/TCP on port 53, for which no ALPN is negotiated. "doh" denotes DNS over HTTPS ; DoH is carried over HTTP, which is identified by the ALPN tokens "h2" or "h3" rather than by a "doh" ALPN token, so "doh" is defined here as a distinct "oots" transport identifier. Weight values are unsigned integers in the range [0, 100]. For a given transport, the weight is the operator's estimate of the fraction of the nameserver's total query load that it is confident it can serve over that transport, expressed as a percentage of that total. The weights are NOT a distribution that partitions queries across transports and are NOT an instruction to a resolver on how to split its queries; each weight is an independent capability assessment against the same total load. Consequently, a nameserver MAY advertise a weight of 100 for more than one transport (full confidence on each), and the sum of the weights in a single "oots" SvcParamValue will typically exceed 100. A weight of 0 indicates that the transport is not available at this nameserver. An "oots" weight is encoded on the wire as a single octet and is therefore syntactically capable of carrying values from 0 to 255, but only the range 0-100 is meaningful. An encoder MUST NOT emit a weight greater than 100. A receiver that encounters a weight octet greater than 100 MUST interpret it as 100; it MUST NOT treat the entry, or the enclosing SVCB RR, as malformed on this basis. As with unrecognized protocol identifiers, this preserves the independence of the remaining entries and ensures that a malformed or hostile weight value can only degrade transport selection, never break resolution. For example, oots="do53:100,dot:10,doq:20" advertises that the operator is confident it can serve its full query load over Do53, but only about 10% of that same load over DoT and about 20% over DoQ. A resolver might use these hints to send a minority of its traffic over DoT or DoQ where supported, but they do not prescribe a fixed split. When a protocol entry is absent from the SvcParamValue, the following default interpretations apply: For dot, doh, and doq: absence of an entry is equivalent to a weight of 0, indicating that the transport is not available at this nameserver. For do53: absence of an entry is equivalent to a weight of 100, reflecting the assumption that traditional DNS over UDP/TCP remains available unless explicitly indicated otherwise. An operator wishing to indicate that DNS service over UDP/TCP is not available MUST explicitly include a do53 entry with a weight of 0. Each protocol identifier string MUST NOT appear more than once within a single SvcParamValue. An implementation receiving an "oots" SvcParamValue containing a duplicate protocol identifier MUST treat the enclosing SVCB RR as malformed and ignore it. An implementation that does not recognize a protocol identifier string MUST ignore that entry and continue processing the remaining entries.

Presentation Format The presentation format for the "oots" SvcParamKey is:

Where "proto" is one of the strings "do53", "dot", "doh", or "doq", and "weight" is a decimal integer in the range 0-100 inclusive. Multiple entries are separated by commas with no surrounding whitespace. The order of entries is not significant. The presentation format differs from the wire format () in that the protocol identifier and weight are separated by an ASCII colon (rather than the wire format's 1-octet length prefix), the weight is written as ASCII decimal digits (rather than a binary octet), and entries are separated by commas (rather than concatenated without a separator). Examples:

A well-formed "proto:weight" entry whose "proto" string is not in the set {"do53", "dot", "doh", "doq"} MUST be ignored, and processing MUST continue with the remaining entries. This mirrors the wire-format handling of unrecognized protocol identifiers (): because the entries are independent of one another, an unrecognized entry does not invalidate the others. An entry that is not well-formed (for example, one missing the colon separator, or one whose weight is absent or not a decimal integer in the range 0-100) is a parse error for the enclosing SvcParam.

Interactions with Other SvcParamKeys The "oots" key is independent of the "alpn", "port", "ipv4hint", and "ipv6hint" keys and MAY appear alongside any of them without conflict. The "oots" key MUST be ignored when it appears in an AliasMode SVCB record.

Security Considerations The "oots" parameter is conveyed in DNS and is subject to the same integrity guarantees as the enclosing SVCB record. An on-path or off-path adversary able to alter DNS responses could change, add, or remove "oots" entries. By design, such tampering can only influence a resolver's opportunistic transport selection: a resolver that receives an absent, altered, or unrecognized "oots" value degrades to its normal transport-selection behavior, and resolution is never prevented. The worst outcome an adversary can achieve by manipulating "oots" values alone is to discourage use of an encrypted transport that would otherwise have been used, or to encourage attempts on a transport the operator did not intend to feature; in either case the resolver remains free to fall back to any transport the nameserver actually offers. Operators SHOULD sign SVCB records containing "oots" with DNSSEC so that a validating resolver can detect alteration of the transport weights. Note that DNSSEC allows a validator to detect modification of records that are present, but an on-path adversary can still strip an entire SVCB RRset from a response (a downgrade), causing the resolver to fall back to normal transport selection; the design of "oots" tolerates this outcome, as described above. The "oots" value reflects only the operator's stated confidence and is not a guarantee. A resolver MUST NOT treat a non-zero weight as an assurance that a transport will succeed, nor a weight of 100 as an assurance of unlimited capacity; the weights are hints, and actual behavior may differ.

IANA Considerations IANA is requested to add the following entry to the "Service Parameter Keys (SvcParamKeys)" registry, in the "DNS Service Bindings (SVCB)" registry group, per the procedure defined in Section 14.3 of : Number Name Meaning Format Reference TBD oots Per-transport operator confidence in serving the nameserver's query load over that transport, as a percentage (This document)

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. 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. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation NLnet Labs Sinodun IT This document proposes a mechanism for authoritative DNS servers to signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)). This signaling may either be provided within the Additional section of authoritative DNS responses or be the result of direct DNS queries. The former, "opportunistic mode" is hint-based and aims to enable resolvers to discover alternative transports efficiently and then opportunistically upgrade connections to the authoritative, thereby improving privacy, security, and performance for subsequent interactions. The mechanism is designed to not require any protocol change or additional queries. It is safe, backward-compatible, and effective even when DNSSEC validation of the hint is not possible or desired. In certain circumstances and with additional overhead it is also possible to use direct queries to securely obtain authentication information for the authoritative that can then be used to authenticate an encrypted connection. It is also possible to establish a "validated mode" where the communication between the resolver and the authoritative server is provably both secure and authentic. Validated mode may not always be possible, depending on whether the resolver is able to DNSSEC validate the signal or not. When Validated mode is possible it does provide a stronger and more trustworthy connection. This document proposes an improvement to the opportunistic (but blind) testing of alternative transports suggested in RFC9539 by providing a mechanism by which a responding authoritative server may signal what alternative transports it supports. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-transport-signaling (https://github.com/johanix/draft-johani-dnsop-transport-signaling). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.

Acknowledgments The "oots" SvcParamKey defined here arose from work on operator-led DNS transport signaling . The authors thank Leon Fernandez, Erik Bergström, Sara Dickinson, and Joe Abley for their contributions to that broader effort, which informed the design of this parameter.

Change History (to be removed before publication)

draft-johani-dnsop-svcb-oots-00 Initial version. Content of the normative sections is derived from the IANA registration request submitted for the "oots" SvcParamKey, recast as an Internet-Draft to provide the specification required by Section 14.3.1 of RFC 9460.