The first Root Zone Key Signing Key was generated June 16, 2010, at 21:19 (UTC) during a key ceremony in Culpeper, VA. The DS record for the generated key is:

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

The full DNSKEY representation of the public key will be published shortly after the second ceremony, which is scheduled for July 12, 2010. At this ceremony, the generated key will be installed at the West Coast Key Management Facility in El Segundo, CA. The generated KSK is to be considered provisional until it has been safely installed in both facilities.

Kirei was represented at the key generation ceremony by Jakob Schlyter and Fredrik Ljunggren, both holding the roles as External Witnesses (EW).

Fredrik and Jakob attests that the key ceremony was executed according to the key ceremony script. This PGP signature may be used to verify the DS record’s authenticity.

With DNSSEC for the root zone going into production in a couple of weeks, it is now possible for Top Level Domain (TLD) managers to submit their Delegation Signer (DS) information to IANA. But what does this really mean for a TLD? In this post we’re going to try to sort that out.

(more…)

As many of you know already, Kirei – as part of the Root DNSSEC Design Team, and on behalf of ICANN – has a central role in implementing DNSSEC for the Root Zone. The team, consisting of a group of Internet and security experts from ICANN, VeriSign and Kirei, has been working closely together with the primary objective of implementing a stable and secure solution for DNSSEC at the Root Zone ready by July 2010.

For the last 10 months, we’ve been working on a number of important issues, including:

• Designing the overall system- and security architecture of the signer and key management system based on the requirements from U.S. Department of Commerce, National Telecommunications and Information Administration (DoC/NTIA).
• Drafting the DNSSEC Practice Statement (DPS) for the KSK and ZSK holder (i.e. ICANN and VeriSign, respectively), and publishing of a DPS framework for other registries to benefit from
• Communicating the progress and gather feedback from the community
• Establishing of Trust anchor publication mechanisms
• Increasing transparency and community trust by introduction of the Trusted Community Representatives into the signing process
• Defining physical security controls and requirements for the KSK operators facilities
• Preparation to undergo a SysTrust examination of the Root Zone KSK Operator function
• Work out key ceremonies, testing of the scripts and carry out rehearsals
• Develop deployment plans and interface with the root server operators
• Perform testing of resolver implementations

Kirei is very proud to be part of this landmark project and believe that a signed root is an important step for improving the security of the DNS infrastructure.

For more information about DNSSEC for the Root Zone, please visit the website at http://www.root-dnssec.org/.

In deployment scenarios where you require dynamic updates, or want to use a HSM which requires multiple threads for decent signing performance, OpenDNSSEC version 1.x come short. There are plans for how to address this in version 2.x, but fortunately there are other options until then. When designing OpenDNSSEC I’ve always tried to keep the different modules clearly separated and the interface between them well defined. This is something that recently paid off, when I started out replacing the OpenDNSSEC signer engine with ISC BIND.

By using the OpenDNSSEC key manager, the KASP Enforcer, for managing signing keys and cryptographic parameters and then convert this information into a format that ISC BIND can read, one can replace the original signer engine with BIND. This works for both offline signing (i.e. when the zone is first signed, then loaded into a name server) and for online signing (i.e.when the zone is signed while BIND is running).

My tests with BIND 9.7.0rc2 looks very promising and it looks like this could be a viable alternative for those who are want to sign their dynamically updated zone, but doesn’t want to bother with manual key management.

Last week, Kirei in co-operation with .SE, John A Dickinson, NLnet Labs, Nominet, SIDN and SURFnet, released a technology preview of OpenDNSSEC.

• Press release

Awaiting the signing of the root zone there has been an extensive discussion regarding who should control the cryptographic key signing key (KSK) forming the basis for validating the root zone, and consequently also all lower-level domains of the Domain Name System (DNS). At stake is the trust in the root zone and the confidence for the corporation administering and implementing it, i.e. ICANN. The threat they’re trying to avert is a partitioning of the Internet into several alternative root zones. To strengthen ICANN’s legitimacy and the trust in the root zone some people are advocating that the control of the key signing keys should be divided between several interest groups through so called M-of-N control.

The security technique of M-of-N aims to obstruct or prevent individual officials from disregarding stipulated security practices. The technical means of control in using M-of-N are based on the regulation of access to a physically protected signing unit (a security module, HSM), including key storage and manipulation protection, which requires M-of-N officials to be present during key operations. This access control does not normally mean that the key material itself is divided between the officials, it only relates to the security module access.

Even if it is cryptographically possible to share a data set through M-of-N, it is highly impractical, and furthermore makes it possible for a group of collaborating officials to compromise the key material. Division of the key material weakens the confidentiality protection of the private keys, and therefore counteracts the objective to strengthen the trust in them.

Access regulation through M-of-N control is also no appropriate way of delegating (part of) the operational responsibility to other organizations. The operating environment will become too vulnerable, and may suffer serious consequences if the required individuals can’t or won’t turn up, (for whatever political or practical reasons), on short notice to perform the cryptographic operations needed.

In all respects the objective should be a reduction of complexity in root zone administration and management. Organizational, political and technical stability should be the primary objective, and then the trust in it will follow suit.


A common misunderstanding is that the trust in the root key is superior to the confidence in ICANN. In reality, it is the other way around. The trusting parties can choose for themselves who they have confidence in, by pointing their name servers at the ICANN root and configure the trust anchor published by ICANN. The question of who is controlling and performing the signing operations is unimportant as long as the content of the zone is being controlled. The implementation of M-of-N across several organizations will instead increase the risk of introducing uncertainties that in the long run can counteract the objective of preventing a division of the Internet namespace. The trust in the root is also not dependent upon being able to transfer the key material to another organization, since the new organization will still have to use new keys and prove itself reliable in the same way. Having earned people’s trust does not equal to controlling the key material.

We consider there to be no reason for complicating the management of the root zone through involving several different parties in necessary key operations. M-of-N control should only be used within the managing body as a way of strengthening the confidence in the integrity of the root zone.

At the end of the day, trust is a soft value that does not depend solely on this technical means of control.