Summary

  • draft-hardaker-dnsop-nothing-new-00 proposes combining truncation with an NN signal and a LARGE RR identifier so a resolver may retain an apparently unchanged large RRset instead of retrieving it again.
  • The proposal is an individual, explicitly incomplete and non-implementable Internet-Draft. Datatracker records no stream or intended RFC status while its header says Standards Track.
  • NN is a claim by one responding authority. A 16-bit identifier is unique only within the represented data's signature lifetime. A still-valid RRSIG authenticates bounded data, not global convergence or present operator intent.
  • Safe use needs separate records for hint provenance, identifier-to-RRset lineage, signature validity, authoritative generation, transport choice, cache action and client result. “Not refetched” is not “proved current.”

The optimization withholds its own counter-evidence

Large DNS answers have a cost. If a response does not fit the available UDP envelope, the Truncation bit directs the resolver toward a fuller exchange, commonly over TCP. Post-quantum keys and signatures could make that pressure worse, although revision 00 offers no deployment forecast or measured saving.

The draft asks whether repeated transfer is necessary when the resolver already holds the same large RRset. Its NN bit would accompany TC and tell a supporting resolver that the requested record has not changed recently. A proposed LARGE RR would carry a compact identifier for the server's current version. If that identifier matches the resolver's cached version, the resolver could avoid asking for the large data again.

The attraction is clear. The evidentiary problem is equally clear: the optimization makes its decision before acquiring the object that could show the hint was wrong. That does not make the proposal unsound. It makes provenance, scope and failure tests part of the mechanism rather than optional telemetry.

“Nothing new” must therefore retain a speaker and a comparison. Which authoritative instance answered? Which owner name, type and class did it compare? Which generation did that instance believe current? At what time, under which view, and against which identifier rule? Remove those qualifiers and a bounded response becomes a claim about the zone, the authority set or even the Internet.

One authority is not the authority set

Authoritative DNS is deliberately distributed. Primaries and secondaries can expose different generations during transfer, loading or failure. Anycast can place multiple instances behind one address. Views can make different data correct for different clients. An answer is evidence from the server and path that produced it, not a census of every peer.

This is the first trap in the opening sequence. The nearest authority sees generation A and emits NN. A different authority has already moved to generation B. The resolver's cache also contains A. The identifier match is locally coherent: the respondent and cache agree. It is still insufficient to prove convergence or present intent.

An operational design needs a denominator. If the decision is safe after one response, say that explicitly and accept the consequence. If a key rollover, delegation change or policy transition requires stronger evidence, sample the relevant authority set and record the membership used. “All” is not a feeling; it is a named set at a time.

The same discipline applies after the optimization. A client response served from cache proves that one resolver used one generation. It does not prove that other resolvers, other network paths or the application obtained the same state. The receipt chain continues beyond the avoided transfer.

Sixteen bits are not a universal version number

The proposed LARGE identifier is 16 bits. The draft requires it to remain unique within the signature lifetime of the represented data. That is a bounded design rule, not a globally unique version namespace.

The distinction matters when identifiers wrap, are generated differently across authorities, survive a configuration restore or are joined to cache records without their lineage. Equal numbers can support an equality decision only when the operator can show that they belong to the same owner, type, class, generation scheme and non-collision window.

The draft allows hashes, incremental counters, carefully constructed timestamps or values derived from the record. Each creates different evidence. A truncated hash has collision properties. A counter needs durable state and coordinated issuance. A timestamp needs resolution and restart rules. A value derived from content needs canonical construction. The protocol number alone does not disclose which contract produced it.

That is why the SOA serial is a poor automatic substitute. A highly dynamic zone can change its SOA repeatedly while a large DNSKEY RRset stays fixed. Conversely, an implementation mistake could reuse a zone-level signal while the relevant RRset changes. Zone version and RRset version answer different questions.

A minimum receipt should retain the identifier generation profile, authority identity, RRset hash, RRSIG inception and expiration, and the cache record to which the identifier was attached. Without the hash and lineage, an audit can show that two small numbers matched but not that the two large objects did.

A valid signature answers a narrower question

DNSSEC is essential here because the draft's most sensitive use is avoiding retrieval of signed DNSKEY or RRSIG material. Yet “signature valid” is often stretched into “state current.” They are not synonyms.

An RRSIG authenticates a particular RRset under the DNSSEC chain and its inception/expiration interval. It does not report whether the operator has since intended a replacement, whether every authority has loaded that replacement, whether a hidden-view rule changed, or whether the resolver selected the right cached lineage.

Revision 00 makes the boundary harder because the small signal may be unsigned. It says the LARGE RR's signature must be included if it fits and should be omitted if it does not. The security section openly recognizes the concern: unsigned data may decide whether signed data is retrieved.

