Opportunistic Operator based SVCB transport signaling (OOTS)

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 6 May 2027.¶

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

The Domain Name System (DNS) primarily relies on UDP and TCP for communication between resolvers and authoritative servers. While these protocols are well-established, there is a growing interest in leveraging modern encrypted transport protocols like DNS over TLS (DoT) [RFC7858] and DNS over QUIC (DoQ) [RFC9250] to enhance privacy, security, and performance.¶

'Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS' [RFC9539] describes a mechanism for how recursive resolvers can probe authoritative servers to discover if port 853 is open in order to Opportunistically upgrade to an encrypted transport. However that mechanism has not gained widespread deployment due to a number of limitations and a reluctance of authoritative operators to open port 853 with no signaling mechanisms available.¶

Here we propose an alternative mechanism that enables a more controlled deployment of Opportunistic encrypted transports: Opportunistic Operator Transport Signaling mechanism (OOTS). This signaling is based on SVCB records [RFC9460], [RFC9461] which can contain a new (experimental) SVCB "oots" key that specifies per-transport query load parameters. This improves on the Opportunistic (but blind) testing of alternative transports suggested in [RFC9539] by providing a mechanism by which a responding authoritative server may signal which alternative transports it supports, along with more detailed information about each transport.¶

Recursive resolvers can obtain these records either by requesting they be included in the Additional section of authoritative DNS responses (Passive mode), and/or by performing direct DNS queries for SVCB records (Probe mode), depending on the local discovery policy.¶

• The former, "Passive mode", is enabled by use of a new EDNS(0) option and allows resolvers to discover alternative transports efficiently with no additional queries. The records returned here are to be taken by the resolver as a hint of the transport capabilities of the authoritative server.¶

• The latter, "Probe mode", enables recursive resolvers willing to expend additional overhead to obtain SVCB records via direct queries, and to (optionally) directly discover if DNSSEC signed SVCB records exist.¶

This dual approach has some similarities to NS re-validation [I-D.draft-ietf-dnsop-ns-revalidation] whereby a resolver may choose to actively probe the child zone for NS records after receiving a referral. However, OOTS is more flexible in that resolvers may choose to operate in one mode or a combined mode approach.¶

Neither mode requires changes to the parent zone. Passive mode may require additional SVCB alias mode records for certain delegation patterns.¶

On obtaining such SVCB records recursive resolvers can then apply a local connection policy to Opportunistically upgrade connections to the authoritative to an encrypted transport contained within the signaled information.¶

The Opportunistic mechanism described here has a major advantage of being available immediately without any changes to the DNS protocol. Furthermore, as it is a signal directly from an authoritative nameserver, a single SVCB record may allow the recipient recursive nameserver to upgrade the transport used for all the zones served by that authoritative nameserver (which may be millions) without the need to make any changes to the zones, nor to the parent zones.¶

Given the current DNS landscape with a limited number of very large providers of authoritative DNS service and a limited number of large providers of recursive DNS service the Opportunistic model described here has the potential of enabling upgrading the transport for a significant fraction of the DNS traffic with a limited amount of effort.¶

This specification is expected to evolve over time based on interoperability testing and experimental deployments. Early work is expected to include comparing the two modes to see if one or the other is preferable or if both should be part of the long term solution. Other work will investigate if the structure of, and the information in, the SVCB "oots" key is useful in practice.¶

*NOTE: * While DNS over HTTP (DoH) [RFC8484] is also an option as a recursive to authoritative encrypted transport many of the advantages of the use of DoH stub to resolver do not apply in the recursive to authoritative context. Hence, there appears to be little current appetite to deploy DoH for this use. So while DoH is covered by this specification and included in the SVCB "oots" key definition, the examples and discussion here reference only DoT and DoQ for brevity.¶

2. Github repo

TO BE REMOVED: This document is being collaborated on in Github at: 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.¶

3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶

General DNS terminology used here follows that defined in [RFC9499].¶

