Export Compliance Daily is a Warren News publication.

ICANN Issues Guide on What to Expect During Root KSK Rollover

ICANN, which plans to change the domain name system (DNS) cryptographic keys, published a guide (available here) to tell users what to expect. The changing of the keys, known as the "Root Key Signing Key (Root KSK)" is scheduled for…

Sign up for a free preview to unlock the rest of this article

Export Compliance Daily combines U.S. export control news, foreign border import regulation and policy developments into a single daily information service that reliably informs its trade professional readers about important current issues affecting their operations.

Oct. 11, pending approval by the ICANN board, the organization blogged. The DNS was signed with Domain Name System Security Extensions (DNSSEC) in 2010 and has two kinds of keys: zone-signing keys (ZSKs) that sign the main data in the root zone and key-signing keys that sign only the root key sets in the root zone, the guide said. The rollover occurs when the Root KSK is changed and the new KSK starts signing the root key set for the zone, the guide said. The new KSK is KSK-2017; all validating resolvers, which are configured with a set of trust anchors -- copies of the keys or key identifiers that match the root KSK -- will have to add KSK-2017 to their trust anchor configuration. Most resolvers either did that manually when KSK-2017 was created and published or had the change made for them by their software vendor, ICANN said. Some resolver operators, however, didn't update their configuration and are unprepared for the rollover because they're still using KSK-2010 as a trust anchor. When rollover occurs, those operators will have no valid trust anchors, and will start to fail to validate the answers they get from authoritative DNS servers. (Authoritative name servers are defined as a network of hundreds of servers in many countries that are configured in the DNS root zone as 13 named authorities). When such failures happen "is not predictable," the guide noted. Failure starts when the ZSK can't be validated, it said. Whenever a validating resolver gets a response from an authoritative name server, it checks the signature and saves the validation status of the signature on each name in its cache. For example, ICANN said, validating the signature on a name such as "www.example.com" means resolvers must validate the signatures on the root, on ".com," on "example.com" and on "www.example.com." At some point within 48 hours after the change, DNS queries from some users -- either individuals or automated systems -- will begin to fail, which could mean a web page becoming unavailable or the inability to receive new email, ICANN said. The failures will then "cascade until no program is able to show new information from the Internet." Once operators discover that their resolvers' DNSSEC validation is failing, they should change their resolver configuration to temporarily disable DNSSEC validation, which should fix the problem immediately, the guide said. Data analysis "suggests that more than 99% of users whose resolvers are validating will be unaffected by the KSK rollover," ICANN said.