What Is a TLSA Record

A TLSA (Transport Layer Security Authentication) record associates a TLS server certificate or public key with a domain name, enabling DANE (DNS-based Authentication of Named Entities). TLSA records provide an alternative or supplement to traditional Certificate Authority validation. While CAA records control which CAs can issue certificates for your domain, TLSA goes further by telling clients exactly which certificate or key to expect when connecting.

How TLSA Records Work

TLSA records specify what certificate or key a client should expect when connecting via TLS:

_443._tcp.example.com.    3600    TLSA    3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

This tells clients: "When connecting to example.com on port 443 via TCP, expect a certificate matching this SHA-256 hash."

TLSA records are part of the broader DNS security ecosystem. They rely on DNSSEC to guarantee the authenticity of the TLSA record itself — without DNSSEC, an attacker could forge a TLSA record just as easily as they could forge any other DNS record type.

Record Components

Usage Values Explained

Each usage value represents a different trust model. Choosing the right one depends on whether you want to rely on the existing CA system, replace it entirely, or use a combination.

DANE-EE (usage 3) is the most widely deployed because it is the simplest. It does not require CA validation at all — the DNS record itself serves as the trust anchor. This is particularly powerful for protocols like SMTP where browser-style CA validation has historically been weak.

DANE-TA (usage 2) is useful when you operate your own internal CA and want to publish its certificate in DNS rather than relying on the public WebPKI. All certificates chaining to your published trust anchor will validate.

Selector Values

Selector 1 (SPKI) is preferred for most deployments because it survives certificate renewal as long as you reuse the same key pair. This simplifies rollover since you do not need to update the TLSA record every time you renew your certificate.

Matching Type Values

Common Use Cases

Web Server DANE-EE (Recommended)

Self-sign validation using DNS:

_443._tcp.example.com.    3600    TLSA    3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Usage 3 + Selector 1 + SHA-256 is the most common configuration.

Mail Server (SMTP DANE)

SMTP DANE is arguably the most impactful use of TLSA records today. Traditional SMTP uses opportunistic TLS (STARTTLS), which is vulnerable to downgrade attacks — an attacker can strip the STARTTLS offer and force plaintext delivery. DANE solves this by publishing TLSA records for mail servers, telling sending MTAs both that encryption is required and which certificate to expect.

Secure email delivery with DANE:

_25._tcp.mail.example.com.      3600    TLSA    3 1 1 abc123...
_465._tcp.mail.example.com.     3600    TLSA    3 1 1 abc123...
_587._tcp.mail.example.com.     3600    TLSA    3 1 1 abc123...

For SMTP DANE to work, the MX record target must have both a TLSA record and DNSSEC enabled on the zone. Major mail providers including Comcast, Deutsche Telekom, and many European ISPs have deployed SMTP DANE, protecting billions of email messages.

SMTP DANE is endorsed by several European data protection authorities as a best practice for protecting email confidentiality. When combined with SPF, DKIM, and DMARC, it provides comprehensive email authentication and transport security.

XMPP Server

_5222._tcp.xmpp.example.com.    3600    TLSA    3 1 1 def456...
_5269._tcp.xmpp.example.com.    3600    TLSA    3 1 1 def456...

Multiple Certificates (Rollover)

During certificate renewal:

_443._tcp.example.com.    3600    TLSA    3 1 1 oldcerthash...
_443._tcp.example.com.    3600    TLSA    3 1 1 newcerthash...

Generating TLSA Data

Using OpenSSL

Get SHA-256 hash of public key (selector=1, matching=1):

# From certificate file
openssl x509 -in cert.pem -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256
 
# From live 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

Get SHA-256 hash of full certificate (selector=0, matching=1):

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

Get SHA-512 hash of public key (selector=1, matching=2):

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

Generate hash from a mail server (SMTP DANE):

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | \
  openssl x509 -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256

Using ldns-dane

ldns-dane create example.com 443 3 1 1

