The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
updated by
Extracted elements (27)
Certificate rollover is handled by publishing both old and new TLSA records simultaneously (pre-publish method, analogous to DNSSEC key rollover), waiting for TTL expiry before switching the server certificate, and then removing the old TLSA record. This avoids client downtime during the transition.
DANE was designed because any of the hundreds of public CAs can issue a certificate for any domain name, meaning a single compromised CA can undermine TLS security globally. DNSSEC restricts assertions to keys within the signing zone's hierarchy, implementing the principle of least privilege: only the zone's own DNS administrator can assert certificate bindings for that zone.
Selector type 1 (SubjectPublicKeyInfo) is preferred over selector type 0 (full certificate) when associating with CA or intermediate certificates, because TLS clients may rebuild trust chains using locally cached or AIA-retrieved reissued certificates that share the same public key but differ in signature algorithm or extensions, causing full-certificate associations to fail with false negatives.
DANE TLSA applies equally to TLS (RFC 5246) and Datagram TLS/DTLS (RFC 6347), including versions earlier than 1.2. The document exclusively uses 'TLS' for readability but all normative text applies to both.
TLSA records are not special DNS resource records; they follow standard DNS aliasing rules. A CNAME on the prefixed name (e.g., _443._tcp.host) aliases the TLSA lookup, but a CNAME on the base host name alone does not alias TLSA lookups at the prefixed name. DNAME records can alias entire _tcp subtrees.
A TLSA RRSet whose DNSSEC validation state is indeterminate or insecure MUST be considered unusable and cannot be used for TLS.
Clients that validate DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients relying on an external validator MUST use a secure mechanism (e.g., TSIG, SIG(0), IPsec) between themselves and the validator; using secure transport to a non-validating resolver is not sufficient.
If a certificate association contains a certificate usage, selector, or matching type not understood by the TLS client, or if the comparison data is malformed, or if a cryptographic algorithm is considered too weak by local policy, that certificate association MUST be considered unusable.
If an application has TLSA use turned on and a request for a TLSA record returns neither a valid signed response nor verification that the domain is insecure/indeterminate, the application either MUST NOT start a TLS connection or MUST abort the TLS handshake, and SHOULD NOT indicate that TLSA was applied.
If an application receives zero usable certificate associations, it processes TLS normally without TLSA input. If one or more usable associations are received but none matches the server's certificate during the TLS handshake, the TLS client MUST abort the handshake.
If implementations cache TLSA-related domain name lookups for performance, they MUST observe the TTL information reported by DNS. Failure to do so could result in spoofing or denial of access during certificate rollover.
If the DNSSEC validation state on the TLSA RRSet response is bogus, this MUST cause TLS not to be started or, if TLS negotiation is already in progress, MUST cause the connection to be aborted.
TLS clients conforming to this specification MUST be able to correctly interpret TLSA records with certificate usages 0, 1, 2, and 3; MUST support selectors 0 and 1; MUST support matching types 0 (exact) and 1 (SHA-256); and SHOULD support matching type 2 (SHA-512).
Whether a TLSA RRSet can be used MUST be based on the DNSSEC validation state. A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association unless prohibited by local policy.
The Certificate Usage field (1 octet) specifies how the TLSA record constrains the TLS certificate. Value 0 = CA constraint (PKIX path must include matching CA cert); 1 = service certificate constraint (end entity must match, PKIX validation required); 2 = trust anchor assertion (matching cert used as trust anchor); 3 = domain-issued certificate (end entity must match, no PKIX validation required).
The Matching Type field (1 octet) specifies how the certificate association data is presented. Value 0 = exact match on selected content; value 1 = SHA-256 hash of selected content; value 2 = SHA-512 hash of selected content.
The Selector field (1 octet) specifies which part of the TLS certificate is matched against the association data. Value 0 = full certificate (DER-encoded binary structure per RFC 5280); value 1 = SubjectPublicKeyInfo (DER-encoded per RFC 5280).
TLSA records are stored at a prefixed DNS domain name constructed as: _port._transport.base-domain (e.g., _443._tcp.www.example.com). Valid transport labels are 'tcp', 'udp', and 'sctp'. Internationalized domain names MUST use A-label form.
IANA allocated DNS RR type value 52 for the TLSA RRtype from the Resource Record (RR) TYPEs subregistry of the DNS Parameters registry.
IANA created the 'TLSA Certificate Usages' registry (policy: RFC Required) with initial values: 0 = CA constraint, 1 = Service certificate constraint, 2 = Trust anchor assertion, 3 = Domain-issued certificate, 4–254 Unassigned, 255 = Private use.
IANA created the 'TLSA Matching Types' registry (policy: Specification Required) with initial values: 0 = No hash used, 1 = SHA-256, 2 = SHA-512, 3–254 Unassigned, 255 = Private use.
IANA created the 'TLSA Selectors' registry (policy: Specification Required) with initial values: 0 = Full certificate, 1 = SubjectPublicKeyInfo, 2–254 Unassigned, 255 = Private use.
A TLSA record with certificate usage 2 that matches a revoked certificate effectively overrides revocation checking because the client treats the matched certificate as a trust anchor and does not check its revocation status. Domain administrators using usage 2 bear responsibility for ensuring those certificates remain trustworthy.
DANE's security depends entirely on DNSSEC integrity. A rogue DNS administrator who can modify A/AAAA and TLSA records can redirect clients to unauthorized servers, but PKIX certificate path validation (for usages 0 and 1) limits the damage. A weaker authentication mechanism for TLSA records than for A/AAAA records creates an additional man-in-the-middle vector.
DNSSEC validation by an external recursive resolver, with the AD bit set but no authenticated channel to the client, can be trivially spoofed. Even with a secure channel, a compromised external validator can falsify DNSSEC data. For best security, DNSSEC validation should be performed on-host.
SSL/TLS inspecting proxies that act as man-in-the-middle will be broken by TLSA: the TLS client will retrieve a certificate association from DNS that does not match the proxy's substituted certificate, causing the handshake to fail.
The TLSA RDATA consists of a one-octet Certificate Usage field, a one-octet Selector field, a one-octet Matching Type field, and a variable-length Certificate Association Data field. The first three fields are encoded as 8-bit unsigned integers; the association data is raw bytes or a hash thereof.