BRev TLSA record — DANE certificate association
A TLSA record states which certificate or public key a service is allowed to present. It is the DANE mechanism, and it depends completely on DNSSEC: without a signed chain, an attacker who can forge DNS can forge the pin too, so an unsigned TLSA record provides no security at all. Publishing one on an unsigned zone is a common and entirely wasted exercise.
The name follows the SRV-like convention with the port first: _443._tcp.example.com, or _25._tcp.mail.example.com. The RDATA has three selectors before the data. Usage 3 (DANE-EE) pins the server’s own certificate and bypasses the public CA system entirely; usage 2 (DANE-TA) pins a private CA; usages 0 and 1 constrain which public CA may be used. Selector 1 with matching type 1 — the SHA-256 of the public key — is the usual combination, because the pin then survives certificate renewal as long as the key is reused.
Browsers never adopted DANE, so TLSA does nothing for a website in practice. SMTP did adopt it, and there it works: a sending mail server that supports DANE looks up the TLSA record for the MX host and refuses to deliver if the presented certificate does not match — which closes the STARTTLS downgrade attack that plain opportunistic TLS leaves open. That is the deployment worth doing.
What a TLSA record looks like
Type 52 · DANE — pin certificates in DNS. Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| _25._tcp.mail.example.com. | 3600 | TLSA 3 1 1 8e5ab8f2c4… | Usage 3 (pin this exact key), selector 1 (public key), matching 1 (SHA-256) — the SMTP DANE norm. |
| _443._tcp.www.example.com. | 3600 | TLSA 3 1 1 a1b2c3d4e5… | The same for HTTPS. Valid, but browsers do not check it, so its effect is limited to DANE-aware clients. |
| _25._tcp.mail.example.com. | 3600 | TLSA 3 1 1 f00dbaadf0… | A second record during a key roll — publish the new pin before switching, remove the old after. |
The mistakes that break production
Publishing TLSA without DNSSEC
It achieves nothing. The entire security property comes from the record being signed, so an unsigned TLSA can be forged by exactly the attacker it is meant to stop. DANE-aware clients ignore it; everyone else already did.
Renewing the certificate without updating the pin
A usage-3 record pinned to the certificate (selector 0) breaks on every renewal. Pin the public KEY (selector 1) and reuse the key across renewals, and always publish the new pin alongside the old before the switch — for SMTP the failure mode is deferred mail, which is quiet until someone notices a queue.
Query a TLSA record now
The box below is seeded with _25._tcp.mail.ietf.org. Choose TLSA as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
Does a TLSA record need DNSSEC?
Yes, absolutely. Without a signed chain the pin can be forged, so DANE-aware clients treat an unsigned TLSA record as absent. DNSSEC is not optional for this record type.
Do browsers support DANE?
No. Chrome and Firefox both declined to implement it, so TLSA records have no effect on web browsing. The successful deployment is SMTP, where it prevents STARTTLS downgrade between mail servers.
What do the three numbers mean?
Usage (0–3: which part of the chain is being constrained — 3 pins the server’s own certificate), selector (0 = full certificate, 1 = public key), and matching type (0 = exact, 1 = SHA-256, 2 = SHA-512).