Why does a DNSSEC-signed zone usually use two keys, a key-signing key and a zone-signing key, and what does each one sign?
answer
- validators treat every zone key alike
- which key the parent points at
- how often each key is used
- where each private key can live
basics
~20 sA DNSSEC zone-signing key signs every authoritative RRset; the key-signing key signs only the apex DNSKEY RRset, which the parent's DS record points at. The split is operational: the ZSK rolls without the parent, and the KSK can stay offline.
solid answer
~40 sIn a split scheme the **zone-signing key (ZSK)** produces the `RRSIG` for every authoritative RRset in the zone, and the **key-signing key (KSK)** signs just one RRset: the apex `DNSKEY` RRset, which holds both public keys. The parent's `DS` record identifies the KSK, so the chain runs DS -> KSK -> DNSKEY RRset -> ZSK -> data. The reason is operational, not cryptographic (RFC 6781 §3.1): the ZSK is used constantly and must be reachable by whatever re-signs the zone, so it is replaced often, and replacing it needs no parent; the KSK is used rarely, so it can be kept offline or behind tighter access control, and changing it is the expensive event that involves the parent. Validators do not distinguish the roles, and a single combined key is legal.
go deeper
Remember the two jobs: the zone-signing key signs the records, the key-signing key signs the key set. The parent's DS record points at the key-signing key.
Explain the chain DS to KSK to DNSKEY RRset to ZSK to data, and why a ZSK change stays inside the child while a KSK change reaches the parent.
Argue the split from operations: how often each key is used, where each private key must live, and what an emergency replacement of each costs. Know when a combined key wins.
Frame it as risk against operating cost: offline protection and cheap ZSK changes on one side, extra keys and procedures on the other, judged against hardware storage and parent automation.
## Two roles, one kind of key A DNSSEC zone is signed with public-key pairs. The public half of each pair is published in a `DNSKEY` record at the zone apex; the private half creates `RRSIG` records, one signature per **RRset** (all records sharing an owner name, class and type). The protocol (RFC 4033-4035, collected as BCP 237 by RFC 9364) has only one kind of zone key. RFC 6781 §3.1 is explicit: "The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. The motivations to differentiate between keys are purely operational." Operators nevertheless usually give keys two roles: - **Key-signing key (KSK)** - signs only the apex `DNSKEY` RRset. It is the key the parent zone's `DS` record identifies, and by convention it carries the Secure Entry Point (SEP) flag, so its `DNSKEY` flags value is 257 rather than 256. - **Zone-signing key (ZSK)** - signs every other authoritative RRset: `SOA`, apex `NS`, `A`, `MX`, the denial-of-existence records and so on. - **Combined key** - RFC 6781 calls the alternative a **Single-Type Signing Scheme**: one key does both jobs. It is legal and sometimes the better choice. ## What each key signs | Signed data | Split scheme | Combined key | |---|---|---| | Apex `DNSKEY` RRset (both public keys) | KSK | the one key | | `SOA`, apex `NS`, `A`, `MX`, `TXT` and other authoritative RRsets | ZSK | the one key | | Denial-of-existence records | ZSK | the one key | | Delegation `NS` and glue in the parent | nobody - RFC 4035 §2.2 says they MUST NOT be signed | nobody | The resulting chain for the enterprise zone `example.com` is: 1. The parent's `DS` record for `example.com` holds a digest of the KSK's `DNSKEY` record. 2. The KSK's `RRSIG` over the `DNSKEY` RRset authenticates every key in that set, including the ZSK. 3. The ZSK's `RRSIG` records authenticate the zone's data. Because step 2 vouches for the whole set, "once a DNSKEY RRset is signed with the KSK, all the keys in the RRset can be used as ZSKs" (RFC 6781 §3.1). ## Why split: the operational argument RFC 6781 §3.1-3.3 gives the reasons, and none of them is cryptographic strength: - **Frequency of use.** Every zone change and every routine re-signing pass needs the ZSK. The KSK is needed only when the `DNSKEY` RRset changes or its signature nears expiry. - **Where the private key lives.** A key used constantly has to be online - on the signer or a reachable hardware module. RFC 4033 §9 notes that with dynamic update the ZSK must be online, while the KSK "can still be kept offline and may have a longer useful lifetime". RFC 6781's example is a KSK on a smartcard in a safe and a ZSK on a file system operators use daily. - **Cost of replacement.** Replacing a ZSK touches only the child zone: publish the new key, sign with it, re-sign the `DNSKEY` RRset with the KSK. Replacing the KSK means a new `DS` at the parent, or new trust anchors wherever the key was configured as one. So the ZSK gets a short planned lifetime (RFC 6781 suggests about a month for an exposed online key) and the KSK a long one. - **Not cryptanalysis.** RFC 6781 §3.1 works through the argument that a long-lived KSK needs a stronger key and concludes the size difference is "too insignificant to warrant a key-split". ## When one key is the better design RFC 6781 §3.1 lists the conditions under which the split earns least: keys held in hardware modules, so exposure is already low; certainty that the key is not configured as a trust anchor; key maintenance that cannot be done through tools; and predictable DS updates at the parent, even in an emergency. When those hold, "choosing a Single-Type Signing Scheme is a reasonable option". The price is that every planned key change becomes a parent interaction. ## What a validator actually checks The roles are invisible to resolvers. The SEP flag is "only intended to be a hint" and validators "MUST NOT alter their behavior" based on it (RFC 4034 §2.1.1). A validator needs a `DNSKEY` matching the parent's `DS` that has the Zone Key flag set and has signed the apex `DNSKEY` RRset (RFC 4035 §5.2); after that, any key in the authenticated set may verify the data. A zone that signs everything with its SEP-flagged key validates exactly as well as one that splits the roles - the split protects the operator, not the protocol.
- Does a validating resolver treat a DNSKEY flagged 257 differently from one flagged 256?No. Bit 15 is the Secure Entry Point flag, and RFC 4034 §2.1.1 says validators `MUST NOT` alter their behaviour because of it - it is a hint for signing and debugging tools. What a validator checks is that the key matching the parent's `DS` has the Zone Key bit set and has signed the apex `DNSKEY` RRset; after that, any key in the authenticated set may verify data.
- If the ZSK's private key is stolen, which zones have to act?Only the child. The parent's `DS` identifies the KSK, so the operator publishes a new ZSK in the `DNSKEY` RRset, re-signs the zone's data with it, re-signs the `DNSKEY` RRset with the unchanged KSK and then withdraws the stolen key. Until the old key has left the published set and resolvers' cached copies, its forgeries can still verify, which is why the replacement's timing matters.
- Can an enterprise zone run on a single combined key?Yes. RFC 6781 calls it a Single-Type Signing Scheme and suggests setting the SEP flag on every key in that case. It is reasonable when the key sits in a hardware module, is not a trust anchor, and DS changes at the parent are predictable. The cost is that each planned key change now involves the parent, and the one key must be as available as a ZSK.
A company's bank mandate names one authorised signatory, and the bank keeps a copy of that signature. The signatory signs a letter listing which office stamps are genuine; staff stamp daily paperwork. A worn or stolen stamp is replaced by a new signed letter, with no visit to the bank; replacing the signatory means re-registering with the bank.
saying these in an interview costs you the question
- The DNSSEC protocol requires separate key-signing and zone-signing keys.
- The parent's DS record points at the zone-signing key.
- Replacing the zone-signing key needs a new DS record at the parent.
- The KSK signs only the ZSK's record, and the ZSK signs the KSK back.
- The split exists because the KSK must be cryptographically much stronger.
- Validators refuse data signed by a key whose SEP flag is set.