TLSA record

Last change on 2025-10-07 • Created on 2025-10-07 • ID: NE-494A3

Usage

TLSA records point a service to security details (e.g. the public key of a certificate) to verify the server certificate in a TLS handshake.

Example for mail server:

Type Name (use @ for root) Usage Selector Matching Target TTL
A mail 198.51.100.1
MX @ mail.example.com.
TLSA _25._tcp.mail Domain-Issued Certificate Subject Public Key Info SHA-256 A9A70E866BC9A...

Example for web server:

Type Name (use @ for root) Usage Selector Matching Target TTL
A @ 203.0.113.1
TLSA _443._tcp Trust Anchor Assertion Subject Public Key Info SHA-256 0DEFB3A9C4D8E...
TLSA _443._tcp Domain-Issued Certificate Subject Public Key Info SHA-256 6B3D5F9E1A2C4...

Description

The client has to support DANE. If a client doesn't support DANE, it won't check if a TLSA record is available.

TLSA records are a key component of DANE (DNS-based Authentication of Named Entities). When a client establishes a secure connection to a server, they complete a TLS handshake. During the TLS handshake, the server presents a certificate chain that includes its own certificate and the certificates of all intermediate CAs. To verify the server certificate's authenticity, the client compares the certificate chain that it received from the server against the TLSA record that it received in the DNS response.

TLSA records may look a bit strange at first because they use underscores _ and dots . between some of the information they contain.

Naming scheme:

Examples:
_<port-number>._<protocol>.<domain>

_443._tcp.www.example.com
_25._tcp.mail.example.com

CA-based verification and DANE in comparison:

  • With CA-based verification, the client verifies that the server certificate was indeed signed by the CA that issued it, and that this CA is trusted (chain of trust). To verify, the client typically stores the public keys of well-known public root CAs locally. This ensures that the root CA’s public key used for verification is trusted and legitimate.

  • With DANE, the client verifies that the certificate chain matches the requirements defined in the TLSA record. To verify, the client must trust the TLSA record itself, meaning it needs assurance that the TLSA record is authentic and has not been tampered with by any third parties. To guarantee the legitimacy of the TLSA record, DANE is used in combination with DNSSEC.

ℹ   Note on Security
A TLSA record can only verify a server's certificate in a trustworthy way if the client can trust the TLSA record itself. This trust is established through DNSSEC. Without DNSSEC, the integrity and authenticity of the TLSA record cannot be guaranteed, and DANE validation may become unreliable.

Example: If an attacker performs a man-in-the-middle attack and swaps both the certificate and the TLSA record, they will still match — but both will be malicious. However, with DNSSEC, you can be confident that the TLSA record has not been tampered with, so if the certificate matches the TLSA, you can trust that certificate.

For more information about DNSSEC, see the explanation in the article "Technical concepts » Architecture"

Available options

Usage:

Also requires CA-based verification Description
CA Constraint Yes The certificate or public key belongs to a public CA in the chain of trust.
Service Certificate Constraint Yes The certificate or public key belongs to the server (end entity).
Trust Anchor Assertion No The certificate or public key belongs to a private root CA (Trust Anchor).
Domain-Issued Certificate No The certificate or public key belongs to the server (end entity).

Selector:

Description
Full Certificate Data is based on the full certificate
Subject Public Key Info Data is based on the public key

Matching:

Description
Full Certificate or public key as is, no hash
SHA-256 SHA-256 hash of certificate or public key
SHA-512 SHA-512 hash of certificate or public key

Zone file

The values of "Usage", "Selector" and "Matching" are represented by numbers.

For example:

_443._tcp    IN    TLSA    3 1 1                1306c288896771534a5b60744a535e1025f79b0b64e1bbc89278ba4d413cb9f1
                           | | └ Matching
                           | └── Selector
                           └──── CA Constraint

Here's what each of the numbers stand for:

Usage Selector Matching
0 CA Constraint 0 Full Certificate 0 Exact Match
1 Service Certificate Constraint 1 Subject Public Key Info 1 SHA-256 Hash
2 Trust Anchor Assertion 2 SHA-512 Hash
3 Domain-Issued Certificate
Table of Contents