DANE TLSA Binds TLS Service Keys Through DNSSEC
TLS normally authenticates a server through certificate validation rules defined by the application and its trust model. DANE adds a DNS-based binding: a TLSA resource record associates a service endpoint with certificate or public-key material, while DNSSEC supplies authenticated DNS data for that association.
The boundary is strict. A TLSA RRset that is insecure or has an indeterminate DNSSEC state cannot serve as an authenticated DANE association. DANE therefore depends on DNSSEC validation rather than treating ordinary DNS transport as sufficient evidence.
TLSA names identify a service endpoint
A TLSA lookup is scoped to a port, transport, and host name. For a TLS service on TCP port 443 at www.example.org, the owner name has this form:
_443._tcp.www.example.org.That naming scheme separates services that share a host but use different ports or transports. A TLSA association for one endpoint is not a generic assertion for every TLS service on the same host.
The RR data has four parts: certificate usage, selector, matching type, and certificate association data.
_443._tcp.www.example.org. IN TLSA 3 1 1 <sha256-digest>The three numeric parameters determine what object is associated and how the final field is compared.
Certificate usage defines the trust relationship
RFC 6698 defines four certificate-usage values. Usage 0 constrains a CA in a PKIX-valid certification path. Usage 1 constrains the end-entity certificate while retaining PKIX validation. Usage 2 supplies a trust-anchor assertion for path validation. Usage 3 directly associates the end-entity certificate or its selected public-key material and does not require PKIX validation for that association.
RFC 7671 gives the symbolic names PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). The distinction matters because a matching digest alone does not describe the trust semantics; the usage field does.
For DANE-specific designs, RFC 7671 recommends support centered on DANE-TA(2) and DANE-EE(3) rather than treating all four usages as interchangeable.
Selector chooses certificate bytes or public-key material
Selector 0 means the complete DER-encoded certificate. Selector 1 means the DER-encoded SubjectPublicKeyInfo structure.
This choice changes rotation behavior. An association over the complete certificate changes when certificate bytes change. An association over SubjectPublicKeyInfo can remain stable across certificate replacement when the same public key is retained.
That stability is not automatically preferable. Keeping the same key and rotating to a new key are separate operational decisions, and the published TLSA RRset has to remain compatible with the certificate chain or key actually served.
Matching type controls the comparison representation
Matching type 0 stores the selected data directly. Matching type 1 stores its SHA-256 digest, and matching type 2 stores its SHA-512 digest.
A common 3 1 1 record therefore means:
3: DANE-EE1: selectSubjectPublicKeyInfo1: compare its SHA-256 digest
The digest is certificate association data, not a certificate fingerprint with independent trust semantics. Its meaning comes from the complete TLSA parameter tuple and the DNSSEC-authenticated RRset that carries it.
Key rotation requires overlap in DNS and service state
A TLSA deployment can fail during an otherwise valid certificate or key rotation if DNS changes and server changes are ordered poorly. RFC 7671 describes transitional RRsets that contain associations compatible with both the current and incoming service state before the endpoint switches keys.
This is a cache-sensitive operation. Publishing the incoming association early enough for old DNS data to expire reduces the interval in which validators can see an RRset that matches only the previous endpoint state.
After the service transition and the relevant DNS cache interval, the obsolete association can be removed. The exact sequence depends on the chosen usage, selector, certificate chain, key plan, and application protocol.
DANE does not turn every TLS client into a DNSSEC validator
A client can validate DNSSEC itself or rely on another validating component, but the path between the client and that validator must preserve the security property required by the DANE design. A non-validating resolver does not create authenticated TLSA data merely because DNS queries reach it over a protected channel.
Application support also matters. Publishing TLSA records does not force software that lacks DANE processing to enforce them. DANE authentication is effective only where the relevant application protocol and client implement the required TLSA and DNSSEC behavior.
The resulting control is specific: DNSSEC-authenticated TLSA data can bind a service endpoint to selected certificate or public-key material under explicit trust semantics. Its reliability depends on DNSSEC validation, correct TLSA parameters, compatible service state, and disciplined rollover rather than on the presence of a DNS record alone.