Summary

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02 proposes that a child send exact NS, glue or DS changes to a parent-side UPDATE Receiver through DNS UPDATE, authenticated with SIG(0) and located through DSYNC.
  • The bootstrap request is self-signed. That proves possession of the offered private key, not authorization to govern the child. The receiver must keep the key merely known until an accepted validation method promotes it to trusted.
  • A durable authority-transition receipt should join the old key, proposed key, bootstrap method, independent evidence, policy verdict, accepted update and observed parent publication. This is a governance recommendation, not a DNSOP requirement.

Imagine a parent receives a neatly formed request: delete the old KEY set, add this new public key, and verify the message with the private half of that same new key. The signature checks. Nothing was corrupted in transit. The sender undeniably possesses the key it wants the parent to trust.

That is also the least surprising fact in the exchange. Anyone can generate a key pair and sign a request with it. The institutional question begins where the cryptography ends: why should this particular key now control the delegation for child.parent.?

Revision 02 of Automating DNS Delegation Management via DDNS was published on 17 June 2026. It is an active DNSOP working-group Internet-Draft and remains work in progress, capable of changing or expiring. The rendered document calls its intended status Standards Track, while the Datatracker summary leaves that field blank. It is not an RFC and no deployment should be inferred from its publication.

The draft addresses a real operational failure. A child zone may change its authoritative servers or DNSSEC material while the parent retains old NS, glue or DS records. The child can continue to answer through part of the old arrangement, making the mismatch look tolerable until another failure removes the remaining path. What appeared to be spare capacity was already gone.

Existing CDS and CSYNC scanners let a parent discover some requested changes by polling children. The draft’s alternative makes the child push an ordinary secure DNS UPDATE when its delegation data changes. A DSYNC record tells the child whether the parent accepts UPDATE for this purpose and identifies the receiver and port. The proposal can remove scanning latency and can serve unsigned children as well as signed ones.

That efficiency gain moves the governance problem; it does not dissolve it.

The packet carries a change, not a mandate

DNS UPDATE is stronger than a notification in one narrow respect. A notification hints that the recipient should look for a change. An UPDATE contains the additions and deletions the sender wants applied. SIG(0) binds the transaction to a private key and permits the receiver to verify integrity and origin relative to a public key it already trusts.

The draft is careful about the last phrase. A SIG(0) signature can use cryptography as strong as a DNSSEC signature, but the trust models differ. DNSSEC validation normally follows signatures to a configured trust anchor. The proposed UPDATE key is trusted individually after a bootstrap procedure. Mathematical strength cannot replace the missing decision about initial authority.

The UPDATE Receiver therefore is not meant to be a signature-controlled write socket into the live parent zone. It may be a separate parent service or a third party such as a registrar. It should restrict changes to the intended NS, glue, DS and key-management scope, apply the correctness tests used for CDS or CSYNC processing, retain an audit trail and hand an accepted change to the parent’s provisioning system.

The normal authorization rule also scopes the key name. An update to child.parent. must be signed by a trusted SIG(0) key bearing that exact name. This blocks one child’s key from rewriting another child’s delegation. A receiver may use an alternative scheme, such as a registrar key authorized for many children, but then the receiver assumes responsibility for authorizing each child-level change by other means.

Name scoping answers which object a trusted key may touch. It does not answer how the key became trusted.

Known is deliberately weaker than trusted

The initial bootstrap request is self-signed. It proposes a KEY record and may carry an instruction that, if executed immediately, would delete the existing key set. The receiver can validate the self-signature and mark the offered key as known.

It must stop there. The draft says a self-signature proves only that the sender possesses the corresponding private key. It does not prove that the sender is authorized to manage the child’s delegation. A key becomes trusted only after a separate validation step succeeds. Until then, a previously trusted key must not be removed.

This is more than defensive programming. It is a two-stage constitution for machine authority. Learning a credential is an observation. Entrusting a credential with power is a decision. If an implementation stores both states in one boolean, or a dashboard renders both as “key present,” the distinction can disappear even while the protocol text preserves it.

The rule about the old key gives the distinction practical force. An attacker can always submit a new self-signed key. If that message could evict the old trusted key before validation, failed bootstrap would already have caused damage. Retaining the incumbent key until successful promotion turns an unauthorised request into inert evidence rather than a denial-of-service command.

Bootstrap methods assert different principals

The proposal offers more than one route from known to trusted because DNS deployments do not share one signing state.

For a DNSSEC-signed child, the public SIG(0) key can be published at the child apex and validated through the existing chain. For an unsigned child whose authoritative nameserver sits in a signed zone, the child’s key can be republished under a special name below that nameserver and validated there. That second route requires cooperation from the nameserver operator; the draft recommends a separate intent signal but leaves the provider’s provisioning handoff out of scope.

For a wholly unsigned child, the proposed policy follows the lineage of RFC 8078: retrieve the key repeatedly from multiple network vantage points, at multiple times and across stronger transports where available, and accept only consistent observations. This raises the cost of a transient on-path substitution. It does not turn observation of the serving infrastructure into proof of the registrant’s identity. The draft says the method authenticates the current operator of the authoritative servers, not the registrant, and is the weakest of the automatic methods.

