TLSA TLSA Certificate Association Common
Binds a TLS certificate or public key to a hostname and port, enabling DANE certificate validation.
What it's for
A TLSA record binds a specific TLS certificate (or public key) to a hostname and port, forming the basis of DANE (DNS-Based Authentication of Named Entities). Instead of — or in addition to — relying purely on the traditional CA-based trust model, DANE lets a domain owner publish, directly in DNS, exactly which certificate or key should be presented for a given service, and clients that support DANE can verify the presented certificate against this DNS-published expectation.
Because TLSA is only meaningfully trustworthy when the zone is DNSSEC-signed (otherwise the TLSA record itself could be forged, defeating the point), it's almost always discussed and deployed alongside DNSSEC.
Format & syntax
_443._tcp.example.com. 3600 IN TLSA 3 1 1 abcdef1234567890...
- Name —
_port._protocol.hostname, e.g._443._tcp.example.com.for HTTPS on port 443 - Certificate Usage — how to interpret the data:
0(CA constraint),1(service certificate constraint, in addition to normal CA validation),2(trust anchor assertion, replacing normal CA validation),3(domain-issued certificate, self-published trust with no CA involvement — the most common for self-managed setups) - Selector — whether the data covers the full certificate (
0) or just the public key (1) - Matching Type — whether the value is the full data (
0), a SHA-256 hash (1), or a SHA-512 hash (2) - Certificate Association Data — the actual hash or data, matching the selector/matching type combination
How it's used in practice
- SMTP (mail) with DANE — the most common real-world TLSA deployment by far: mail server operators publish TLSA records so receiving servers can verify the TLS certificate presented during SMTP delivery, protecting against downgrade or interception attacks on mail-in-transit, independent of the traditional CA system.
- Pinning your own certificate without relying solely on public CAs — usage type
3lets an operator publish and trust a certificate purely through DNSSEC-secured DNS, useful for internal services or situations where you want an additional layer of assurance beyond standard CA trust. - Defense in depth against CA compromise or misissuance — even with a properly issued, CA-trusted certificate, TLSA gives clients an additional independent check, so a fraudulently issued certificate from a compromised or careless CA (something CAA also aims to prevent from a different angle) would still fail DANE validation if it doesn't match the published TLSA data.
Common mistakes & gotchas
- Deploying TLSA without DNSSEC — TLSA's security guarantee depends entirely on the zone being DNSSEC-signed; without that, an attacker capable of forging DNS answers could simply forge the TLSA record too, defeating the entire point.
- Forgetting to update TLSA after a certificate renewal — if the TLSA record pins specific certificate/key data (rather than a CA, via usage type
0or1) and you renew or rotate your certificate without updating the TLSA record, DANE-validating clients will start rejecting connections even though the new certificate is perfectly valid by normal CA standards. - Limited client support — DANE/TLSA validation isn't universally implemented across all clients and mail servers; it's most commonly meaningful for SMTP-to-SMTP mail delivery where major providers have real support, less so for general web browsing where browser support for DANE never became mainstream.
- Choosing the wrong certificate usage field — using usage
3(domain-issued, bypasses CA validation entirely) when you actually wanted1(an additional constraint alongside normal CA validation) changes the security model significantly; understand which usage type matches your actual trust model before publishing.
Comparison & FAQ
| Type | Purpose | Key difference from TLSA |
|---|---|---|
| CAA | Restricts which CAs are allowed to issue certs at all | A policy control on issuance; TLSA is a runtime binding clients can check per-connection |
| SSHFP | Similar concept but for SSH host keys instead of TLS certificates | Same underlying idea (publish trust data in DNS), different protocol |
Does TLSA work without DNSSEC?
Not securely — TLSA's value comes from being cryptographically trustworthy, which requires the zone to be DNSSEC-signed. Without DNSSEC, the TLSA record itself could be forged by the same kind of attacker DANE is meant to protect against.
What's the most common real-world use of TLSA?
SMTP (mail server) DANE deployments — mail providers with DANE support use TLSA to verify TLS certificates during mail delivery, protecting against interception or downgrade attacks on the connection between mail servers.
What happens if I renew my certificate but don't update TLSA?
If your TLSA record pins the specific certificate or key data (rather than just a CA), DANE-validating clients will reject the new certificate as not matching, even though it's a perfectly valid certificate from a normal CA-trust perspective — this is a real operational gotcha to build into your certificate renewal process.
Is TLSA widely supported by web browsers?
No — DANE/TLSA validation never gained mainstream browser support for general HTTPS browsing. Its practical adoption is concentrated in SMTP mail delivery, where several large mail providers do support it.