Root KSK rollover postponed

Yesterday, ICANN announced that the definitive root KSK rollover scheduled for 11 October was being postponed indefinitely. The decision was motivated by fears that many internet users would encounter problems if the rollover went ahead on the planned day. Once the rollover is complete, all internet domains will become unreachable for anyone relying on a resolver that doesn't have the new KSK-2017 trust anchor installed.

Back out scenario

Just four weeks until the root KSK rollover: time to check your DNSSEC trust anchors!

Although this development is disappointing, the rollover process has always allowed for the back out scenario now being implemented. It's estimated that about 750 million people around the world (a quarter of all internet users) use a DNSSEC-validating resolver. So the impact of going ahead with a rollover that access providers and network operators weren't ready for was potentially enormous.

ICANN was persuaded to postpone the rollover by statistics compiled on the basis of the relatively new RFC 8145 protocol. The key tag signalling process defined in the protocol enables a validating resolver to tell a server which keys it is using as a trust anchor to build the chain of trust. So the operator of a signed domain is provided with client-side information about the progress of a key rollover.

According to the data reaching the root server operators, more than 5 per cent of reporting resolvers only have the KSK-2010 trust anchor installed. However, RFC 8145 is currently supported only by recent versions of BIND (9.10.5b1 and 9.11.0b3 and above) and Unbound (1.6.4 and above). On the other hand, RFC 8145 data is also being sent by some non-validating resolvers that run BIND.

What next?

ICANN is currently working with the technical internet community to establish why so many validating resolvers don't yet have the new trust anchor installed.

ICANN President Göran Marby says that he hopes the rollover can go ahead in the first quarter of next year, but no new date has been set.

In the meantime, we are advising validating resolver operators who haven't already done so to update their systems as a matter of urgency.