]> The Swedish Internet Foundation

Sweden johan.stenstam@internetstiftelsen.se

The Swedish Internet Foundation

Sweden leon.fernandez@internetstiftelsen.se

The Swedish Internet Foundation

Sweden erik.bergstrom@internetstiftelsen.se

NLnet Labs

Netherlands philip@nlnetlabs.nl

Sinodun IT

United Kingdom sara@sinodun.com

Internet DNSOP Working Group Internet-Draft This document proposes an Opportunistic Operator Transport Signaling mechanism (OOTS) based on SVCB records, to enable operators of authoritative DNS servers to signal their support for alternative transport protocols (e.g., DNS over TLS (DoT) and DNS over QUIC (DoQ)). These SVCB records can contain a new (experimental) SVCB "oots" key which contains fine grained information about the support for specific transports. Recursive resolvers can obtain these records either by requesting they be included in the Additional section of authoritative DNS responses (Passive mode) or by direct DNS queries (Probe mode). Resolvers can then Opportunistically upgrade connections to the authoritative to encrypted transports according to local policy, thereby improving privacy, security, and performance for subsequent interactions.

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) and DNS over QUIC (DoQ) to enhance privacy, security, and performance. 'Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS' 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 , 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 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 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) 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.

Structure of the document gives a general overview of the OOTS mechanism. provides recommendations for recursive resolvers on how to discover SVCB records using both Passive and Probe mode. provides recommendations for authoritative servers, in particular when to include records requested in Passive mode. describes how to use the parameters from the "oots" SvcParam (however they were obtained). The final sections provide Security, Operational and Privacy considerations.

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.

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. General DNS terminology used here follows that defined in . 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 . SCVB "oots" key: New experimental Service Parameter Key (SvcParamKey) key defined in 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 . 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.

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

Discovery policy for SVCB records Recursive resolvers can discover SVCB records one of two ways: Passive mode: A recursive resolvers sets the OOTS EDNS(0) option to indicate they want to receive SVCB records in the Additional section if they are available. A nameservers that is authoritative for the zone in question (i.e. managed by the zone operator) returns any SVCB records available for the authoritative nameservers when responding to a query with the OOTS EDNS(0) option set. This is the most efficient mode as it requires no additional queries to obtain the signal. Probe mode: A recursive resolver actively probes for SVCB records for some or all of the authoritative nameservers they query. This mode incurs more overhead but is useful, for example, for resolvers that have a local policy that includes attempting DNSSEC validation of the SVCB records. Discovery policy heuristics: The heuristics for doing SVCB discovery are an implementation decision since they should align with the local resolution logic in the software implementation. A typical use case might be to attempt to discover SVCB records when the resolver has no cached transport signaling information (i.e. the resolver is contacting the authoritative for the first time or any existing record has expired from the cache). However, a resolver might: perform cleartext queries and discover SVCB records in parallel. perform cleartext queries and in lazily discover for SVCB records (i.e. at some point in the future) delay cleartext queries until the result of a direct probe for SVCB records is known perform priming probes for an list of well known authoritative servers on start up and apply one of the above policies for all other authoritatives. In another approach, a resolver may start in Passive mode and subsequently probe directly for a SVCB binding record in an attempt to obtain a DNSSEC signed record (if the one obtained via the OOTS Option was not signed).

Connection policy for SVCB records Strict and Opportunistic connection policies for stub to recursive connections are described in and the terms are used analogously here. A recursive resolver can use SVCB records to Opportunistically upgrade connections to encrypted transports, but SHOULD honor the total query load shares specified in the SVCB records. Connection policy heuristics: Similarly to discovery policy heuristics, the details of the local connection policy are an implementation detail. Resolvers may attempt connections over encrypted transports at any time i.e. before sending any queries to the resolver, in parallel to sending cleartext queries to the resolver or at a later time after having obtained a SVCB record. Clearly, from a privacy perspective, is is preferable to use an encrypted transport as early as possible in the resolution process. But for an Opportunistic policy, this can and should be balanced with efficient and reliable query resolution. Capturing data on and developing the details of one or more strategies for these activities is expected to evolve over time.

