- The first-ever DNS root key-signing key (KSK) rollover on 11 October may leave some users unable to get online
- All operators of validating resolvers need to ensure that their trust anchors are updated before it’s too late
The root zone of the Domain Name System was signed with the DNSSEC security extensions in 2010. The original key, KSK-2010, is still in use today. On 11 October, KSK-2010 will be retired and the new key, KSK-2017, will take over.
This process, known as the Root Zone KSK Rollover, is the first of its kind and has been in planning for several years now. The Internet Corporation for Assigned Names and Numbers (ICANN), the organization responsible for implementing the rollover, warns that “some Internet users might be affected if the network operators or Internet Service Providers (ISPs) have not prepared for the update. Those operators who have enabled the checking of Domain Name System Security Extensions or DNSSEC information (a set of security protocols used to ensure DNS information isn't accidentally or maliciously corrupted) are those who need to be certain they are ready for the roll.”
It is expected that a small percentage of Internet users will experience problems in resolving some domain names. Within 48 hours after the rollover, some Internet users’ DNS queries will begin to fail, meaning that they will be unable to get online.
Unprepared resolvers may mean your customers are unable to access the Internet
In the case that a resolver fails, if the user has multiple resolvers configured (as most users do), their system software will try the other resolvers that have been configured. This might slow down
DNS resolution – as their system keeps trying the resolver that is not prepared before switching to the resolver that is prepared – but the user will still get DNS resolution and might not even notice the slowdown. However, if none of the user’s resolvers are prepared for the rollover (such as if they are all managed by one organization and that organization has not made any of their resolvers ready), the user will start seeing failure sometime in the 48 hours after the rollover.
Users will see different symptoms of failure depending on what program they are running and how that program reacts to failed DNS lookups. In browsers, it is likely that a web page will become unavailable (or possibly only images on an already displayed web page might fail to appear). In email programs, the user might not be able to get new mail, or parts of message bodies may show errors. The failures will cascade until no program is able to show new information from the Internet.
Update trust anchors on resolvers now
Each validating resolver is configured with a set of trust anchors, which are copies of the keys or key identifiers that match the root KSK. Trust anchors are typically configured automatically by software vendors, or by the resolvers which are configured to automatically update the trust anchors using the process described in RFC 5011. It can also be done by the resolver operator, by manually adding a new KSK to the resolver’s trust anchor store.
To ensure that users are not impacted by the rollover, it is important that all operators of validating resolvers have a look at whether they are properly prepared for the rollover by checking their current trust anchors. If you should find that you are not ready, you should update to the latest trust anchors now. However, if you operate resolvers that are not doing DNSSEC validation, then there’s no need to worry – you are already prepared for the rollover.
Unprepared resolvers won’t only impact your customers – they can take you, as an operator, offline too
Unless operators of resolvers are actively monitoring for significant errors, they will probably not know about the failing validation until automated systems that rely on the resolver start failing, or users start calling to complain about outages. But there’s more: If you are also only using resolvers with incorrect trust anchor configurations, you may yourself be unable to receive email messages.