TLS normally authenticates a server through a certificate chain that terminates at a trust anchor already accepted by the client. DANE adds another path: a domain can publish a TLSA record in DNS and protect that record with DNSSEC. A DANE-capable client can then compare certificate material from the TLS handshake with the association published by the domain.
RFC 6698 defines the TLSA resource record. RFC 7671 updates the operational rules and narrows several deployment choices. The central security property is specific: only DNSSEC-validated TLSA data is suitable for DANE authentication. An insecure or indeterminate TLSA RRset does not provide the authenticated DNS binding that DANE requires.
The query name identifies a transport endpoint
For direct TLS services, the TLSA owner name combines the service port, transport protocol, and server name. A TLS service on TCP port 443 at www.example.com uses this form:
_443._tcp.www.example.com. IN TLSA ...The leading labels matter. They bind the association to a particular transport endpoint rather than treating one certificate rule as an unrestricted statement about every service under the host name.
Protocols that locate servers through records such as SRV need protocol-specific construction rules. RFC 7673, for example, derives the TLSA query from the SRV port, transport, and target host. A client cannot safely substitute an arbitrary host or port and assume that the resulting association has the same scope.
Four fields define the certificate association
A TLSA record contains three numeric parameters followed by Certificate Association Data:
usage selector matching-type association-dataThe certificate usage field defines the role of the association. RFC 7671 names the four standard values PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).
The selector determines which certificate material is compared. Cert(0) selects the complete certificate, while SPKI(1) selects its SubjectPublicKeyInfo. Selecting SPKI can keep an association stable across certificate renewals when the same public key remains in service.
The matching type determines the representation stored in DNS. Full(0) carries the selected material directly. SHA2-256(1) and SHA2-512(2) carry digests. RFC 7671 recommends digest-based associations instead of large full-certificate records, in part because oversized DNS responses are less suitable for reliable UDP delivery.
A compact association can therefore look like:
_443._tcp.www.example.com. IN TLSA 3 1 1 <sha256-of-spki>Here, 3 1 1 means DANE-EE, SPKI, and SHA-256. The final field is the SHA-256 digest of the selected SubjectPublicKeyInfo.
DANE-EE can authenticate the presented endpoint key directly
With DANE-EE(3), the TLSA association applies to the end-entity material presented by the server. RFC 7671 specifies that the binding of the server public key to the service name is based on the TLSA RRset for this usage. The client checks that the presented leaf material matches a usable TLSA association.
This differs materially from ordinary PKIX validation. For DANE-EE, the TLSA record itself supplies the authenticated association, so a preconfigured public CA trust anchor is not required for that DANE authentication path. RFC 7671 also states that certificate name matching and validity-period enforcement for DANE-EE are governed by the TLSA association rules rather than ordinary PKIX checks.
That does not make the TLS handshake optional. The server still has to prove possession of the private key corresponding to the authenticated public key as required by the negotiated TLS authentication mechanism. TLSA publishes the association; it does not publish or replace the private key.
DANE-TA delegates trust to certificate-authority material
DANE-TA(2) takes a different approach. Instead of associating the service directly with its leaf certificate or key, it identifies trust-anchor material used to validate the server’s certificate chain.
This can support a private or otherwise non-public trust anchor without requiring that anchor to be preinstalled in every client. Operational details are important. RFC 7671 recommends Cert(0) for DANE-TA publishers so certificate constraints remain part of the selected trust-anchor material. It also requires suitable certificate material to be available in the server chain when a digest-based DANE-TA association would otherwise leave the client without the certificate needed to construct and verify the path.
The distinction between DANE-EE and DANE-TA is therefore architectural, not cosmetic. One associates the endpoint material directly; the other associates authority used in certificate-chain validation.
PKIX usages add DNS constraints without discarding PKIX
PKIX-TA(0) and PKIX-EE(1) retain PKIX validation. The TLSA association constrains certificate material that must also pass the applicable PKIX checks. Existing requirements such as accepted CA trust, identity checks, and other PKIX validation remain relevant.
RFC 7671 recommends that application designs generally avoid supporting all four usages indiscriminately. Protocol specifications can select the usages that fit their authentication model. A deployment therefore has to follow the rules of the application protocol using DANE, not merely publish a syntactically valid TLSA record and assume every DANE client will treat it identically.
DNSSEC is part of the authentication path
A TLSA record fetched from ordinary unsigned DNS is not enough. DANE depends on a DNSSEC validation chain that marks the TLSA RRset as secure. If a client delegates validation to a resolver, the path between the client and that validating resolver also has to preserve the security assumptions required by the DANE implementation.
This shifts operational responsibility. Certificate or key rollover must be coordinated with DNS publication, DNS TTLs, DNSSEC signatures, and the material actually served by the TLS endpoint. RFC 7671 describes rollover sequences in which old and new associations coexist before the endpoint changes. Publishing only future material too early, or removing current material too early, can leave clients with a secure TLSA RRset that does not match the active server.
The same fail-closed property appears when secure TLSA data is present but authentication fails. For protocols that require authenticated DANE TLS, a mismatch is not a hint to ignore the record and continue as if it did not exist. Application-specific standards define the exact connection policy, especially for opportunistic TLS.
The security boundary spans DNS and TLS operations
DANE does not replace DNSSEC, TLS, certificate lifecycle controls, or private-key protection. It composes them. DNSSEC authenticates the published association; TLS supplies the live peer material and possession proof; the application defines when DANE authentication is mandatory and which TLSA usages are accepted.
That composition creates a precise operational boundary. A correct TLS certificate deployed without the matching secure TLSA state can fail. A correct TLSA RRset pointing at material not served by the endpoint can fail. A matching TLSA record delivered without the required DNSSEC security state cannot carry DANE authentication authority.
For operators, the practical unit is therefore not the certificate alone. It is the synchronized state of the DNSSEC-signed TLSA RRset, the TLS endpoint, and the client policy that interprets both.