TLSA Records and DANE: How to Publish and Read Them

A TLSA record is how DANE pins a TLS certificate or public key in DNS, so a client can verify the certificate it receives against a value the domain owner published rather than trusting the public certificate authority system alone. DANE, short for DNS-Based Authentication of Named Entities, only means anything when the zone is DNSSEC-signed, because the signature is what stops an attacker from forging the pin. This guide walks field by field through the three bytes at the front of a TLSA record, explains how the record is named, and shows how to read and publish one correctly.

What a TLSA record actually pins

DANE is defined in RFC 6698 and clarified by RFC 7671, with the SMTP profile living in RFC 7672 (all current as of November 2026). The idea is simple: instead of relying only on a public CA to vouch for a certificate, the domain owner states in DNS which certificate, or which public key, a correct connection should present. A client that supports DANE fetches the TLSA record, confirms the DNSSEC chain is valid, then checks that the certificate offered in the TLS handshake matches the pin. If it does not match, the client aborts.

Because the whole trust model rests on the DNS answer being authentic, DANE without DNSSEC is meaningless. An unsigned TLSA record can be stripped or rewritten in transit, which defeats the point. Confirm your zone validates before you publish anything.

How a TLSA record is named

TLSA records do not sit at the bare hostname. They use an underscore-prefixed naming scheme that encodes the port and transport protocol, followed by the host:

_<port>._<protocol>.<hostname>

_443._tcp.www.example.com.   IN TLSA 3 1 1 <hash>
_25._tcp.mail.example.com.   IN TLSA 2 0 1 <hash>

So an HTTPS service on TCP port 443 for www.example.com is published at _443._tcp.www.example.com, and a mail server listening on port 25 is published at _25._tcp.mail.example.com. The protocol is almost always tcp.

The three leading bytes: usage, selector, matching type

Everything that makes a TLSA record specific is in the three small integers before the hash. Read them left to right as certificate usage, selector, and matching type.

A record of 3 1 1 therefore reads as: DANE-EE (this exact leaf certificate, self-trusted), selector SPKI (match the public key), matching type SHA-256 (the final field is a SHA-256 digest of that key). That combination is the most popular choice for web and mail because it survives certificate renewal as long as the key stays the same.

Which combination to pick

For most operators the two durable choices are 3 1 1 and 2 1 1. The 3 1 1 form pins the end key directly and does not care about public CAs, which is ideal when you control the key and rotate the certificate frequently. The 2 1 1 form pins an intermediate or private trust anchor, which lets you reissue leaf certificates freely as long as they chain to the same CA. Avoid matching type 0 (full, unhashed) unless you have a specific reason; the hashed forms are shorter and easier to manage.

Publishing a TLSA record step by step

1. Confirm the zone is DNSSEC-signed and validates end to end. Without this, stop here.
2. Decide what you are pinning: the leaf key (usage 3) or a trust anchor (usage 2). Key-based pins outlive certificate renewals.
3. Generate the digest. For a 3 1 1 record, extract the SubjectPublicKeyInfo and take its SHA-256: openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256.
4. Publish the record at _port._tcp.host with the three bytes and the hex digest.
5. Wait for DNSSEC signatures to propagate, then validate before you rely on it.
6. When you rotate the certificate, publish the new TLSA record first, let it propagate, then deploy the new certificate, and remove the old pin last. This rollover order prevents an outage.

How to read and verify a published record

Use dig to pull the record, then confirm the DNSSEC chain and the match against the live service:

$ dig TLSA _443._tcp.www.example.com +dnssec +short
3 1 1 0a9b...e4f1

$ openssl s_client -connect www.example.com:443 -dane_tlsa_domain \
  www.example.com -dane_tlsa_rrdata "3 1 1 0a9b...e4f1"

The openssl output reports Verification: OK and a DANE line showing a match when the pin is correct. A mismatch, a missing record, or a broken DNSSEC chain all mean a DANE-aware client would refuse the connection, so test from a resolver that validates signatures.

Where DANE is used in practice

The strongest real-world deployment is SMTP between mail servers, where DANE for SMTP (RFC 7672) lets a sending server demand verified TLS and shut the door on downgrade attacks. Browser support for DANE over HTTPS never arrived at scale, so web pins are mostly used inside controlled environments rather than the public web. If your goal is enforced inbound mail encryption, compare the DANE approach with the policy-file alternative in our guide on MTA-STS versus DANE, and make sure your signing is solid first with DNSSEC basics. To control which authorities may issue for your names in the first place, pair TLSA with CAA records.

Once your TLSA records are live, run the hostname through the Valla DNS domain health check to confirm the record is present and the DNSSEC chain that protects it validates, so the pin you published is the pin clients actually see.

Does DANE replace my public certificate authority?

Not usually. Usage 3 and usage 2 let you self-assert trust, but most public clients still expect a normally trusted certificate. In practice DANE adds a second, DNSSEC-backed check on top of the CA system rather than removing the CA.

Why does DANE require DNSSEC?

The TLSA record is only trustworthy if nobody can forge or strip it. DNSSEC signatures give the client cryptographic proof the record came from the real zone. An unsigned TLSA record offers no security because an attacker could simply replace it.

What breaks if I rotate my certificate without updating TLSA?

A key-pinning record such as 3 1 1 stops matching the moment the key changes, and DANE-aware clients will refuse the connection. Always publish the new pin and let it propagate before deploying the new certificate, then remove the old pin last.

Can I pin the public key so renewals do not break DANE?

Yes. Use selector 1 (SPKI) so the record matches the public key rather than the whole certificate. If you reuse the same key pair across renewals, the existing TLSA record keeps validating without any DNS change.

How many TLSA records can I publish for one service?

You can publish several at the same name, and a client treats a match against any one of them as success. This is exactly what makes a safe rollover possible: during the overlap window both the old and new pins are live at once.