As we have reported several times, after massive upgrades of the anycast DNS for the .CZ domain zone in recent years and building of the 100GbE DNS infrastructure, we are now focusing more on targeted tuning of the anycast operation. For example, we try launching new DNS stacks in the locations of significant DNS traffic sources, both abroad and in Czechia. The launch of the DNS stack on the CESNET network at the beginning of April is the most recent fruit of this work.
Recently, two entities have asked us to help them host their DNS zones and in both cases, we were happy to oblige. One of them was the Czech neutral peering node NIX.CZ, with which we often share technical know-how and help each other when it makes sense. The other one was the domain register of Guatemala operating the .gt ccTLD, which we humored as part of our long-term support of developing registers, like we have done the case with the registers of Angola, Malawi, Tanzania or North Macedonia.
DNS is one of the critical services necessary for proper operation of the Internet. Also it is often a target of various cyber attacks. Considering this fact, operators of authoritative DNS servers require robust solutions offering enough performance for regular DNS traffic and resisting possible attacks against this service. That is the reason why we focus, besides other aspects, on the performance during development of our authoritative DNS server Knot DNS. Benchmarking is an inseparable part of the project and we have been exploring various ways of further performance growth. Recently we had a great opportunity to play with the epic 128-thread processor AMD EPYC 7702P. In this blog post I will share some results from its benchmarking.
A global DNS maintenance is scheduled for February 1, 2019, and authoritative server operators must get ready for it. That is why we dedicate our today’s article to the state of readiness of .CZ domains for changes that will be effective from the beginning of next month.
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.