In the rapidly evolving landscape of network technology, efficient service discovery, and secure connection establishment stand as pivotal components for developers, network engineers, and DNS administrators. To address the increasing complexities and demands of modern internet infrastructure, SVCB (Service Binding) and HTTPS DNS resource records have emerged as groundbreaking standards. These new DNS record types promise to revolutionize the way services are discovered and connections are established, paving the way for more dynamic, secure, and scalable internet communication.
This blog post is dedicated to giving you a full introduction to SVCB and HTTPS DNS records. We’ll also explore why these have been named the new standards and how they are set to transform service discovery and connection establishment. Whether you’re a seasoned developer, a network engineer seeking to optimize service performance, or a DNS administrator looking to stay ahead of the curve, this deep dive will equip you with the necessary insights and technical know-how.
What is a 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 includes multiple fields, including SvcPriority, TargetName, and optional SvcParams. SvcPriority indicates the record’s preference, with lower values being 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: Provides IP address 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.
SVCB in action.
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.
The record can include parameters like echconfig (Encrypted ClientHello configuration), enhancing privacy and security in initial TLS handshakes.
It also 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
SVCB and HTTPS records can transform DNS in real-world scenarios, including:
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 eCommerce reliability
During high-traffic events like Black Friday sales, SVCB records can help eCommerce 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 to support 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.
Meeting the evolving needs of users
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.
To learn more about how Vercara can help your organization address the complexities and challenges of modern web service delivery, visit our UltraDNS product page.
