Summary

  • CDS and CDNSKEY express the child side's desired replacement for the DS RRset that lives in the parent. When an existing DS already authenticates the child, the current chain can validate a rollover signal; without that DS, the child cannot bootstrap trust merely by signing itself.
  • RFC 9615 solves most initial-enrollment cases by requiring matching signals beneath the DNSSEC-secured namespaces of every applicable out-of-domain nameserver. That proves operational consent across the listed DNS operators, not registrant title or human awareness.
  • Parent admission, digest policy, publication, TTL completion and resolver validation remain separate evidence. The algorithm-zero request to remove all DS records is a destructive third state, not a routine key roll.

The instruction that could not authenticate itself

A managed DNS provider enables signing for a customer's domain. Its authorities publish DNSKEY, CDS and CDNSKEY at the zone apex. Every RRset is internally consistent. Every signature verifies against the DNSKEY in the same answer. The provider's console therefore reports that its side is ready.

The parent has no DS for the domain. A validating resolver cannot start with the child's DNSKEY, because the point of the missing DS is to tell the resolver which child key may be trusted. The child has produced a signed statement, but the parent has not yet authenticated the signer. Self-consistency is not a chain of trust.

This small gap contains the whole authority problem. The operator can prove possession of a private key and control of the serving system. The registrant may have authorized that operator, or may not know that automatic DNSSEC was enabled. A registrar can authenticate an account holder yet have no direct view of the operator's current key state. A registry can publish DS but may receive the request through an intermediary. Each actor holds a different fact.

CDS/CDNSKEY exists to make those facts coordinate without requiring a person to copy a digest during every key change. The automation is valuable precisely because parent interaction is a historical bottleneck. It is also dangerous if the first signed object is mistaken for the final authority.

A child request and a parent record

The DS RRset used in validation is parent-zone data. It carries a key tag, algorithm, digest type and digest that lead from the parent's authenticated state to a child DNSKEY. CDS has the same fields as DS but a different type code. CDNSKEY carries the public DNSKEY material from which a parental agent can calculate DS.

RFC 7344 gives the child an unambiguous way to express a desired replacement state. The consumer compares the CDS/CDNSKEY view with the current parent DS and translates the difference into additions and removals. This is not a DNS UPDATE against the parent and not an authoritative transfer of parent data. It is input to the parent or parental agent's own provisioning act.

Absence has exact semantics. If neither CDS nor CDNSKEY exists, the parental agent does nothing. It must not treat a failed query, an omitted record or an operator's cleanup after successful synchronization as an instruction to delete DS. That rule turns silence into stability rather than destruction.

The parent also chooses a consumption mode. It may accept CDS, calculate DS from CDNSKEY, or support one as the default and the other as fallback. Digest policy remains local. A parent calculating DS may publish only the digest types it supports, so the resulting set can differ from the child's CDS without changing which key is represented.

These are bounded powers. The child selects key material it wants represented. The parental agent decides whether the signal is admissible and how it maps into supported DS data. The parent publishes the record. Resolvers decide whether the resulting chain validates. None of these roles disappears because the record can be processed automatically.

Existing trust makes rollover a different operation

Once the parent already publishes a DS that matches a current child DNSKEY, the chain can authenticate a later CDS/CDNSKEY signal. RFC 7344 requires the child-apex signal to be signed by a key represented in both the current DNSKEY and DS RRsets. It also requires continuity: applying the proposed replacement must not break the current delegation.

That is an authorization bridge, not a generic certificate of intent. The current secure entry point licenses a bounded transition to another secure entry point. A parental agent still has to obtain the current RRset, validate it, compare it with the parent state and prevent an older observation from overwriting a newer one. RRSIG inception and child SOA serial may help, but they are evidence inputs, not a universal total order.

The child and parent then wait on different clocks. The child may prepublish a new key and its signal. The parent publishes new DS data. Caches can retain the old DS, DNSKEY and signatures for their respective TTLs. The child cannot safely retire an old key merely because an API request succeeded or one parent server shows the new record.

BIND's current guide makes this distinction visible. It can publish CDS/CDNSKEY for a KSK or combined-key roll, query configured parental agents and pause progression until every expected response includes the relevant DS. If the parent does not consume the signal, manual submission remains necessary. Child-side automation cannot invent parent-side capability.

Initial enrollment borrows a different chain

Initial trust lacks the bridge just described. RFC 8078 listed several possible acceptance approaches: authenticated account interaction, extra registration checks, delay with repeated observations, a challenge, or processing at delegation inception. Each can be useful, but none is an in-band cryptographic validation path from the insecure child.

