Summary

  • Revision 03 of the DNSOP GREASE draft proposes exercising DNS fields with unallocated values so implementations and middleboxes do not hard-code today’s assignments. It is an active Internet-Draft, not an RFC, allocation or deployment mandate.
  • Failure handling has a real price: a sequential retry can add latency, a parallel regular query can preserve response time while adding traffic, and responder-initiated greasing can cause downstream failure that the responder cannot observe.
  • Before greasing becomes an implementation default, a time-bounded experiment charter should record the extension point, value algorithm, traffic and cost ceilings, telemetry, fingerprinting controls, end date, abort conditions and named rollback owner. This is Daniel Kade’s governance proposal, not IETF text.

Protocol extension points rarely fail on the day they are designed. They fail years later, after software has learned that only the values it has already seen are possible. An implementation rejects an unfamiliar number even though the specification told it to ignore that number. A middlebox rewrites a field it does not understand. The installed base appears healthy until somebody tries to use the space that was deliberately left open.

GREASE reverses the timing. Instead of waiting for a real extension to discover that the joint has rusted shut, an implementation sends values that carry no useful protocol meaning and are supposed to be ignored. Intolerance becomes visible while the value is still expendable. RFC 8701 established that pattern for TLS, reserving sparse values that clients can advertise. A correct server continues; a defective one reveals itself before a future capability depends on the path.

The active DNSOP draft Greasing Protocol Extension Points in the DNS asks how that discipline might fit DNS. Revision 03 was published on 6 July 2026 and expires on 7 January 2027. It is a Working Group Internet-Draft with unfinished decisions. It is not an RFC, proof of consensus on every detail or permission to enable a particular experiment across production traffic.

That status matters because the draft is most candid where governance is still needed. It identifies useful targets, retry choices and telemetry. It also leaves reserved ranges, detailed behavior and IANA actions unresolved. The gap between those two states is exactly where an attractive implementation feature can become a default before its operational bargain has been accepted.

One technique, several different wire contracts

DNS does not contain one generic extension bucket. Revision 03 lists seven possible surfaces: the remaining DNS header flag, Opcode, EDNS version, EDNS header flags, Class, Resource Record Type and EDNS option code. Their spaces differ dramatically. A single flag has almost no room. Sixteen-bit types and options have tens of thousands of presently unallocated values. Some spaces have internal structure and some values already carry reserved, private-use or experimental semantics.

The list is deliberately selective. Unknown values in these elements are expected to be tolerated transparently by a conforming receiver. RCODE and Extended RCODE are excluded because they are responder status. Changing them would change the querier’s understanding of the answer, not merely test whether an optional value is ignored.

That boundary prevents the easy but false description of GREASE as “sending malformed DNS.” The proposed values are meaningful to the experiment precisely because they are supposed to have no useful meaning to the protocol. If the receiving system ignores them and interoperates, the extension joint remains mobile. If it fails, the outcome identifies an intolerance that can obstruct future change.

It does not follow that every field should be exercised in the same way. An unknown EDNS option also carries data, so the option’s payload needs its own generation rule. A new query type can require construction of another query rather than merely attaching an ignored value. A one-bit flag cannot support the same reservation strategy as a 16-bit registry. The unit of authorization must therefore be an exact extension point and test behavior, not a broad switch labelled DNS GREASE.

The production answer and the experiment can take different paths

Revision 03 sketches two ways for a resolver to handle intolerance. The first is sequential. A resolver sends a greased query; if it fails, the resolver generally tries again without the unallocated extension. That preserves compatibility, but the user may pay for the failed first attempt in added latency. The retry can also mask the defect in ordinary service metrics unless the first outcome is retained separately.

The second is parallel. The resolver sends a regular query alongside a greased query. It uses the regular response to serve resolution and records the greased result only for telemetry. The user need not wait for the experiment to fail, but the authoritative side receives an extra query. At a sufficiently low sampling rate that cost may be modest. It remains a cost allocated to infrastructure that did not necessarily choose the experiment.

