The history of introducing the DNSSEC technology in the CZ domain goes back more than a decade, and there have been several important changes during its course. For example, let’s look at the year 2010, which was literally packed with events related to the introduction of DNSSEC. First of all, the root zone was signed in July and right afterwards, the first KSK rotation with the change of algorithm among the top-level domains took place in the CZ domain in August. After eight years, we are going to repeat this “combo”, only in reverse order. There is a delayed first rotation of the root zone KSK (without altering the algorithm) scheduled in October. And in June we will perform the already announced KSK key rotation in the CZ domain, again with the change of the algorithm. This time, however, we will use the ECDSA algorithm based on elliptic curves — as the first top-level domain administrator.
The advantages and disadvantages of the new algorithm have already been discussed many times. To those previously mentioned advantages such as higher security (greater strength of the key) and lower susceptibility to abuse for DDoS (smaller DNS responses), I would add a generally better DNS availability. Based on the research by the APNIC laboratory on the issue of delivery of fragmented datagrams over IPv6, the reduced size of the DNS response also means a potential speeding up of the DNS over IPv6 in some networks. However, the downside is that there are still old, non-updated DNS servers that in an unknown algorithm behave as if the query domain did not have DNSSEC turned on. It is quite likely that such non-updated DNS servers will be punished by the already mentioned exchange of the root zone KSK and the DNS will not run at all, so we will once again appeal to DNS server administrators: update and verify your configurations!
For users interested in the status of their DNS resolver, probably managed by their ISP, there are several tools available. For example, if you view our homepage and see the green circle next to the DNSSEC Secured tag, you can rest assured. Other color means you should contact your DNS resolver administrator for better security. A slightly more detailed overview of supported algorithms is offered by a test by Dutch researchers.
However, the situation in the CZ domain has evolved over the last year so that the ECDSA algorithm became the most commonly used DNSSEC algorithm. The Czech registrars Zoner, Ignum, and ACTIVE24 have evaluated the new algorithm as one with great advantages and sufficient support and transitioned to it on all the domains they host in their infrastructure. Both versions of this algorithm, namely ECDSAP256SHA256 and ECDSAP384SHA384, already cover almost half of all secure domains. Regardless of the DNSSEC algorithm used directly for the CZ domain, you probably use the ECDSA algorithm when visiting Czech domains.
Over the past eight years, the way we manage DNSSEC has also changed dramatically. In 2013, we decided to split the management of ZSK and KSK between two teams. While ZSK, which changes every two months, is managed by system administrators, KSK is stored in an offline vault and supervised by members of the CSIRT security team. Twice a year the ZSK team generates three new keys and prepares files containing corresponding combinations according to the time schedule for the next six months. The KSK team then picks up the KSK from the vault and signs the prepared files. These signed files are then saved back to the system, where the zone-signing script selects the appropriate signature key combination according to the current time and inserts it into the zone file. During this procedure, in the past we have tried the standard KSK rotation, however without the change of algorithm.
A proper change of algorithm requires a special procedure that involves signing of the zone file with two keys from the current and the new algorithms before the new key is published in the DNS. Otherwise, some versions of the Unbound DNS resolver would consider the entire domain invalid. However, the versions of Unbound behaving in such a strict way are diminishing considerably, so for example, the SE domain administrator has dared to perform the algorithm change in a standard (liberal) way. As can be seen in the presentation on this topic shown at the recent RIPE76 conference, no problems were detected. We have decided to be more conservative in this respect and make the change according to the recommendations of RFC6781. So we had to design a new procedure that involved cooperation of both the ZSK and KSK teams. Among other things, the KSK team, for example, had to update its environment for the KSK ceremony to the latest Ubuntu that already contains ECDSA-supported software. We tested the entire process in a specially created test environment and then executed it on the domain 0.2.4.e164.arpa (ENUM domain), which is managed in the same way as the CZ domain.
Since there were no problems during the testing and the change of the algorithm on 0.2.4.e164.arpa, we are planning to implement the same procedure on the CZ domain. The steps will be as follows:
- June 4, 2018 10AM – Adding new signatures using the ECDSA algorithm
- June 5, 2018 10AM – Publishing new ECDSA keys
- June 5, 2018 6PM – Generating a request to change the DS record in the root zone (processing time is up to seven days)
- June 7, 2018 10AM – Removing old RSA keys (subject to change according to the speed of the DS change in the root zone)
- June 8, 2018 10AM – Removing old signatures using the RSA algorithm (subject to change according to the speed of the DS change in the root zone)
Given that the time of zone signing with both keys is more than twice as long as the current one, we decided to generate a zone file only once per hour during rotation. We will keep you informed of the next steps.