Summary

  • CDS and CDNSKEY let a child DNS operator state the delegation parameters it wants, but they do not edit the parent zone. The parental agent must authenticate the request, reconcile every authoritative server address, confirm CDS/CDNSKEY agreement and preserve at least one valid DNSSEC path before acting.
  • NOTIFY(CDS) can shorten discovery time, while parent publication, cache turnover and validator probes supply later evidence. A green automation flag is therefore weaker than a ledger of distinct state transitions and cancellation reasons.

One server is still yesterday

Imagine a child DNS operator preparing a key rollover. The new DNSKEY RRset is signed. Matching CDS and CDNSKEY records appear at the apex. A dashboard queries the nearest authoritative server, sees the expected fingerprints and declares the request ready.

The parental agent does not update the DS record.

It has queried every address attached to every nameserver hostname in the parent delegation. Most return the new pair. One secondary address still serves the previous records. The child has not expressed one unambiguous future state; it has exposed two. Refusing the change is not an institutional veto over the child. It is the protocol's safety property working at the point where an ambiguous signal would otherwise become a shared trust link.

This is an analytical scenario, not a report about a named registry, registrar or DNS provider. It reveals why “the child has published the record” is an incomplete operational statement. Which address answered? Was the answer authenticated? Did every reachable server agree? Did CDS and CDNSKEY identify the same key set? Would the resulting DS RRset leave a valid chain? Has the parent published it? Which recursive resolver has stopped using the old set?

The useful answer to each question belongs to a different actor and a different observation surface.

The parent owns the trust link it publishes

DNSSEC crosses a delegation through a record that the child cannot place in its own zone: the DS RRset in the parent. That record refers to a child DNSKEY and lets a validator extend trust across the zone cut. The chain is conceptually parent DNSKEY, parent-signed DS, then child DNSKEY.

CDS and CDNSKEY were designed to reduce the manual traffic around maintaining that link. CDS carries information in DS form. CDNSKEY carries a DNSKEY form from which a DS can be calculated. The child DNS operator publishes one or both at the child apex to express its desired delegation parameters to a parental agent.

The verb is express. RFC 7344 transfers information from the child to the parental agent. It does not grant the child a remote write primitive into the parent zone. That distinction is not bureaucratic decoration. The parent is responsible for the zone that third-party validators query, while the child is responsible for signing and serving its own zone. Automation connects the responsibilities without pretending that either actor controls both.

The parental agent may be a registry, registrar, reseller or another entity authorized to insert DS records on the child's behalf. In a registrant–registrar–registry chain, more than one parent-side actor may be capable of causing a change. The operational design must identify which actor is listening, which channel has precedence and when automation should pause after an out-of-band intervention.

A sampled answer is not a zone state

The sharpest modern clarification is found in RFC 9975. Before acting, the parental agent must obtain all IP addresses for each nameserver hostname listed in the child's parent-side delegation. It uses a validating resolver and includes available glue. It then queries all those addresses for the relevant RRsets.

This is stronger than “ask every nameserver name.” One hostname can map to several IPv4 and IPv6 addresses, anycast edges may not converge at the same instant, and a multi-provider configuration can expose different publication machinery behind different targets. The state being tested is what the delegated service actually answers across those addresses, not what one control plane intended to deploy.

Consistency is required across the responses received. A NODATA response counts as a response. If one reachable address disagrees, the parental agent must abort. It must not create a record that would have been created, alter a record that would have changed or remove a record that would have been deleted under the consistent case.

Unreachability is different from inconsistency. A temporary timeout is not proof of agreement or disagreement. RFC 9975 recommends retrying on a configurable schedule, with exponential backoff as a useful default, and permits a second network vantage point to separate a localized routing problem from a persistently unreachable server. That means the decision log must preserve absence, disagreement and validation failure as different conditions. Collapsing all three into “check failed” destroys the information needed to repair the right layer.

Two formats, one intention

CDS and CDNSKEY convey related information in different forms. A parent processing CDS can take DS-format data supplied by the child. A parent processing CDNSKEY calculates the digest and can select a digest algorithm under its own policy. The choice allocates a small but real control surface: who selects the digest representation placed in the parent.