The difference is not an implementation detail. Sequential mode spends a latency budget. Parallel mode spends a query-volume and processing budget. Both consume logging, analysis and incident-response attention. A charter that merely says “sample one in a thousand” cannot show which budget was authorized.

Even the fraction is unfinished. The draft says only a sampled portion of traffic is necessary and offers “perhaps 1 in 1000 requests?” as a tentative phrase. The question mark belongs in the record. It is not a standard safety threshold, a capacity calculation or evidence that the same ratio suits a small resolver, a global public service and an enterprise deployment.

A useful test budget begins with traffic classes. High-consequence names, fragile authoritative systems, incident periods or latency-sensitive clients may need exclusion. Operators should distinguish a percentage from a hard ceiling: a fraction can still create a large burst on a high-volume resolver. Parallel queries need a maximum additional rate by destination and globally. Sequential tests need latency and failure ceilings. Both need circuit breakers that work without waiting for a software release.

The two directions are not symmetrical

Most of the DNS draft concerns greasing initiated by a resolver or querier. The initiator observes whether a response arrives and can compare the greased result with a normal retry or parallel query. That is already imperfect evidence, but at least the actor running the experiment can see a proximal outcome.

A DNS responder can also insert an unexpected flag, option or version into an answer. This can help a targeted measurement. It also moves the blind spot. The responder may not know whether the querier accepted the answer, retried another server, failed quietly or caused an outage for an application downstream. Ordinary authoritative logs cannot reconstruct the last step.

Revision 03 therefore says responder-initiated greasing should be disabled by default. That sentence should survive every product wrapper around the draft. A vendor toggle named “GREASE support” must not merge resolver and responder behavior. An operator consenting to outbound resolver tests has not consented to modify answers sent by its authoritative service.

Responder experiments need a stricter charter: named test zones or traffic classes, an external client-observation path, lower ceilings, rapid disablement and proof that ordinary answers remain available. A server-side test whose owner cannot observe downstream failure has no defensible automatic promotion path.

Random values and reserved values move different risks

The draft has not resolved whether DNS should reserve ranges for GREASE or select randomly from currently unallocated space. Each approach buys one protection by accepting another exposure.

Reserved values are easier to recognize in traces and cannot later be assigned a genuine meaning while they remain reserved. They can also become their own hard-coded exception. A receiver may learn to ignore the known GREASE range while continuing to reject every other unknown value. The test then turns green without proving the more general tolerance it was meant to exercise.

Random selection from the unallocated space reaches beyond a recognizable pattern. It also risks choosing a value that IANA later assigns to a real extension. Software trained to ignore that number could continue ignoring it after the number acquires meaning. The draft suggests a preconfigured or configurable end-of-test date to retire an operation before later allocations collide with it.

This is not one decision for the whole DNS. Some fields are too small to spare a useful range. Some type spaces are structured, so one block may not exercise each relevant class. The IANA DNS Parameters registry gives these fields separate tables and allocation procedures. At the research cutoff, it did not supply the unresolved DNS-wide GREASE reservations contemplated by the draft.

A registry snapshot in the charter does two things. It proves what the initiator believed to be unallocated at authorization time. It also creates a comparison target. If a relevant assignment changes, the test should retire or recalculate automatically rather than relying on an operator to remember that a once-empty number now carries public meaning.

An end date is therefore not project-management decoration. It is part of the wire-safety design. “Run until disabled” silently transfers future registry monitoring to whoever happens to own the implementation years later. Automatic expiration makes renewal an affirmative decision based on a new registry snapshot and new operational evidence.

Telemetry must be able to justify the disturbance

The purpose of GREASE is observation. If the outcome is not measured well enough to drive repair, the operator has incurred failure without receiving the public benefit.

The general protocol-greasing draft describes a narrow balance. Send values too rarely and resulting errors disappear into baseline noise. Send them too consistently and receivers can special-case the pattern. DNS adds another difficulty: retries can make the user-visible request look successful even when the first exchange failed. Service success and experiment success are therefore separate measures.

