What is a TLSA record?TLSA records hold Certificate Association data and are used to specify the keys used in a domain's TLS servers. TLSA records can only be trusted if DNSSEC is enabled on your domain.
TLSA record format
A typical TLSA record looks like the following in standard BIND format:
$ORIGIN example.com. _443._tcp.host-dane 3600 IN TLSA 3 1 1 0D6FCE13243AA7An anatomy of the TLSA Record
_443._tcp.host-dane 3600 IN TLSA 3 1 1 0D6FCE13243AA7looks like the below:
|Host Label||TTL||Record Class||Record Type||Certificate Usage||Selector||Matching Type||Certificate Association Data|
_443._tcp.host-dane.example.com specifies the port number the TLS server listens on (443), the protocol used (tcp) and the hostname of the TLS server (host-dane.example.com).
The time-to-live in seconds. It specifies how long a resolver is supposed to cache or remember the DNS query before the query expires and a new one needs to be done.
Mainly 3 classes of DNS records exist:
- IN (Internet) – default and generally what internet uses.
- CH (Chaosnet) – used for querying DNS server versions.
- HS (Hesiod) – uses DNS functionality to provide access to databases of information that change infrequently.
The record format is defined using this field. Common record types are A, AAAA, CNAME, CAA, TXT etc. In the case of a TLSA record, the record type is TLSA.
An integer value of 0-3.
- 0 - Certificate Authority Constraint. It limits which CA can be used to issue certificates for a given service on a host. The presented certificate must pass PKIX certification path validation, and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path.
- 1 - Service Certificate Constraint. It limits which end entity certificate can be used by a given service on a host. The target certificate must pass PKIX certification path validation and must match the TLSA record.
- 2 - Trust Anchor Assertion. This certificate usage allows a domain name administrator to specify a new trust anchor. For example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate must pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation.
- 3 - Domain Issued Certificate. The services use a self-signed certificate. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3.
An integer value of 0 or 1.
- 0 - Full certificate. It means to select the entire certificate for matching.
- 1 - Use Subject Public Key. It means to select just the public key for certificate matching.
An integer value of 0 to 2.
- 0 - No hash. Exact match on selected content
- 1 - SHA-256 hash of selected content
- 2 - SHA-512 hash of selected content.
The actual data to be matched given the settings of the other fields. These bytes are either raw data (that is, the full certificate or its Subject Public Key, depending on the selector) for matching type 0, or the hash of the raw data for matching types 1 and 2.
TLSA record glossary
DNSSEC protects against forged DNS answers. DNSSEC protected zones are cryptographically signed to ensure the DNS records received are identical to the DNS records published by the domain owner.
Berkeley Internet Name Daemon - is the most commonly used DNS software on the Internet and Dynu observes BIND format.