DNSSEC works as a chain of signatures. Your resolver trusts .com's keys because the root zone signs a hash of them. It trusts a domain's keys because .com signs a hash of those. At the top of every one of those chains sits a single cryptographic key: the root zone Key Signing Key, the KSK. Resolvers around the world ship with its public half baked in as the trust anchor. There is no key above it. If it were ever stolen or misused, an attacker could sign a forged version of the root zone and make forged DNS data validate everywhere DNSSEC is checked.
So the interesting question is operational rather than mathematical: how do you use a key like that for decades without ever exposing it?
Two Rooms, Seven Keyholders, One Script
The private half of the KSK exists only inside hardware security modules, tamper-resistant devices certified to FIPS 140-2 Level 4, the tier where the hardware is expected to destroy its secrets if someone tries to open it. Those HSMs are kept powered off, in safes, inside layered access-controlled rooms at two ICANN facilities on opposite coasts of the United States: El Segundo, California and Culpeper, Virginia. Each site is a full copy of the other, so the loss of one facility does not take the key with it.
The HSMs will not operate for any single person. Activating one requires smart cards that are locked in individual safe deposit boxes, and the keys to those boxes are held by trusted community representatives: volunteers from the global DNS community, deliberately from many countries, screened and appointed for the role. Each site has seven of these crypto officers, and it takes three of them, physically present with their physical keys, to bring the HSM online. No ICANN employee can sign anything alone. Neither can any three employees. The people who control access to the key do not work for the organization that runs the ceremony.
The KSK does not sign DNS records directly, and it is far too sensitive to keep online. It signs the root zone's key set, which endorses a separate Zone Signing Key operated by Verisign. The ZSK does the day-to-day signing of the root zone. Ceremonies exist to produce a fresh batch of those KSK signatures covering the months ahead, which is why the key only needs to wake up a few times a year.
What Actually Happens in the Room
A ceremony is not a meeting. It is the execution of a published script, dozens of pages of numbered steps, read aloud and performed one at a time in front of witnesses, auditors, and cameras. Participants sign in past biometric checks. Equipment comes out of tamper-evident bags whose serial numbers are read aloud and checked against the log from the previous ceremony. The laptop that talks to the HSM has no battery, no disk of note, and boots from read-only media. When the crypto officers' cards have been retrieved from their boxes and the HSM comes online, the signing requests are loaded from an encrypted USB stick, verified, signed, and carried back out. Then everything goes back into new tamper-evident bags, serial numbers are read into the record, and the safes close.
Every ceremony is livestreamed, and the recordings, scripts, logs, and audit reports are published on IANA's website afterward. A third-party auditor attests that the script was followed. Anyone, anywhere, can watch the footage and check the paper trail. That is the actual security model: not that you trust ICANN, but that a deviation from the script would have to happen on camera, in front of external witnesses, and survive an independent audit.
The security of the root key does not rest on secrecy about how it is handled. It rests on the opposite: a process so public and so constrained that misuse would be visible.
The Rollover That Took Eight Years
The original KSK was generated in 2010, when signing the root was new. Replacing it was always the plan; doing so meant every validating resolver on the internet had to learn a new trust anchor. The replacement key, KSK-2017, was generated and the switch scheduled for October 2017. Then telemetry defined in RFC 8145, which lets resolvers report which trust anchors they hold, showed that a worrying number of resolvers still only knew the old key. Flipping the switch would have broken DNS resolution for their users. ICANN postponed the rollover for a full year and finally rolled the key on October 11, 2018. The failures that followed were minor and short-lived.
That episode is the clearest picture of what makes the root key hard. The cryptography of generating a new key takes minutes inside an HSM. Convincing the installed base of the entire internet to follow along takes years of measurement and patience, and a mistake is felt as a global outage. It is also why ceremonies have kept running through everything since, including 2020, when pandemic travel restrictions forced ceremonies with the minimum possible staff, ICANN employees drilling open a safe deposit box on camera under remote observation by the crypto officers who could not fly in.
What This Model Can and Cannot Give You
It is worth being precise about what all this ceremony protects. It protects the integrity of the chain: the assurance that a DNSSEC-validated answer was signed by the holder of the real chain of keys. It does nothing about what the chain chooses to sign. The root zone's contents are decided by an administrative process, and DNSSEC will faithfully authenticate whatever that process publishes. Signature ceremonies authenticate; they do not adjudicate.
The single-anchor design also cuts both ways. The web PKI distributes trust across scores of certificate authorities, any one of which can issue for any site, which is why Certificate Transparency exists to watch them all. DNSSEC concentrates trust in one anchor and then spends extraordinary effort guarding it. One model has many doors and cameras on all of them; the other has one door and a vault. Protocols like DANE only make sense because that one vault is guarded well enough to hang TLS trust from it.
The ceremony's split of one secret across many hands is an old idea with a modern cryptographic cousin; if the m-of-n structure interests you, Shamir's secret sharing is the mathematical version, and key transparency is what the same instinct for auditable key handling looks like in end-to-end encrypted messaging.