Manual bootstrap remains available. It may involve an established portal, authenticated support exchange or another out-of-band ceremony. “Manual” is not automatically stronger or weaker. Its assurance depends on who is checked, against which authority record, through what recovery path, and with what evidence retained.

These methods are not interchangeable implementations of one abstract proof. They answer different questions about different principals. A DNSSEC chain can bind a key to the signed child namespace. Multi-vantage observation can show durable control of current authoritative answers. A registrar’s authenticated process may bind a requester to account or registrant records. A parent should state which principal it intends to authorize before choosing the evidence that will stand for that authority.

Capability discovery can itself change the trust path

The parent may advertise supported bootstrap methods through a bootstrap parameter in an SVCB record at the DSYNC target. A child can then see whether the receiver supports apex validation, nameserver-assisted validation, unsigned multi-vantage acceptance or manual handling.

This is useful interoperability data, but it participates in the decision. If an attacker can forge an unsigned advertisement, the attacker may steer a child away from a stronger method toward the weaker unsigned path. The draft consequently recommends signing that SVCB record where the parent supports DNSSEC and choosing the strongest advertised method the child can satisfy.

An operator should therefore not log only the method eventually used. It should preserve the advertised method set, whether the advertisement validated, the child’s available methods and the selection rule. Otherwise a later reviewer can see a successful bootstrap but cannot tell whether a downgrade preceded it.

Acceptance is not publication

Once a trusted key signs an in-scope UPDATE, the receiver still applies local policy and correctness checks. A NOERROR response means the request was received and accepted and that the change should be expected in the parent zone later. It does not say that publication has already happened.

That temporal boundary matters during nameserver migration and DNSSEC rollover. A child that treats acceptance as visible state may withdraw old service too early. A monitoring system that closes the ticket on NOERROR can report convergence while resolvers still see the old delegation. An audit that stores only the parent zone’s final state cannot later determine which accepted command produced it.

The four states must remain distinct: the receiver knows a key; the receiver trusts the key; the receiver accepts a signed update; the parent publishes the resulting delegation. Failure and recovery differ at each boundary. BADKEY may mean the receiver does not know the key. A key can be known but still awaiting validation or can have failed validation. A valid, trusted update can be refused by policy. An accepted update can wait in provisioning. A published change can later be rolled back.

Mutual authentication adds another asymmetry. The parent needs to trust the child key before accepting change. The child needs to trust the receiver’s response key before acting safely on key-state answers. Where the parent is unsigned and no manual receiver-key bootstrap occurred, forged responses can trigger disruption or needless re-bootstrap even though they cannot authorize a delegation mutation. “The request was secure” and “the response was trustworthy” are separate statements.

Preserve the authority transition

I propose an authority-transition receipt for every bootstrap and re-bootstrap. It is not a public registry of child secrets and it is not a field set required by the draft. It is an access-controlled record that prevents an efficient protocol from compressing its most important decision into an unexplained trusted=true.

The receipt begins with the parent, child, DSYNC answer and validation status, UPDATE Receiver identity, software and policy version, old trusted key fingerprints, proposed key fingerprint, signature times and the exact bootstrap request digest. It records which bootstrap methods were advertised, which were available, which was selected and why.

The evidence section records the principal being authorized. For apex or nameserver-assisted validation it keeps the DNSSEC chain outcome, observation time and names used. For unsigned bootstrap it records vantage independence, times, transports, complete answer fingerprints and consistency verdicts. For manual bootstrap it references the authenticated session, account or registrant authority checked, reviewer or automated control, challenge, recovery exceptions and approval result without publishing sensitive personal data.

The decision section separates known, validation started, validation failed, trusted, superseded and revoked, each with time and actor. It proves that an incumbent key remained active until the replacement was validated. A later update record binds the trusted key, exact NS/glue/DS delta, correctness tests, policy verdict, response and provisioning job. A final observation records when the intended parent RRsets actually became visible and from which authoritative servers.

This receipt also makes re-bootstrap governable. Loss of the child private key, loss of the parent’s stored public key and a failed rollover are not the same incident. Each has a different claimant, recovery authority and revocation risk. Repeating “the same mechanism as initially” is operationally sensible only if the initial mechanism and its evidence are still discoverable.

The draft’s strongest insight is not that a signature can automate delegation change. That has long been technically possible. It is that the parent must decline the seductive shortcut from self-signed to trusted. A key may introduce itself. Only an accountable authority process can give it power.

Sources

  1. Automating DNS Delegation Management via DDNS — revision 02
  2. Datatracker record for the DNSOP draft
  3. Draft history
  4. DNSOP documents
  5. DNSOP working group
  6. RFC 9859: Generalized DNS Notifications
  7. RFC 2136: Dynamic Updates in the DNS
  8. RFC 2931: DNS Request and Transaction Signatures
  9. RFC 3007: Secure DNS Dynamic Update
  10. RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY
  11. RFC 7477: Child-to-Parent Synchronization in DNS
  12. The Policy Mirror