Introducing SVCB and HTTPS Resource Records
Completed
The SVCB (Service Binding) and HTTPS DNS resource records have been announced as standard. They mark a significant advancement in how connections to network services will be managed going forward and are an excellent addition to the DNS protocol. These new DNS record types were proposed as a standard in November 2023 as detailed in RFC 9460. They are specifically designed to optimize performance and privacy for internet services that use HTTP.
The emergence of SVCB and HTTPS records was a response to the need for more secure, flexible, and efficient DNS resolution. Traditional DNS records such as A, AAAA, and CNAME were not considered adequate to support modern web architectures and security standards, and these records were conceived to fill in the gaps. They were developed as part of a broader effort by the internet community to enhance DNS capabilities in line with evolving internet technologies and security requirements.
SVCB DNS Record
The core functionality of SVCB records lies in their ability to offer a service from multiple alternative endpoints. Each endpoint can have its own set of associated parameters, such as transport protocol configurations. This adaptability not only enhances the service's flexibility but also prepares it for future technological developments, like the implementation of keys for encrypting the TLS ClientHello. Additionally, SVCB records facilitate a previously unattainable feature with traditional CNAME records: the aliasing of apex domains.
SVCB Record Structure: The SVCB record is comprised of multiple fields, including SvcPriority, TargetName, and optional SvcParams. SvcPriority indicates the record's preference, with lower values being more preferred. TargetName specifies the domain name of the service endpoint.
SvcParams: This field is a collection of key-value pairs providing specific service parameters. Some important parameters include:
alpn: Lists supported application-layer protocols, crucial for protocol negotiation.
no-default-alpn: Indicates the absence of a default ALPN, requiring explicit negotiation.
port: Specifies the service's port if it differs from the default.
ipv4hint and ipv6hint: Provide IP addresses hints to expedite connection establishment.
AliasMode vs ServiceMode:
AliasMode (SvcPriority = 0) functions like a CNAME record but can be used at the zone apex.
ServiceMode (SvcPriority > 0) binds the TargetName to specific service parameters, guiding the client to the optimal service endpoint.
Example
Consider a scenario with a domain service.example.com that wants to specify multiple service endpoints with different parameters.
service.example.com. 7200 IN SVCB 1 svc1.example.net. (
"alpn=h2,h3"
"port=8443"
"ipv4hint=192.0.2.10,192.0.2.11"
"ipv6hint=2001:db8::1,2001:db8::2"
) In this example:
‘7200’ is the TTL (Time To Live) in seconds.
‘1’ is the SvcPriority. A non-zero value means it's in ServiceMode.
‘svc1.example.net.’ is the TargetName, the domain name of the service endpoint.
The ‘alpn’ parameter specifies the supported protocols (HTTP/2 and HTTP/3 here).
‘port’ specifies the service's port number.
‘ipv4hint’ and ‘ipv6hint’ provide IP address hints.
HTTPS DNS Record: Specialized for HTTP Services
The HTTPS resource record is a variation of SVCB designed for use with HTTP services according to "HTTP Semantics." These records provide detailed information to the client before attempting to establish a connection, which can improve the performance and privacy of web interactions. They allow direct connections to HTTP/3 alternative endpoints and support non-default TCP and UDP ports. Additionally, they offer benefits similar to SRV records for HTTP, which have yet to see widespread adoption.
HTTP-Specific Optimization: While structurally similar to SVCB, the HTTPS record is explicitly designed for HTTP services, enabling direct and optimized connections to HTTP(S) servers.
Additional HTTP Parameters:
The record can include parameters like echconfig (Encrypted ClientHello configuration), enhancing privacy and security in initial TLS handshakes.
Supports direct HTTP/3 connections, bypassing the usual upgrade process from HTTP/1.1 or HTTP/2.
Enhanced Performance and Security: By pre-resolving service details, HTTPS records reduce the need for additional DNS lookups and connections, streamlining the process for clients and improving overall efficiency and security.
HTTPS Record Example
For an HTTPS-specific record, let's consider a domain web.example.com with an HTTPS service:
web.example.com. 7200 IN HTTPS 1 svc2.example.net. (
"alpn=h3"
"port=443"
"echconfig=..."
) Here, ‘HTTPS’ indicates the record type specific to HTTP services.
‘svc2.example.net.’ is the TargetName for the HTTPS service.
The ‘alpn’ parameter specifies HTTP/3 as the supported protocol.
‘port’ is the standard HTTPS port (443 in this case).
‘echconfig’ provides Encrypted ClientHello configuration, a string representing the encrypted configuration for the initial TLS handshake.
SVCB and HTTPS Records in Action
How SVCB and HTTPS records can transform DNS in real-world scenarios.
1. Streamlining Video Streaming Services: Consider a scenario where a widely used video streaming platform faces a surge in traffic, particularly during the debut of a highly anticipated show. In such a situation, the platform can leverage SVCB records to allocate user requests to several endpoints, each optimized for different network conditions or locations. This helps balance the load, preventing server overload and minimizing latency, ultimately creating a seamless streaming experience.
2. Boosting E-commerce Reliability: During high-traffic events like Black Friday sales, SVCB records can help e-commerce giants by directing users to the nearest server farm with the lowest latency. This results in faster page loads, quicker transaction processing, and a higher chance of converting timely clicks into sales.
3. Enhancing Financial Services Security: A financial organization may use HTTPS records to implement strict security measures. They can specify endpoints that support advanced security protocols for mobile banking apps, ensuring that users always connect through the safest path, fortified with the latest encryption standards.
4. Facilitating Multi-CDN Deployments: Websites with global audiences often use multiple Content Delivery Networks (CDNs) to serve content efficiently. SVCB records can help by providing DNS-level instructions that guide user requests to the most appropriate CDN based on real-time performance data.
5. Seamless Cloud Services Transition: Cloud services frequently move from one data center to another or switch to different operational endpoints. To ensure smooth transitions with minimal disruption to users, SVCB and HTTPS records redirect traffic through DNS responses instead of requiring changes in server configurations. This enables seamless migration between data centers or shifts to new endpoints.
By enabling more intelligent and flexible connections, SVCB and HTTPS records promise a faster, more secure, and more stable internet. These scenarios are just a few examples of their applications.
SVCB records and the implementation of keys for encrypting the TLS ClientHello.
The SVCB record enables the passing of service-specific parameters for supporting Encrypted ClientHello (ECH). For instance, a web server with domain name web.example.com can include an SVCB record in its DNS response, which contains parameters like alpn, port, and echconfig.
web.example.com. 7200 IN HTTPS 1 svc2.example.net. (
"alpn=h3"
"port=443"
"echconfig=1234...abcd”
) The SVCB record can include an echconfig parameter containing the information needed to perform ECH. In the SVCB record, you pass the SVCB echconfig parameter as echconfig="1234...abcd". The echconfig value is essentially an encoded string that provides the necessary details for the client to encrypt parts of its ClientHello message.
When a client resolves a domain name and receives an SVCB record in response, it can use the echconfig information from the SVCB record to initiate a TLS handshake with ECH. This means the client has the information to start a secure connection without exposing details like the server name indication (SNI) to potential eavesdroppers.
By providing ECH information in the SVCB record, the number of round trips required during the TLS handshake can be reduced. Normally, a client would connect to a server using a non-encrypted ClientHello, receive a response indicating ECH support, and then restart the handshake process with ECH. The SVCB record simplifies this process, resulting in faster connection setup times.
These advancements represent a thoughtful response to the complexities and challenges of modern web service delivery. The emphasis on enhanced performance, privacy, and flexibility underscores the continued evolution of internet technologies and the persistent drive to optimize user experience in an increasingly connected world.
In conclusion, the recent developments in web services demonstrate a comprehensive understanding of the industry's challenges and a commitment to providing high-quality services that meet the evolving needs of users.
If you would like to obtain more detailed information regarding SVCB and HTTPS DNS resource records, you can refer to the official documentation available at RFC 9460.