DNS TLSA Record Explained — DANE Certificate Pinning

When your browser connects to a website over HTTPS, it trusts the certificate because a Certificate Authority (CA) vouched for it. But what if a CA is compromised, coerced, or simply makes a mistake? A rogue CA could issue a valid certificate for your domain without your knowledge, enabling man-in-the-middle attacks.

TLSA records address this problem by publishing certificate information directly in DNS. Combined with DNSSEC, they enable DANE (DNS-Based Authentication of Named Entities) — a protocol that lets domain owners specify which certificates are valid for supporting clients and, in some usage modes, reduce reliance on the traditional CA trust model.

How DANE Works

Traditional TLS verification relies on a chain of trust rooted in Certificate Authorities. DANE adds a second verification path through DNS:

1. A client wants to connect to example.com on port 443
2. It queries DNS for a TLSA record at _443._tcp.example.com
3. The TLSA record contains a hash of the expected certificate or public key
4. During the TLS handshake, the client compares the server's actual certificate against the TLSA data
5. If they match (and the DNSSEC chain validates), the connection is trusted

Because TLSA records are protected by DNSSEC, a validating client can detect forged TLSA data unless the DNSSEC chain is compromised. This gives the domain owner a DNSSEC-backed way to publish which certificates supporting clients should trust.

Tip: DANE does not replace TLS itself. It replaces or supplements the CA-based trust model. The encrypted connection still uses standard TLS.

Anatomy of a TLSA Record

A TLSA record has a specific owner name format and four data fields:

_443._tcp.example.com.  3600  IN  TLSA  3 1 1 a]b2c3d4e5f6...

The owner name encodes the port and protocol: _port._protocol.hostname. The four numeric fields control how the certificate is matched.

Field 1: Certificate Usage (0-3)

This is the most important field. It determines the trust model:

Usage 3 (DANE-EE) is the most widely deployed because it gives the domain owner complete control. You do not need to involve any CA. Usage 2 (DANE-TA) is useful when you operate your own internal CA.

Usages 0 and 1 supplement traditional CA validation rather than replacing it. They constrain which CA or certificate is acceptable but still require a valid CA chain.

Field 2: Selector (0-1)

Determines what part of the certificate is matched:

Selector 1 (SPKI) is recommended in most cases. If you reuse the same key pair when renewing a certificate, the TLSA record does not need to change. With selector 0, every certificate renewal requires a TLSA update.

Field 3: Matching Type (0-2)

Determines how the comparison is made:

Matching type 1 (SHA-256) is the standard choice. It produces a compact, fixed-length hash that is efficient to store and compare.

Field 4: Certificate Association Data

The hex-encoded hash (or full certificate data if matching type is 0) that the client compares against the server's actual certificate.

Tip: The most common TLSA configuration is 3 1 1 — DANE-EE, public key selector, SHA-256 hash. This combination is simple, robust, and survives certificate renewals when you reuse your key pair.

Generating TLSA Record Data with OpenSSL

You need to extract the appropriate hash from your certificate or server. The commands differ based on your selector and matching type choices.

Usage 3, Selector 1, Matching Type 1 (Recommended)

Hash the public key with SHA-256:

# From a certificate file
openssl x509 -in cert.pem -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256

Output example:

8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d

From a Live Server

# Extract TLSA data from a running server
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256

Usage 3, Selector 0, Matching Type 1

Hash the full certificate with SHA-256:

openssl x509 -in cert.pem -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256

Usage 3, Selector 1, Matching Type 2

Hash the public key with SHA-512:

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

Using ldns-dane

If you have ldns installed, you can generate the full TLSA record in one command:

ldns-dane create example.com 443 3 1 1

DANE for SMTP (RFC 7672)

DANE for SMTP is where TLSA records have gained the most real-world traction. Traditional SMTP encryption is opportunistic — a mail server advertises STARTTLS support, but a man-in-the-middle can strip the STARTTLS offer and force plaintext delivery. DANE for SMTP solves this.

How It Works

1. A sending mail server looks up the MX record for the recipient domain
2. Before connecting, it queries the TLSA record for the MX hostname on port 25
3. If a TLSA record exists and is DNSSEC-validated, the sender requires TLS with the specified certificate
4. STARTTLS stripping attacks become impossible — the sender knows TLS is mandatory

SMTP TLSA Record Example

For a mail server at mail.example.com:

; MX record pointing to the mail server
example.com.                  3600  IN  MX    10 mail.example.com.
 
; TLSA record for SMTP on port 25
_25._tcp.mail.example.com.    3600  IN  TLSA  3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
 
; Also cover submission ports if applicable
_587._tcp.mail.example.com.   3600  IN  TLSA  3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
_465._tcp.mail.example.com.   3600  IN  TLSA  3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d

Tip: DANE for SMTP is already supported by major mail providers including Gmail (receiving side), Comcast, and many European ISPs. Publishing TLSA records for your mail server protects inbound email from interception.

Why DANE Is Gaining Traction for Email

Email is uniquely vulnerable because SMTP connections between servers are typically opportunistic TLS — encryption is attempted but not enforced. DANE changes this by making TLS mandatory when TLSA records are present. Combined with SPF, DKIM, and DMARC for sender authentication, DANE provides encryption enforcement that the email ecosystem has lacked for decades.

Several factors drive adoption:

• MTA-STS is an alternative to DANE but requires HTTPS infrastructure and has a trust-on-first-use weakness
• Dutch and German government mandates require DANE for government email systems
• Let's Encrypt makes certificates free, removing the cost barrier to deploying TLS on mail servers
• Postfix, Exim, and other major MTAs have built-in DANE support

DANE for HTTPS

