Summary

  • A DNSOP draft in Working Group Last Call would let a child send exact NS, glue and DS changes to a parent in an ordinary DNS UPDATE protected by SIG(0), using DSYNC to discover the receiver.
  • Its crucial safeguard is a two-stage key state. A self-signed replacement becomes known because possession can be checked; it becomes trusted only after the parent's chosen bootstrap method validates the authority that possession is meant to represent.
  • The parent must keep an old trusted key until the replacement validates. Even after a trusted update earns NOERROR, acceptance, provisioning, authoritative publication and resolver observation remain separate receipts.

The dangerous line in the packet is not the new key. It is the delete instruction beside it.

Revision 02 of draft-ietf-dnsop-delegation-mgmt-via-ddns describes initial bootstrap as a self-signed DNS UPDATE that deletes the child's previous KEY RRset and adds a new KEY. A receiver can validate that self-signature with the very public key being presented. This establishes possession of the corresponding private key. If it also established authority, any stranger could manufacture a key pair, sign an eviction request and turn bootstrap into a denial-of-service primitive.

The draft therefore gives the receiver two states. The key is first known: received, syntactically usable and able to verify its own signature. It is not yet trusted. The receiver queues a separate validation step and must not apply the delete against a previously trusted key until the candidate has passed it. Only then may the replacement occupy the authorization slot for that child.

This state machine is the most consequential feature of a proposal now at a live standards checkpoint. DNSOP opened Working Group Last Call on 20 August with 7 September as the closing date. On 4 September, a chair asked for more positive support and constructive comment, stressing that silence was insufficient. Geoff Huston supported publication and described the mechanism as more efficient than parent-side polling. Johan Stenstam supported progression, disclosed his implementation position and emphasized the unsigned-child case.

Michael Richardson said he could write code from the draft, while asking for clearer treatment of KEY rather than DNSKEY, key state, algorithm futures and a visual state machine. These messages record individual technical views. They do not prove Working Group consensus, IETF approval or interoperable deployment.

The proposal's transport is deliberately unnovel. The child sends an ordinary RFC 2136 DNS UPDATE secured by the SIG(0) transaction-signature rules in RFCs 2931 and 3007. RFC 9859's DSYNC record tells the child whether the parent offers this form of update and where its logical UPDATE Receiver resides. That receiver can be separate from the parent's primary name server and can feed a provisioning system rather than touch the running zone directly.

That separation matters because an authenticated packet is not a delegated decision. The receiver must limit the update to the child's NS, glue, DS and narrowly defined KEY operations. Unless it intentionally deploys a broader authorization scheme, it must bind the requested child name to a trusted SIG(0) key with that exact name. It then performs the same substantive checks that a CDS/CDNSKEY or CSYNC scanner would perform. The delivery method changes; parent policy does not disappear.

The bootstrap method decides what kind of claim has been proved. If the child is DNSSEC-signed, the parent can validate an apex KEY through the child's chain. If the child is unsigned but uses a nameserver whose zone is signed, a provider can publish the KEY under a special signal name in that signed zone. Both paths inherit DNSSEC validation. A manual exchange can bind the key through an existing operational channel.

The unsigned-child path is weaker and more revealing. The parent compares the submitted KEY with observations from the child's authoritative service across multiple vantage points, times and transports. Consistency makes interception harder, but does not transform observation into registrant title. The draft says the method authenticates the current operator of the authoritative servers, not the registrant, and cannot be stronger than those servers. “Trusted” is therefore not a universal property of the bytes. It is a receiver decision grounded in a named proof path.

The record type also deserves precision. SIG(0) uses KEY, not DNSKEY. DNSKEY participates in DNSSEC's zone-signing trust structure; the KEY here authenticates a transaction. Conflating them hides which key store, rollover procedure, compromise response and validation evidence actually governs the update channel.

Responses expose another set of boundaries. Under the draft, NOERROR means the receiver obtained and accepted the UPDATE, so a parent-data change should be expected later. It does not prove that a provisioning job completed, the authoritative zone published the change, caches expired or resolvers observed it. REFUSED can reflect policy, rate limiting or misconfiguration; one response is not necessarily a permanent verdict. BADKEY means the receiver lacks the public key required for verification, but without richer error information it cannot describe every intermediate state.

Silence cannot tell the child whether the request or reply was lost.

A useful operational ledger would therefore preserve at least eight records: DSYNC endpoint and policy discovery; submitted UPDATE digest and prerequisites; signing-key identity; bootstrap method; known and trusted transitions; receiver decision and authenticated response; provisioning transaction; authoritative serial and RRset observation; and resolver views after the relevant TTLs. A service check belongs after those records, not inside them.

This follows Heng Lu's distinction between a description and reality. A public key can be accurately recorded as known while authority remains unproved. A standards draft can precisely specify a transition while no operator has adopted it. A parent can accept a change while the public DNS still shows the old delegation. Keeping those layers separate is not procedural caution. It is what prevents one valid proof—possession—from silently acquiring the power of another—authorization.

Sources