Summary

  • Revision 02 of Automating DNS Delegation Management via DDNS is active DNSOP work, not an RFC or a deployment report. Its Datatracker metadata and header disagree on intended status, and both must remain visible.
  • The proposal lets a child discover a parent UPDATE Receiver through DSYNC and request NS, glue or DS changes with a SIG(0)-signed DNS UPDATE. Authentication is followed by parent policy and CDS/CSYNC-style correctness checks.
  • NOERROR confirms that the update was received and accepted. The text says publication in the parent is expected at some future time, so it cannot prove authoritative publication, secondary convergence, cache passage or application outcome.
  • Safe automation needs separate receipts for key bootstrap, scoped authorization, receiver acceptance, provisioning, public parent state and observed result. Withdrawal of an old path belongs after the last relevant receipt, not after the first green response.

The protocol makes a promise in the future tense

The most important sentence in revision 02 is easy to flatten in an implementation. A NOERROR response confirms receipt and acceptance; the requested parent data should be expected to be published later. That is a useful acknowledgement. It is also deliberately narrower than “the delegation changed.”

Between those claims sits the parent's provisioning system. The receiver may write a database, call an API, update a text-backed zone or hand work to another control plane. The primary must build and publish a new generation. Secondaries must acquire it. Only then can authoritative observation show the requested NS, glue or DS material. Resolver caches introduce another exposure after publication.

A dashboard that maps NOERROR directly to “complete” deletes the most important edge. It turns a message about acceptance into a statement about public state. During normal operation the shortcut may appear harmless. During offboarding, key rollover or a nameserver replacement it can authorize removal of the only path still serving the old delegation.

The safer status model uses verbs that belong to their evidence: submitted, authenticated, policy-accepted, queued, provisioned, published at primary, converged across parent authority, cache horizon passed and independently observed. Those states can move quickly. They still must not be synonyms.

Discovery is not mutation authority

The child first needs to find the appropriate receiver. RFC 9859 supplies DSYNC, which points to a synchronization endpoint. The record answers where a request can go and which scheme applies. It does not grant every discoverer permission to change a delegation.

Revision 02 uses ordinary RFC 2136 DNS UPDATE and protects it with SIG(0). By default, the trusted key name must exactly match the child name whose delegation is being changed. That name-scoping rule prevents one child key from changing a sibling. A parent can implement a broader registrar-operated authority, but then the parent owns the added authorization responsibility.

Signature verification is not the last policy step. The receiver applies the correctness checks it would use for CDS/CDNSKEY or CSYNC, and it retains its own approval policy, audit trail and provisioning integration. The draft calls this a shift of complexity rather than its elimination. Moving detection to the child reduces scanning load; it does not transfer final parent authority.

The transition ledger should therefore preserve the discovered DSYNC target, transport, receiver identity, child name, requested RRsets, signature key, replay window, policy version and decision. Without those fields, a successful response cannot later show which principal asked which parent component to do what.

Possession becomes authority only after bootstrap closes

Initial SIG(0) bootstrap is a separate state machine. A child can present a KEY record in a self-signed update. The self-signature proves control of the candidate private key. It does not prove that the holder is authorized to manage the child delegation.

The receiver marks the key known but not trusted and validates it through an allowed method. A signed child zone can publish the KEY at its apex. An unsigned child may use a signed nameserver zone under the specified signal name. Manual verification remains possible. A weaker unsigned path follows the current authoritative-server operator rather than the registrant.

This distinction changes incident handling. BADKEY says the receiver lacks the key needed for verification. It does not by itself say whether a presented key is awaiting validation or has failed it. The proposed Extended DNS Error details help, but they do not replace the bootstrap record. Operators need a durable mapping from presented, known, validated and trusted to the evidence that caused each transition.

Replacement is where the ledger prevents an irreversible error. A self-signed rebootstrap request can ask to delete old keys and add a new one, but the receiver must keep the previously trusted key until the replacement validates. Otherwise any attacker could present an unusable candidate and evict the working authorization before failing the proof.

The response itself has a trust chain

The child signs the request, but that does not automatically authenticate the reply. The UPDATE Receiver can maintain its own SIG(0) key and sign responses. The child must acquire and validate that key, commonly through DNSSEC on the parent side or through manual bootstrap when the parent is unsigned.

