Summary

  • A TLSA record is selected under an owner name constructed from a port, transport protocol and base domain. A successful match is evidence for that service tuple and validation model, not universal authority for the certificate, host or organisation.
  • The useful proof must retain DNSSEC status, owner-name derivation, certificate usage, selector, matching type, certificate or key material, application rules and observation time. Dropping any of them can turn a bounded association into a false global claim.

One certificate, two services

Consider an illustrative host that presents the same certificate on TCP ports 443 and 8443. Its signed zone publishes a usable TLSA RRset only at _443._tcp.service.example. The first client derives that owner name, validates the DNSSEC chain, applies the record's usage and matches the presented key. A second client connecting to 8443 cannot borrow the result. Its query begins at _8443._tcp.service.example, where no equivalent assertion exists.

This is a synthetic control case, not an allegation about a named deployment. Its value lies in how ordinary the mistaken shortcut sounds: “the certificate already passed DANE on this host.” DANE did not make that statement. It authenticated a certificate association selected through one application-specific service name.

RFC 6698 deliberately places the port and transport labels before the base domain. Multiple TLS services on one host can therefore carry different associations, validation models and rollover schedules. A database that indexes a passing TLSA result only by certificate fingerprint or hostname discards the boundary that made the result valid.

The owner name is part of the evidence

For direct TLS over TCP, the familiar form is _port._tcp.base-domain. The port is expressed as a decimal number, not merely a service nickname. The transport label distinguishes TCP from other transports. The base domain comes from the application's rules, not from an analyst choosing a convenient name after the connection.

Redirection makes provenance more demanding. CNAME processing can move the TLSA lookup while application rules preserve the identity against which certificates are evaluated. SRV-based applications derive a TLSA base domain through service discovery under RFC 7673. SMTP DANE follows MX resolution and has its own rules for TLSA base domains, reference identifiers, DNS errors and fallback. The visible host in a socket log is therefore not always enough to reconstruct which TLSA owner name was authoritative.

The minimum record should preserve the original application destination, every secure discovery step, the unexpanded and expanded DNS names, port, transport, final TLSA query name, DNSSEC result and the rule that connected them. “TLSA matched” without that chain cannot be independently replayed.

Four usages express different trust decisions

The first TLSA octet is not decorative metadata. RFC 7218 gives the four original usages stable names.

PKIX-TA(0) constrains a certification authority while still requiring ordinary public-key infrastructure path validation. PKIX-EE(1) constrains the end-entity certificate and also retains PKIX validation. DANE-TA(2) supplies a trust-anchor assertion through DNSSEC. DANE-EE(3) associates the service directly with the selected end-entity certificate or public key under DANE rules.

A byte match under one usage cannot be reported as a pass under another. Usage 1 does not allow a client to ignore an expired or otherwise invalid PKIX path merely because the selected material matches. Usage 3 does not silently import every web-PKI name-check assumption. Application profiles can further restrict which usages are supported: RFC 7672 treats SMTP DANE differently from a generic TLS client and does not make usages 0 and 1 the normal security basis for opportunistic SMTP DANE.

The operational question is therefore not “was there a TLSA record?” It is “which party chose which trust model for which service, and did this client implement that model under the applicable application standard?”

Selector and matching type define what matched

The selector identifies the object. Selector 0 chooses the full DER-encoded certificate. Selector 1 chooses the SubjectPublicKeyInfo structure that contains the public key and its algorithm. A certificate can be renewed with the same key: an SPKI association may continue to match while a full-certificate association changes.

The matching type then defines the comparison. Type 0 carries the selected bytes exactly. Type 1 carries their SHA-256 digest. Type 2 carries SHA-512. A dashboard that records only the hexadecimal association data cannot tell whether the publisher meant a whole certificate, a public key or a digest of either.

This distinction controls rollover and compromise response. Reusing a key can reduce DNS changes across certificate renewal, but it also makes key retirement more consequential. Pinning a whole end-entity certificate narrows the object but demands coordinated updates at renewal. Trust-anchor associations cover a different change surface again. There is no universally safest tuple apart from the deployment and recovery model.

DNSSEC supplies the publication authority

DANE authority depends on DNSSEC validation, not on receiving a syntactically correct type 52 response. A validating client must distinguish a secure RRset from an insecure delegation, a bogus answer and an indeterminate state. A resolver error string or Extended DNS Error can help explain a failure, but it does not replace cryptographic validation state.

That boundary cuts in both directions. A forged unsigned TLSA answer must not override certificate validation. Conversely, when an application profile treats a secure usable TLSA RRset as a commitment, silently falling back after a match failure can recreate the downgrade path DANE was intended to close. RFC 7672 requires an SMTP client with usable secure TLSA records to authenticate the server and not deliver through that server when authentication fails.

DNSSEC authenticates publication under a DNS name. It does not prove that the publisher exclusively controls the matching private key, that the endpoint is correctly configured or that the business principal intended every use of the service. Compromise of the DNS signing path can publish new DANE-EE material; compromise of the TLS private key can satisfy an unchanged record. The two control planes need separate custody and separate incident evidence.

A successful match stops before the application

TLSA evaluation can establish that selected material from a TLS handshake satisfied one DNSSEC-authenticated association under one usage. It cannot prove that the handshake negotiated the intended protocol, that the application request was authorized, that a human or workload identity was authenticated or that a transaction completed.

ALPN, SNI, HTTP authority, SMTP destination, client authentication and application access control each have their own inputs. A reverse proxy can terminate the validated TLS channel and originate another connection. A certificate shared across functionally different servers can permit substitution within the set of endpoints that present it. RFC 7672 warns about shared end-entity associations unless the servers are functionally equivalent or mutually incompatible in a way that gives redirection no advantage.

Leadership evidence should therefore say “the presented SPKI matched secure TLSA usage 3 for this owner name at this time.” It should not compress the result into “the domain authorized the request” or “the server was trusted.”

Rotation is an interval, not a switch

A safe change usually publishes new association material before the endpoint starts depending on it, keeps old and new material during an overlap, verifies observations from relevant resolver and client populations, then removes the old association only after TTLs, DNSSEC signatures and deployment state make retirement defensible.

The ordering changes with the tuple. A new certificate under the same SPKI may not change an SPKI association. A new key necessarily does. A DANE trust-anchor rollover differs from an end-entity rollover. Caches can retain a removed record; endpoints can present old material; signers can publish the right RRset under an expired or unavailable chain.

The control record needs timestamps for zone publication, authoritative observation, recursive-cache observation, certificate or key deployment, old-material removal and DNSSEC signature validity. A green result from one resolver is not evidence that the global transition has converged.

Test the boundary by trying to cross it

Present the same certificate on two ports and publish an association for only one. Change TCP to another transport label. Move the service through a CNAME or SRV target and verify the application-specific base-domain rule. Exercise each supported usage, then deliberately make the PKIX path fail under usage 1 while the selected bytes still match.

Renew a certificate with the same key and compare selector 0 with selector 1. Rotate to a new key with old and new associations overlapping, then query through recursive resolvers with different cache histories. Return secure, insecure, bogus and indeterminate DNS states and require visibly different outcomes. Finally, let the TLSA check pass while ALPN, client authorization or the application transaction fails.

The expected result is not that DANE approves more. It is that the implementation refuses to let one precise proof escape its tuple.