Skip to main content

ICANN Launches Testing Platform for the KSK Rollover

13 March 2017 – ICANN is offering a testing platform for network operators and other interested parties to confirm that their systems can handle the automated update process for the upcoming Root Zone Domain Name Systems Security Extensions (DNSSEC) Key Signing Key (KSK) rollover. The KSK rollover is currently scheduled for 11 October 2017.

"Currently, seven hundred and fifty million people are using DNSSEC-validating resolvers that could be affected by the KSK rollover," said ICANN's Vice President of Research, Matt Larson. "The testing platform is an easy way for operators to confirm that their infrastructure supports the ability to handle the rollover without manual intervention."

Internet service providers, network operators and others who have enabled DNSSEC validation must update their systems with the new KSK. This can be done in one of two ways:

  • An operator can configure a new trust anchor manually by obtaining the new root zone KSK from the iana.org website at https://www.iana.org/dnssec/files.
  • An operator can enable a feature available in many validating resolvers that automatically detects and configures a new root zone KSK as a trust anchor, in which case they need take no action.

Check to see if your systems are ready by visiting go.icann.org/KSKtest.

The KSK has been widely distributed and configured by every operator performing DNSSEC validation. If the validating resolvers using DNSSEC do not have the new key when the KSK is rolled, end users relying on those resolvers will encounter errors and be unable to access the Internet. A careful and coordinated effort is required to ensure that the update does not interfere with normal operations.

More information is available at www.icann.org/kskroll.


More Announcements
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""icann.org"" is not an IDN."