• OOTS Passive mode: Recursive resolvers set the EDNS(0) OOTS Option in a query and authoritative servers supply EDNS(0) OOTS Responses in the Additional section if appropriate.¶

• OOTS Probe mode: Recursive resolvers directly query for SVCB records of authoritative servers and process any "oots" keys in those records¶

• SVCB Record: Service Binding record, as defined in [RFC9460].¶

• SCVB "oots" key: New experimental Service Parameter Key (SvcParamKey) key defined in [I-D.draft-johani-dnsop-svcb-oots] which allows an operator to advertise a requested query load for each advertised transport.¶

• EDNS(0) OOTS Option: New EDNS(0) flag that indicates a resolver wishes to receive SVCB records in the Additional section of the response.¶

• EDNS(0) OOTS Response: An SVCB record included in the Additional section of an authoritative DNS response, intended to signal the responding authoritative nameserver's transport capabilities.¶

• Strict and Opportunistic connection modes: These connection modes are entirely analogous to those defined for stub to recursive connections in [RFC8310].¶

  • Strict requires both an encrypted and authenticated connection to the server based on authentication credentials that were obtained via a secure mechanism. Clients MUST hard-fail the connection if this is not possible.¶

  • Opportunistic uses cleartext as the baseline connection, with encryption and authentication negotiated and applied to the connection when available.¶

4. Overview of the OOTS mechanism

The basis of the Opportunistic operator transport signaling (OOTS) mechanism is the discovery of and usage by recursive resolvers of Service Binding records (SVCB RRs) for authoritative nameservers that offer encrypted transports.¶

An new, experimental SCVB "oots" parameter is defined in [I-D.draft-johani-dnsop-svcb-oots] for the OOTS mechanism. It 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.¶

Recursive resolvers can discover and use SVCB records that contain the "oots" parameter. However, it is important to note that the information conveyed by the SVCB records alone (even when DNSSEC signed) signals only the capabilities of the authoritative nameserver serving the zone. It does not, therefore, establish a full chain of trust directly to the zone itself and MUST be considered as insecure. It should not be used as a basis of a Strict connection policy, only to enable an Opportunistic connection policy.¶

However, acquiring such a signal enables resolvers to immediately apply the local Opportunistically connection policy for the nameserver in question. Resolvers may, of course, still validate the certificate presented by the nameserver and log the result.¶

The mechanism is expected to be experimental in nature in the early stages as various details of the discovery heuristics and signaling mechanism are explored and developed.¶

5. Recommendations for recursive resolvers

This section describes how recursive resolvers can discovery SVCB records.¶

                                              1   1   1   1   1   1
      0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 0: |                            OPTION-CODE                        |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 2: |                           OPTION-LENGTH                       |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Header: ...

Answer:
www.example.com.   IN A 1.2.3.4

Authority:
example.com.       IN NS ns1.example.com.
example.com.       IN NS ns.dnsprovider.net.

Additional:
ns.dnsprovider.net. IN A 5.6.7.8
ns.dnsprovider.net. IN RRSIG A ...
_dns.ns.dnsprovider.net. IN SVCB 1 . "oots=doq:100,dot:100,do53:100"
_dns.ns.dnsprovider.net. IN RRSIG SVCB ...

Header: ...

Answer:
_dns.ns.dnsprovider.net.  IN SVCB 1 . "oots=doq:100,dot:100,do53:100"
_dns.ns.dnsprovider.net.  IN RRSIG SVCB ...

Additional:

6. Recommendations for Authoritative servers

7. Using SVCB records

The SVCB records are a mechanism to discover capabilities of nameservers, not to override trusted delegation or service configuration.¶

[I-D.draft-johani-dnsop-svcb-oots] specifies the syntax and semantics of the "oots" SvcParam. To summarise, it 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. Weight values are unsigned integers in the range [0, 100]. 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" SvcParam value will typically exceed 100. A weight of 0 indicates that the transport is not available at this nameserver. An example SVCB record containing this parameter is:¶