There is no general discovery protocol by which a child learns which format a parent prefers. Current operational guidance therefore requires a child operator to publish both unless the preference is known. Redundancy here increases interoperability, but it creates a new consistency obligation. Both RRsets must refer to the same key set.

The parent must not infer that one is newer, average the results or choose the format that happens to pass. It rejects ambiguity and leaves responsibility for a clear request with the child operator. This is a useful discipline for automation generally: when two authenticated expressions claim to describe the same transition, disagreement is a reason to stop, not an invitation for the receiver to invent intent.

The cryptographic choices are not frozen forever. IANA's live DNSSEC registries identify which signing algorithms and DS digest algorithms are suitable for implementation or validation. A hard-coded assumption that was sensible when a client shipped can become an interoperability failure later. The acceptance record should therefore include the policy and registry view applied at the time, not merely the calculated digest bytes.

Continuity is the acceptance test that matters

Even an unambiguous request can be unsafe. RFC 10026 requires the automated maintainer to verify that the resulting DS RRset would allow continued DNSSEC validation. The change is cancelled when that test does not succeed.

The minimum useful invariant is that the child DNSKEY RRset has a valid RRSIG from a key referenced by at least one resulting DS record, using acceptable algorithm and digest choices. This permits overlap during a rollover. It rejects a transition that would leave the parent pointing only to a key that cannot validate the child's DNSKEY set.

The invariant also gives the parent a narrow mandate. It is not asked to approve the child's business model, DNS provider choice or reasons for rolling a key. It is asked to avoid publishing a trust link that breaks the delegation. Additional local requirements may exist—for example, national cryptographic rules—but they should be explicit, versioned and attributable. An unexplained “policy denied” result is operationally weaker than a deterministic continuity failure because the child cannot reproduce or predict it.

Running-Code Primacy clarifies the boundary. The shared layer is justified by what mutually dependent systems must verify: authenticated intent, unambiguous publication and a surviving validation path. Publication of a record does not make the transition real by declaration. A valid state becomes operational through compatible implementations, parent publication and validators that can actually follow the chain.

Bootstrap is not an ordinary rollover

An already secure delegation can authenticate later CDS/CDNSKEY changes through its existing DNSSEC chain. Initial enrollment is harder. If the parent publishes no DS, a signed record at the child apex cannot prove itself to a validator through that absent parent link. Treating the first CDS record as self-authenticating would turn the missing trust anchor into circular logic.

RFC 9615 addresses this bootstrap gap with authenticated signals associated with the child DNS operator's authoritative nameservers. Signed signaling zones publish per-child _dsboot information. A parental agent that can validate those signaling zones can authenticate the initial CDS/CDNSKEY material at the insecure child and, if all other checks succeed, secure the delegation.

This is not a universal shortcut. The construction has documented edge cases, including excessively long child names and domains that use only in-domain nameservers. Operators need an explicit capability result rather than one binary “supports CDS” flag. A system may support ongoing automated rollover while lacking authenticated initial bootstrap for a particular delegation shape.

The distinction should appear in product language and audit data. “Automation enabled” might mean polling a secure child for changes, supporting RFC 9615 bootstrap, accepting an authenticated registrar instruction, or merely offering a web form. Those are not interchangeable promises.

A notification rings the bell; it does not open the gate

Polling every child zone introduces delay and does not scale elegantly for large parents. RFC 9859 defines a way for the parent to advertise a notification target through a DSYNC record. A child operator can discover that endpoint and send a generalized NOTIFY for CDS when it has published a new CDS or CDNSKEY RRset.

The notification contains urgency, not authority. It tells a responsible parent-side service to look now. The service still retrieves the RRsets, validates them, checks every delegated address, compares CDS with CDNSKEY, computes the resulting DS and tests continuity. A spoofed or duplicated notification cannot manufacture an accepted change because the authoritative data and validation chain remain the decision inputs.

