ICANN has decided to postpone an unprecedented change at the DNS root after discovering it could break internet for potentially millions of users.

The so-called KSK Rollover was due to go ahead on October 11, but it’s now been pushed back to — tentatively — some time in the first quarter 2018.

The delay was decided after ICANN realized that there were still plenty of ISPs and network operators that weren’t ready for the change.

Had ICANN gone ahead anyway with the change anyway, it could have seen subscribers of affected ISPs lose access to millions of DNSSEC-supporting domain names.

So the postponement is a good thing.

A KSK or Key Signing Key is a public-private cryptographic key pair used to sign other keys called Zone Signing Keys. The root KSK signs the root ZSK and is in effect the apex of the DNSSEC hierarchy.

The same KSK has been in operation at the root since 2010, when the root was first signed, but it’s considered good practice to change it every so often to mitigate the risk of brute-force attacks against the public key.

While it’s important enough to get dramatized in US spy shows, in practice it only affects ISPs and domain names that voluntarily support DNSSEC.

ICANN estimates that 750 million people use DNSSEC, which is designed to prevent problems such as man-in-the-middle attacks against domain names.

That’s a hell of a lot of people, but it’s still a minority of the world’s internet-using population. It’s not been revealed how many of those would have been affected by a premature rollover.

When DNSSEC fails, people whose DNS resolvers have DNSSEC turned on (Comcast and Google are two of the largest such providers) can’t access domain names that have DNSSEC turned on (such as domainincite.com).

In July this year, the new public KSK was uploaded as part of a transition phase that is seeing the 2010 keys and 2017 keys online simultaneously.

Last year, CTO David Conrad told us the long lead time and cautious approach was necessary to get the word out that ISPs needed to test their resolvers to make sure they would work with the new keys.

In June, ICANN CEO Goran Marby spammed the telecommunications regulators in every country in the world with a letter (pdf) asking them to coordinate their home ISPs to be ready for the change.

The organization’s comms teams has also been doing a pretty good job getting word of the rollover into the tech press over the last few months.

But, with a flashback to the new gTLD program, that outreach doesn’t seem to have reached out as far as it needed to.

ICANN said last night that a “significant number” of ISPs are still not ready for the rollover.

It seems ICANN only became aware of this problem due to a new feature of DNS that reports back to the root which keys it is configured to use.

Without being able to collate that data, it’s possible it could have been assumed that the situation was hunky-dory and the rollover might have gone ahead.

ICANN still isn’t sure why so many resolvers are not yet ready for the 2017 KSK. It said in a statement:

There may be multiple reasons why operators do not have the new key installed in their systems: some may not have their resolver software properly configured and a recently discovered issue in one widely used resolver program appears to not be automatically updating the key as it should, for reasons that are still being explored.

It’s not clear why the broken resolver software has not been named — one would assume that getting the word out would be a priority unless issues of responsible disclosure were in play.

ICANN said it is “reaching out to its community, including its Security and Stability Advisory Committee, the Regional Internet Registries, Network Operator Groups and others to help explore and resolve the issues.”

The organization is hopeful that it will be able to go ahead with the rollover in Q1 2018, but noted that would be dependent on “more fully understanding the new information and mitigating as many potential failures as possible.”

While it’s excellent news that ICANN is on top of the situation, the delay is unlikely to do anything to help the perception that DNSSEC is mainly just an administrative ball-ache and far more trouble than it’s worth.