RFC 9615 adds that path for delegations with at least one out-of-domain nameserver. It derives a signaling domain by placing _signal before each nameserver hostname listed in the parent's NS RRset. Beneath each signaling domain, a _dsboot name identifies the child. The DNS operator publishes there the same CDS/CDNSKEY content that appears at the child apex.

The difference is where the signature leads. A child-apex signature cannot yet reach a parent trust anchor. The signaling copy is signed by the zone that contains the nameserver operator's signaling domain, whose chain must already validate. The parental agent is therefore not trusting the insecure child through itself. It is transferring authentication from an established operator namespace to a proposed child secure entry point.

The procedure is intentionally demanding. The parental agent confirms that the child has no DS and identifies the parent-side NS set. It queries the child-apex CDS/CDNSKEY directly, without cache, from every listed authoritative server. It retrieves the signal beneath every applicable out-of-domain nameserver and validates those answers through DNSSEC. It then compares the RRsets separately by type.

Any applicable failure stops enrollment: a server that cannot answer, an unauthenticated signal, an empty-versus-present difference or inconsistent content. Fully in-domain delegations cannot use this mechanism because every signaling path would depend on the very child whose first trust link is missing.

The rigor produces an important governance property. In a multi-provider delegation, one operator cannot silently make itself the new DNSSEC authority while the other listed operators serve a different key view. Every exposed operator has to present the same signal. RFC 8901 imposes a related discipline after enrollment: multi-signer providers need a common CDS/CDNSKEY view so the parent does not build DS from incompatible key sets.

Operator consent is not owner title

RFC 9615 authenticates an operational statement: the DNS operators behind the parent-listed nameservers agree to act as signers for this child and present the specified key material. It does not authenticate the commercial or legal chain by which they received that role.

The distinction is not hypothetical. The RFC notes that an operator can add CDS/CDNSKEY and signaling records without the domain owner's explicit knowledge, and recommends telling the owner through the service interface or notification. A compromised DNS-provider account, an erroneous automatic enablement or an incomplete provider migration can therefore produce cryptographically authentic records that are institutionally disputed.

Parental admission remains necessary. The parental agent is the party authorized to insert DS on behalf of the child, whether that party is a registry, registrar, reseller or another approved intermediary. It should record which delegation relationship licensed the act, which transition class was requested and which independent checks are required. “DNSSEC validated” answers provenance. It does not answer mandate.

QNAME minimization matters at this boundary. RFC 9615 warns that without it an ancestor of a signaling domain may see the full query and attempt to answer with data signed under its own zone rather than refer the resolver onward. Minimization reduces that attack surface. It does not replace validation of the correct signaling name, delegation or equality set.

Deletion is not a key rollover with fewer keys

RFC 8078 defines two exact one-record instructions: CDS 0 0 0 0 and CDNSKEY 0 3 0 0. Algorithm zero is not a usable DNSSEC signing algorithm. In these record types and exact forms, it means remove the entire parent DS RRset.

The request changes the security state, not merely the key. Once the parent has verified the signal and its acceptance checks, it removes DS. The child must still wait for the relevant parent-side TTL effects before it stops signing. Removing child keys too early creates a bogus delegation for validators that still hold DS. Leaving signing material visible for a time after DS removal is not itself a failure; it can be the safe overlap needed to drain old parent state.

Cloudflare's documented states illustrate this separation. Its pending-disable and disabled stages continue serving DNSSEC material while publishing algorithm-zero CDS/CDNSKEY until parent DS removal is observed; only a later deleted state removes the signing records. This is one product's control design, not a new universal state machine, but it shows why “DNSSEC off” cannot be one instantaneous toggle.

Returning to insecure should have a separate authorization and recovery path. It reduces protection, may surprise the owner and can make later re-enrollment difficult. A mass automation system that treats deletion as an empty desired set recreates the very ambiguity RFC 7344 forbids. Only the exact signed delete instruction, admitted under the appropriate destructive-change policy, means delete.

Evidence must cross the cut

A strong record begins before the parent mutation. It captures the parent-side NS and DS sets; every authoritative child response; every signaling name and validation chain; record equality; freshness and replay evidence; the parent policy decision; the exact proposed DS diff; and the account or delegation authority under which the parental agent acts.

It continues after publication. The operator observes the DS on each authoritative parent, waits the defined cache window, checks DNSKEY and signature availability from every child authority and tests validating resolvers from independent networks. A green provider console proves only that one system accepted a command. A parent answer proves only recorded state. A successful resolver chain proves consequence along one path and time.

The evidence should also preserve negative decisions. An abort because one nameserver disagreed is not failed automation; it is the consent boundary working. A digest rejected by policy is not necessarily a broken child. A fully in-domain delegation sent to the manual path is not non-compliance. These outcomes explain where authority stopped and prevent staff from bypassing a guard they mistake for friction.

Sources