AWS Route 53: SVCB, TLSA and SSHFP

AWS Route 53 has recently added support for several new DNS record types: SVCB (Service Binding), HTTPS, TLSA (DANE) and SSHFP. These records open up new options for performance optimisation, TLS hardening and SSH authentication. In this post we look at what they do and how they're used in practice.

What do SVCB/HTTPS, DANE/TLSA and SSHFP do?

These DNS record types extend the classic DNS entries with additional functions:

• SVCB/HTTPS — flexible connection parameters and protocol information directly in DNS
• DANE/TLSA — DNS-based certificate validation for stronger TLS security
• SSHFP — SSH key fingerprints in DNS for automatic server verification

SVCB: flexible connection parameters for more performance

The SVCB record (Service Binding, RFC 9460) lets you publish additional information about a service directly in DNS. That includes preferred protocols, alternative endpoints and connection parameters.

Compared with rigid A or AAAA records, SVCB offers significantly more flexibility. The client learns at DNS resolution time which protocols are supported and which endpoint is optimal. That reduces latency and enables faster connections.

An SVCB record might, for example, indicate that a service supports HTTP/3 and is reachable via a specific CDN node — the client can use this information immediately, without first probing different connection paths.

HTTPS: specialised connections for modern HTTPS optimisations

The HTTPS record builds on SVCB and is specifically optimised for HTTPS connections. It tells the client about supported protocols and encryption settings, for example HTTP/2 or HTTP/3 via ALPN (Application-Layer Protocol Negotiation).

The advantages at a glance:

• Faster connections: the client already learns at the first DNS request which connection parameters are optimal. That saves round-trips and speeds up page rendering.
• Flexible prioritisation: different endpoints and protocols can be prioritised so that the client always picks the best path.
• More security: encryption information is integrated directly into connection setup, which makes downgrade attacks harder.

A practical example with AWS CloudFront:

example.com 300 IN HTTPS 1 <cloudfront-distribution-domain-name> alpn="h2,h3,http/1.1,http/1.0"

This record tells the client that the domain is reachable via CloudFront and supports HTTP/2 as well as HTTP/3. The browser can then immediately set up the optimal connection.

DANE/TLSA — overview

DANE (DNS-based Authentication of Named Entities) improves TLS security through DNS-based certificate validation. Instead of relying solely on Certificate Authorities (CAs), the certificate information is published directly in DNS.

The two terms in detail:

• DANE is the security protocol that verifies TLS certificates via DNSSEC.
• TLSA record is the DNS record type DANE uses to store certificate information.

How it works:

1. A hash of the certificate or public key is stored in the TLSA record.
2. On connection, the client retrieves the TLSA record and compares it with the certificate the server presents.
3. DNSSEC protects the DNS entry against tampering, so the client can be sure the information is authentic.

Advantages of DANE/TLSA:

• More control: domain owners decide for themselves which certificate is valid.
• Protection against forged certificates: even if a CA is compromised, no false certificate can be issued for the domain.
• Reduced CA dependency: the trust chain is extended through DNS, not replaced.

DANE/TLSA is especially relevant for email servers, where it secures transport encryption between mail servers.

To work out the fingerprint of a certificate, you can use the following command:

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

The resulting hash is then stored in DNS as a TLSA record:

_443._tcp.example.com. IN TLSA 1 1 1 <fingerprint>

The parameters mean:

• 1 (Certificate Usage) — DANE-TA: Trust Anchor Assertion
• 1 (Selector) — Subject Public Key Info
• 1 (Matching Type) — SHA-256 hash

SSHFP: overview

The SSHFP record (SSH Fingerprint) stores SSH key fingerprints in DNS. With it, an SSH client can automatically verify the authenticity of a server, without the user having to confirm the fingerprint manually.

How it works:

1. The server's SSH public key is stored as a hash in the SSHFP record.
2. On connection, the SSH client retrieves the SSHFP record and compares it with the key the server presents.
3. DNSSEC protects against manipulation of the DNS entries here too.

Advantages:

• Secure connection: the client can automatically check that it is connected to the right server.
• Automated administration: no more manual confirmation of fingerprints — ideal for automated deployments and large server fleets.
• No TOFU problem: 'trust on first use' is replaced by DNS-based verification.

SSHFP records can be generated easily with the following command:

ssh-keyscan -D example.com

The output contains the ready-made DNS entries that you can paste straight into Route 53.

Conclusion

Of the new record types, the HTTPS record has the biggest measurable impact on day-to-day web performance. It lets browsers immediately set up the optimal connection without extra round-trips. If you use DNSSEC, you should set the HTTPS record by all means — it's easy to set up and the effect on load time is noticeable.

DANE/TLSA and SSHFP are particularly valuable in environments with elevated security requirements. They replace manual trust chains with automated, DNS-based verification, which delivers a real security gain.