Recommendations for recursive resolvers This section describes how recursive resolvers can discovery SVCB records.

OOTS Passive mode This mode consists of two steps: A resolver MAY include the new EDNS(0) option that defines an OOTS request in a query to an authoritative nameserver. A authoritative nameserver receiving that query SHOULD include SVCB records in the response if the required conditions are met, see .

Design decisions See for the rationale for using the Additional section for the transport signaling EDNS(0) OOTS Response.

The EDNS(0) OOTS Option To provide a mechanism for resolvers to explicitly request to receive transport signals, this document defines a new EDNS(0) option called "OOTS". When included in a query, this option signals to the authoritative server that the resolver wants to receive transport signals in the response. The EDNS(0) OOTS option is structured as follows:

Field definition details: OPTION-CODE: 2 octets / 16 bits (defined in ) contains the value TBD for OOTS. OPTION-LENGTH: 2 octets / 16 bits (defined in ) contains the length of the payload in octets. For the OOTS option, this value MUST be 0 as there is no payload. The OOTS option is designed to be a simple, lightweight mechanism that can be used to enable transport signaling without affecting the normal operation of DNS resolution.

Sending Queries Recursive resolvers MAY include the EDNS(0) OOTS Option in a query to an authoritative to request transport signaling be included in the response.

Receiving Responses

Parsing responses When receiving an authoritative DNS response to a query where the EDNS(0) OOTS option was set the resolver SHOULD parse the Additional section for SVCB records. When receiving a DNS response to a query where the EDNS(0) OOTS option was not set the resolver SHOULD ignore any SVCB records in the Additional section for the purposes of transport signaling. If the EDNS(0) OOTS option was set in a query but no SVCB record was received in the response, the resolver should proceed as if there are no SVCB records for the zone that resolution is being performed on.

Valid SVCB records If an SVCB record is found whose owner name matches an authoritative nameserver identified in the Authority or Answer sections of the current response and the SVCB contains an "oots" SvcParam , the resolver MAY consider this a valid SVCB record. If it does not, the resolver MUST ignore the SCVB record. If any other parameter, including "ipv4hint" and "ipv6hint", is present in the SVCB parameter list then that parameter SHOULD be ignored. TODO: We do not yet discuss multiple SVCB records in a response. One option is to have multiple records, one per transport and then the other ScvParams in the record e.g. 'port', 'ipv4 hint' can be used for that transport. Another is to have only one record, and ignore all other SvcParams to avoid having to define interactions while we experiment. Regardless, we need to clarify interactions with other keys, if any. QUESTION: Should we specify that authoritatives that implement this specification set the EDNS(0) OOTS option in a response to make it clearer that there is no signal? Since both the option and the records can be tampered with if they are sent over cleartext this may not be useful. But if the response it sent over an encrypted transport this may form a useful signal for measuring deployment.

OOTS Passive mode queries Example 1: If the resolver queries ns.dnsprovider.net for www.example.com. and ns.dnsprovider.net is authoritative for www.example.com, the respond might be:

TODO: More examples, including use of Alias Mode (with a discussion of priority)

Forwarders Forwarders SHOULD NOT modify any EDNS(0) OOTS option in any query. Forwarders SHOULD NOT modify SVCB records in the Additional section of any response.

Stub resolvers Stub resolvers SHOULD NOT set the EDNS(0) OOTS option in any query. Stub resolvers SHOULD ignore any SVCB records in the Additional section of any response.

OOTS Probe mode

Sending queries Recursive resolvers MAY also probe directly for SVCB records for any authoritative nameserver they need to connect to perform recursion.

Receiving responses If the SVCB record contains a "oots" SvcParam the resolver MAY consider this a valid SVCB record. If it does not, the resolver MUST ignore the SCVB record for the purposes of transport signaling. If any other parameter, including "ipv4hint" and "ipv6hint", is present in the SVCB parameter list then it SHOULD be ignored.

OOTS Probe mode queries Example: The resolver explicitly asks for the DNS transport signal for the authoritative nameserver ns.dnsprovider.net. by querying for "_dns.ns.dnsprovider.net. SVCB":

Recommendations for Authoritative servers

OOTS Probe mode

