Skip to main content

ICANN is Revoking the Old Key Signing Key This Week

If you followed the rollover to the new root zone Key Signing Key (KSK) on 11 October 2018, you might have thought the process is now complete. However, there are a few more important technical steps that need to take place before the KSK rollover is finished. One of those steps is revoking the old key, which will happen on 11 January 2019.

The root zone currently contains two KSKs: the old one (called "KSK-2010") and the new one (called "KSK-2017"). Since the rollover, only KSK-2017 is used for signing the root zone's key set, which is all the Domain Name System Security Extensions (DNSSEC) keys at the root. Now that KSK-2010 is no longer used to generate signatures, it is time to mark the key as revoked and remove it from the root zone.

Before we remove KSK-2010 from the zone altogether, we want to mark that key as revoked for all the resolvers that follow the "Automated Updates of DNSSEC Trust Anchors" standard (RFC 5011). By marking the old key as revoked, any system that uses RFC 5011 will see that KSK-2010 is no longer valid and will not trust that key in the future. The revocation mark will be visible until 22 March 2019, at which point KSK-2010 will be completely removed from the root zone forever.

The revocation will cause the size of the root zone's key set to grow slightly. The ICANN organization does not expect problems with the revocation. However, this is the first time a KSK in the Domain Name System (DNS) root has been revoked, so the ICANN org and the DNS technical community will be watching carefully for at least 48 hours after the publication of the revoked KSK-2010.

The ICANN org strongly encourages vendors no longer ship KSK-2010 in their products. Similarly, anyone who is maintaining their list of DNS root trust anchors by hand should remove KSK-2010 from their configurations.

We will report any significant issues that we see on the mailing list, our normal place for communicating about the KSK rollover.


    romi gupta  02:57 UTC on 08 March 2019

    hi, nyc post thankq for sharing this

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."