DNS-SVCB and HTTPS RRs Faster Connection Bootstrap

The Domain Name System (DNS) is the cornerstone of the modern Internet’s addressing infrastructure, translating human-readable domain names into IP addresses that computers can use to locate services. Traditionally, this process has been limited in its scope, offering basic mappings from domain names to A (IPv4) and AAAA (IPv6) records, along with service-specific SRV records for certain protocols. However, as the complexity of web protocols and performance optimization requirements has grown, the limitations of traditional DNS responses have become more apparent. To address these challenges, the Internet Engineering Task Force (IETF) introduced two new DNS record types—SVCB (Service Binding) and HTTPS Resource Records (RRs)—which aim to streamline the process of establishing secure connections to web services and other protocols. Together, these new record types enable faster connection bootstrapping by providing clients with richer metadata during the initial DNS lookup, reducing round-trip times and improving service performance.

The SVCB and HTTPS record types are defined in RFC 9460 and build upon the concept of service binding, offering a way for authoritative DNS servers to inform clients not only of the IP addresses of a service, but also of additional connection-related parameters. The SVCB record, which stands for Service Binding, is a generic mechanism that can be used by multiple protocols to describe how clients should connect to a named service. The HTTPS RR is a specialization of SVCB tailored specifically for use with the HTTPS protocol, although functionally they share the same record format and semantics. Both allow a domain to specify information such as supported protocols (e.g., HTTP/3 over QUIC or HTTP/2 over TLS), alternative endpoints, ALPN (Application-Layer Protocol Negotiation) identifiers, port numbers, and even Encrypted Client Hello (ECH) configurations.

One of the most impactful features of SVCB and HTTPS RRs is their ability to advertise alternate service endpoints or aliases through the use of service priorities. For example, a domain can specify a primary service with a low-priority value and fallbacks with higher values. This allows clients to attempt connections in a prioritized order, enabling automatic failover to other infrastructure if the preferred service is unreachable. Additionally, these records can include parameters such as “alpn” and “ipv4hint” or “ipv6hint,” which allow clients to skip certain steps in the connection process. ALPN hints inform clients about the expected application protocols, enabling them to establish connections without additional handshakes to determine compatibility. Address hints can eliminate the need for a separate A/AAAA resolution, reducing the latency of the initial connection setup.

For HTTPS in particular, the new record type addresses several long-standing performance bottlenecks. Traditionally, a client connecting to an HTTPS server must first perform a DNS lookup to obtain the IP address, then initiate a TCP connection and a TLS handshake. If the server supports multiple application-layer protocols, the client must perform ALPN negotiation during the TLS handshake to determine which protocol to use. With HTTPS RRs, much of this information can be learned in advance during the DNS query. This allows the client to preconfigure its connection parameters, select the appropriate transport protocol (e.g., TCP or QUIC), and even decide on the use of HTTP/3 before sending a single byte on the wire. In scenarios where HTTP/3 is available, the client can initiate a QUIC connection immediately, avoiding the overhead of a TCP+TLS handshake entirely.

Another powerful feature enabled by these new records is support for Encrypted Client Hello (ECH), which is designed to encrypt the contents of the TLS ClientHello message, including the Server Name Indication (SNI). SNI has historically been a privacy concern because it reveals the specific hostname the client is connecting to, even before encryption is established. HTTPS RRs can contain the configuration necessary to support ECH, allowing clients to encrypt their initial handshake messages without an additional round-trip or out-of-band key discovery. This capability is essential for preserving user privacy in an era of pervasive encryption and surveillance concerns.

Deployment of SVCB and HTTPS records requires updates to both authoritative DNS infrastructure and client resolvers. Authoritative name servers must support the new record types and serve them in response to queries for SVCB or HTTPS. These records coexist with traditional A and AAAA records, allowing a gradual transition for clients that do not yet support the new types. On the client side, support is emerging in major web browsers and operating systems. For example, Firefox and Chromium-based browsers have experimental or partial support for HTTPS RRs and ECH, while platforms like Android and iOS are adding capabilities to parse and act on SVCB metadata during DNS resolution.

From a network perspective, the impact of these new record types is significant. By reducing the number of required DNS queries and enabling clients to make more informed connection choices up front, overall connection setup times are lowered. This is particularly valuable in mobile or high-latency environments, where even minor reductions in round-trips can have a noticeable effect on user experience. Furthermore, the additional metadata can help optimize the use of alternate CDNs, load balancing strategies, and network path selection based on the client’s capabilities and location.

Operationally, SVCB and HTTPS records introduce some new considerations for domain administrators. These include key management for ECH configurations, coordination with CDN providers to ensure consistent records across regions, and monitoring client behavior to assess the performance benefits of the new data. DNSSEC signing of SVCB and HTTPS records is also recommended to prevent spoofing or injection of malicious service metadata, especially given the increased sensitivity of information contained within these records.

In conclusion, DNS-SVCB and HTTPS resource records represent a significant advancement in the way DNS can assist with connection establishment and security negotiation. By enabling the transmission of connection-specific metadata during the initial DNS lookup, they reduce latency, enhance privacy, and provide a more flexible framework for deploying modern transport protocols. As client support matures and infrastructure adoption increases, these record types are poised to become a cornerstone of efficient, secure, and responsive service discovery on the Internet.

The Domain Name System (DNS) is the cornerstone of the modern Internet’s addressing infrastructure, translating human-readable domain names into IP addresses that computers can use to locate services. Traditionally, this process has been limited in its scope, offering basic mappings from domain names to A (IPv4) and AAAA (IPv6) records, along with service-specific SRV records…