Summary

  • DNS Push replaces ordinary TTL countdown with a session-bound change-delivery obligation. The client may stop aging a record only while the relevant NAME, TYPE and CLASS subscription remains accepted on that DSO session.
  • Closing the connection terminates every subscription. TLS session resumption may shorten the next handshake, but the new DSO session begins without subscription state and requires fresh SUBSCRIBE exchanges and fresh initial results.
  • A defensible “current” verdict must join discovery, TLS authentication, DSO lifecycle, subscription response, ordered PUSH records, TTL freeze/resume state and an independent service probe. A green socket is not that chain.

A recovered channel with a missing promise

Consider an illustrative service-discovery client. It subscribes to an SRV RRset and receives an initial endpoint with a TTL of 120 seconds. Ten minutes later, the service owner withdraws that endpoint. Around the same moment, a middlebox drops the client’s long-lived connection. The client resumes TLS quickly, so the transport dashboard returns to green. No new SUBSCRIBE request is accepted on the replacement DSO session.

The failure is easy to hide in a reassuring phrase: “the secure session recovered.” Cryptographically, the phrase may be accurate. Operationally, it omits the state that mattered. RFC 8765 says that closing TLS ends the DSO session and that a resumed TLS session contains no DNS Push subscription state. The client must recreate every desired subscription. If it instead leaves the old record’s TTL frozen, it has converted a two-minute record into an unbounded local claim without any server still owing it a removal message.

This is not an argument against session resumption. It is an argument about names. TCP connectivity, TLS resumption, a DSO session and an accepted RRset subscription are four different facts. When monitoring compresses them into “connected,” it transfers authority from a defined protocol state to an ambiguous green indicator.

Why DNS Push is allowed to stop a clock

Ordinary DNS caching is built around aging. A resolver stores an answer and decrements its TTL. Once the remaining lifetime reaches zero, the record cannot be treated as fresh merely because querying again is inconvenient. Polling faster can reduce discovery delay for volatile records, but it consumes client, resolver and authoritative capacity even when nothing changes.

DNS Push changes that bargain. A client requests a subscription for exactly one NAME, TYPE and CLASS. The server accepts or rejects that subscription independently. If the answer set is non-empty when acceptance occurs, the server sends an initial PUSH immediately after the SUBSCRIBE response. Later additions and removals arrive asynchronously over the ordered TLS/TCP stream.

The unusual cache rule follows from that accepted duty. RFC 8765 tells the client to store the TTL supplied with an added record but not to decrement it while a relevant subscription is active. A TTL change itself would produce an update, and the client may assume the server will notify it when the record disappears. The stopped clock is therefore not a longer statement by the zone publisher. It is a temporary change in evidence: instead of proving currency by remaining TTL and a future query, the client relies on a live server obligation to deliver every relevant change.

That authority has a precise end. UNSUBSCRIBE ends one subscription. Closing the DSO session ends them all. At that point record aging resumes from the stored TTL, and the record is removed when the TTL reaches zero. An implementation that cannot identify the exact transition from non-aging to aging cannot prove why any retained record is still usable.

The subscription is smaller than the connection

DNS Push begins with discovery. A client normally tries its configured recursive resolver over DNS over TLS on port 853. A resolver that accepts may maintain an upstream subscription and relay results. If it cannot, the client may discover a zone’s advertised service through _dns-push-tls._tcp.<zone>. These steps identify where to ask; they do not all make the same security statement.

RFC 8765 requires the Strict Privacy profile. TLS protects the channel and authenticates a peer under the selected name and credential rules. Yet the specification also warns that TLS alone is incomplete: a subverted SRV lookup can lead a client to establish an impeccably encrypted connection to the wrong server. The audit record therefore needs the discovery RRset and TTL, DNSSEC result where used, target name, SNI, certificate or TLSA outcome and actual peer endpoint. “TLS valid” is not enough.

Once connected, either a DSO Keepalive exchange or the SUBSCRIBE request itself can establish DSO. Each SUBSCRIBE request carries a MESSAGE ID and one NAME, TYPE and CLASS. Its response says whether that particular subscription was accepted. The existence of a TLS socket does not grant a subscription; a DSO-capable server may not implement Push, may not be authoritative for the requested name, or may reject new state because its finite capacity is exhausted.

This layered model preserves local decision. The common protocol defines the request, response, timers and error meanings. The server still decides how many subscriptions it can safely hold. The client decides which live views deserve that cost and is told not to keep subscriptions open continuously merely to make a future display appear instantly.

Deltas without a cross-session cursor

A PUSH message is a server-originated, unidirectional DSO message with MESSAGE ID zero. It is not acknowledged by the client. Its records describe additions, individual removals or collective removals. An addition uses an ordinary TTL range from zero through 0x7FFFFFFF. An individual removal uses 0xFFFFFFFF. A collective removal uses 0xFFFFFFFE with an empty RDATA form whose TYPE and CLASS determine the scope.

The client must validate that each change matches at least one active subscription on the same session. A record arriving after an UNSUBSCRIBE race may be silently ignored when the matching subscription no longer exists. That is a useful tolerance, but it also makes session and subscription identity indispensable evidence. A raw record without the active-subscription context cannot prove it was authorized to modify the cache.