While DANE was originally designed for all TLS services, browser adoption for HTTPS has been slow. Browsers have not implemented native DANE validation because it requires DNSSEC, which adds latency to page loads. However, DANE for HTTPS is valuable in contexts where:

• You operate internal services and control the client software
• You use a browser extension that performs DANE validation
• You want defense-in-depth alongside CAA records

HTTPS TLSA Record Example

_443._tcp.www.example.com.    3600  IN  TLSA  3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d

Tip: Even if browsers do not validate TLSA records natively, publishing them signals that you take certificate security seriously and provides a verification path for automated monitoring tools.

The DNSSEC Requirement

TLSA records without DNSSEC do not provide reliable DANE authentication. Here is why:

Without DNSSEC, an attacker performing a DNS spoofing attack can forge both the TLSA record and the server certificate. The client would see a matching pair and trust the connection. DNSSEC lets validating clients detect this by cryptographically signing DNS responses so they can authenticate the TLSA data.

Before deploying TLSA records:

1. Sign your zone with DNSSEC — this is a prerequisite for DANE authentication
2. Verify the DNSSEC chain — use dig +dnssec to confirm signatures are valid
3. Monitor DNSSEC validity — expired signatures will break DANE validation and cause connection failures

# Verify DNSSEC is working for your domain
dig +dnssec example.com SOA
 
# Check TLSA record has valid DNSSEC signatures
dig +dnssec TLSA _443._tcp.example.com

If the ad (Authenticated Data) flag appears in the response, the DNSSEC chain is valid.

Certificate Rollover with DANE

Certificate renewal is the most operationally sensitive aspect of DANE. If you update your certificate but forget to update the TLSA record, clients that validate DANE will refuse to connect.

Safe Rollover Process

1. Generate the new certificate (or obtain it from your CA)
2. Compute the TLSA hash for the new certificate
3. Add the new TLSA record alongside the existing one
4. Wait for DNS propagation — at least one full TTL period
5. Deploy the new certificate on your server
6. Remove the old TLSA record after another TTL period

; During rollover — both records exist simultaneously
_443._tcp.example.com.  3600  IN  TLSA  3 1 1 oldcerthash...
_443._tcp.example.com.  3600  IN  TLSA  3 1 1 newcerthash...

Tip: Using selector 1 (SPKI) with key reuse eliminates the need for TLSA updates during routine certificate renewals. The public key stays the same even when the certificate changes. This is especially useful with Let's Encrypt certificates that renew every 90 days.

Querying TLSA Records with dig

# Query TLSA record for HTTPS
dig TLSA _443._tcp.example.com
 
# Query TLSA record for SMTP
dig TLSA _25._tcp.mail.example.com
 
# Short output
dig TLSA _443._tcp.example.com +short
# Returns: 3 1 1 8D02536C887482BC34FF54E41D2BA659...
 
# With DNSSEC validation
dig +dnssec TLSA _443._tcp.example.com
 
# Against a specific nameserver
dig TLSA _443._tcp.example.com @ns1.dnscale.eu
 
# Verify with ldns-dane
ldns-dane verify example.com 443

Common Mistakes

1. Deploying TLSA without DNSSEC: The record exists but provides no security. An attacker can spoof both the certificate and the TLSA record. Always enable DNSSEC first.

2. Updating the certificate without updating TLSA: Clients that validate DANE see a mismatch and refuse to connect. Always add the new TLSA record before deploying a new certificate.

3. Using selector 0 with frequent renewals: If you hash the full certificate (selector 0), every renewal requires a TLSA update. Use selector 1 (SPKI) with key reuse to avoid this.

4. Wrong port or protocol in the owner name: A TLSA record at _443._tcp.example.com does not protect _443._tcp.www.example.com. Each hostname and port combination needs its own TLSA record.

5. Forgetting submission ports: If your mail server accepts connections on ports 25, 465, and 587, you need TLSA records for each port.

6. Ignoring TTL during rollover: If your TLSA TTL is 86400 seconds (24 hours), you must wait at least 24 hours after publishing the new TLSA record before deploying the new certificate. Cached old TLSA data will cause validation failures.

7. Not monitoring DNSSEC expiry: DNSSEC signatures have expiration dates. If your zone signatures expire, all DANE validation fails and services become unreachable for validating clients.

TLSA vs CAA: Complementary Security

CAA records and TLSA records serve different but complementary purposes:

Use both for defense-in-depth: CAA reduces certificate mis-issuance risk, and TLSA tells DANE-validating clients which certificate or key to trust even if another certificate exists.

Related Record Types

• CAA Record — Controls which CAs can issue certificates for your domain
• MX Record — Mail server designation, used with DANE for SMTP
• SSHFP Record — Similar concept for SSH host key verification
• SPF, DKIM, DMARC — Email authentication that complements DANE encryption
• SSL/TLS Certificates — Understanding the certificates TLSA records pin
• SSL/TLS Handshake — Where certificate and DANE checks happen during connection setup
• DNSSEC — Required for TLSA records to provide security
• DNS Record Types — Overview of all DNS record types
• What is DNS — Fundamentals of the Domain Name System

Conclusion

TLSA records and DANE represent a fundamental shift in how TLS trust can work — moving some authority from centralized Certificate Authorities to domain owners via DNS. While browser adoption remains limited, DANE for SMTP is already used to protect email in transit in deployments where sending MTAs validate DANE and DNSSEC. The combination of DNSSEC-signed zones and TLSA records lets validating clients verify which certificates are valid, reducing certificate-substitution risk. If you operate a mail server, deploying DANE with a 3 1 1 TLSA record on port 25 can be a high-impact security improvement when your DNSSEC and certificate operations are mature.