A DNS zone is usually served by multiple authoritative servers, which is actually recommended for the sake of redundancy. Large authoritative DNS operators even combine different name server implementations to avoid complete infrastructure outage in case of any software error. For synchronizing zone contents between authoritative servers, a DNS-specific mechanism is available, called zone transfer. It is well established and supported by all common DNS implementations. It enables both full zone transfer (AXFR) and incremental update (IXFR).
I try to describe the basic building blocks of our national domain registry administration to people around me quite often. Yet (or maybe for that very reason), the .cz is still perceived as something that simply works. Just like when you get in your car to take your children to school every morning. You expect the journey to take the usual 10 minutes (or 15 if you need to refuel) and that you won’t have to deal with any trouble. Even though you know that you need to change the oil regularly, check and change worn parts, or repair defects caused by operation, most of you leave these “out of order” cases to service professionals or at least a handy neighbor and avoid having to wash your hands from automotive grease or to remember the required type of brake pads. Modern cars are able to inform you of any necessary maintenance and all you have to do is dial the correct phone number. Although you don’t fully understand the person at the other end of the line, they manage to get through to you because you have a basic idea of how a car works.
Recently, version 3.0 of Knot DNS – an open-source implementation of an authoritative DNS server – has been released. Despite the version number, the software isn’t changing much. There are slightly more new features than in common feature releases such as 2.9. However, the features added in 3.0 don’t change any behaviour, unless the user turns them on. The migration from 2.9 to 3.0 is therefore seamless.
During the development of the DNS Knot Resolver, CZ.NIC Labs have managed to reveal a security flaw that makes it possible to bypass DNSSEC security on F5 load balancers and cause denial of service. These products are being used, for example, in some internet banking applications, including those of Czech banks and public authorities. From the perspective of a user attempting to access an internet banking service, a successful attack exploiting this error would manifest in the browser suddenly reporting an “address not found” error and the service becoming unavailable.
DNS has been in use on the Internet for more than 30 years — now it is time for its worldwide maintenance that shall, for the first time in the existence of DNS, require coordinated actions from all operators of DNS servers and DNSSEC validators.
On August 14, over 50 representatives of internet organizations met at the headquarters of DENIC, the German top-level domain registry, to attend the first ID4me summit. ID4me is the current name of the project, which was started last year under the name DomainID — I mentioned it briefly in my presentation at our last year’s conference IT 17.2. It was initiated by the .DE domain administrator, together with the major German registrar 1&1, and Open-Xchange, the operator of online collaboration tools. However, there are many other companies that are willing to support it, including the UK domain registry Nominet. The goals set by the project are quite familiar to us — reducing the number of passwords and registrations that people need while using the Internet. Like CZ.NIC with its mojeID project, the authors of ID4me have come to the conclusion that the domain world is just the place for an attempt to achieve these goals.
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.
I hope former US President Ronald Reagan would forgive me for borrowing and altering the slogan of his presidential campaign. After all, quite a few people seem to be doing it these days.
For many years, our association has been running a service going by the acronym “ODVR” – Open DNSSEC Validating Resolvers. At times when DNSSEC was just beginning, we thought it was necessary to come up with an alternative to DNS resolvers provided by ISPs who introduced the validation support too slowly. Since then, we have offered a publicly available service that allows validation of domains using DNSSEC security even in those networks whose default DNS resolvers do not support this.
It has been almost half a year since we presented the intention to change the DNSSEC algorithm for .cz zone DNSSEC key at our IT 16.2 conference. In his presentation, our colleague Zdeněk Brůna described in detail the advantages of algorithms based on elliptic curves, especially the ECDSA algorithm. However, due to the situation where this step cannot be done because of the lack of support for this algorithm in the root zone, our activities have shifted to mainly educate and monitor the impact of this education on the state of support for this new technology. At a seminar with registrars that we held at the end of February, we noticed a positive response to some ECDSA properties, such as smaller zone file size or smaller DNS response size. Some registrars have already declared interest in switching to ECDSA. At the same time, the registrars have suggested that we publish statistics on our site showing how different DNSSEC algorithms are used in the .cz zone. We liked this idea and we are now publishing these statistics.