ns.example.net. 300 IN SVCB 1 . oots="do53:100,dot:5,doq:5"

Resolver MAY attempt connections over any transport with a weight greater than 1 in the "oots" SvcParam.¶

A resolver MUST interpret a value of more than 100 as 100.¶

If resolvers choose to use encrypted transports, they SHOULD honor any transport weight value found in the "oots" SvcParam for any transport they attempt to connect over. Resolvers MAY choose to use lower transport weights for encrypted transports due to local resource constraints. Resolvers SHOULD NOT use higher transport weight value found in the unless there is a compelling reason, e.g. no other transport is available.¶

Resolvers MUST always be prepared to fall back to traditional UDP/TCP transport if an attempt to use an alternative transport based on an SVCB record (especially an unvalidated one) fails or times out.¶

QUESTION: Did we decide to say anything about possible implementations of this in the appendix??¶

Resolvers MAY also cache information about the result of a connection attempt based on an SVCB record, for example when a particular transport is indicated as being supported but connection attempts fail. Resolvers MAY choose to implement a back-off for retrying connection attempts in this scenario. For a more detailed analysis of this possible caching logic, see [RFC9539], section 4.¶

8. Security Considerations

• DNSSEC Validation (Optional but Recommended): The resolver SHOULD attempt to DNSSEC validate the SVCB record. This involves validating the SVCB record itself and its corresponding RRSIG (if present) against the DNSSEC chain of trust for the zone that owns the SVCB record (e.g., dnsprovider.com for ns.dnsprovider.com).¶

• DNSSEC Validation Failure: If DNSSEC validation fails the resolver SHOULD ignore the record and proceed as if no record had been received. The result of a failed the DNSSEC validation can be logged for further investigation.¶

QUESTION: Should the above DNSSEC restriction still apply? If so, we should explain when the two SHOULDs above might not be followed.¶

• Prioritisation of signals: Similarly to NS re-validation [I-D.draft-ietf-dnsop-ns-revalidation], any DNSSEC-validated SVCB record found via an explicit probe query MUST take precedence over any unvalidated SVCB record. OOTS signals are one of a number of methods that resolvers can use to determine transport capabilities of servers and they should be prioritized appropriately. For example, and OOTS signal may be deemed higher priority then the results of probing port 853 but MUST not take precedence over a DNSSEC signed transport signal obtained via a DELEG record.¶

• Spoofing of Unvalidated SVCB records: An SVCB record that cannot be DNSSEC validated (e.g., for ns.example.com where example.com is unsigned) is susceptible to spoofing by an on-path attacker. Such an attacker could insert a fake SVCB record advertising a non-existing transport, thereby denying connection over that transport. However, since the resolver connection policy is Opportunistic and not required for DNS resolution, the worst-case scenario is that the resolver attempts a connection that fails and then falls back to traditional transports. Security for the actual DNS data remains unaffected. The cryptographic validation of TLS/QUIC (via X.509 certificates) for DoT/DoQ would still protect the integrity and privacy of the connection itself.¶

• Certificate validation: While the certificate presented by the nameserver can be validated in a manner analogous to that described in [RFC8310] this only validates that the capability of the nameserver is as advertised. This does not validate that the nameserver is authoritative for the zone in question. If validation fails for any reason that information might be logged and/or reported to the operators of the servers in question.¶

• No New Attack Vectors: This mechanism does not introduce new attack vectors for DNS data itself, as it primarily concerns transport discovery. It relies on the existing security properties of DoT, DoH and DoQ for actual session security.¶

• Safe Rollout: Only recursive resolvers that implement OOTS will request or probe for SVCB records and only authoritatives that publish such records will respond with them.¶

9. Operational Considerations

• Response Size: Including an SVCB record in the Additional section will increase the size of UDP responses. Authoritative server operators should consider the potential for UDP fragmentation or TCP fallback if responses become excessively large, though a single SVCB record is typically small. Recursive nameservers should usually only set the EDNS(0) OOTS when they do not already have the transport signaling information.¶