Sending responses An authoritative nameserver SHOULD NOT include SVCB records in a response if the EDNS(0) OOTS option was not present in the query. This is to avoid increasing the size of responses to resolvers that do not implement this specification. NOTE - During development and prototyping of this specification a valid reason that an experimental deployment might decide to include SVCB records in all responses is for testing purposes. Authoritative servers that implement this specification should provide a configuration option to control whether or not SVCB records are included in responses if the nameserver is configured to serve minimal responses. Authoritative nameserver implementations differ significantly in how they generate the content of responses. Some have a concept of a server identity, others do not. Some can synthesize records and DNSSEC sign on-the-fly, others cannot. As a result, attempting to specify a general algorithm for how nameservers should determine which responses to include SVCB records in is out of scope for this document. Instead it is stated that the nameserver SHOULD include an SVCB record in a response if the EDNS(0) OOTS option was set in the query and: the nameserver is authoritative for the zone containing the QNAME in the query the nameserver has access to, or can generate an SVCB record with a matching owner name the owner name of the SVCB record MUST be the label "_dns" followed by the FQDN of an authoritative nameserver for the zone, as identified in the child NS RRset for the zone. QUESTION: Have changed the text in the owner name bullet here to say 'child NS set' - is that correct or can we be more flexible 'parent or child'? Details of some known implementation methodologies are presented for context in .

Using SVCB records The SVCB records are a mechanism to discover capabilities of nameservers, not to override trusted delegation or service configuration. 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:

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 , section 4.

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 , 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 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.

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.

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.

IANA Considerations

OOTS EDNS(0) Option This document defines a new EDNS(0) option, entitled "OOTS", assigned a value of TBD in the "DNS EDNS(0) Option Codes (OPT)" registry.

Note to the RFC Editor: In this section, please replace occurrences of "(This document)" with a proper reference.

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

Acknowledgments The idea to use an SVCB "oots" SvcParam for transport signaling originated with the work on . 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.

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 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 document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. 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. The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. 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. 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. The Swedish Internet Foundation NLnet Labs 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 document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Salesforce SIE Europe, U.G. NLnet Labs This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the shortest TTL among the parent NS RRset, the DS RRset (if present), and the child NS RRset. ISC Akamai Technologies Salesforce This document specifies a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGPARAM records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. In classic DNS, both parent and child zones contain copies of NS delegation records, which can potentially be out of sync and confusing. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information.

Change History (to be removed before publication) -03 version Re-structure draft and introduce Passive and Probe mode

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.

Implementation considerations

Authoritative Probe mode methodologies

Multiple Server Identities An authoritative nameserver may be known by multiple FQDNs (e.g., ns1.example.com, dns.customer.org, ns.cdnprovider.net). To facilitate methodology 1 ("Self-Identification"), authoritative server implementations can include a configuration mechanism (e.g., an identities list) where operators can list all FQDNs by which the server is known. This allows the server to correctly identify itself regardless of the specific name used in the NS RRset.

Methodology 1 An authoritative nameserver SHOULD include SVCB records in the Additional section and all of the following conditions are met: Presence of the OOTS Option: The query includes an EDNS(0) OOTS option from the resolver. NS RRset Presence: An NS Resource Record Set (RRset) for the queried zone is present in either the Answer section or the Authority section of the DNS response. Self-Identification: The responding authoritative nameserver's own Fully Qualified Domain Name (FQDN) (or one of its configured aliases/identities) is found within the NS RRset mentioned in condition 1. Transport Capability: The responding authoritative nameserver supports one or more alternative transport protocols (e.g., DoT, DoH, DoQ) and is configured to advertise these capabilities. Availability of RRSIG SVCB: If the zone in which the nameserver name is located is signed, only include the SVCB record if it is possible to also include the corresponding RRSIG SVCB. If the zone with the nameserver name is unsigned, then include the SVCB even without the RRSIG. TODO: Discuss - the requirement for the SVCB record to be included only if it is DNSSEC-signed has the consequence that the DTS transport signal cannot be present for an unsigned zone using vanity names in the zone for its nameservers.

Methodology 2 TODO: Refine the NSD example to be included here.