Without that reverse trust, an injected reply can falsely report an unknown key and trigger unnecessary rebootstrap. The draft treats this chiefly as disruption rather than unauthorized mutation: a forged response cannot make the parent accept an invalid change. It can still make the child abandon a valid path, rotate credentials or flood an already degraded workflow.

Every automation record should say whether the response signature was present, which receiver key verified it, how that key was trusted and what response semantics followed. “Server replied” is weaker than “the expected receiver made an authenticated statement.” Even the stronger statement remains an acceptance receipt, not an observation of the parent zone.

The two-way bootstrap also changes ownership. Child operations controls the request key; parent operations controls the receiver key; DNSSEC or an out-of-band process anchors each direction. No single successful signature proves that every adjacent authority is current.

Silence cannot tell whether the mutation happened

No response creates a classic distributed-systems ambiguity. The update might have been lost before reaching the receiver. It might have been accepted and the response lost. The receiver might be unavailable. From silence alone, the sender cannot choose among those states.

Revision 02 recommends a baseline timeout, exponential backoff and a bounded number of retries. Those controls reduce load and give transient loss a chance to clear. They do not convert a retry count into a publication verdict.

Because DNS UPDATE expresses a desired state, replaying the same coherent RRset can be operationally manageable, but the controller still needs to compare the current parent state and the request identity. A later retry must not overwrite a newer child decision, revive removed glue or treat an old accepted request as the latest intent. SIG(0) inception and expiration limit the useful replay window; the workflow needs its own generation and supersession rules.

The closeout test is observation, not transport repetition. Query the relevant authoritative parent servers, record the exact RRset and zone generation, validate where applicable, and compare it with the accepted intent. If evidence remains mixed, the state is partial publication, not success or failure manufactured from the last response code.

Publication still has more than one surface

The parent primary may contain the new data while a secondary continues serving the prior generation. The change can be visible from one authoritative address and absent from another. Delegation NS, glue and DS also have different operational consequences and may be cached under different bounds.

An observation receipt should name the queried server, transport, time, answer, authority, TTL, DNSSEC state and zone-generation evidence. Sampling a recursive resolver is useful for reader impact, but it cannot substitute for parent-authority verification because it may legitimately hold cached old data.

Once the parent authority converges, cache reasoning becomes possible. The team can calculate when previously observed data should have expired under recorded TTLs. That is still a bounded inference, not global enumeration. Independent resolver checks can show representative outcomes without claiming that every cache on the Internet agrees.

Application success sits beyond DNS. A service may remain unreachable after a correct delegation change, or it may keep working through cached or alternate paths before publication finishes. The final incident record should keep application probes alongside DNS evidence, not use one to overwrite the other.

Draft status limits the strength of the conclusion

At the evidence freeze, Datatracker identified revision 02 as active DNSOP work, last updated 25 September 2026, with the Working Group state “Waiting for WG Chair Go-Ahead Other - see Comment Log” and IESG state “I-D Exists.” The revision itself is dated 17 June and expires 19 December 2026.

Datatracker displayed no intended RFC status while the document header said Standards Track. That mismatch is source state, not a detail for an editor to resolve. The draft can change, expire, be replaced or advance. Proposed registry values and examples are not final allocations or evidence of running systems.

No frozen source names a deployment or proves a completed delegation transition. The constructed opening is an analytical device. The article can describe the protocol's receipt boundaries; it cannot claim that a registry currently emits them or that a named operator failed to do so.

The useful automation product is a receipt graph

A durable record begins with intent: child, parent, desired NS/glue/DS set, prior set, reason, generation and approving principal. It then appends DSYNC discovery, endpoint identity, bootstrap method, key state, signature result, name-scope result, policy checks and receiver decision.

After acceptance, the graph continues. It records the parent provisioning job, primary generation, secondary generations, authoritative samples, TTL horizons, resolver samples and application checks. Every edge has a timestamp, owner and evidence hash. Unknown remains a first-class value.

This graph supports safe action. An old nameserver can remain until parent publication and exposure close. A retry can be suppressed if authoritative state already matches. A failed bootstrap can be repaired without evicting the last trusted key. A disputed incident can show whether the gap was request transport, parent policy, provisioning, publication or cache.

The narrow conclusion is stronger than a broad success label: SIG(0) can authenticate a scoped child request, and NOERROR can acknowledge that the parent receiver accepted it. Neither fact alone proves that the public parent zone changed. Automation becomes trustworthy when it preserves that difference.

Sources