Summary

  • DNSSEC’s first root-zone key-signing key was not created in the same instant that the signed root went live. A first ceremony at Culpeper generated KSK-2010; a second at El Segundo imported it, established the western facility’s role and completed another operational step.
  • The public timeline separates the ceremonies on 16 June and 12 July 2010 from the first production signed root on 15 July. Checklists, divided duties, witnesses, cameras, hashes and published logs made parts of custody inspectable; they did not prove universal resolver adoption.

The signature was the last visible step

On 15 July 2010, IANA announced that the root zone was signed. It was a short public statement attached to a long operational chain. The root’s DNSKEY set now carried a cryptographic signature, and signed root data could begin moving through the existing distribution system. The announcement did not say that every recursive resolver had enabled validation, nor could a ceremony compel that outcome. It marked a change in the root zone’s published data.

The key behind that change had been prepared in two places. IANA’s ceremony archive records the first DNSSEC key-management ceremony at its East facility in Culpeper, Virginia, on 16 June. The second took place at the West facility in El Segundo, California, on 12 July. IANA’s launch chronology then dates the first production signed root to 15 July. The three dates describe distinct acts: creating and using the key in a controlled setting, completing a second facility’s preparation, and operating the production signing path.

That distinction matters because “the root was signed” can sound like a single switch. It was instead a custody and operations problem distributed across people, equipment, evidence, and organizations. A cryptographic key is useful only if the system can show how it was generated, restrict who can cause it to be used, recover safely from failure, and connect its output to the published root data.

Ceremony 1: generation at Culpeper

IANA’s record for Ceremony 1 gives a start time of 17:00 UTC on 16 June. The event ran across midnight UTC; a contemporaneous ICANN presentation places the end at 00:25 UTC on 17 June. Later documents that call the generation date 17 June are describing the same session from its UTC completion date. Keeping the boundary visible prevents an apparent one-day disagreement from becoming a false chronology.

The ceremony’s published objectives were specific: instantiate the East key-management facility, generate KSK-2010, and sign the third-quarter 2010 zone-signing keys. These were not interchangeable jobs. The root-zone KSK signs the root DNSKEY key set. The root-zone maintainer uses a separate zone-signing key to sign the root zone’s records. DNSSEC’s hierarchy lets a validator follow a chain of signatures from a trust anchor through delegated data; it does not mean that one key directly signs every record at every level.

The archive exposes material that lets an outside reader inspect the event’s documentary boundary: scripts, SHA-256 manifests, an ISO image, three camera recordings, and a key-generation log named kskgen-20100616-211906.log. Those files are evidence that particular records were published and associated with the ceremony. They do not allow a distant reader to watch every physical action independently or establish that no undisclosed event occurred. Their value is narrower and more practical: they make the operator’s account reproducible enough to be checked against expected steps and artifacts.

People were assigned distinct duties. ICANN’s 7 June announcement described 14 Trusted Community Representatives, independent of ICANN, VeriSign and the US Department of Commerce, each with a separate key-management role. A contemporaneous ICANN38 presentation later counted 16 representatives present in role categories that included Crypto Officers, Recovery Key Share Holders and backups. These numbers answer different questions—volunteers announced for the programme versus attendees mapped to roles—and should not be collapsed into one definitive headcount.

The same presentation described internal staff, an auditor, a VeriSign representative and a camera operator alongside the representatives.

Ceremony 2: a second facility becomes operational

The second ceremony took place on 12 July at the West key-management facility in El Segundo. IANA records its start at 20:00 UTC and lists the objectives as instantiating the western facility, importing KSK-2010 and signing the fourth-quarter 2010 ZSKs. Its archive includes scripts, checksums, video and a log named ksrsigner-20100712-224426.log.

IANA’s launch update says the second event transported key materials west, imported or replicated the key there, and completed the next-quarter signing process. It also says VeriSign accepted the signed response. The public record therefore shows more than a symbolic second room: the western facility participated in the operating chain and returned an output accepted by the root-zone maintainer. It does not establish that one facility held the only copy throughout the key’s lifecycle. The sources describe a controlled multi-facility arrangement, not a single-box story.

The two-site design addressed continuity as well as secrecy. A root key locked into one building or one narrow team would be vulnerable to local failure, lost access or an unavailable custodian. Replication and recovery arrangements create their own risks: more people and artifacts must be controlled, and the system must prove that copies correspond to the intended key. The ceremonies made these tradeoffs procedural. Trusted representatives, role separation, secure equipment, rehearsals, scripts, logs and audit were meant to make exceptional access difficult and ordinary work repeatable.

A public signature, then a pause to observe

On 15 July, IANA announced that the root zone was signed. A short change moratorium followed from 15 to 20 July so operators could observe effects and mitigate problems. The moratorium is a reminder that producing signatures and operating them safely were separate tasks. Deployment required the changed root data to pass through publication and distribution, while resolvers and their administrators still had to decide whether and how to validate it.

The US National Telecommunications and Information Administration’s 28 May report described a divided control surface: IANA/ICANN was responsible for the KSK, VeriSign for signing and distributing the full root zone with ZSKs, and NTIA for authorizing root-zone changes under the arrangement then in force. That pre-launch report also said some authorization tests were incomplete at the time it was written. It is therefore evidence of the planned responsibilities and open work in May, not proof that all checks had already passed. The later July status updates record launch completion.

What a ceremony could prove

The event’s legitimacy claim was deliberately procedural. A checklist could show that required steps were followed. Separate roles could make unilateral action harder. Multiple recordings, hashes and audit materials could support review. Representatives without institutional employment ties could witness that operators followed the agreed process. Together, those controls offered a public chain of evidence around a private key operation.

They could not settle every political question about who should administer the root, nor certify the intentions of every participant. They also could not prove worldwide security merely by existing. A signed root gives validating resolvers a way to detect forged or altered DNS data along the chain they trust. A resolver that does not validate does not gain that protection simply because the root key ceremony was carefully run. Nor does the signature establish that a domain’s content is truthful, that a server is safe, or that a name’s owner is socially legitimate.

That is the useful scale of the story. The first ceremony did not make the Internet trust ICANN by decree. It created a key under a documented procedure; the second made the other facility part of the custody and signing operation; production followed after additional change control. Publication of records let technical readers inspect the process without making them participants in it. In Heng Lu’s terms, the ceremony is best read as a coordination procedure whose claims still meet an operational test: the key had to produce signatures that the root-zone system could accept and distribute.

The historical record supports that narrower conclusion more firmly than any claim of universal adoption.

The 2010 launch also established a baseline for later KSK ceremonies and eventual rollover. Those later events concerned replacing or maintaining a key already in service and testing whether resolvers could follow a change. They are not the same story as making the first root KSK. In 2010, the central question came earlier: how could a new cryptographic authority be made, stored, moved and operated in a way that left enough evidence for others to inspect its use?

Sources

Additional later context, not evidence for the 2010 event