The minimum event should record the extension point, generated value class, selection version, time, query direction, retry or parallel branch, proximal response, elapsed time and whether the ordinary answer was served. It should preserve enough destination grouping to find a defective implementation without turning every queried name or resolver path into an indefinite surveillance record.

Failure labels need restraint. A timeout does not identify a middlebox. A FORMERR does not prove which component rejected the message. A normal retry does not prove that the original path would have been safe for a future real extension. The evidence can establish a reproducible difference between greased and control traffic; attribution requires more work.

Privacy also belongs in the design, not in a later notice. Revision 03 warns that non-random choices may let observers fingerprint resolver implementations. The broader greasing draft notes that parameter variability can affect fingerprinting. A stable value, position or cadence may make failures easier to reproduce while also creating a recognizable product signature. TLS guidance similarly identifies a trade-off between diversity and determinism: per-connection variation can let retries mask intermittent bugs, while release-stable behavior exercises fewer cases more consistently.

The charter should record that trade rather than promise both perfect unpredictability and perfect reproducibility. It can rotate behavior inside a bounded epoch, publish the algorithm class without exposing a per-deployment secret, aggregate telemetry, minimize names and retain raw events only long enough to diagnose a specific failure.

Fallback can preserve service while weakening the lesson

DNS implementations have long used fallback to survive peers that reject extensions. That is operationally attractive: turn off the unfamiliar feature and try again. It also teaches the ecosystem that refusing change carries no lasting consequence.

The security problem is sharper when the disabled extension protects something important. Revision 03 warns that an attacker may be able to induce the path that silently disables a security feature. GREASE is intended to reveal these compatibility failures so implementers can eventually remove unsafe fallback for future extensions.

But the act of discovering the problem does not automatically authorize the cure. An operator may be able to isolate a broken authoritative service, file an implementation defect or reduce traffic to it. It may not control the middlebox or software release that caused intolerance. Removing fallback immediately could transfer a maintenance dispute into user-visible unavailability.

The charter should separate three states: observe intolerance; contain its immediate service effect; decide whether and when fallback can be withdrawn. The first is measurement. The second is incident management. The third is a compatibility-policy decision with different stakeholders and a larger blast radius.

A GREASE experiment charter

The charter begins with authority. It names the resolver or responder operator authorizing the test, the vendor or team implementing it, the owner able to stop it and the person responsible for evaluating results. Shipping code is not evidence that every operator has accepted the same service trade-off.

Next comes the exact wire object: extension point, candidate value set, selection algorithm, payload-generation rule where applicable, query direction and implementation version. The current IANA registry snapshot is hashed or archived beside it. Reserved, private-use, experimental and simply unallocated values must not be collapsed into one bucket.

Traffic scope follows. The charter records eligible and excluded query classes, percentage and hard rate ceiling, destination caps, rollout stages and observation window. It states whether the control is a later retry or a parallel regular query. It assigns separate budgets for added latency, timeouts, duplicate traffic, CPU, logs and operational alerts.

The telemetry section identifies what a success and failure mean. It preserves comparison with control traffic, sets retention and sharing boundaries, limits query-name collection, handles resolver fingerprinting and prevents an ambiguous timeout from being published as an accusation against a named operator.

Finally, the charter defines time. Each test has a start, default end date, renewal owner, current-registry recheck, per-test kill switch and automatic collision retirement. Abort conditions can include a user-visible failure increase, latency regression, destination overload, telemetry loss or inability to distinguish experimental traffic from normal traffic. The rollback path should be exercised before the sample expands.

The result is not a permission slip for careless deployment. It is a compact account of the exchange: today’s users and operators carry a bounded test so tomorrow’s DNS can still change. If that exchange cannot be stated, measured and stopped, it is not ready to become a default.

Sources

  1. Greasing Protocol Extension Points in the DNS — revision 03
  2. Datatracker record for the DNS GREASE draft
  3. DNS GREASE document history
  4. DNSOP active documents
  5. DNSOP charter
  6. RFC 8701 — GREASE for TLS
  7. RFC 6891 — Extension Mechanisms for DNS
  8. Maintaining Protocols Using Grease and Variability — revision 06
  9. IANA Domain Name System Parameters