skip to content

What do DNSSEC CDS and CDNSKEY records contain, where must a child zone publish them, and what does their delete form look like?

level: seniorimportance: nice to knowfreq 8%

answer

  1. borrowed formats, new type codes
  2. only at the apex
  3. replace, not add
  4. algorithm zero means delete

basics

~20 s

CDS (type 59) copies the DS format and CDNSKEY (type 60) the DNSKEY format; a child publishes them at its apex to state the DS RRset it wants. 'CDS 0 0 0 0' or 'CDNSKEY 0 3 0 0' asks for all DS removed.

solid answer

~50 s

RFC 7344 defines `CDS` with a wire and presentation format identical to `DS`, and `CDNSKEY` identical to `DNSKEY`, each using the same IANA registries for its fields. They MUST sit at the child zone apex and are signed like any other child RRset. The RRset is a **replacement** statement — what the child wants the parent's DS RRset to become — and no CDS/CDNSKEY at all means "no change". A child that publishes one SHOULD publish both, and their contents MUST match; a parent may compute DS from CDNSKEY using digest types it requires. RFC 8078, which also elevated RFC 7344 to Standards Track, adds the delete form: exactly one record, `CDS 0 0 0 0` or `CDNSKEY 0 3 0 0`, where algorithm 0 means "remove the whole DS RRset". Resolvers do nothing special with either type.

code

dns · 11 lines
dns
; request: make the parent's DS RRset match this
example.net. 3600 IN CDS 55648 13 2 (
        b4c8c1fe2e7477127b27115656ad6256f424625bf5c1
        e2770ce6d6e37df61d17 )
example.net. 3600 IN CDNSKEY 257 3 13 (
        GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
        krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )

; request: remove the parent's DS RRset entirely (RFC 8078)
example.net. 3600 IN CDS 0 0 0 0
example.net. 3600 IN CDNSKEY 0 3 0 0

go deeper

for a junior

Recall that CDS and CDNSKEY are copies of the DS and DNSKEY formats that a child publishes to ask its parent for a change.

for a middle

Explain the apex-only rule, replace semantics, why both records should match, and that resolvers ignore them.

for a senior

Read a child apex and the parent's DS together, tell a pending change from no change, and recognise the exact delete form.

for a principal

Judge when publishing a delete request is acceptable — for example a move to an operator that cannot sign — against the protection the delegation loses.

## Why these records exist A DS record lives in the parent zone, but the information it needs — the child's key — lives in the child. RFC 4035 §2.4 left that hand-off as "an operational matter". RFC 7344 gives the child a way to **publish** what it wants in its own signed zone, where the party maintaining the parent's DS can read it. It was published as Informational; RFC 8078 elevated it to Standards Track and added a delete signal and policies for enabling DNSSEC through these records. This answer covers what the records hold; the procedure the parent runs to poll, accept and apply them is a key-rollover topic. ## Two borrowed formats | Record | Type value | Format | Parent derives DS by | |---|---|---|---| | `CDS` | 59 | Identical to `DS`: key tag, algorithm, digest type, digest | Copying the record | | `CDNSKEY` | 60 | Identical to `DNSKEY`: flags, protocol 3, algorithm, public key | Hashing it with the digest types the parent requires | Both use the same IANA registries as the records they mirror, so a `CDS` with digest type 2 is SHA-256 and a `CDNSKEY` with algorithm 13 is ECDSAP256SHA256. RFC 7344 §3 states that authoritative servers and resolvers perform **no special processing**: for serving and resolving they are ordinary record types, and no validator consults them when building a chain of trust. ## The publication rules RFC 7344 §4 and §4.1 set the constraints on the records themselves: 1. **Location** — they MUST be at the child zone apex; a CDS anywhere else is ignored. 2. **Signer** — they MUST be signed with a key present in both the child's current DNSKEY RRset and the parent's current DS RRset, unless the parent is using them for initial enrolment and validates them by some other means. 3. **Continuity** — applying them MUST NOT break the current delegation. 4. **Both or matching** — a child that publishes either SHOULD publish both, and if it publishes both the contents MUST match; a child that knows which one its parent reads MAY publish only that one. A record that fails these conditions MUST be ignored and the error SHOULD be logged. ## Replace semantics, and what absence means The CDS/CDNSKEY RRset describes the **whole** DS RRset the child wants after the change; it is not a list of additions. Two readings follow: - If the child lists one key, the parent's result has one DS (or a DS per required digest type for that key), even if the parent held several before. - If there is **no** CDS or CDNSKEY at the apex, that means "make no change", not "delete". Once parent and child agree, RFC 7344 lets the child remove its CDS/CDNSKEY records to shrink the zone. RFC 7344 §6.2.1 also explains why a correct parent's DS can differ from the child's CDS: a parent in "calculate DS" mode builds DS from CDNSKEY and may use a different set of digest types. ## The delete form RFC 8078 §4 gives the previously reserved algorithm number **0** a meaning inside CDS and CDNSKEY only: remove the entire DS RRset at the parent, turning DNSSEC off for the delegation. The RRset MUST contain exactly one record with exactly these fields: - `CDS 0 0 0 0` - `CDNSKEY 0 3 0 0` — the 3 stays because the protocol field must always be 3. The zero algorithm is what signals deletion; RFC 8078 says the `0 0 0 0` spelling is mandated for clarity and is not itself a definition of digest type 0. Algorithm 0 stays reserved in DS and DNSKEY, and a validator that met it there would treat it as unknown. The delete records are signed exactly like ordinary CDS/CDNSKEY records. ## Reading a child apex - CDS lines read exactly like DS lines; CDNSKEY lines like DNSKEY lines. - Compare them with the parent's DS: a difference is a pending request. - A single zero-algorithm record is a request to go unsigned.

  • Why might a parent's published DS differ from the CDS its child publishes, even when both are correct?
    RFC 7344 lets a parent run in a calculate-DS mode: it fetches the CDNSKEY and computes DS itself with the digest types its policy requires, either only its own or in addition to the child's. The key is the same; the digest type set differs.
  • Why does the DNSSEC delete form of CDNSKEY still carry a 3 in its second field?
    The second field of a DNSKEY-format record is the protocol field, which RFC 4034 fixes at 3. Only the algorithm field set to 0 signals deletion, so RFC 8078 mandates `CDNSKEY 0 3 0 0` rather than all zeros.

saying these in an interview costs you the question

  • CDS uses a new record layout the parent must parse differently from DS.
  • A child may publish its CDS records at any name inside its zone.
  • Publishing a CDS adds those DS records to whatever the parent already has.
  • Validating resolvers consult CDS records when walking the chain of trust.
  • Removing every CDS record from the child tells the parent to delete the DS.