SVCB DNS Records: Modernizing Service Discovery

Introduction

Have you ever wondered why connecting to a website sometimes feels slower than it should, even with a fast internet connection? The culprit often lies in the multiple DNS lookups and negotiation roundtrips required before your browser can establish a secure connection. Traditional DNS records like A, AAAA, and CNAME were designed decades ago and simply weren’t built for today’s complex web architectures with HTTP/3, multiple CDNs, and encrypted connections.

SVCB (Service Binding) and HTTPS DNS records, standardized in RFC 9460 in November 2023, fundamentally change how clients discover and connect to network services. These records allow services to advertise complete connection information—including supported protocols, alternative endpoints, and encryption parameters—in a single DNS query. This means faster connections, better privacy, and more flexibility for service operators.

In this guide, you’ll learn what SVCB and HTTPS records are, how they work, when to use them, and how to implement them in your infrastructure. Whether you’re optimizing a high-traffic website, managing multi-CDN deployments, or simply curious about modern DNS innovations, understanding these records is becoming essential for network engineers and developers alike.

Prerequisites

Before diving into SVCB records, you should have:

Basic understanding of DNS concepts (A, AAAA, CNAME records)
Familiarity with HTTP/HTTPS and TLS connections
Knowledge of how browsers resolve domain names
Access to a DNS server or managed DNS provider (for practical implementation)
Basic command-line skills for testing DNS queries

Optional but helpful:

Understanding of ALPN (Application-Layer Protocol Negotiation)
Familiarity with HTTP/2 and HTTP/3
Experience with DNSSEC

Understanding the DNS Performance Problem

Traditional DNS resolution for HTTPS connections involves multiple steps that add latency:

DNS Query: Client queries for A/AAAA records to get IP addresses
TCP Connection: Client establishes TCP connection to the server
TLS Handshake: Client and server negotiate encryption (multiple roundtrips)
Protocol Negotiation: ALPN negotiates which HTTP version to use
Potential Redirect: Server might redirect to HTTP/3 or different endpoint

Each step adds latency, especially over high-latency networks. For users, this translates to slower page loads and a perception of poor network performance, even when the underlying infrastructure is fast.

What are SVCB and HTTPS Records?

SVCB: The Generic Service Binding Record

SVCB (DNS Type 64) is a general-purpose DNS record that provides complete service binding information for any protocol. It allows domain owners to specify alternative endpoints with associated connection parameters.

Key capabilities:

Specify multiple alternative endpoints with priorities
Include service parameters like port, protocol, and IP hints
Enable apex domain aliasing (solving CNAME limitations)
Support any protocol scheme (HTTPS, DNS-over-TLS, custom protocols)

HTTPS: Specialized for Web Traffic

HTTPS (DNS Type 65) is a specialized variant of SVCB designed specifically for HTTP and HTTPS services. It uses the same syntax but removes the need for prefix labels when using standard HTTPS on port 443.

Why a separate record type?

