In a DNSSEC-signed delegation, what do the DNSKEY, RRSIG, DS and CDS/CDNSKEY records each carry, and which zone publishes each one?
answer
- keys, signatures, pointers, requests
- same owner name, different zones
- DS sits above the cut
- the child asks, the parent decides
basics
~20 sDNSKEY holds a zone's public keys at the child apex; RRSIG signs each RRset beside it; DS, in the parent at the delegation, holds a digest of a child key; CDS and CDNSKEY at the child apex request the DS the child wants.
solid answer
~40 s`DNSKEY` (type 48) carries a zone's public keys and lives at the **child's** apex. `RRSIG` (type 46) carries a signature over one RRset and sits next to that RRset in whichever zone is authoritative for it. `DS` (type 43) carries a key tag, an algorithm number, a digest type and a digest of one child `DNSKEY`; it has the child's owner name but is authoritative data in the **parent** zone, signed with the parent's key (RFC 4034 §5). `CDS` (59) and `CDNSKEY` (60) have exactly the DS and DNSKEY formats but are published at the **child** apex: they state what the child wants the parent's DS RRset to look like (RFC 7344). So the child publishes keys, signatures and requests; the parent publishes the DS that vouches for the child.
go deeper
Recall the four names and one fact about each: keys, signatures, the parent's pointer, the child's request.
Explain why DS and DNSKEY share an owner name but live in different zones, and what fields the DS uses to point at the right child key.
Be ready to read a parent and child side by side and spot a DS with no matching DNSKEY, a CDS that disagrees with the published DS, or a signed delegation NS RRset.
Discuss why the design keeps the parent in control of the DS while giving the child a published request channel, and what that means for who can break a delegation.
## Four record types, two zones DNSSEC splits its data between the **child zone** (for example `example.net`) and the **parent zone** that delegates to it (`net`). The surprising part is that a DNSKEY and the DS that points at it have the *same owner name* yet live in *different zones* (RFC 4034 §5). | Record | Type value | What it carries | Published by | Where | |---|---|---|---|---| | `DNSKEY` | 48 | A public key: flags, protocol (always 3), algorithm, key material | Child | Child apex | | `RRSIG` | 46 | A signature over one RRset plus its validity window, key tag and signer's name | The zone authoritative for that RRset | Same owner name as the RRset | | `DS` | 43 | Key tag, algorithm, digest type and a digest of one child DNSKEY | Parent | Parent side of the delegation point | | `CDS` | 59 | DS-format records the child wants the parent to publish | Child | Child apex | | `CDNSKEY` | 60 | DNSKEY-format records the parent can turn into DS | Child | Child apex | ## DNSKEY: the keys A signed zone stores the public half of each signing key in a `DNSKEY` RRset at its apex. RFC 4034 §2 restricts the record to DNS zone keys: it MUST NOT be used to store certificates or unrelated public keys. RFC 4035 §2.1 adds that a zone meant to be more than an "island of security" MUST have at least one DNSKEY that can serve as a **secure entry point** — the key the parent's DS will point to. ## RRSIG: the signatures Every authoritative RRset in a signed zone gets at least one `RRSIG` with the same owner name and class, a `Type Covered` field equal to the RRset's type, and a `Signer's Name` equal to the zone name (RFC 4035 §2.2). Two placements are worth knowing: - The apex `NS` RRset of the child MUST be signed by the child. - The `NS` RRset at the delegation point in the parent, and any glue addresses, MUST NOT be signed — the parent is not authoritative for them. ## DS: the parent's pointer The `DS` record is how the parent vouches for the child. It does not copy the key; it holds a **digest** of the child DNSKEY's owner name and RDATA, together with that key's key tag and algorithm so a validator can find the right key quickly. Because it is authoritative data in the parent, the parent signs it with the parent's own keys. RFC 4035 §2.4 states the placement rules: 1. A DS RRset SHOULD be present at a delegation point when the child is signed. 2. All DS RRsets MUST be signed. 3. DS RRsets MUST NOT appear at a zone's apex. 4. The DS TTL SHOULD match the TTL of the delegating NS RRset. ## CDS and CDNSKEY: the child's request A child cannot edit the parent's zone, so RFC 7344 (published as Informational, elevated to Standards Track by RFC 8078) gives it a way to *say* what it wants. `CDS` uses the DS format and `CDNSKEY` the DNSKEY format, both at the child apex. The RRset is a **replacement** statement — "make the DS RRset look like this" — and an absent CDS/CDNSKEY RRset means "no change". Authoritative servers and resolvers treat them as ordinary records; only the party maintaining the parent's DS reads them. How that party polls, checks and applies them is a key-rollover concern, not part of the record layout. ## Reading the split correctly - Ask "who is authoritative for this data?" and you get the placement right every time. - The child owns its keys and its signatures; the parent owns the statement that those keys are the right ones. - The child's request (CDS) and the parent's statement (DS) use one format precisely so the parent can copy one into the other.
- Why does the DS record hold a digest of the child's key instead of a copy of the key itself?RFC 4034 §5 says the digest is enough to identify the key; the key tag and algorithm are added to make finding the matching DNSKEY efficient. The full key is fetched from the child's DNSKEY RRset, and the validator hashes it to compare. A digest is short and fixed-size per digest type, so the parent stores far less.
- Why can't a child zone simply publish its own DS record at its apex?RFC 4035 §2.4 forbids DS at a zone apex: the DS is meaningful only because the parent signs it with the parent's key. A DS the child signed with its own key would be the child vouching for itself, which adds nothing. That is why the child publishes a CDS request instead and the parent decides.
A DS record is the town hall's notarised fingerprint of a householder's key: anyone can compare the key the house shows against the fingerprint filed at the town hall. The householder can leave a signed note asking for the file to be updated (CDS), but only the town hall changes what it holds.
saying these in an interview costs you the question
- The DS record lives in the child zone, next to the DNSKEY it describes.
- The parent zone publishes a copy of the child's DNSKEY records.
- Validating resolvers read CDS records while checking a delegation.
- The NS RRset at a delegation point is signed by the parent zone.
- A DNSKEY record can store any public key, such as a server's TLS key.