Nothing here supplies a durable cross-session sequence number. PUSH uses zero as its MESSAGE ID, and several changes may be packed into one message. Ordered TCP delivery can prove the order in which bytes arrived on one connection; it cannot prove that a newly resumed connection continued an old logical stream without a gap. The safe recovery action is not to infer a cursor. It is to create a new subscription and process the new initial state.

An empty answer requires equally careful language. RFC 8765 promises an immediate initial PUSH when the answer set is already non-empty. It does not require an invented empty RRset record merely to fill a dashboard. A successful SUBSCRIBE response followed by silence can mean “accepted and currently empty.” Monitoring must preserve both the acceptance event and the absence of an initial non-empty state, rather than labeling silence as either failure or proof of content.

Keepalive proves less than the name suggests

DSO uses an inactivity timeout and a keepalive interval. Keepalive traffic can maintain middlebox state and demonstrate that the peers still have connectivity. An active subscription prevents the session from being considered idle even during a long period with no changes, while keepalive still checks the path.

This proves a narrow operational fact. It does not prove that an upstream recursive subscription is intact, that every RR change was observed, that the advertised endpoint is serving traffic, or that the client applied every delta correctly. A service can fail while its DNS records remain current. Conversely, the push path can fail while the service still answers. The two surfaces require separate canaries.

RECONFIRM reinforces this boundary. When a Discovery Proxy is involved and a client encounters an apparently stale target, RECONFIRM can cause fresh multicast queries. If the disputed record is no longer valid, later PUSH messages can remove it for interested clients. For other kinds of DNS server, the action is undefined: a NOERROR response need not mean the server performed a new verification. Treating RECONFIRM as a universal truth oracle would assign it authority the specification withholds.

Resumption, replay and recovery

TLS resumption is attractive because reconnecting a long-lived service can otherwise add latency and computational cost. But the resumed cryptographic relationship and the new application session have separate lifecycles. RFC 8765 is explicit: after the TLS connection closes, the DNS Push server has no subscription state when TLS resumes. The client must recreate it.

SUBSCRIBE may also be sent as TLS early data. The latency benefit carries an evidentiary limit. Early data is not forward secret and has no general non-replay guarantee between connections. A duplicated request may create short-lived extra state. A server may rate-limit such requests. Therefore a 0-RTT SUBSCRIBE cannot serve as an exactly-once authorization receipt. The client needs the accepted response on the actual session before it calls the subscription live.

Recovery should produce an observable sequence: old session ended; record aging resumed; new TCP/TLS connection established; full or resumed handshake identified; new DSO session established; every desired NAME/TYPE/CLASS request sent; each response classified; new initial state received where non-empty; only then did non-aging status return. If subscription establishment fails, conventional polling is a fallback, not an invisible substitute. RFC 8765 recommends a bounded polling interval and a fresh attempt to restore Push before each poll.

The evidence chain for “current”

A useful audit row starts before the first PUSH. It records the discovery answer and TTL, resolver and vantage, DNSSEC status, target name, SNI, peer address and authentication result. It then records the TCP connection, TLS handshake type, DSO session start, Keepalive values and any Retry Delay. Each subscription needs its MESSAGE ID, canonical NAME, TYPE, CLASS, raw request, response RCODE and acceptance time.

For the change stream, retain the ordered message bytes or a privacy-safe digest, the active subscription matched, add/remove form, record identity, stored TTL and cache decision. Preserve the moment TTL aging stops and resumes. Record UNSUBSCRIBE, orderly TLS close, TCP FIN, timeout, abort or path failure as different causes. A single connected=true field destroys the distinctions the protocol created.

The application consequence closes the chain. A direct authoritative query can show what the DNS authority currently serves. A service probe can show whether the endpoint works. Neither substitutes for the other, and neither proves that the client’s cache arrived at its state through a complete subscription history. The final verdict should say exactly which claim it supports: channel authenticated, subscription active, RRset current under Push, authoritative answer observed, or service reachable.

Thin coordination, local responsibility

Heng Lu’s minimum-initial-specification framework fits DNS Push unusually well. The shared layer is narrow but real: DSO message roles, subscription identity, add/remove encodings, timers, transport security and closure semantics. It lets unlike implementations coordinate without placing admission budgets, user-interface policy, telemetry retention or endpoint-health judgment into a universal authority.

Localized future decision belongs to the operators who bear the cost. A server may ration subscriptions during load. A client may subscribe only while a screen or workflow needs live data. A privacy team may retain event digests rather than raw names. An SRE team may require a fresh initial state before routing work after reconnection. Voluntary adoption means an RFC and an IANA code point do not make any of these controls real; deployment, test vectors and observed wire behavior do.

Running-code primacy is not permission to trust whatever the program did. It means the implementation and its consequences outrank the diagram. If code leaves a TTL frozen after the session that justified the freeze has gone, the code has supplied the evidence of a governance failure. The remedy is to narrow the authority again: a publisher owns the RRset, a server accepts one bounded subscription, a session carries its changes, a cache maintains state while that duty exists, and an application separately decides whether a current name is a usable service.

Sources