An SVCB Service Parameter for Opportunistic Operator-led Transport Signaling (oots)
draft-johani-dnsop-svcb-oots-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Johan Stenstam , Philip Homburg | ||
| Last updated | 2026-06-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-johani-dnsop-svcb-oots-00
DNSOP Working Group J. Stenstam
Internet-Draft The Swedish Internet Foundation
Intended status: Standards Track P. Homburg
Expires: 17 December 2026 NLnet Labs
15 June 2026
An SVCB Service Parameter for Opportunistic Operator-led Transport
Signaling (oots)
draft-johani-dnsop-svcb-oots-00
Abstract
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.
Status of This Memo
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.
Stenstam & Homburg Expires 17 December 2026 [Page 1]
Internet-Draft SVCB oots SvcParamKey June 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. The "oots" SvcParamKey . . . . . . . . . . . . . . . . . . . 3
2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 6
3. Interactions with Other SvcParamKeys . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Change History (to be removed before publication) . . . . . . . . 9
draft-johani-dnsop-svcb-oots-00 . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. 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)
[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
Stenstam & Homburg Expires 17 December 2026 [Page 2]
Internet-Draft SVCB oots SvcParamKey June 2026
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.
1.1. 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 [RFC2119] [RFC8174] when, and only
when, they appear in all capitals, as shown here.
2. 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.
Stenstam & Homburg Expires 17 December 2026 [Page 3]
Internet-Draft SVCB oots SvcParamKey June 2026
2.1. 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 [RFC7858] |
+----------+-------------------+------------------------+
| doh | "doh" | DNS over HTTPS |
| | | [RFC8484] |
+----------+-------------------+------------------------+
| doq | "doq" | DNS over QUIC |
| | | [RFC9250] |
+----------+-------------------+------------------------+
Table 1
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.
Stenstam & Homburg Expires 17 December 2026 [Page 4]
Internet-Draft SVCB oots SvcParamKey June 2026
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.
Stenstam & Homburg Expires 17 December 2026 [Page 5]
Internet-Draft SVCB oots SvcParamKey June 2026
An implementation that does not recognize a protocol identifier
string MUST ignore that entry and continue processing the remaining
entries.
2.2. Presentation Format
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.
3. 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.
Stenstam & Homburg Expires 17 December 2026 [Page 6]
Internet-Draft SVCB oots SvcParamKey June 2026
4. 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.
5. 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
[RFC9460]:
+========+======+======================================+===========+
| Number | Name | Meaning | Format |
| | | | Reference |
+========+======+======================================+===========+
| TBD | oots | Per-transport operator confidence in | (This |
| | | serving the nameserver's query load | document) |
| | | over that transport, as a percentage | |
+--------+------+--------------------------------------+-----------+
Table 2
Stenstam & Homburg Expires 17 December 2026 [Page 7]
Internet-Draft SVCB oots SvcParamKey June 2026
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
6.2. Informative References
[I-D.johani-dnsop-transport-signaling]
Stenstam, J., Fernandez, L., Bergström, E., Homburg, P.,
and S. Dickinson, "Authoritative DNS Transport Signaling",
Work in Progress, Internet-Draft, draft-johani-dnsop-
transport-signaling-02, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-johani-dnsop-
transport-signaling-02>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/rfc/rfc9250>.
Stenstam & Homburg Expires 17 December 2026 [Page 8]
Internet-Draft SVCB oots SvcParamKey June 2026
Acknowledgments
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.
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.
Authors' Addresses
Johan Stenstam
The Swedish Internet Foundation
Sweden
Email: johan.stenstam@internetstiftelsen.se
Philip Homburg
NLnet Labs
Netherlands
Email: philip@nlnetlabs.nl
Stenstam & Homburg Expires 17 December 2026 [Page 9]