A signed zone has at least one key, and most have two with different jobs. Which arrangement a zone uses is visible in one query, and it determines how much work a rollover is.
Reading the flags
256 3 13 Zone Signing Key (ZSK) 257 3 13 Key Signing Key (KSK)
| Flag | Role | Signs | Referenced by |
|---|---|---|---|
257 | Key Signing Key | The DNSKEY RRset only | The DS record at the parent |
256 | Zone Signing Key | Every other RRset in the zone | Nothing outside the zone |
The split exists so the two can be managed differently. The ZSK signs constantly and can be rolled freely, because nothing outside the zone refers to it. The KSK is referenced by a DS record in the parent zone, so rolling it requires the parent to be updated — and that is the rollover that goes wrong.
One key instead
A Combined Signing Key does both jobs. Only a 257 appears:
257 3 13
| KSK + ZSK | CSK | |
|---|---|---|
| Keys to manage | Two, with different schedules | One |
| Rolling the signing key | Local to the zone. No parent involvement. | Requires a DS update at the parent, every time. |
| Zone size | Larger — the DNSKEY RRset carries both | Smaller |
| Suits | Zones where the ZSK is rolled often, or a large operator | Modern ECDSA zones with infrequent rollovers |
The CSK became reasonable when algorithms got small. With 2048-bit RSA there was a real argument for a long-lived KSK and a short-lived ZSK; with ECDSA P-256 the keys are tiny and the operational simplicity of one key usually wins.
Whichever you have, the DS is the thing that breaks
The parent’s DS record is the only part of your DNSSEC configuration that lives somewhere you do not control. Every serious DNSSEC outage is either an expired signature or a DS that no longer matches the key it names, and a CSK means you meet the second one more often.