Adding a TLSA Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter _443._tcp (or appropriate port/protocol)
   • Type: Select TLSA
   • Usage: Select the certificate usage (0-3)
   • Selector: Choose Full cert (0) or Public key (1)
   • Matching Type: Choose SHA-256 (1) or SHA-512 (2)
   • Certificate Data: Enter the hex-encoded hash
   • TTL: Set the cache duration (default: 3600) — see TTL best practices
4. Click Create Record

Using the API

Create a TLSA record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_443._tcp",
    "type": "TLSA",
    "content": "3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "ttl": 3600
  }'

Create TLSA for mail server:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_25._tcp.mail",
    "type": "TLSA",
    "content": "3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "_443._tcp.example.com.",
      "type": "TLSA",
      "content": "3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "ttl": 3600,
      "disabled": false
    }
  }
}

You can also manage TLSA records as code using Terraform or DNSControl.

DANE Requirements

For DANE to work, your zone must:

1. Be DNSSEC-signed - TLSA records without DNSSEC provide no security benefit
2. Have correct TLSA records - Hash must match the actual certificate/key
3. Update records during certificate rotation - Add new hash before deploying new certificate

Certificate Rollover Process

1. Generate new certificate
2. Add TLSA record for new certificate hash
3. Wait for DNS propagation (at least TTL duration)
4. Deploy new certificate on server
5. Remove old TLSA record

# Step 2: Add new hash while keeping old
_443._tcp.example.com.    3600    TLSA    3 1 1 oldhash...
_443._tcp.example.com.    3600    TLSA    3 1 1 newhash...
 
# Step 5: Remove old hash
_443._tcp.example.com.    3600    TLSA    3 1 1 newhash...

If you use selector 1 (SPKI) and reuse your key pair when renewing certificates, the hash does not change and no TLSA update is needed. This is one of the strongest arguments for using selector 1 in production.

Best Practices

1. Use DANE-EE (usage 3) - Simplest and most commonly deployed

2. Use selector 1 (SPKI) - Survives certificate renewal if key is reused

3. Use SHA-256 (matching type 1) - Standard and widely supported

4. Publish before deployment - Add TLSA records before deploying new certificates

5. Enable DNSSEC first - TLSA without DNSSEC is insecure

6. Keep multiple records during rollover - Prevent service interruption

7. Monitor with automation - Use monitoring tools to alert you if TLSA records become stale or mismatched

Testing TLSA Records

# Query TLSA record
dig TLSA _443._tcp.example.com
 
# Verify with ldns
ldns-dane verify example.com 443
 
# Online tools
# - https://dane.sys4.de/
# - https://internet.nl/

TLSA and the SSL/TLS Certificate Chain

TLSA records work alongside the traditional SSL/TLS certificate chain. With usage values 0 and 1 (PKIX-TA and PKIX-EE), DANE supplements the existing CA system — the certificate must still pass standard validation. With usage values 2 and 3 (DANE-TA and DANE-EE), DANE replaces CA validation entirely, using DNS as the trust anchor instead.

This distinction matters for DNS security: DANE-EE effectively removes the CA as a single point of compromise, replacing it with DNSSEC-protected DNS. An attacker would need to compromise DNSSEC — a significantly harder target than compromising or deceiving a certificate authority.

Related Record Types

• CAA - Certificate authority authorization
• TXT - Domain verification and email security
• SSHFP - SSH fingerprints (similar concept)
• SRV - Service location records
• HTTPS/SVCB - Service binding records
• A / AAAA - Address records that TLSA protects

Conclusion

TLSA records enable DANE, providing DNS-based certificate validation that can supplement or replace traditional CA verification. When combined with DNSSEC, TLSA records offer strong protection against man-in-the-middle attacks. SMTP DANE in particular has become a critical component of modern email security, protecting mail delivery where opportunistic TLS alone falls short. DNScale's intuitive interface makes configuring TLSA records straightforward, with dedicated fields for usage, selector, and matching type parameters.