Skip to content
Control Plane Labs

TLSA record

Binds a certificate or public key to a hostname and port, so DNSSEC can authenticate TLS.

Last updated July 27, 2026

Zone-file example

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 8A9F2C4E1D7B03556E8C1A2FD94B77E0...

Typical uses

  • Opportunistic DANE for SMTP between mail servers, the one place it is widely deployed
  • Pinning an internally issued CA for services outside the public trust store
  • Constraining which public CA may be used for a service
  • XMPP and other server-to-server protocols where both ends are under your control

When it breaks, check

  • TLSA is meaningless without DNSSEC — an unsigned record is ignored by every DANE client
  • The owner name encodes port and protocol; _443._tcp is not the same as _25._tcp
  • Selector 0 breaks on every certificate renewal; selector 1 survives if the key is reused
  • Publish the new association before deploying the new certificate, and keep both live

What the TLSA record does

The idea is to use the DNS hierarchy as a second trust root. If a resolver can validate the chain down to your zone, a record in that zone naming the public key for port 25 on a host is as trustworthy as the delegation itself. DANE is therefore strictly dependent on DNSSEC: a TLSA record in an unsigned zone is no security at all, and correct clients ignore it.

Deployment split along protocol lines. No mainstream browser implements DANE, so a record on port 443 affects almost nobody. Mail is different. Opportunistic SMTP TLS had no authentication, DANE gave it some, and much mail infrastructure now checks TLSA for MX hosts.

Zone-file and wire format

The owner name is _port._transport.hostname, so a mail server on port 25 is _25._tcp.mx1.example.com. The RDATA is three single-octet numbers plus the association data. Certificate usage says what that data represents: 0 constrains which CA may appear in the chain, 1 constrains the end-entity certificate, 2 asserts your own trust anchor, 3 asserts an end-entity certificate with no PKIX validation. Selector picks what is matched: 0 the full certificate, 1 the SubjectPublicKeyInfo. Matching type is 0 for raw bytes, 1 for SHA-256, 2 for SHA-512.

; _port._transport.hostname
;                 usage  selector  matching type
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 8A9F2C4E1D7B03556E8C1A2FD94B77E0...
;                                      |  |  |
;                                      |  |  +-- 0=raw, 1=SHA-256, 2=SHA-512
;                                      |  +----- 0=full certificate, 1=SubjectPublicKeyInfo
;                                      +-------- 0=CA constraint, 1=end-entity constraint,
;                                                2=own trust anchor, 3=end-entity, no PKIX

; during a rotation, publish both associations and wait out the TTL
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 5C0E71B2A46D8F39B0741CAE2255DD18...

Common uses

Treat SMTP as the real use case. Publishing a TLSA record for each MX host in a signed zone upgrades opportunistic TLS from “encrypted against a passive observer” to “authenticated”, the gap RFC 7672 exists to close. MTA-STS in RFC 8461 reaches the same goal without DNSSEC, and running both is reasonable. Outside mail, TLSA is most useful internally, where you control the clients and can assert a private CA with usage 2 instead of shipping roots everywhere.

Troubleshooting

Certificate rotation is what breaks DANE deployments. Selector 0 matches the whole certificate, so it stops matching the instant that certificate is reissued, even with an identical key. Selector 1 covers only the public key and survives renewal as long as the key is reused, which is why 3 1 1 is the usual recommendation. The safe procedure mirrors a DNSSEC key roll: publish the new association alongside the old, wait out the TTL, deploy, then remove the stale record.

If verification fails and the record looks correct, check DNSSEC first: a zone that fails to validate makes every TLSA record invisible. Compare the association against what the server presents with the TLS inspector.

# the association published for a mail server on port 25
dig _25._tcp.mx1.example.com TLSA +short

# DANE is worthless without an authenticated answer — look for the ad flag
dig _25._tcp.mx1.example.com TLSA +dnssec +noall +comments | grep flags
delv _25._tcp.mx1.example.com TLSA

# compare against the key the server actually presents (selector 1, SHA-256)
openssl s_client -connect mx1.example.com:25 -starttls smtp </dev/null 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

The defining RFC

TLSA is type 52, defined in RFC 6698, with the field semantics in §2.1 and the numeric values in the IANA DANE Parameters registry. Read RFC 7671 before deploying: it is the operational update covering rollover and which usage to choose. RFC 7218 supplies the acronyms (PKIX-TA, PKIX-EE, DANE-TA, DANE-EE) you will meet in tooling.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types