The latest release of our authoritative DNS server, Knot DNS 2.7, comes with several new features. One of them is the GeoIP module for geography-based or subnet-based responses. In this article, we will briefly explain what the module is for and how it works and then we will explore how to set up and configure the module on your Knot server.
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.
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.