TLSA

TLSA is a DNS resource record type defined for the DNS-based Authentication of Named Entities (DANE). It allows domain owners to publish bindings between a TLS service’s certificate and DNS records, enabling TLS authentication to be performed using DNSSEC-protected data rather than relying solely on the traditional public key infrastructure (PKI).

A TLSA record is stored in DNS and is typically associated with a specific TLS service name, such as a domain and port (for example, a service exposed via HTTPS or SMTP over TLS). When a client connects to the service, it can retrieve the TLSA record via DNSSEC and compare it against the certificate presented by the server. If they match according to the configured parameters, the TLS connection can proceed with a higher assurance of the server’s identity.

A TLSA record contains four fields: usage, selector, matching type, and data. The usage indicates how the record should be interpreted, with four possibilities: PKIX-TA and PKIX-EE for X.509 PKI concepts, and DANE-TA and DANE-EE for DNS-based trust anchors or end-entity certificates. The selector specifies which part of the certificate is used (full certificate or just the SubjectPublicKeyInfo). The matching type determines how the data is matched (full data, SHA-256 hash, or SHA-512 hash). The data field contains either the raw certificate data or the hash value, depending on the selected matching type.

TLSA is intended to complement or, in some deployments, replace traditional certificate validation. It relies on DNSSEC for authenticity; without DNSSEC, TLSA data cannot be trusted. Adoption varies by protocol and ecosystem, with notable use in email (DANE-enabled SMTP) and growing, but not universal, support in HTTPS clients.