• Server Configuration: Authoritative server implementations will need configuration options to enable this feature and manage the identities list.¶

• Rollout Strategy: This mechanism supports a gradual rollout. Authoritative servers can begin sending SVCB records to just those resolver requesting them, and resolvers can begin requesting SVCB records without requiring all authoritative servers to implement the feature.¶

• Monitoring: As there is extremely limited data on effects of alternative DNS transports for communication resolver to authoritative nameserver it is strongly suggested that monitoring (of use, resource consumption, etc) is considered.¶

10. Privacy Considerations

• Opportunistic provides no security guarantees: The above text discusses discovery of transport signals and authentication information in queries made by the recursive resolver. Those queries may or may not occur over encrypted or authenticated connections. Only when all the connections are authenticated are all the queries protected from active surveillance. If all the connections are Opportunistically encrypted then the queries are protected from passive surveillance. Otherwise they may occur in cleartext, or a combination of circumstances may exist.¶

• Leakage in queries to parents: Such queries leak the name of the zone that the resolver wishes to ultimately query which in itself can be sensitive. During the early stages of the incremental rollout of technologies such as recursive to authoritative encrypted connections it is unlikely that fully confidential discovery will be possible due to the nature of the DNS hierarchy. However, if large TLDs and/or those hosted by large CDNs support encrypted transports a significant number of queries from busy resolvers to discovery information on TLD child zones (and below) could be performed confidentially thereby greatly improving the privacy over the current situation.¶

11. IANA Considerations

   +-------+----------------------+----------+----------------------+
   | Value | Name                 | Status   | Reference            |
   +-------+----------------------+----------+----------------------+
   | TBD   | OOTS                 | Standard | ( This document )    |
   +-------+----------------------+----------+----------------------+

12. Implementation Status

Note to the RFC Editor: Please remove this entire section before publication.¶

• The TDNS Framework of experimental DNS servers developed and maintained by the Swedish Internet Foundation implements this draft (see https://github.com/johanix/tdns). TDNS has support for both the authoritative nameserver and recursive nameserver parts of the draft.¶

• There is a work-in-progress implementation in NSD TODO: Reference needed¶

13. Acknowledgments

The idea to use an SVCB "oots" SvcParam for transport signaling originated with the work on [DELEG].¶

Many people have commented and contributed to this document in different ways. In no particular order and with a significant risk of forgetting someone: The participants of the DELEG Working Group, Peter Thomassen, Christian Elmerot, John Todd, Peter Koch, Willem Toorop, Peter van Dijk.¶

14. References

Appendix A. Change History (to be removed before publication)

• -03 version¶

  • Re-structure draft and introduce Passive and Probe mode¶

Appendix B. Rationale for Using the Additional Section

Only DNS nameservers (authoritative or recursive) that are aware of the proposed mechanism will use it. It requires no changes to the existing protocol in order to convey more RR sets in the Additional section.¶

A downside is that it is not possible to strictly rely on anything specific being present in the Additional section, as it may be stripped off by a middlebox or even by the sending nameserver (eg. due to packet size constraints). For this reason it is not possible to guarantee the presence of the SVCB records even when the signal is explicitly queried for.¶

This is usually a major issue and the primary reason that data in the Additional section is actively ignored by resolvers. In this particular case, though, even an untrusted transport signal is better than no signal at all. Furthermore, the only effect of a forged or otherwise incorrect transport signal is a, typically failed, connection attempt to an authoritative nameserver that does not support the advertised transport. This will cause immediate fallback to "Do53", i.e. traditional DNS over UDP/TCP and the non-availability of the advertised transport will be remembered by the resolver (for some suitable time).¶

Hence, using the Additional section for request mode of OOTS has vastly more benefits than drawbacks.¶

Appendix C. Implementation considerations

Authors' Addresses