TLSA: DANE certificate pinning
A certificate pin, served from DNSSEC-signed DNS. A TLSA record lets a client verify that the cert a TLS server offers is one the domain owner authorized (RFC 6698 §2.1.1). Same role as SSHFP, for TLS instead of SSH.
In one line:
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...
└── port.proto.host ──────┘ └type┘ └── expects this certificate| Type number | 52 |
| RFC | 6698, updated by 7671 (operational guidance) and 7218 (the acronyms below) |
| RDATA | usage · selector · matching type · cert-association data |
| Required for trust | DNSSEC: the record's security depends entirely on it (RFC 6698 §8) |
What it holds#
Four fields:
| Field | Codes |
|---|---|
| Usage | 0 = PKIX-TA · 1 = PKIX-EE · 2 = DANE-TA · 3 = DANE-EE |
| Selector | 0 = full cert · 1 = SubjectPublicKeyInfo |
| Matching type | 0 = exact · 1 = SHA-256 · 2 = SHA-512 |
| Cert association | Hex blob of the hash (with matching=0, the entire selected content) |
For SMTP, RFC 7672 §3.1.1 says the record SHOULD, in most cases, be usage 3 selector 1 matching 1 (DANE-EE, SPKI, SHA-256):
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...The name is _<port>._<proto>.<host>. The underscore prefix, shared with SRV, keeps the label from colliding with a real hostname.
When to use it#
- SMTP servers: DANE for SMTP (RFC 7672) is the only mainstream production use. Sending MTAs that support DANE validate the TLSA against the cert the MX presents.
- Specialized internal services where you want cert pinning without a private CA.
When not to use it#
- Browser HTTPS: browsers do not validate DANE.
- Unsigned zones: DNSSEC is required; TLSA without it cannot be trusted (RFC 6698 §8).
- Certs that rotate faster than you can keep TLSA in sync: a stale TLSA is a hard outage.
dig example#
Asks which certificate the HTTPS service on this name should present.
dig @1.1.1.1 _443._tcp.tlsa.example.isitdns.net TLSAGO NOERROR and one TLSA record, usage 3 selector 1 matching type 1
NO GO NOERROR with no answer, which means nothing is pinned for this service
The record is live in the demo zone: usage 3, selector 1, matching 1 (DANE-EE / SPKI / SHA-256). The ad flag confirms the resolver validated the DNSSEC chain; the hash is a documentation sample, not a real cert's fingerprint.
See it live: isitdns.net/#dig?name=_443._tcp.tlsa.example.isitdns.net&qtype=TLSA
RFC: RFC 6698 defines TLSA, RFC 7671 is the operational guidance, and RFC 7672 §3.1 covers SMTP DANE.
Gotchas#
- Cert rotation is a synchronization problem. Publish the new TLSA before serving the new cert. Publish both old and new during the transition, then drop the old one.
- Usage 3 (DANE-EE) is the pragmatic default. Usages 0 and 1 also require the cert to pass normal public-CA validation; usage 2 (DANE-TA) pins a trust anchor the presented chain must validate up to; usage 3 trusts the cert on a hash match alone (RFC 6698 §2.1.1). For SMTP, RFC 7672 §3.1.3 says usages 0 and 1 SHOULD NOT be used at all.
- Wildcards don't cover TLSA. An asterisk is a wildcard only as the name's leftmost label (RFC 4592 §2.1.1); list each host and port explicitly.
- Hashes get chunked for display.
digfolds a long hex hash into space-separated groups; strip the whitespace before comparing it to a hash you generated yourself. - CAA and TLSA are complementary, not redundant. CAA is an authorization control a CA checks before issuing; TLSA is a verification control the client checks after issuance (RFC 8659 §1).