1. Introduction

The SVCB ("Service Binding") and HTTPS resource records (RRs) provide clients with complete instructions for access to a service. This information enables improved performance and privacy by avoiding transient connections to a suboptimal default server, negotiating a preferred protocol, and providing relevant public keys.

For example, HTTP clients currently resolve only A and/or AAAA records for the origin hostname, learning only its IP addresses. If an HTTP client learns more about the origin before connecting, it may be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted ClientHello [ECH], or switch to an operationally preferable endpoint. It is highly desirable to minimize the number of round trips and lookups required to learn this additional information.

The SVCB and HTTPS RRs also help when the operator of a service wishes to delegate operational control to one or more other domains, e.g., aliasing the origin https://example.com to a service operator endpoint at svc.example.net. While this case can sometimes be handled by a CNAME, that does not cover all use cases. CNAME is also inadequate when the service operator needs to provide a bound collection of consistent configuration parameters through the DNS (such as network location, protocol, and keying information).

This document first describes the SVCB RR as a general-purpose RR that can be applied directly and efficiently to a wide range of services (Section 2). It also describes the rules for defining other SVCB-compatible RR types (Section 6), starting with the HTTPS RR type (Section 9), which provides improved efficiency and convenience with HTTP by avoiding the need for an Attrleaf label [Attrleaf] (Section 9.1).

The SVCB RR has two modes: 1) "AliasMode", which simply delegates operational control for a resource and 2) "ServiceMode", which binds together configuration information for a service endpoint. ServiceMode provides additional key=value parameters within each RDATA set.