When should a DNSSEC zone be signed online at query time rather than pre-signed by a signer, and what does each choice cost the operator?

## Two ways to produce signatures A validating resolver cannot tell how an `RRSIG` was made; it only checks the signature against a key in the zone's authenticated `DNSKEY` RRset. The choice between signing ahead of time and signing on demand is therefore entirely the zone operator's, and it is mostly a choice about **where private keys live** and **when the cryptographic work happens**. - **Pre-signed (offline) signing** - a signer processes the whole zone, adding an `RRSIG` to every authoritative RRset and building the denial-of-existence records, and the result is transferred to the authoritative servers, which serve it as static data. - **Online signing** - the authoritative server holds a private key and creates signatures, and denial records, while it builds each response. ## Pre-signed zones RFC 6781 §3.4.3 describes the most protective arrangement: keep the zone master copy and private keys on "off-line, non-network-connected, physically secure machines", periodically sign, and transfer the signed file to the primary. A common compromise is a **hidden primary**: a signing server not listed in the NS RRset that feeds the public secondaries by zone transfer. What it buys and what it costs: - Private keys never sit on the servers the Internet queries. - Serving costs no cryptography; a flood of queries is just a flood of lookups. - Every edit is a signing event: changed RRsets are re-signed, the SOA serial increases, the `SOA` RRset is re-signed, and NOTIFY and transfers follow (RFC 4033 §8.2). - Even an unchanged zone must be re-signed before its signatures expire. - The signed zone is much larger than the unsigned one, and its denial chain is computed in advance. ## Online signing Some answers do not exist until a query arrives: a reply tailored to the asker, a name synthesised from a large backing database, or a minimally covering denial record built around the queried name, which is what RFC 4470 ("white lies") and RFC 9824 (Compact Denial of Existence) define. Those must be signed when they are made. Both RFCs list the costs in their security considerations: 1. **Key exposure.** "On-demand signing requires that a zone's authoritative servers have access to its private keys" (RFC 4470 §5), and keys on Internet-reachable servers are more exposed (RFC 9824 §8). 2. **Computational denial of service.** Signing per response is far more work than returning a stored signature, so an attacker can try to exhaust the servers' CPU. 3. **Algorithm choice follows.** RFC 9824 §8 recommends algorithms "that have a comparatively low cost for signing", such as elliptic-curve ones; RFC 6605 reports ECDSA signing more than 20 times faster than RSA in some implementations, while RSA verification is about 5 times faster. Dynamic update forces a related compromise. RFC 4033 §9 says the private half of each key should be kept offline "if possible", but with dynamic update the primary "will have to re-sign the zone when it is updated, so the private key corresponding to the zone signing key will have to be kept online" - and RFC 4033 §12 notes that a stream of updates can force needless re-signing. ## The key-signing key need not follow The KSK/ZSK split is what makes online signing tolerable. The KSK signs only the apex `DNSKEY` RRset; that RRset changes rarely, so its signatures can be produced in advance on an offline system and handed to the online servers. RFC 4033 §9 says exactly this: in the dynamic-update case the key-signing keys "can still be kept offline and may have a longer useful lifetime". A stolen online ZSK is then replaced without involving the parent. ## Choosing | Question | Pre-signed | Online | |---|---|---| | Private key on public servers? | No | Yes, the signing key | | Signing work per query | None | One or more signatures per response | | Cost of a zone edit | Re-sign, bump serial, transfer | No stored signatures to redo | | Answers computed per query | Not possible | Supported | | Best-fit algorithm | Any recommended one | Cheap-to-sign, typically ECDSA | A zone that changes slowly and answers the same way to everyone should be pre-signed. A zone whose answers are synthesised, or that needs minimally covering denial records, signs online - with the ZSK in a hardware module or as tightly held as the servers allow, rate limits and capacity sized for signing, and the KSK kept away from the servers.