Simpler syntax for the most common use case
Enables offline DNSSEC signing of wildcard domains
Compatible with existing CNAME chains at CDN edges
Signals automatic HTTPS upgrade (http:// URLs use https://)

Two Operating Modes

Both SVCB and HTTPS records operate in one of two mutually exclusive modes, determined by the priority value:

AliasMode (Priority = 0)

AliasMode functions similarly to CNAME but without the restrictions. It redirects resolution to another domain name.

Example:

example.com. 3600 IN HTTPS 0 cdn.example.net.

Key differences from CNAME:

Can coexist with other records (A, AAAA, MX, SOA, NS)
Works at the zone apex
Only matches HTTPS/SVCB query types (not a wildcard)
Clients must be SVCB-aware

When to use: Delegating your apex domain to a CDN or cloud provider while maintaining MX and other records.

ServiceMode (Priority ≥ 1)

ServiceMode provides connection parameters for specific service endpoints. Multiple ServiceMode records can exist, with lower priority values preferred.

Example:

example.com. 3600 IN HTTPS 1 . alpn=h3,h2 ipv4hint=192.0.2.1
example.com. 3600 IN HTTPS 2 backup.example.net. alpn=h2

When to use: Advertising protocol support, providing IP hints, or offering multiple alternative endpoints.

Essential Service Parameters

Service parameters (SvcParams) are key-value pairs that describe how to connect to an endpoint. Here are the most important ones:

alpn (Application-Layer Protocol Negotiation)

Specifies supported protocols, allowing clients to skip the ALPN negotiation during TLS handshake.

Format: alpn=h3,h2,http/1.1

Common values:

h3 - HTTP/3 (QUIC)
h2 - HTTP/2
http/1.1 - HTTP/1.1
dot - DNS-over-TLS

Example:

example.com. IN HTTPS 1 . alpn=h3,h2

This tells clients the server supports HTTP/3 and HTTP/2, enabling direct protocol selection.

port

Specifies an alternative port number (default is protocol-specific).

Format: port=8443

Example:

_https._tcp.example.com. IN SVCB 1 srv.example.com. port=8443 alpn=h2

ipv4hint and ipv6hint

Provides IP address hints to reduce additional DNS lookups. Clients can use these addresses immediately while still querying A/AAAA records for fallback.

Format: ipv4hint=192.0.2.1,192.0.2.2 ipv6hint=2001:db8::1

Example:

example.com. IN HTTPS 1 . alpn=h3 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

Performance benefit: Eliminates the need for separate A/AAAA queries when HTTPS record is cached.

mandatory

Indicates which parameters must be understood by the client. If a client doesn’t understand a mandatory parameter, it must skip that record.

Format: mandatory=alpn,ipv4hint

Example:

example.com. IN HTTPS 1 . mandatory=alpn alpn=h3

This ensures only HTTP/3-capable clients attempt connection.

ech (Encrypted ClientHello)

Provides configuration for encrypting the TLS ClientHello, enhancing privacy by hiding the Server Name Indication (SNI).

Format: ech=<base64-encoded-config>

Example:

example.com. IN HTTPS 1 . alpn=h3 ech=AEX+DQBBNw...

Practical Implementation Examples

Example 1: Basic HTTPS with HTTP/3 Support

Enable HTTP/3 for your website:

; Basic HTTPS record advertising HTTP/3 support
example.com. 3600 IN HTTPS 1 . alpn=h3,h2 ipv4hint=203.0.113.1

; Keep traditional records for non-SVCB clients
example.com. 3600 IN A 203.0.113.1
example.com. 3600 IN AAAA 2001:db8::1

What this achieves:

SVCB-aware clients connect directly via HTTP/3
Legacy clients fall back to A/AAAA records
Single DNS query for modern clients

Example 2: Apex Aliasing for CDN

Delegate your apex domain to a CDN while maintaining email:

; Alias apex to CDN (impossible with CNAME)
example.com. 3600 IN HTTPS 0 example.cdn.com.

; Email records coexist (would conflict with CNAME)
example.com. 3600 IN MX 10 mail.example.com.

; Traditional records for legacy clients
example.com. 3600 IN A 203.0.113.50

Example 3: Multi-CDN with Priorities

Distribute traffic across multiple CDNs with fallback:

; Primary CDN (priority 1)
example.com. IN HTTPS 1 primary.cdn-a.net. alpn=h3,h2

; Secondary CDN (priority 2)
example.com. IN HTTPS 2 backup.cdn-b.net. alpn=h2

; Tertiary on-premise (priority 3)
example.com. IN HTTPS 3 direct.example.com. alpn=h2 ipv4hint=203.0.113.10

Client behavior: Tries endpoints in priority order (1, 2, 3), with parallel attempts allowed.

Example 4: Service on Custom Port

Advertise a service running on a non-standard port:

; SVCB for a custom protocol on port 8080
_myapp._tcp.example.com. IN SVCB 1 app.example.com. port=8080 alpn=myprotocol

; Can include IP hints to optimize connection
_myapp._tcp.example.com. IN SVCB 2 app2.example.com. port=8080 ipv4hint=203.0.113.20

Example 5: Encrypted ClientHello for Privacy

Enhance privacy with ECH:

example.com. IN HTTPS 1 . ( 
  alpn=h3,h2 
  ech=AEn+DQBBNwAgACCKJZaJeQ...
  ipv4hint=203.0.113.1 
)

Privacy benefit: TLS handshake doesn’t reveal destination hostname in plaintext.

Testing SVCB/HTTPS Records

Using dig (DNS Query Tool)

Query SVCB records:

# Query HTTPS record
dig example.com HTTPS

# Query with detailed output
dig +noall +answer +additional example.com HTTPS

# Query specific SVCB record with service prefix
dig _https._tcp.example.com SVCB

Using modern DNS tools

# Dog (modern dig alternative)
dog example.com HTTPS

# kdig with verbose output
kdig example.com HTTPS +short

Verify with online tools

DNS Checker: Various online DNS checking tools now support HTTPS/SVCB
Cloudflare’s DNS resolver (1.1.1.1) and Google Public DNS (8.8.8.8) both support these records

Testing client behavior

For browsers, check the Network tab in Developer Tools:

Look for “h3” in Protocol column (HTTP/3)
Check if connection was established on first try vs. upgrade

Client and Server Support

Browser Support (2024-2025)

Chrome/Chromium:

Supported since Chrome 88 (2020) with Secure DNS enabled
Actively queries HTTPS records for connections
Uses records to optimize HTTP/3 connections

Firefox:

Support available but requires enabling DoH (DNS-over-HTTPS)
Set network.dns.upgrade_with_https_rr to true in about:config
Not enabled by default as of late 2024

Safari (iOS/macOS):

Full support since iOS 14 (2020) and macOS 11 (2020)
Queries Type 65 (HTTPS) for all HTTP/HTTPS connections
Best production support among major browsers

Edge:

Follows Chromium implementation
Supported with Secure DNS enabled

DNS Provider Support

Major providers with SVCB/HTTPS support:

Cloudflare (authoritative and resolver)
AWS Route 53 (added October 2024)
Google Cloud DNS
Akamai Edge DNS
NS1
UltraDNS
PowerDNS (v4.4.0+)
BIND9 (v9.18+)
Knot DNS (v3.0.3+)

Server Requirements

Web servers don’t need changes to support SVCB/HTTPS records—they’re a DNS feature. However, servers should:

Support protocols advertised in records (HTTP/3, HTTP/2)
Listen on ports specified in records
Have ECH support if advertising ech parameter

Common Pitfalls and Troubleshooting

Issue 1: Records Not Working for Legacy Clients

Problem: Users with older browsers can’t connect after adding SVCB/HTTPS records.

Solution: Always maintain traditional A/AAAA records alongside SVCB/HTTPS records.

; CORRECT: Both record types
example.com. IN HTTPS 1 . alpn=h3
example.com. IN A 203.0.113.1

; WRONG: HTTPS only - breaks legacy clients
example.com. IN HTTPS 1 . alpn=h3

Why: SVCB/HTTPS records require client support. Legacy clients ignore them and fall back to A/AAAA.

Issue 2: Divergent A/AAAA and HTTPS Responses

Problem: Load balancer returns different IPs for A records vs. HTTPS records, causing connection failures.

Solution: Use ipv4hint and ipv6hint parameters to ensure consistency:

example.com. IN HTTPS 1 . alpn=h3 ipv4hint=203.0.113.1
example.com. IN A 203.0.113.1

Why: If responses diverge (e.g., DNS-based load balancing to different CDNs), the IP in ipv4hint takes precedence for SVCB-aware clients.

Issue 3: Incorrect Priority Causes Loops

Problem: AliasMode record points to itself or creates a loop.

Solution: Never point an alias to the same name:

; WRONG: Points to itself
example.com. IN HTTPS 0 example.com.

; CORRECT: Points to different domain
example.com. IN HTTPS 0 cdn.example.net.

RFC limit: Maximum 8 alias hops (SVCB + CNAME combined).

Issue 4: Advertising Unsupported Protocols

Problem: Server advertises HTTP/3 but doesn’t actually support it.

Solution: Only advertise protocols your server actually supports:

# Test if your server supports HTTP/3
curl --http3 https://example.com -v

# Test HTTP/2
curl --http2 https://example.com -v

If either fails, don’t include that protocol in alpn.

Issue 5: DNSSEC Validation Failures

Problem: SVCB records fail DNSSEC validation.

Solution: Ensure your DNSSEC chain is complete:

# Test DNSSEC validation
dig example.com HTTPS +dnssec +multi

# Verify RRSIG exists
dig example.com HTTPS +dnssec | grep RRSIG

Why: Invalid DNSSEC causes SVCB-optional clients to fall back, but cryptographically-protected responses should fail completely per RFC 9460 Section 3.1.

Issue 6: Parameter Ordering

Problem: Service parameters must be in ascending key order.

Solution: Order parameters by their numeric key:

; CORRECT: Ordered by key number
example.com. IN HTTPS 1 . alpn=h3 ipv4hint=203.0.113.1 port=443

; WRONG: Random order may cause parse errors
example.com. IN HTTPS 1 . port=443 alpn=h3 ipv4hint=203.0.113.1

Key numbers: alpn=1, port=3, ipv4hint=4, ipv6hint=6, mandatory=0

Performance Best Practices

1. Use IP Hints for Speed

Include both IPv4 and IPv6 hints when possible:

example.com. IN HTTPS 1 . (
  alpn=h3,h2
  ipv4hint=203.0.113.1,203.0.113.2
  ipv6hint=2001:db8::1,2001:db8::2
)

Impact: Eliminates separate A/AAAA queries, saving 20-50ms per connection.

2. Implement Client-Side Caching

Clients should cache SVCB/HTTPS responses per TTL. This is especially important for mobile applications.

3. Structure Zones for Performance

Follow RFC 9460 Section 10.2: Structure zones so recursive resolvers can return all information in one query.

Good structure:

example.com. IN HTTPS 1 server.example.com. alpn=h3
server.example.com. IN A 203.0.113.1
server.example.com. IN AAAA 2001:db8::1

Resolver can return all three records in Additional section.

4. Parallel Queries for SVCB-Optional Clients

SVCB-optional clients (like browsers) should issue HTTPS and A/AAAA queries in parallel to avoid adding latency.

5. Set Appropriate TTLs

; Short TTL for frequently changing endpoints
example.com. 300 IN HTTPS 1 . alpn=h3

; Longer TTL for stable configurations
example.com. 3600 IN HTTPS 1 . alpn=h3

Balance between cache efficiency and update propagation speed.

Security Considerations

DNSSEC is Highly Recommended

SVCB/HTTPS records contain security-sensitive information (protocols, ECH configs). Use DNSSEC to prevent tampering:

# Sign your zone with DNSSEC
dnssec-signzone -o example.com zonefile

Why: Without DNSSEC, attackers could:

Downgrade protocols (remove HTTP/3 support)
Redirect traffic to malicious endpoints
Remove ECH configurations, exposing SNI

ECH Downgrade Protection

If advertising ECH, follow RFC guidance:

Clients should fail connections if SVCB resolution fails under certain conditions
Don’t fall back to cleartext SNI if ECH was expected

Validate All Parameters Server-Side

Even though DNS advertises capabilities, servers must validate:

Client actually supports advertised protocols
ECH decryption succeeds
ALPN matches offered protocols

Real-World Use Cases

Use Case 1: Video Streaming Platform

Problem: High-traffic video streaming during popular show premieres causes server overload.

Solution with SVCB:

streaming.example.com. IN HTTPS 1 edge1.cdn.example.net. alpn=h3
streaming.example.com. IN HTTPS 2 edge2.cdn.example.net. alpn=h3
streaming.example.com. IN HTTPS 3 edge3.cdn.example.net. alpn=h2

Result: Traffic distributed across multiple CDN edges, each optimized for different network conditions.

Use Case 2: E-Commerce High-Traffic Events

Problem: Black Friday sales cause latency spikes and lost sales.

Solution with SVCB:

shop.example.com. IN HTTPS 1 . (
  alpn=h3,h2
  ipv4hint=203.0.113.1,203.0.113.2
  ipv6hint=2001:db8::1,2001:db8::2
)

Result: Clients connect via HTTP/3 without protocol negotiation overhead, reducing latency by 20-30%.

Use Case 3: Financial Services Security

Problem: Need to ensure highest security for mobile banking connections.

Solution with SVCB:

mobile-api.bank.example.com. IN HTTPS 1 . (
  mandatory=alpn,ech
  alpn=h3
  ech=AEn+DQBBNwA...
)

Result: Ensures only clients supporting HTTP/3 and ECH can connect, maximizing privacy and security.

Conclusion

SVCB and HTTPS DNS records represent a significant evolution in how services are discovered and connections are established on the internet. By consolidating connection information into DNS responses, these records eliminate multiple roundtrips, enable smarter client decisions, and provide better support for modern protocols like HTTP/3.

Key takeaways:

SVCB/HTTPS records reduce connection latency by eliminating protocol negotiation
AliasMode solves the apex domain CNAME problem
ServiceMode advertises protocol support, ports, and IP hints
Always maintain A/AAAA records for backward compatibility
Use DNSSEC to protect security-sensitive parameters
Browser support is growing but not yet universal

Next steps:

Check if your DNS provider supports SVCB/HTTPS records
Test with non-production domains first
Monitor client behavior and connection times
Gradually roll out to production services
Consider implementing ECH for enhanced privacy

As browser and resolver support continues to expand in 2024 and 2025, SVCB and HTTPS records will become standard practice for high-performance, secure web services. Start experimenting now to gain experience with these powerful DNS innovations.

References:

RFC 9460 - Service Binding and Parameter Specification via the DNS - https://datatracker.ietf.org/doc/rfc9460/ - Official IETF standard for SVCB and HTTPS records
ISC Knowledge Base: SVCB and HTTPS Resource Records - https://kb.isc.org/docs/svcb-and-https-resource-records-what-are-they - Detailed technical explanation with examples
Cloudflare Blog: Speeding up HTTPS and HTTP/3 negotiation with DNS - https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ - Real-world implementation and benefits
Vercara: SVCB and HTTPS DNS Records Guide - https://vercara.digicert.com/resources/svcb-and-https-dns-records-the-future-of-service-discovery-and-connection-establishment - Industry perspective on deployment
AWS: Route 53 HTTPS/SVCB Support Announcement - https://aws.amazon.com/about-aws/whats-new/2024/10/amazon-route-53-https-sshfp-svcb-tlsa-dns-support/ - Recent provider support addition