How do CDS and CDNSKEY records let a DNSSEC child zone update or delete its DS records at the parent without a manual submission?
answer
- the child publishes, the parent polls
- a signed request at the apex
- signed by a key the DS already trusts
- absence means no change
basics
~20 sThe child publishes CDS or CDNSKEY records at its apex stating the DS set it wants; the parent fetches them, validates them through the current DS, checks they keep the delegation working, and updates the DS. A single algorithm-0 record requests deletion.
solid answer
~50 sRFC 7344 lets the child zone state, in its own signed data, what its parent's `DS` RRset should be: a `CDS` RRset (ready-made DS records) or a `CDNSKEY` RRset (keys the parent hashes itself). The parental agent polls or is prompted, fetches the records and validates them with DNSSEC. They must sit at the child apex and be signed by a key that the **current** `DNSKEY` and `DS` RRsets both represent, so only whoever already controls the trusted key can steer the next one. The agent must refuse a change that would break the delegation, must not let an older version overwrite a newer one, and must do nothing when no CDS or CDNSKEY is published. RFC 8078 moved RFC 7344 to the Standards Track, listed acceptance policies for a first DS, and defined deletion: one record with algorithm 0.
go deeper
Recall that a child zone can publish CDS or CDNSKEY records stating which DS it wants, and that the parent reads them instead of waiting for a manual request.
Explain the parent's checks, apex location, a signer the current DS represents, continuity and freshness, and why an absent CDS means leaving the DS alone.
Show how CDS drives each step of a double-DS or double-KSK roll, how the delete signal works, and what a parent's acceptance delay does to your timeline.
Weigh automation against the risk that a compromised signer can now steer its own DS, and decide what acceptance delay and out-of-band notice a parent operator should impose.
## The problem it removes Every key-signing key (KSK) rollover changes the parent's `DS` RRset, once or twice. Done by hand, by pasting a digest into a registrar form or emailing a registry, that is the step where rollovers stall or go wrong; RFC 7344 observes that operators avoid changing keys, or skip publishing the new DS, because of it. **CDS** ("child DS") and **CDNSKEY** ("child DNSKEY") turn the request into DNS data that the parent can read and verify. Their record format mirrors DS and DNSKEY; what matters here is the procedure around them. ## How an automated update runs 1. The child publishes a `CDS` and/or `CDNSKEY` RRset at its apex describing the **complete** DS set it wants. It is a replace operation, not a diff (RFC 7344, Section 3). If the child publishes both types, their contents must match. 2. The **parental agent**, whichever entity may change the delegation (registry, registrar or another), notices it by polling its signed children or through a trigger such as a request from the child. Triggers may be unauthenticated, because the data itself is validated. 3. The agent fetches the RRset and validates it with DNSSEC. 4. It applies the acceptance rules below. If any fails, it ignores the records and should log the error. 5. If the requested set differs from the published DS set, it applies the change; with CDNSKEY it calculates the DS digests itself. 6. Once parent and child agree, the child may remove its CDS and CDNSKEY records. ## The acceptance rules - **Location:** the records sit at the child zone apex. - **Signer:** the RRset is signed by a key represented in both the current `DNSKEY` RRset and the current `DS` RRset. In a split-key zone that normally means the existing KSK, not only the zone-signing key that signs the other apex RRsets. - **Continuity:** applying the new set must not break the current delegation. - **Freshness:** an older CDS must not overwrite a newer one; the agent may compare signature inception times or the child's SOA serial. - **Absence means no change:** with no CDS or CDNSKEY published, the agent must not delete or alter the DS RRset. ## Driving a rollover with it - **Double-DS:** publish a CDS listing the old and new digests; after the swap and its wait, publish one listing only the new digest. RFC 7344 rejected deriving the DS from the DNSKEY SEP flag partly because that cannot express a DS for a key not yet published. RFC 8078, for a parent accepting CDS over an authenticated channel, says it should not refuse records whose key is not yet in the child zone, so a spare key can be pre-published. - **Double-KSK:** publish the new KSK, then a CDS naming only it; the agent swaps the DS in one change. - The waits remain: the child still waits out the DS TTL after the parent changes, and the parent may add its own acceptance delay. ## A first DS, and deleting the DS The signer rule cannot work when no DS exists yet. RFC 8078 lists acceptance policies for a first DS: an authenticated channel, extra checks, acceptance after a delay of repeated observation, a challenge record, or acceptance at the moment the domain is first delegated. RFC 9615 adds authenticated signals from the zone's DNS operator for this bootstrapping. For removal, RFC 8078 defines DNSSEC algorithm number 0 in CDS and CDNSKEY as **delete**. A single, validly signed record, `CDS 0 0 0 0` or `CDNSKEY 0 3 0 0`, tells the parent to remove the whole DS RRset; the child should begin unsigning only after the parent's TTLs have passed. It is the documented exit when, for example, moving between operators with disjoint algorithms makes a proper algorithm rollover impossible. | Child publishes | Parent does | |---|---| | no CDS or CDNSKEY | nothing; the DS RRset stays as it is | | a set matching the current DS | nothing to change | | a different, valid set | replaces the DS RRset | | one algorithm-0 record | removes the DS RRset | ## The security trade - Whoever compromises the signer can now publish CDS records and extend the compromise; RFC 7344 notes that an acceptance delay, and notice to the child by other means, narrow that window. - A compromised registrar account is not helped at all. - Deletion lowers the domain's security and should be the last resort. On status: RFC 7344 was published as Informational; RFC 8078 elevated it to the Standards Track, and RFC 9615 updates both.
- Why must a DNSSEC child's CDS RRset be signed by a key the parent's current DS already represents?That rule ties the request to whoever already controls the trusted key-signing key. A parental agent validating through the existing chain knows the instruction came from the zone's legitimate signer, not from anyone who can merely answer for the zone. It also means RFC 7344 alone cannot enrol a first DS; RFC 8078's acceptance policies and RFC 9615's bootstrapping cover that case.
- A DNSSEC child removes all its CDS records once the parent has synchronised; does the parent then delete the DS?No. Under RFC 7344 an absent CDS or CDNSKEY RRset means no change, and a polling parent must not delete or alter the DS set because of it. Removing the DS needs RFC 8078's explicit delete signal: a single, validly signed CDS or CDNSKEY record with algorithm 0.
saying these in an interview costs you the question
- Removing all CDS records tells the parent to delete the DS.
- A CDS RRset only needs the zone-signing key's signature, like other apex records.
- CDS lets a child enrol its very first DS with no extra checks.
- The parent must apply a CDS change the moment it sees one.
- CDS is still an Informational mechanism, not a standard.