The draft's response is comparative. An on-path party able to spoof the signal can already drop packets and push the resolver toward stale serving after a timeout. NN may make the stale path faster rather than create the attacker's power from nothing. That is a useful argument about marginal capability. It is not authentication of the signal, proof of benign intent or proof that every stale-use policy is equivalent.

The log must preserve whether NN and LARGE were authenticated, which validation path applied, and what the resolver would have done without them. Otherwise operators cannot distinguish a valid optimization from an accelerated fallback induced by an untrusted statement.

Truncation is not transport failure

TC says the available response was truncated. It does not say TCP is unavailable, that a reliable exchange would fail, or that the omitted data contains no new evidence. RFC 7766 treats TCP support as a requirement for full DNS implementations. Avoiding an exchange can be efficient; it is not the same as proving the exchange has no value.

The resolver therefore owns a policy choice. It can accept the hint, compare the identifier, evaluate signature time, consider its cache state and decide whether to refetch. That decision should remain visible as an action with inputs, not disappear into a metric named fresh=true.

The policy may vary by RR type and transition. Reusing an unchanged bulky record during an ordinary query is different from suppressing acquisition during a trust-anchor change, DNSKEY rollover, incident recovery or authority disagreement. The cost of a false match is contextual.

Reliable-transport fallback also supplies running-code evidence. A test harness can deliberately create mismatched authorities, make the hint unsigned, reuse an identifier, expire the cached RRSIG and leave TCP fully functional. The correct result is not one universal answer. It is that the implementation follows its declared policy and retains enough evidence to explain the choice.

Stale service and freshness are different contracts

RFC 8767 permits serving stale data under bounded operational rules when authoritative refresh fails. That capability is relevant to the draft's security argument. It does not erase the difference between “this is stale but serviceable under policy” and “this has been proved current.”

NN could move a resolver into continued cache use before the timeout that otherwise exposes reachability failure. That may improve latency and reduce load. It also changes which evidence exists. A timeout documents unsuccessful refresh. An NN response documents a server's claim that refresh is unnecessary. Those are different events even if both lead to the same cached bytes.

Dashboards should preserve the distinction. Useful states include cache-valid-by-TTL, cache-valid-by-signature, retained-after-authenticated-NN, retained-after-unauthenticated-NN, served-stale-after-refresh-failure and refetched-over-reliable-transport. Collapsing them into “cache hit” destroys the incident story.

The client outcome is another layer. A resolver may serve cryptographically valid old DNSKEY data while an application still succeeds, or serve the operator's latest generation while another dependency fails. Service continuity does not prove the freshness decision was correct; a correct freshness decision does not guarantee service.

The document itself is not a deployment receipt

At the evidence freeze, Datatracker described revision 00 as an active individual Internet-Draft. Anyone may submit such a draft; the page expressly says it has no IETF endorsement or formal standing. There is no stream, responsible Area Director, telechat or Datatracker intended status. The document header says Standards Track, so the two source surfaces disagree.

The text is more candid still. It says the proposal is very much a work in progress, not fully specified and not implementable. IANA considerations are TBD. The DNSSEC section flags unwritten ideas about large signatures associated with small records. Alternatives for record format, placement and resolver-to-parent signalling remain discussion notes.

Those facts limit every conclusion. The Article can analyze the control boundary suggested by NN and LARGE. It cannot claim a final bit assignment, RR type, interoperability contract, production resolver behavior, authoritative support, bandwidth improvement or PQC deployment.

This uncertainty is not a reason to ignore the draft. Early proposals reveal where future systems may compress evidence. The right response is to define the receipts before an optimization becomes an opaque green status.

A receipt graph makes the optimization auditable

A defensible record begins with the query: owner, type, class, resolver capability and cache generation. It adds the responding authority, path and view; TC and NN values; LARGE owner and identifier; signature presence and validation; and the authority's generation profile.

The comparison record binds the received identifier to the cached identifier, exact RRset hash, RRSIG interval and identifier-uniqueness window. The policy record says whether refetch was suppressed, why, and which risk class applied. If transport is attempted, the result remains separate. If cache state is served, the client response and later application observation remain separate again.

This graph makes uncertainty useful. A responder can truthfully say “I observed NN from authority X, matched identifier Y to cached RRset hash Z, validated its signature until T, and therefore skipped one retrieval under policy P.” That statement is narrower than “DNS was current.” It is also far more actionable.

Leadership then has a real decision: where may a low-cost hint authorize non-acquisition of higher-cost evidence? For routine traffic, the threshold may favor efficiency. For irreversible trust or delegation transitions, it may require multi-authority observation, authenticated hints or a full refetch.

The draft's idea is valuable precisely because it exposes that trade. A small signal can reduce a large transfer. It should not reduce the number of reality layers recorded with it. The disciplined conclusion is simple: the server said nothing had changed; the resolver decided not to look again. Current state still needs its own proof.

Sources