Summary

  • draft-ietf-dnsop-dry-run-dnssec-01 proposes a deliberately intermediate state: supporting resolvers validate a signed zone, report faults, but fall back to an insecure answer for ordinary clients when the dry-run validation is bogus.
  • A proposed NOERROR report proves that one participating resolver observed a successful check. It does not reveal the size or composition of the silent resolver population, and RFC 9567 reporting is dampened and unauthenticated.
  • Before a parent replaces the dry-run DS with a real DS, the operator needs a graduation receipt that records the observed cohort, test coverage, report limits, parent state and residual unknowns. This is Daniel Kade’s governance recommendation, not IETF text.

DNSSEC adoption has an unforgiving last step. Before the parent publishes a DS record, a signed child can be inspected without creating a chain of trust. After the real DS is visible, a validating resolver may turn a signing mistake into SERVFAIL. The configuration change is small. The service consequence is distributed among parents, resolvers, caches and clients the zone operator does not control.

The active DNSOP draft called dry-run DNSSEC tries to create a useful middle. Revision 01, published on 21 June 2026, is a working-group Internet-Draft whose text says Standards Track. It is not an RFC, an approved standard or evidence of deployment. Its proposed code points remain unfinished.

The method uses the behavior that RFC 6840 assigns to an unknown DS digest algorithm. A validator disregards an authenticated DS record whose digest algorithm it cannot use. If no supported authentication path remains, it treats the child as though it were unsigned. The draft would reserve a high-bit counterpart for each ordinary digest algorithm. A parent publishes only those dry-run DS values for the child.

Two resolver populations then see different things. A resolver that knows nothing about the proposal ignores the unfamiliar digest and resolves the child as insecure. A supporting resolver recognises the signal, validates the child and can report what it found. If validation succeeds, it can return authentic data. If validation is bogus, it withholds the ordinary DNSSEC failure from a regular client and returns the insecure answer that would have existed without the dry-run DS.

This is not partial DNSSEC protection. The draft says the dry-run delegation should not be considered DNSSEC signed. Its security section is sharper: falling back to insecure disables the data-integrity guarantee and can allow forged answers to affect the zone. That exposure is the price of testing a production path without breaking ordinary resolution. It is why dry-run must remain an intermediate state rather than a comforting label left in the parent indefinitely.

Failure can be visible without being enforced

The test separates observation from consequence. Supporting resolvers perform the validation work. Extended DNS Errors, defined by RFC 8914, identify the class of fault. DNS Error Reporting, standardised in RFC 9567, carries the error toward a monitoring-agent domain that the authoritative server advertised.

The report query encodes the faulty name, query type and EDE code in DNS labels. This gives the zone operator evidence that a real validation path encountered a problem. It is more valuable than a laboratory check because it includes deployed resolvers, real caches and ordinary query patterns.

It is also a bounded signal. RFC 9567 does not authenticate the reporting resolver to the monitoring agent. TCP or DNS Cookies make source-address spoofing harder, but an apparent source is not an institutional identity. Reports sent over UDP may be false. Error reporting can disclose a resolver’s local mistakes, including stale trust anchors, and the RFC recommends query-name minimisation for privacy.

Caching deliberately reduces traffic. Once a resolver has contacted the monitoring agent, later reports may be dampened. If the constructed QNAME would exceed the DNS limit, the report is not sent. A monitoring dashboard therefore records a shaped sample, not a raw count of every failing query.

These qualifications do not make reporting useless. They define what it proves. A report can establish that some reporting path observed a named error at some time. It cannot by itself establish how many end users were affected, how many successful queries occurred, or whether the source represents a distinct resolver population.

Silence needed a positive signal

Dry-run creates a familiar measurement trap. An empty error log might mean the signed zone is correct. It might also mean no supporting resolver queried it, the report was dampened, the monitoring agent was unreachable, the QNAME was too long, or the resolver did not implement reporting.

Revision 01 addresses one part of that ambiguity with a proposed NOERROR Extended DNS Error code. When a supporting resolver validates the dry-run zone successfully, it can send a positive report. The zone apex is used in the query name, allowing the monitoring agent to distinguish zones while limiting the signal to the applicable zone-level presence. The same caching machinery dampens repeated NOERROR reports.

This changes the meaning of a quiet graph. A successful report proves that one participant was present. A mixture of NOERROR and error reports can describe the results inside the observed cohort. But the mechanism still has no external denominator. Unsupported resolvers are silent by design because they treat the unfamiliar digest algorithm as an unsigned delegation. Supporting resolvers that never receive a query are also silent. A resolver’s one positive report does not enumerate all clients behind it or all later cache states.

The draft itself points to DMARC reporting, the root key sentinel in RFC 8509 and trust-anchor signaling in RFC 8145. Their lesson is not that small samples become universal. It is that a current and strategically placed observer set may supply substantial operational evidence. The governance mistake would be to erase the word “set.”

Wet-Run changes who accepts the failure

