A DNSSEC-signed child zone can rotate its signing keys without changing the delegation immediately, but validators ultimately depend on the DS record set published by the parent. That parent-side state creates an operational handoff: a new key in the child does not become a secure delegation anchor merely because the child publishes it.
CDS and CDNSKEY provide an in-band mechanism for that handoff. RFC 7344 defines records that a child can publish at its zone apex to signal prospective DS parameters. A parental agent can retrieve the signal, validate it under the applicable rules, apply local acceptance policy, and update the parent-side DS set.
The mechanism reduces manual coordination, but it does not make every delegation change automatically trustworthy. Existing trust, bootstrap policy, consistency across authoritative servers, and explicit handling of removal remain part of the security boundary.
CDS carries DS-shaped data; CDNSKEY carries key material
The two record types express closely related intent in different forms.
A CDS record has the same presentation format as a DS record. It can state the key tag, DNSSEC algorithm, digest algorithm, and digest that the child wants represented in the parent:
example.com. CDS 12345 13 2 49FD46E6C4B45C55D4AC...A CDNSKEY record instead has the same presentation format as DNSKEY. It publishes key material from which the parent can calculate DS records according to its supported digest policy:
example.com. CDNSKEY 257 3 13 <base64-public-key>RFC 7344 permits a parent to consume CDS, CDNSKEY, or both according to its implementation policy. When a child publishes both, their content must describe matching prospective delegation state under the protocol rules.
This distinction gives the parent a choice. CDS lets the child supply DS-form data directly. CDNSKEY lets the parent derive DS records from the advertised key, including use of digest algorithms selected by the parent.
The records belong at the child zone apex
CDS and CDNSKEY are not arbitrary hints that can be placed anywhere in a zone. The processing rules put them at the child zone apex, where they represent a requested change to the delegation above that zone.
For an already secure delegation, RFC 7344 ties acceptance to the existing chain of trust. The CDS or CDNSKEY RRset must be signed appropriately, and applying the prospective state must not break the current secure delegation during the rollover process.
That continuity is the central protection for routine key rollover. The parent is not treating an unsigned DNS answer as authority to replace a trust anchor. It is processing a signal authenticated through the delegation state that already exists.
A parent can also impose additional checks or delays. Automation defines a transport and processing path for the request; it does not remove the parent’s responsibility to decide which requests satisfy its acceptance policy.
Initial enrollment needs a separate trust decision
The existing DS set can authenticate a rollover only when a secure delegation already exists. Initial DNSSEC enrollment has no prior DS anchor at the parent, so the same continuity argument cannot establish the first trust relationship.
RFC 8078 extends the model with methods for initial trust establishment and makes clear that the parent needs an acceptance policy for this transition. Possible designs can use an authenticated channel, additional checks, a delay, or other mechanisms defined by the parent.
More recent DNSSEC automation work also defines authenticated bootstrap signals for deployments that support them. Those mechanisms are separate from simply seeing an unauthenticated CDS or CDNSKEY RRset.
This boundary matters operationally: key rollover inside an established secure delegation and creation of the first secure delegation are different security events. A system should not silently treat them as equivalent.
A delete signal is explicit
An empty CDS or CDNSKEY RRset does not mean “remove DNSSEC.” RFC 7344 treats absence of these records as no requested change once parent and child are synchronized.
RFC 8078 defines a specific delete signal. For CDS, the standardized form is:
example.com. CDS 0 0 0 0For CDNSKEY, the corresponding form is:
example.com. CDNSKEY 0 3 0 0The parent must validate the signal and its acceptance conditions before removing the DS RRset. After parent-side DS removal, cached delegation data also has to age out before the child can safely complete a transition to unsigned operation.
Deletion therefore deserves the same care as enrollment. Removing the DS set changes the delegation from a cryptographically linked state to an insecure delegation after caches converge. It is not merely cleanup of obsolete metadata.
Authoritative servers must present a consistent target state
A parent may query more than one authoritative server for the child. If those servers expose conflicting CDS, CDNSKEY, or related delegation-update data, acting on whichever response arrives first can turn deployment skew into a trust-management error.
RFC 9975 clarifies consistency requirements for CDS/CDNSKEY and CSYNC processing. Parent-side entities accepting these signals need to ensure that the target states retrieved from authoritative servers satisfy the required consistency conditions before applying an update.
This is especially relevant during staged DNS changes. Zone publication, signer state, and authoritative serving infrastructure can briefly disagree if rollout sequencing is poor. A safe parental agent treats disagreement as a reason not to manufacture a single intended state from incompatible observations.
Consistency checking is therefore part of the security logic, not just an availability optimization.
Automation still needs state and observability
A robust parental agent needs more than a periodic DNS query. It must distinguish current delegation state from a proposed state, avoid allowing older observations to overwrite newer accepted state, apply its acceptance policy, and record failures clearly enough for operators to diagnose them.
RFC 7344 discusses protection against stale updates, including state based on signed data and zone progression. Current operational guidance for DS automation also emphasizes acceptance checks, reporting, and coordination when several parties or update channels can affect the delegation.
The practical consequence is that automation should have visible state transitions. Operators need to tell whether a signal was absent, invalid, inconsistent, pending policy checks, accepted, or already synchronized. Treating every non-update as the same generic failure hides the distinction between a safe refusal and a broken workflow.
Delegation automation narrows a fragile manual boundary
CDS and CDNSKEY move DNSSEC trust maintenance closer to the signed zone that owns the key transition. For an established secure delegation, that creates a useful continuity path: the child publishes authenticated prospective state, and the parent can validate and apply it without copying DS values through a separate manual interface.
The mechanism remains deliberately bounded. Initial enrollment requires bootstrap policy. Removal requires an explicit authenticated signal and cache-aware sequencing. Conflicting authoritative views must not be collapsed into an invented target state.
Used with those boundaries intact, CDS and CDNSKEY turn DS maintenance into a protocol-driven operation while preserving the distinction between routine rollover, first-time trust establishment, and deliberate removal of the secure delegation.