DNS TLSA records enable DNS-based Authentication of Named Entities (DANE), which allows domain owners to specify which SSL/TLS certificates should be trusted for their services. TLSA records provide an additional layer of security by binding certificates to domain names through DNSSEC-protected DNS records.
TLSA records contain certificate association data that specifies which SSL/TLS certificates are valid for a particular service on a domain. Each TLSA record includes parameters that define how the certificate should be matched, what part of the certificate to validate, and the actual certificate data or hash to compare against.
TLSA records are published as part of DANE (DNS-based Authentication of Named Entities) and require DNSSEC to ensure the integrity of the certificate association data. They provide protection against certificate authority (CA) compromise and man-in-the-middle attacks by creating a direct binding between domain names and certificates.
When a client connects to a service protected by DANE, it queries for TLSA records associated with the service (typically published under a name like _443._tcp.example.com for HTTPS). The client then compares the server's certificate against the constraints specified in the TLSA record to verify that the connection is authentic.
TLSA records can specify different validation modes: certificate association (binding to a specific certificate), trust anchor assertion (specifying a trusted CA), domain-issued certificate (requiring the certificate to be issued by the domain owner), or service certificate constraint (limiting valid certificates for the service).
DANE provides stronger security guarantees than traditional certificate validation because it removes reliance on the entire public CA infrastructure. However, it requires proper DNSSEC deployment and client support, which has limited its widespread adoption despite its security benefits.
Here's what a TLSA record looks like for the domain example.com:
