The Internet Corporation for Assigned Names and Numbers (ICANN) is a nonprofit organization created by U.S government who coordinates and maintains several databases related to the namespecs in the internet. ICANN is responsible to perform the technical maintenance work of the Central Internet Address pools and DNS root zone. ICANN coordinates the domain name system to ensure that all the domains and addresses are unique. You should have a knowledge about DNSSEC, keys used in DNSSEC and trust anchors before reading about the KSK rollover. So let’s get started on ICANN Performs DNS Root Zone KSK RollOver.
What is DNSSEC?
When the DNS was first implemented, it was not secured and vulnerabilities in the DNS were discovered that allow an attacker to hijack a DNS query (process of looking for the IP address corresponding to a domain name). It may lead the user to hijacker’s own deceptive website for fraud purposes like collecting passwords, account information ..etc.
These vulnerabilities led to implement an end to end deployment of security protocols called “DNS Security Extension (DNSSEC)” which is an additional security layer to the DNS lookup and exchange process. DNSSEC was developed in the form of extensions that could be added to the existing DNS protocols. DNSSEC does not encrypt the data, but it attests the validity of the address of the site you visit so that a resolver can be assured that the answer provided to the DNS query is valid and authentic and thus we can prevent activities like cache poisoning, pharming, and man-in-the-middle attacks.
We can ensure that the end user is connecting to the actual website corresponding to a domain name by the full deployment of DNSSEC (it must be deployed at each step in the lookup from root zone to final domain name) and thus we can eliminate the vulnerability from the internet.
How DNSSEC Works?
DNSSEC uses a system of digital signatures and public keys to verify the data. It simply adds new records such as RRSIG and DNSKEY to DNS with the existing records. Each domain name is digitally signed by using these new records using a method known as public key cryptography. Each signed domain name has a public and private key for each zone. If a DNS query came for a domain name that is using DNSSEC, it sends information signed with its private key. The recipient then unlocks it with the public key. If a third party tries to send malicious information, it won’t unlock properly with the public key, so the recipient will know the information is bogus.
There are two types of keys that are used by DNSSEC at the root zone:
ZSK – “Zone Signing Key” is a private/public key pair. The ZSK private key is used to digitally sign the DNS records on the zone of a domain name and the digital signature is called RRSIG. The ZSK public key is stored on the DNS zone to authenticate an RRSIG.
KSK – “Key Signing Key” is a private/public key pair. The digital signature for ZSK is generated using KSK private key and the KSK public key is stored on the DNS to authenticate the ZSK.
Given sufficient time and data, cryptographic keys can eventually be compromised may be through brute force or other methods. This allows an attacker to defeat the protections afforded by DNSSEC. So it is necessary to rollover the ZSK and KSK keys frequently. DNSSEC overcomes these compromise attempts by rolling over the ZSK frequently (every 3 months) to make it difficult for an attacker to “guess” while the longer KSK is changed over a much longer time period.
The KSK rollover plans were developed by the Root Zone Management Partners; ICANN in its role as the IANA Functions Operator, Verisign as the Root Zone Maintainer, and the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator.
Key Signing Key (KSK): rollover means that generating a new cryptographic key pair (public and private key pair) and distributing the new public component of KSK (trust anchors) to parties who operate validating resolvers (Recursive DNS), including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root’s
The DNS root zone was first signed with DNSSEC in 2010 and the corresponding Key Signing Key (KSK) is known as
KSK2010. The Board of Directors for the Internet Corporation of Assigned Names and Numbers (ICANN) had approved plans for the first-ever changing of the cryptographic key on 18 September 2018 that helps to protect the Domain Name System (DNS). As per the plan, ICANN had performed the Root Zone Domain Name System Security Extension’s (DNSSEC) key signing key (KSK) rollover first time in the history on 11th October 2018 at 16:00 UTC. The new KSK is called KSK-2017. After the rollover, KSK-2010 will no longer be signing the root key set: instead, KSK-2017 will be signing the root key set.
The changing of the DNS root key was originally scheduled to happen a year ago (11 October 2017), but plans were postponed on 27 September 2017 after the ICANN organization found and began analyzing some new last-minute data. It was a good news that since the Root KSK Rollover was delayed 1 year, most all of the DNS resolver software has been shipping for quite some time with the new key. That data dealt with the potential readiness of network operators for the key roll. Since then, ICANN has undertaken efforts to determine if and when the KSK rollover should proceed. So ICANN had conducted a research on the effect KSK rollover on the end users.
The design of DNSSEC includes a mechanism, commonly referred to as RFC 5011, whereby DNSSEC validators can automatically update their trust anchors. Because this was the first operational root KSK rollover, RFC 5011 had never been tested in production. Starting in 2017 a few popular recursive DNS resolvers implemented a feature defined in RFC 8145 — “Signaling Trust Anchor Knowledge in DNSSEC.” If a DNSSEC validator supports RFC 8145 and the feature is enabled, it sends periodic reports of its trust anchor configuration to one of the root name servers.
Verisign, an operator of root name servers, receives some of this RFC 8145 data. Verisign regularly analyze the data to identify sources that appear to have an out-of-date trust anchor configuration. Earlier this year, they began contacting operators of recursive servers that reported only the old trust anchor. However, in many cases, a responsible party could not be identified, due in large part to dynamic addressing of ISP subscribers. Also, late last year, ICANN began receiving trust anchor signaling data from more root server operators, as well as data from more recursive name servers as the recursive name servers updated to software versions that provided these signals.
Based on the research, David Conrad, ICANN’s Chief Technology Officer revealed before the KSK rollover that the research shows there are many thousands of network operators that have enabled DNSSEC validation, and about a quarter of the Internet’s users rely on those operators. ICANN makes this data publicly available. Out of these DNSSEC validating resolvers, 7% of reporters were signaling the 2010 trust anchor before the KSK rollover. These validating name servers were expected to experience DNS resolution failures after the KSK rollover. As planned, the rollover had completed on October 11, 2018. According to the research by APNIC, more than 99% of users (whose resolvers perform DNSSEC validation) were successfully resolved in the rollover.
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 public key. Trust anchors are typically configured automatically by software vendors, or by the resolvers who are configured to automatically update the trust anchors using the process described in RFC 5011 or by the resolver operator who manually adds a new KSK to the resolver’s trust anchor store. Before KSK-2017 existed, all validating resolvers only had the KSK-2010 configured as a trust anchor. After that KSK-2017 created and published, most resolver operators either manually added KSK-2017 to their resolver’s trust anchor configuration, or the change was made for them by their software (such as through the RFC 5011 automated update process) or by their software vendor.
How to update the DNS Validating Resolver with the Latest Trust Anchor
There are currently a small number of Domain Name System Security Extensions (DNSSEC) validating recursive resolvers that are misconfigured, and some of the users relying on these resolvers will be experiencing problems. As soon as operators discover that their resolver’s DNSSEC validation is failing, they should change their resolver configuration to “temporarily disable” DNSSEC validation. This should cause the problems to immediately stop. After that, the operator should install, as soon as possible, the KSK-2017 as a trust anchor and turn on DNSSEC validation again.
If you are an administrator of a DNSSEC validating resolver, you need to check whether the the validating resolver is configured with the latest trust anchor (KSK-2017). You can check which trust anchor is using by your resolver by following the steps on this link https://www.icann.org/dns-resolvers-checking-current-trust-anchors
You need to install the new trust anchor (KSK-2017) if the validating resolver is using the old trust anchor (KSK-2010). You can follow the steps here rust anchor (KSK-2010). You can follow the steps here https://www.icann.org/dns-resolvers-updating-latest-trust-anchor to update the trust anchor on your DNSSEC validating resolver to the latest KSK-2017 trust anchor.
Effect of KSK Rollover on End Users
- Users who rely on a resolver that does not perform DNSSEC validation will not see any effect from the rollover.
- Users who rely on a resolver that has the new KSK will not see any effect from the rollover.
- Users of resolvers that are prepared for the rollover will see no difference when the rollover happens. The responses they get to normal queries will be identical before and after the rollover.
- Most Internet users have more than one DNS resolver configured. If any of the resolvers that a user has configured is prepared for the rollover, the user’s software should find that resolver after the rollover and continue to use it. 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.
- If all of a users’ resolvers do not have the new KSK-2017 key configured as a trust anchor and that resolver performs DNSSEC validation, the user will likely experienced the effects at some point in the 48 hours after the rollover happened, since the TTL for the KSK and ZSK records are 48 hours. If a resolver obtains the root key set and validates it just before the rollover, that resolver won’t know about the rollover for almost two days, because the resolver will not fetch a new KSK until it gets the first query after the TTL of root key set has expired.
Only negligible number of cases reported by the Internet end-users who had negatively impacted by the rollover process of the cryptographic keys. The few issues that is arising, appears to have been quickly mitigated and none suggested a systemic failure that would approach the threshold (as defined by the ICANN community) to initiate a reversal of the roll. In that context, it appears the rollover to the new Key Signing Key, known as KSK 2017, is a success. At this point, there are no indications it is necessary to back out of the rollover and ICANN will now proceed to the next step in the rollover process: revoking the old KSK, known as KSK 2010 during the next key ceremony on 11 January 2019.
Effect of KSK Rollover on Root DNS Servers
Since the rollover is completed, root server operators might already started to see significantly more queries from resolvers that are unprepared for the rollover. Those queries will most likely be for the DNSKEY of the root (./IN/DNSKEY), and will also likely include queries for the DNS record of the .net zone (.net/IN/DS). Additionally, since the responses can’t be validated correctly, they will not be cached, and may lead to increased traffic overall from these validating resolvers. Similarly, operators of resolvers that allow other resolvers to forward through them has already been seeing increased counts of these requests.
Do you need any expert advice on ICANN Performs DNS Root Zone KSK RollOver?
We have an expert team to guide you
Thanks for dropping by. Ready for the next blog?