Ordinary clients in the proposed dry-run mode receive the fail-open answer. That makes service-safe observation possible, but it does not test how an application behaves when DNSSEC enforcement actually rejects the response.

The draft therefore proposes a Wet-Run EDNS option. A client can explicitly ask a supporting resolver to expose the actual dry-run validation error. The resolver must retain the dry-run status beside the ordinary cached status and echo the option when returning the failure. A resolver that does not understand the option ignores it.

This is a separate consent and coverage surface. A Wet-Run probe can show that a chosen client, network and resolver path receives the expected failure semantics. It says nothing about clients that did not opt in. A resolver-side NOERROR report and a client-side Wet-Run result answer different questions; collapsing them into “the test passed” loses the identity of the tested path.

Negative answers need another probe. RFC 8198 permits validators to synthesise answers from cached NSEC or NSEC3 proofs. That efficiency can conceal a faulty negative proof during a rehearsal because the resolver may answer without contacting the authoritative server. Revision 01 tells a dry-run resolver to pause that synthesis, issue an explicit query, compare the answer and report a discrepancy with a proposed error code. Readiness therefore depends on more than successful positive lookups.

The parent holds the graduation switch

Dry-run is not installed solely by the child signer. The parent must publish the special DS state. If the parent accepts DS records, the child provides the dry-run DS. If the parent normally generates DS from DNSKEY, it needs an interface flag or logic that inspects an accompanying CDS. CDNSKEY alone cannot carry the proposed dry-run distinction; the draft advises the child to publish both CDS and CDNSKEY.

Graduation is another parent action. The draft describes the turn-key commitment as replacing the dry-run DS with the real DS RRset. That phrase is operationally elegant but evidentially dense. A submitted change is not an accepted change; acceptance is not publication; one observed parent response is not universal cache expiry.

The replacement also changes the contract with resolvers. During rehearsal, a supporting resolver can report a bogus state and still give the ordinary client an insecure answer. Under a real, supported DS, the same fault becomes a validation failure. A dashboard threshold is therefore not merely a monitoring preference. It helps authorize when an external population begins enforcing the child’s claims.

The signal still needs a registry home

Revision 01 proposes using the most significant bit of the DS digest-algorithm value and asks IANA to identify 128 through 255 as Dry-run DNSSEC. The live IANA Digest Algorithms registry does not presently contain that assignment. Updated on 13 January 2026, it lists 128–252 as Reserved, 253–254 as Private Use and 255 as Unassigned, with RFC 9904 as a reference.

That is a current-state discrepancy, not proof of rejection or impossibility. Internet-Drafts routinely contain proposed IANA actions that occur only if the work advances. The rows and recommendation columns would have to be reconciled explicitly. Until then, an experiment cannot treat the draft’s requested block as a public allocation.

RFC 9904 adds a second useful distinction. The registry now records recommendations for use separately from recommendations for implementation. Software capability and operator deployment are not the same fact. Dry-run evidence has the same shape: a resolver can implement the feature without observing this zone; a zone can request the feature without its parent supporting it; a parent can publish the signal without proving that representative clients traverse supporting resolvers.

A graduation receipt

A credible graduation record should begin with exact artifacts: the signed-zone fingerprint, DNSKEY set, proposed dry-run DS set, parent submission and the observed parent publication. It should name the observation window and the authoritative vantage points used to distinguish acceptance from visibility.

The receipt should then describe the cohort rather than imply a census. Which reporting resolvers were independently identifiable? Which were merely source addresses with TCP or Cookie confidence? How many NOERROR and error signals survived dampening? Which error codes appeared, on which names and query types, and what corrections followed? Aggregation can preserve privacy while retaining the evidence needed for a decision.

Client testing belongs in its own section: Wet-Run probes by network, resolver and application class; ordinary fallbacks; positive and negative answers; NSEC/NSEC3 explicit-query checks; cache horizons; and cases the test could not reach. The current IANA registry snapshot and implemented experimental code points should be recorded without presenting them as assigned.

Finally, the receipt should name who may authorize the real DS, what minimum evidence they accepted, which residual unknowns remain, and who owns rollback. Actual submission, parent acceptance, observed publication and post-change validation should be separate timestamps.

No receipt can prove every resolver. Its purpose is to stop a selected sample from silently becoming “the Internet” in the decision record. A bounded claim can still support action. It simply makes the uncertainty reviewable by the people who will bear the consequences.

Sources

  1. dry-run DNSSEC — revision 01
  2. Datatracker record for dry-run DNSSEC
  3. dry-run DNSSEC document history
  4. DNSOP active documents
  5. DNSOP charter
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — DNSSEC Implementation Notes
  9. RFC 8198 — Aggressive Use of DNSSEC-Validated Cache
  10. RFC 8509 — Root Key Trust Anchor Sentinel
  11. RFC 8145 — Signaling Trust Anchor Knowledge
  12. RFC 9904 — DNSSEC Cryptographic Algorithm Recommendation Update Process
  13. IANA DS Digest Algorithms registry