TLSA and DANE: Binding a Certificate to a DNS Zone

What DANE is and which problem TLSA solves

Regular TLS relies on certificate authorities: a browser trusts a certificate if a recognized CA signed it. If even one CA out of the hundreds built into the system gets compromised, an attacker can issue a certificate for someone else's domain. DANE (DNS-Based Authentication of Named Entities, RFC 6698) solves this differently: the domain owner publishes in the DNS zone which certificate or key is legitimate for their service, and the zone is protected by a DNSSEC signature.

The record that stores this binding is called TLSA. It answers the question of which certificates can be trusted on this port of this host, regardless of what the CA chain says.

TLSA record syntax: usage, selector, matching type

The record name follows the pattern _port._protocol.host, and the value has three numbers plus a hash:

_443._tcp.example.com. IN TLSA 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

The first number (usage) sets the trust model: 0 restricts the CA (PKIX-TA), 1 restricts the end certificate while still checking it through a public CA (PKIX-EE), 2 uses your own root CA instead of a public one (DANE-TA), 3 pins the exact certificate directly with no CA involved at all (DANE-EE), the most common choice for Let's Encrypt. The selector defines what gets hashed: 0 is the whole certificate, 1 is only the public key (SubjectPublicKeyInfo), which is convenient when a certificate renews with the same key. Matching type: 0 is the full certificate, 1 is SHA-256, 2 is SHA-512.

How to generate a TLSA record for your certificate

The SHA-256 hash of the public key is produced with openssl:

openssl x509 -in cert.pem -noout -pubkey \n  | openssl pkey -pubin -outform DER \n  | openssl dgst -sha256 -binary | xxd -p -c 256

The resulting string goes into the fourth field of a TLSA record with usage 3 and selector 1. When issuing a certificate through an ACME DNS challenge, described in the article on the DNS challenge for SSL, recalculate the hash whenever the key changes, not only when the certificate changes.

DANE for email: use in SMTP

Web browsers barely support DANE for HTTPS at all: Chrome dropped the check back in 2015, and Firefox never enabled it by default. DANE is, however, actively used to protect mail traffic: Postfix with smtp_tls_security_level = dane checks the TLSA record on the recipient's MX host before sending a message and refuses to send it in plain text if a record exists but the certificate does not match it. Setting up regular mail protection with SPF, DKIM, and DMARC is described in the article on protecting email, and DANE complements it at the transport layer rather than the message-content layer.

How to check a TLSA record

The record is checked with dig, and matching it to the certificate is done by comparing the hash manually:

dig TLSA _443._tcp.example.com +short

If the dnsviz tool or an online checker reports that DNSSEC for the zone fails validation, the TLSA record is useless: the resolver must trust the DNSSEC signature itself, otherwise an attacker can spoof the TLSA record just as easily as the certificate. Zone diagnostic methods are collected in the article on dig, dnsviz, and common mistakes.

DANE limitations: mandatory DNSSEC and software support

• DANE only works on top of a signed DNSSEC zone — without it the TLSA record provides no protection, see the article on configuring DNSSEC.
• Browsers do not check TLSA for HTTPS connections, so for websites DANE is only a supplementary measure.
• Mail servers that do not support DANE simply ignore the record and keep relying on the CA.
• During certificate rotation, publish the TLSA record for the new key ahead of time, otherwise strict DANE clients will refuse to connect during the switch.

Summary: a checklist for rolling out TLSA

Before enabling DANE, make sure: the zone is DNSSEC-signed and passes validation, the TLSA record is created with usage 3 and selector 1 for your own certificates, the hash is recalculated for the current key, and the mail server is set to strict DANE checking only after the record is published and verified from an external resolver.