]> Meta Platforms, Inc.

ietf@bemasc.net

Meta Platforms, Inc.

chantr4@gmail.com

This draft defines a flag to mark a service endpoint as being potentially unreliable. This flag may be useful when introducing new features that could have a negative impact on availability. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Service Binding (SVCB) DNS record type , and SVCB-compatible types like HTTPS, convey a collection of endpoints that can provide a service, along with metadata about each of those endpoints. This metadata can indicate protocol features that are available and supported on those endpoints. In most cases, advertising new features is unlikely to render the service unavailable. Clients that are unaware of these features will ignore them, and clients that are aware will fall back to other SVCB records or other connection modes if the feature doesn't work. However, for security-enhancing features, this fallback behavior would create a loss of security against an active attacker, so it is generally not allowed. Instead, if the feature does not work as expected, the client will "fail closed". This behavior can make it challenging to deploy security-enhancing features, as the initial public deployment can create an outage if the service is misconfigured. This document defines a new SVCB SvcParam to help service operators offer new security features. By marking these features as still being tested, the operator advises the client to interpret problems as an accidental failure by the operator, not a malicious action by an active attacker.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Specification The "testing" flag is a SvcParam that always has an empty value in presentation and wire format. When present, this flag indicates that this ServiceMode record is subject to outages, and clients SHOULD NOT interpret connection failures as evidence of an active attack. Service owners SHOULD ensure that this flag is mandatory, either explicitly (by adding mandatory=testing to the SvcParams) or implicitly if this parameter is "automatically mandatory" for the protocol mapping. Future protocol mappings SHOULD make this SvcParam "automatically mandatory".

Interaction with SvcPriority Clients SHOULD NOT alter the priority of SVCB records based on the presence of the "testing" flag. Deprioritizing SVCB records with this flag would result in little or no user traffic making use of the testing record, which would defeat the goal of validating that new features function correctly for real users.

Example: Encrypted DNS Protocol Consider the case of a plaintext DNS server operator at "dns.example.com" who would like to announce support for DNS over TLS . Per , this operator could publish a record like: Clients following would retrieve this record, observe that DNS over TLS is available, and attempt to use it on TCP port 853. If the TLS session cannot be established for any reason, a compliant client will not fall back to plaintext DNS on UDP port 53, because the failure could indicate an active attack (). If the operator of "dns.example.com" does not have operational confidence in their DNS over TLS service, this failure mode could raise concerns about the potential consequences of offering this new service. To reduce the risk associated with this new service, the operator could instead use the new "testing" flag as follows: Clients that do not implement this specification will ignore the record because it specifies an unrecognized mandatory SvcParam. They will continue to use plaintext DNS. Clients that respect the "testing" flag will attempt to use DNS over TLS, but they will fall back to plaintext DNS if DNS over TLS is non-functional.

Security Considerations Use of the "testing" flag explicitly disables SVCB's defense against active attackers. This is a loss in security. However, the intent of this flag is to facilitate the deployment of security-enhancing protocols. Downgrade-resistant security is achieved only when the testing period is complete and the "testing" flag is removed.

IANA Considerations IANA is requested to add this entry to the SVCB SvcParams Registry:

Number	Name	Meaning	Change Controller	Reference
TBD	testing	Endpoint may be unreliable	IETF	(This document)

References Normative References This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. 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. Akamai Technologies Akamai Technologies Salesforce A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace.

Acknowledgments This proposal is inspired by deployment considerations related to .