Summary

  • RFC 9102 lets a validated TLSA authentication chain establish an extension-support lifetime for one service name and port. DNS TTLs still govern the current record; the longer pin governs whether the server must keep supplying a valid chain or authenticated negative evidence.
  • A valid denial of the TLSA RRset, proof of insecure delegation or a validated zero-lifetime transition can clear the pin. An omitted extension while a live pin requires evidence is not the same thing and can force the client to abort.

Two promises hidden in one handshake

Suppose a client connects to a DNS-over-TLS resolver. To authenticate the resolver with DANE, it needs the resolver’s TLSA record and the DNSSEC path that proves it. Fetching that path through the very DNS service being authenticated creates an awkward dependency. RFC 9102 offers an experimental escape: the TLS server can carry the DNSSEC authentication chain inside the TLS handshake.

The response contains both evidence and a number named ExtSupportLifetime. The evidence answers the present question: does a DNSSEC-validated TLSA RRset match the certificate chain for this SNI name and port? The number answers a different, forward-looking question: for how many hours does this server, or this serving cluster, commit to supporting the extension?

Shumon Huque is one of five authors of RFC 9102, alongside Viktor Dukhovni, Willem Toorop, Paul Wouters and Melinda Shore. The RFC credits Adam Langley with the original idea. Huque’s current IETF profile and his own biography describe work on DNS infrastructure, networking and security protocols, after roles at Salesforce, Verisign and the University of Pennsylvania. That record makes him a useful route into the mechanism; it does not make a collective Experimental RFC his individual property.

The distinction between the two promises is the article’s central point. A TLSA RRset has a TTL. Its DNSSEC signatures have inception and expiration times. A server must rebuild the chain as those components change. The extension-support lifetime is explicitly independent of those clocks. A week-long support promise does not stretch a five-minute TLSA record into a week-long credential.

A pin begins only after positive validation

The client cannot safely pin a capability merely because it saw the extension field. RFC 9102 permits a non-zero value to be used only when the response carries a valid TLSA authentication chain that matches the server’s certificate chain. The completed handshake must pass DANE authentication. A syntactically correct message, a conventional PKIX success or an unvalidated set of DNS records cannot create the same state.

The pin is scoped. The client sends a TCP port in the request; the server builds the TLSA name from that port and the client’s SNI hostname. For this in-band method, the server must not expand a CNAME behind the SNI name. The resulting memory belongs to a service instance identified by name and port, not to every name on an IP address and not to every tenant of a shared host.

Clients retain some control over duration. They may reduce a server’s advertised lifetime to a local maximum. The RFC notes the unlikely but serious case of a compromised server advertising the seven-year maximum. Yet an aggressively short cap also weakens the downgrade resistance. The value is therefore neither an order from the server nor a decorative hint: it is an offered commitment bounded by client policy.

The short clock and the long clock

Once a client holds an unexpired validated TLSA RRset, it may reuse that record and omit the extension on later connections. Reuse ends at the received TTL. If the TLSA cache expires while the extension pin remains live, the client must again obtain current evidence—normally by requesting the extension, or by another DNSSEC-valid method.

This creates two clocks. The short clock protects freshness of the current TLSA association. The long clock protects continuity of the evidence channel. They can expire in either order. Monitoring only the pin can hide stale DNS material; monitoring only TTLs can miss a service’s continuing obligation to answer.

TLS session resumption adds a third state. RFC 9102 notes that a resumed session carries no dnssec_chain; with TLS 1.3, it also omits the certificate message to which the chain would attach. An operator who counts every resumed handshake without an extension as a downgrade will manufacture alarms. A useful receipt records full versus resumed handshake, cached TLSA expiry, active pin expiry and the evidence actually used.

Negative evidence is not missing evidence

The most consequential branch occurs when the domain no longer publishes a TLSA record. A supporting server can return a DNSSEC chain that proves authenticated denial of the requested TLSA name. Once validated, that denial can clear the extension pin. Proof of insecure delegation can clear it as well. Local policy then decides whether to continue with PKIX or close the connection.

Silence has a different meaning. If the client has a live pin, lacks an unexpired cached TLSA RRset and receives no required extension, it must abort or delay communication until it obtains valid TLSA data or valid negative evidence out of band. Failure to obtain either ends the TLS attempt. Treating omission as absence would recreate the downgrade path the pin was designed to obstruct: a rogue server with a publicly trusted certificate could simply withhold the DANE material.

This is why RFC 9102 says that requiring the extension is not the same as requiring TLSA or even DNSSEC forever. The zone operator may remove TLSA records or DS records. What remains during the pin is the server’s duty to return a verifiable status. The old positive answer may disappear; an authenticated transition must take its place.

Retirement requires zero, then time

An operator that wants to disable the extension cannot just remove it. RFC 9102 prescribes a staged exit: first advertise an ExtSupportLifetime of zero in a DANE-authenticated handshake, then wait until every previously advertised pin could have expired, and only then stop serving the extension. TLSA or DNSSEC can be removed sooner, but clients with live pins still need authenticated denial.

In hosted services, that schedule crosses organizations. The domain owner controls relevant DNS data and may want to move providers; the provider may control certificates, TLS endpoints and generation of the in-band chain. The RFC therefore recommends non-zero lifetimes only by mutual agreement. A cluster-wide promise is operational only if every serving node can honor it.

Trust also remains external to the server’s assertion. The client validates the chain from a configured DNSSEC trust anchor, needs sufficiently accurate time for RRSIG checks, and must maintain that anchor through rollover. Moving records into the handshake removes an out-of-band lookup; it does not let the endpoint nominate its own root of trust.

RFC 9102 is candid about its status. Pinning raised deployability concerns in the TLS Working Group, and the document frames the mechanism as an experiment intended to study them. The public sources reviewed here do not establish present adoption across major clients or servers. The durable contribution is narrower: it specifies a state machine in which a positive assertion, an authenticated negative assertion and an absent answer cannot be collapsed into one bit.

Sources