Summary

  • A TLSA RRset becomes DANE evidence only through a DNSSEC validation result; insecure or indeterminate data is unusable, while bogus data requires failure.
  • Certificate usage, selector and matching type determine what is compared and what certificate-processing rules apply.
  • A securely published association may still be unusable, or it may fail to match the certificate or key the server actually presents.
  • Operators need a service-binding receipt that keeps published, secure, usable, matched and accepted as separate states.

Imagine a service certificate is rotated successfully at midnight. The new chain is live on every server, but some clients still hold a TLSA association for the old public key. DNS contains a TLSA record, monitoring sees a valid HTTPS endpoint, and the deployment ticket closes. Those clients abort anyway because the authenticated association and the served key no longer match.

This is a hypothetical change trace, not an incident attributed to a named operator. It exposes the gap between publishing an association and reconciling every input needed for certificate acceptance.

TLSA publication is only the first state

RFC 6698 defines a TLSA record through certificate usage, selector, matching type and certificate association data. The first three fields are not decoration. They decide whether the association constrains a public-CA path, supplies a trust anchor, or identifies a domain-issued end-entity certificate; whether comparison uses the full certificate or SubjectPublicKeyInfo; and whether the bytes are exact data, a SHA-256 digest or a SHA-512 digest.

The record also belongs at a name derived from the service port, transport and TLSA base domain. Looking up the wrong service name or stopping at an insecure alias can produce valid DNS bytes for the wrong decision. RFC 7671 further treats securely expanded CNAMEs as part of deriving the preferred base domain. A record inventory that saves only the TLSA RDATA loses the identity of the service to which it was meant to apply.

DNSSEC decides whether the association can speak

RFC 6698 makes the DNSSEC validation state decisive. A secure TLSA RRset is used as a certificate association unless local policy prohibits the specific association. A bogus response must stop or abort TLS. An insecure or indeterminate RRset cannot be used for TLSA authentication.

That creates a hierarchy of evidence. “Found in DNS” is weaker than “validated secure.” Secure is still not the same as usable. An unknown certificate usage, selector or matching type makes an association unusable. So do malformed comparison data and a cryptographic algorithm that the client’s policy considers too weak.

If a lookup yields no usable associations, RFC 6698 directs the application to process TLS in its normal fashion without TLSA input. When one or more usable associations exist, the client attempts the required comparisons and must find a successful match. The same published RRset can therefore lead to different behavior in clients with different protocol support or local policy without either client pretending the record was absent.

The served certificate still has to satisfy the record

The certificate usage changes what a match means. Some usages retain PKIX path-validation requirements; DANE usages can establish a DNSSEC-backed trust anchor or directly associate the end entity. Selector choice determines whether a renewed certificate can keep matching the same public key or whether every certificate byte matters.

RFC 7671 adds operational detail. DANE-TA deployments need the server to send sufficient chain material, including the trust-anchor certificate in specified cases. DANE-EE with an SPKI selector can survive certificate renewal when the key stays the same, but it still fails if the server presents a different key from the authenticated association. Digest agility is applied only after malformed and unsupported associations have been removed.

Server health is therefore not a substitute for DANE health. A TLS handshake may succeed for a conventional PKIX client while a DANE client correctly rejects it. Conversely, an application using opportunistic policy may continue with unauthenticated TLS when no usable secure association exists, while a mandatory-authentication application must not connect. Acceptance is an application decision made from protocol evidence, not a property stored inside a DNS row.

Time can split publication from acceptance

TLSA TTLs, DNSSEC signature validity, resolver cache age and certificate rollout order all bound the observation. RFC 7671 warns that clients holding stale TLSA data may fail after an unplanned certificate or chain change. A long signature lifetime can also keep replayable signed DNS data valid longer than an operator expects during recovery.

A rotation plan must therefore account for old and new certificate associations, authoritative publication, secondary-zone propagation, validating-resolver caches, service rollout and rollback. Seeing the new record at one authoritative server does not prove that the clients making real connections see the same binding.