| Internet-Draft | SVCB oots SvcParamKey | June 2026 |
| Stenstam & Homburg | Expires 17 December 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over QUIC (DoQ) [RFC9250]. 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 [RFC9460], 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 [RFC9460]. 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 [I-D.johani-dnsop-transport-signaling]; that framework is not required in order to implement or use the "oots" SvcParamKey, and this document is self-contained.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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 [RFC7858] |
| doh | "doh" | DNS over HTTPS [RFC8484] |
| doq | "doq" | DNS over QUIC [RFC9250] |
The identifier strings "dot" and "doq" are identical to the ALPN protocol identifiers registered for the corresponding DNS transports ([RFC7858] and [RFC9250] respectively) and used in the "alpn" SvcParamKey [RFC9460]. 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 [RFC8484]; 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.¶
The presentation format for the "oots" SvcParamKey is:¶
oots="proto:weight[,proto:weight]*"¶
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 (Section 2.1) 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:¶
ns.example.net. 300 IN SVCB 1 . oots="do53:100,dot:10" ns.example.net. 300 IN SVCB 1 . oots="do53:100,dot:5,doq:5" ns.example.net. 300 IN SVCB 1 . oots="do53:100,dot:25,doh:10,doq:10"¶
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 (Section 2.1): 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.¶
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.¶
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 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 [RFC9460]:¶
| 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) |
The "oots" SvcParamKey defined here arose from work on operator-led DNS transport signaling [I-D.johani-dnsop-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.¶
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.¶