DANE/TLSA Setup Guide

What is DANE?

DANE (DNS-Based Authentication of Named Entities) is a protocol defined in RFC 6698 that uses DNS to associate TLS certificates or public keys with domain names. Instead of relying solely on the Certificate Authority (CA) system to validate a server's identity, DANE lets the domain operator publish the expected certificate data directly in DNS, secured by DNSSEC.

The mechanism is simple: a TLSA record in DNS states what certificate or key a client should expect when connecting to a service on a specific port and protocol. If the certificate presented during the TLS handshake matches the TLSA record, the connection is authenticated.

Why DANE matters

The traditional CA model has a structural weakness: any of the hundreds of trusted CAs can issue a certificate for any domain. A compromised or coerced CA can issue fraudulent certificates that browsers and clients will accept. CAA records mitigate this by restricting which CAs may issue, but compliance is voluntary and only checked at issuance time.

DANE provides a stronger guarantee. Because TLSA records are signed with DNSSEC, an attacker would need to compromise both the CA system and the domain's DNSSEC chain to mount a successful man-in-the-middle attack. For SMTP (email transport), DANE is particularly valuable because it enables opportunistic encryption to be upgraded to authenticated encryption without requiring a pre-existing trust relationship.

The TLSA record format

A TLSA record has four fields:

_port._protocol.hostname.  TTL  IN  TLSA  usage selector matching-type  data

For example:

_443._tcp.example.com.  300  IN  TLSA  3 1 1 a0b1c2d3e4f5...

Certificate usage (field 0)

Selector (field 1)

Selector 1 (public key) is preferred because it survives certificate renewal as long as the key pair remains the same. Selector 0 (full certificate) requires updating the TLSA record every time the certificate is renewed.

Matching type (field 2)

Matching type 1 (SHA-256) is the standard choice. It keeps the DNS record compact while providing strong integrity verification.

Generating a TLSA record

The most common configuration is 3 1 1 (DANE-EE, public key, SHA-256). To generate the hash from your certificate:

# Extract the SubjectPublicKeyInfo and hash it
openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -hex \
  | awk '{print $NF}'

This produces the hex string you publish in the TLSA record's data field.

DANE for SMTP

DANE's most widespread deployment is in email. When an MTA (Mail Transfer Agent) sends mail to a domain, it looks up the MX records, then checks for TLSA records on the MX hostnames. If valid TLSA records exist and DNSSEC validates, the sending MTA can authenticate the receiving server's certificate without any prior configuration.

For SMTP, the TLSA record is placed at the MX hostname, not the email domain:

_25._tcp.mail.example.com. IN TLSA 3 1 1 abc123...def456

Major email providers including Gmail, Outlook, and Comcast support DANE verification for outbound SMTP. Publishing TLSA records for your mail servers protects your inbound mail from interception.

A critical requirement for DANE verification is that the DNS response carrying the TLSA record must have the DNSSEC AD (Authenticated Data) flag set. Without the AD flag, the validating MTA cannot confirm the TLSA record is genuine, and DANE verification fails. This means the entire chain -- from the root zone through your domain's zone to the TLSA record itself -- must be DNSSEC-signed and valid.

DANE and MTA-STS can coexist on the same domain. They serve complementary roles: DANE provides mandatory enforcement backed by DNSSEC without any negotiation or TOFU (Trust on First Use), while MTA-STS uses HTTPS-based policy discovery with an initial trust-on-first-use fetch. If both are deployed, a sending MTA that supports DANE will prefer it over MTA-STS because DANE provides a stronger authentication guarantee. Deploying both ensures coverage for senders that support only one of the two mechanisms.

Prerequisites

DANE requires DNSSEC. Without DNSSEC, TLSA records provide no security because an attacker who can tamper with DNS responses can simply remove or replace the TLSA record. Before deploying DANE:

1. Ensure your domain has a complete DNSSEC chain from the root to your zone.
2. Verify DNSSEC validation using a DNS inspection tool (check for RRSIG, DNSKEY, and DS records).
3. Confirm your DNS provider supports TLSA record types.

Common mistakes

• No DNSSEC: Publishing TLSA records without DNSSEC is meaningless. Validators will ignore TLSA records in unsigned zones.
• Stale records after certificate renewal: If you use selector 0 (full certificate) or change your key pair during renewal, the TLSA record must be updated before the new certificate is deployed. The safest approach: publish the new TLSA record, wait for the old TTL to expire, then deploy the new certificate.
• Wrong port or protocol: The TLSA record name includes the port and protocol (_443._tcp for HTTPS, _25._tcp for SMTP). A record at the wrong port is invisible to validators.
• CNAME on the TLSA name: TLSA lookups follow CNAMEs, but the interaction with DNSSEC can be subtle. If the CNAME target is in a different zone, that zone must also be DNSSEC-signed.
• Using DANE-TA (usage 2) with Let's Encrypt: Let's Encrypt rotates intermediates. If you pin a specific intermediate with usage 2, the TLSA record breaks when Let's Encrypt switches to a new intermediate. Usage 3 (DANE-EE) with selector 1 (public key) is more resilient because you control the key pair.
• Missing rollover procedure: Always publish both the current and upcoming TLSA records during a key rollover. DNS propagation delays mean some validators will see the old record while others see the new one.

Verifying your DANE configuration

After publishing TLSA records, verify them by querying the TLSA record in DNS and comparing it against the certificate the server actually presents during a TLS handshake. Both checks are needed: the DNS record must exist and the certificate must match.