skip to content

A registrar must DNSSEC-sign 10,000 customer zones it hosts; how would you choose between a KSK/ZSK split and a combined key, and where would the keys live?

level: principalimportance: nice to knowfreq 6%

answer

  1. the conditions where the split earns least
  2. an offline key times ten thousand
  3. hardware-held keys online
  4. spread the expiry times out

basics

~20 s

A registrar signing 10,000 DNSSEC zones is well served by one combined key per zone, held online in hardware, with automated DS updates. An offline key-signing key per zone cannot keep pace with DNSKEY signatures that expire on every zone.

solid answer

~50 s

Start from RFC 6781 §3.1: the KSK/ZSK split earns least when keys sit in hardware modules, the keys are not trust anchors, and DS changes at the parent are predictable. A registrar hosting customer zones usually meets all three - the keys are generated and held in its own hardware, nobody should anchor on a customer's key, and the registrar itself submits DS records toward the registry. A **combined key per zone**, online in a hardware module, therefore fits: one key and one signature in each `DNSKEY` answer, and no offline ceremony per zone. An offline KSK does not scale, because each zone's `DNSKEY` RRset signature expires and must be renewed with that key. I would use per-zone keys rather than one shared key, ECDSA P-256 for size and signing throughput, and jittered validity windows so 10,000 zones do not expire together. For the registrar's own high-value zone the answer flips: split, with the KSK offline.

go deeper

for a junior

Recall that a DNSSEC zone can be signed with two keys in separate roles or with one combined key, and that both validate the same way.

for a middle

Explain why an offline key-signing key must be used again whenever a zone's DNSKEY RRset signature nears expiry or the key set changes.

for a senior

Size the operational load of each scheme for many zones: signing events, DS updates, re-signing peaks and the monitoring that catches a stalled pipeline.

for a principal

State a policy per zone class with RFC 6781's criteria behind it, and defend where offline protection is worth its ceremony cost and where automation is safer.

## The question behind the question DNSSEC itself is indifferent: validators do not distinguish key roles (RFC 6781 §3.1), and a zone signed with one combined key - a **Single-Type Signing Scheme** - validates exactly like a zone with a **key-signing key (KSK)** over the `DNSKEY` RRset and a **zone-signing key (ZSK)** over everything else. The decision is about operating risk and cost, and it comes out differently for 10,000 customer zones than for one enterprise zone. ## What RFC 6781 says decides it RFC 6781 §3.1 says the argument for the split is weakest when: - **exposure is already low**, for example keys held in hardware security modules; - **the key is certainly not a trust anchor**; - **key maintenance cannot be done through tools** and so is prone to human error; - **the child-to-parent DS path is predictable**, even in an emergency. It adds that some hardware modules keep keys online while still protecting them, and "in those cases, a KSK-ZSK split is not more beneficial than the Single-Type Signing Scheme". ## Applying it to the registrar | Factor | 10,000 customer zones | One enterprise zone | |---|---|---| | Key protection | Hardware module, online | Offline KSK practical | | Trust-anchor risk | Very low | Possible inside the enterprise | | DS path to parent | Registrar submits DS itself | A registrar ticket or console | | Key ceremonies | Impossible per zone | A few per year | | Leaning | Combined key per zone | KSK/ZSK split | The offline-KSK model breaks on arithmetic. The KSK's signature over each zone's `DNSKEY` RRset has a validity window like any other `RRSIG`, so it must be renewed before it expires, and again whenever the RRset changes. With 10,000 zones and, say, a 21-day validity period, an offline KSK per zone means about 476 offline signing events a day, or a long-lived pre-signed bundle of future `DNSKEY` signatures per zone that has to be redone at every key change. The registry-registrar model also helps the other way: RFC 6781 §4.3.1 describes key material passing from the DNS operator to the parent via a registrar, so for zones it both hosts and sponsors the registrar controls that path, and DS updates can be automated and tested. ## The design I would propose 1. **One combined key per zone, online in a hardware module.** Each zone publishes one `DNSKEY` with the SEP flag (RFC 6781 §3.2.3 suggests the flag on all keys in a single-type scheme) and one signature over the key set. 2. **Per-zone keys, not one shared key.** A `DNSKEY` record's owner name must be the zone (RFC 4034 §2.1.1), and the DS digest covers owner name and key data (RFC 4035 §5.2), so each zone needs its own DS either way. Reusing private key material across zones saves nothing at the parent and turns one compromise into 10,000; separate keys also keep one customer's key change contained. 3. **ECDSAP256SHA256 (algorithm 13).** 64-octet keys and signatures keep answers small, signing is fast, and validators must implement it under the IANA registry entries RFC 9904 made canonical. 4. **Staggered signing.** Spread validity periods with jitter and offset each zone's re-signing schedule, so 10,000 zones do not expire, re-sign and transfer at the same hour (RFC 6781 §4.4.2.2). 5. **Monitoring by expiry.** Alert on the earliest `RRSIG` expiration served for every zone on every authoritative server - a stuck pipeline across 10,000 zones fails all at once. ## Where the split still wins - **The registrar's own zones** - its brand domain, its name-server domain - are few and high-value. A KSK kept offline, used a few times a year, limits what a compromise of the signing platform can do. - **Customers who bring their own keys** or sign elsewhere are a separate case; their DS comes in through the registrar's interface, and its authentication should be as strong as the registrar's for delegation changes (RFC 6781 §4.3.1). The defensible answer is not "always split" or "never split" but a stated policy per zone class, with the reasons RFC 6781 gives and a tested path for the emergency replacement of each kind of key.

  • Why not sign all 10,000 customer zones with one shared private key?
    It saves nothing at the parent - the DS digest covers the zone's owner name, so each zone needs its own DS anyway - and it ties every zone's fate to one secret. A single leak or a single forced replacement then touches 10,000 delegations at once, and moving one customer to another operator gets harder. Per-zone keys in the same hardware module cost little more.
  • Which part of the registrar's own estate would you still give an offline key-signing key?
    Its own few high-value zones, such as the brand domain and the domain its name servers live in. They change rarely, their DNSKEY RRset needs re-signing only a few times a year, and an offline KSK there limits the damage if the online signing platform is compromised. The ceremony cost is acceptable for a handful of zones, not for ten thousand.

saying these in an interview costs you the question

  • Every DNSSEC zone must have a separate key-signing and zone-signing key.
  • An offline key-signing key scales to thousands of zones with no extra work.
  • Sharing one private key across all customer zones carries no extra risk.
  • Re-signing every hosted zone at the same hour is simplest and harmless.
  • Keys held in a hardware module still must be split to be safe.