This division is operationally useful. Lost notifications affect latency, so periodic reconciliation can remain as a slower safety net. Duplicate notifications should be idempotent. A listening endpoint can report that it received a hint without claiming that it accepted the requested state. Metrics should separate notification delivery, scan start, data collection, acceptance, publication and observed validation.

The same separation resolves a common incident argument. If a child says “we notified you” and a parent says “we did not update,” both statements can be true. The question becomes which later transition failed: endpoint discovery, transport, authoritative convergence, authentication, acceptance policy, publication queue or cache-visible validation.

Deletion is a record, not an absence

Removing DNSSEC protection is more dangerous than adding another valid path because a mistaken deletion can silently turn a secure delegation insecure. RFC 8078 therefore defines an explicit delete signal rather than letting the parent infer intent from missing CDS/CDNSKEY data. The CDS form uses algorithm 0, digest type 0 and digest 00.

An absent record can mean that a server is stale, a publication failed, a query reached the wrong view or the child no longer supports automation. It cannot safely mean “remove the DS.” The explicit signal must itself be consistent, authenticated and processed under the applicable waiting and acceptance rules.

This is another example of a minimal common specification preventing discretionary interpretation. The child must say what it wants in a recognizable state. The parent must not turn silence into an irreversible act. The decision record must show the exact delete signal and the checks that preceded removal.

Publication begins a cache transition

Acceptance is still not publication. A parental agent may write a registry transaction, a registrar may receive a poll message and a parent-zone generator may publish on its own cadence. Each stage can fail independently. The authoritative parent serial and the observed DS RRset are stronger evidence than a successful acceptance API response.

Publication is not global observation either. Recursive resolvers retain earlier DS RRsets under their TTL. During a rollover, some validators can legitimately see the previous parent data while others have fetched the new set. The transition must be designed so both populations retain at least one working validation path.

RFC 10026 recommends a reduced TTL—roughly five to fifteen minutes—for a newly changed DS set during a bounded rollback period. The previous or default TTL is restored later, but not before the previous set has had time to expire. The lower new TTL makes reversal faster if the new state proves defective; it does not travel backward into caches that already hold the old RRset.

This timing detail defeats a tempting but false inference: “the parent published five minutes ago, therefore the Internet now sees the new DS.” The correct evidence includes the previous TTL horizon, authoritative parent observations, resolver samples from multiple networks and successful validation against the child state. One probe can prove one path at one moment. It cannot prove universal convergence.

Recovery must survive the automation

Automated maintenance is normal security work, not an exceptional account modification. RFC 10026 therefore says ordinary registrar or registry update locks alone must not suspend it. A lock that protects a customer portal from accidental edits does not necessarily protect against a registrar or registry acting through its own authority, and blocking routine key maintenance can create the availability risk the lock was meant to reduce.

Automation must nevertheless preserve another DS maintenance channel. A child can lose access to its signing keys. A DNS provider may not support the protocol. A provider migration can leave two submitters in conflict. A compromised or broken automated path cannot be the only way to recover the trust link.

The recovery channel should be out of band relative to the failed mechanism, authenticated to a known registrant or technical authority and recorded with the same rigor as an automated update. Its use may justifiably suspend automation until the actors reconcile the new baseline. What it must not do is silently convert a temporary manual intervention into a permanent, unexplained refusal of future valid signals.

Evidence should read like a sequence, not a verdict

A useful DS-automation ledger records the request before it records the outcome. At minimum it should retain the triggering CDS/CDNSKEY RRsets, time, notification or polling channel, every delegated nameserver address queried, response and DNSSEC status, retry history, consistency result, calculated DS set, continuity result, applied policy version, decision, publication observation and cancellation reason.

The operator then adds a second evidence line for the parent zone: published DS fingerprint, authoritative servers sampled, SOA serial or equivalent release identifier, TTL and publication time. A third line covers external observation: recursive vantage point, cached set, validation result and the child key actually used.

This structure prevents one system from attesting beyond its field of view. The child can prove what it served. The parental agent can prove what it checked and decided. The parent operator can prove what it published. A validator can prove what one network path accepted. Leadership can then ask where the state stopped advancing without asking a green checkbox to explain the whole Internet.

Sources