We are releasing dns-collector, an entry part of our pipeline for monitoring of our DNS servers and analysis of the DNS traffic. Together with advanced analysis of the collected data, we can not only monitor the DNS traffic for urgent problems, but also detect and examine long-term trends and issues (e.g. misconfiguration of other servers). We have presented this system at the IT 15.2 conference (video and slides in Czech).
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.
Over past years, various DNS software developers tried to solve the problems with the interoperability of the DNS protocol and especially its EDNS extension (RFC 6891 standard), by temporary workarounds, which aimed to lend their software an ability to temporarily accept various non-standard behaviors. Unfortunately, time has shown that this attitude of adding temporary workarounds is not a long-term solution, especially because the implementations not fully complying with standards were seemingly functional and there was no reason for a permanent fix. The result of these makeshift solutions is their accumulation in the DNS software, leading to a situation where there are so many of them that they themselves begin to cause problems. The most obvious problem is slower response to DNS queries and the impossibility to deploy new DNS protocol feature called DNS Cookies, which would help reduce DDoS attacks based on DNS protocol abuse.
On July 16-21, 2017, the IETF 99 conference will take place in Prague. What IETF is and how it works has been already explained by my colleague Ondřej Surý in Czech Cesta do hlubin IETF, Odkud pochází internetové standardy (aneb bylo jednou jedno RFC) or Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF. Ladislav Lhotka, in turn, described its unusual geeky atmosphere IETF: internet podle mručící většiny. So it is enough to mention that IETF is an organization that publishes Internet standards. Its goal is to create quality technical documentation that influences the development of the Internet and its applications.
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.
In mid-February we informed about Reducing TTL in the .cz zone by one hour. Then, at a similar hour every Wednesday, we reduced it by another hour, until on March 15, 2017 we reached the required value of 1 hour (i.e. TTL=3600).
The golden rule of security, stability, and resiliency of virtually anything is “don’t put all your eggs into one basket”. This generally applies to the DNS, and there are some recommendations to avoid having all your nameservers in one domain. I would like to show that in this case, this is not a silver bullet, it depends on many conditions, and using different domains in your nameserver set might even make things not better, but worse.
DNS records contain a lot of important data, including the information on how quickly such data becomes obsolete, the so-called TTL (Time To Live). TTL in the DNS indicates for how long the data can be stored on a recursive nameserver (resolver) without it being retrieved from an authoritative nameserver. The lower the TTL, the more frequently resolvers query authoritative nameservers and obtain the most recent data. At the same time, however, a short TTL causes heavier load on nameservers, and if DNS records do not change often, the TTL is usually set to several hours.