Let’s start with a brief reminder of non-existence proofs in DNSSEC. If you have a solid understanding of the topic, feel free to skip this introduction.
The standard DNSSEC solution to proving a record’s non-existence is the NSEC RR. It contains the next node in the lexicographical order and a bitmask of available RTYPEs:
Public release of FRED v2024.1, more news and future plans
The FRED (Free Registry for ENUM and Domains) system has been used for the .cz TLD since 2007 and is also utilized by eleven other domain registry operators worldwide. For us, this leads to an international responsibility for adding functionalities according to operational and legislative requirements, as well as for the security, stability and technological development of the FRED system.
Knot Resolver 6 News: DoS protection – technical solution
In the previous article of this series, we have outlined how Knot Resolver 6 and Knot DNS 3.4 protect themselves as well as other participants on the Internet against denial-of-service attacks, from a high-level point of view. Let us now dive deeper into the implementation and take a look at the actual technical solution used to achieve this kind of protection.
Merry Christmas and Happy New Year 2025!
Layered protocols, or the big I/O rewrite of Knot Resolver 6
One of the bigger changes made in Knot Resolver 6 is the almost complete rewrite of its I/O (input/output) system and management of communication sessions.
To understand why this rewrite was needed, let us first take a brief look at the history of Knot Resolver’s I/O.
In the beginning, the Resolver’s I/O was really quite simple. As it only supported DNS over plain UDP and TCP (nowadays collectively called Do53 after the standardized DNS port), there used to be only two quite distinct code paths for communication – one for UDP and one for TCP.
Knot Resolver 6 News: DoS protection – operator’s overview
The team behind Knot Resolver, the scalable caching DNS resolver, is hard at work developing a complex solution for protecting DNS servers and other participants on the Internet alike against denial-of-service attacks. This effort is a part of the ongoing DNS4EU project, co-funded by the European Union1, which we are a proud part of.
To achieve this goal, we are introducing two new mechanisms:
Authenticated DNSSEC Bootstrapping in Knot DNS
When a domain owner decides to have their zone secured with DNSSEC, adding validation keys and signatures to the zone are only half the story. To allow resolvers to start validating signatures, it is also necessary to link at least one of the domain’s validation keys (DNSKEY records) to the global DNSSEC chain of trust.
Turris OS 7 is finally out!
It took us really long time to release Turris OS 7.0, but it is finally out now. The only change in this release is a switch to a newer OpenWrt – namely 22.03. We are not introducing any new features (although we are for the first time using “Staging Updates“). We are even sticking with iptables for now, although upstream has moved towards nftables. All that to minimize impact on our users and provide smooth update experience. That was also part of the reason why it took so long. We tested it over and over again, fixed the issues we found and started with the tests from scratch again. Sometimes we found our feature not working, sometimes we encountered some problems with state of the upstream distribution we had to help to fix. But finally we got into state where we could release it and we did exactly that.
Sentinel View report – December 2023
The Romanian attack peak was recorded on December 6th, with 52,576,312. Overall, attacks from Romania are dominant, as we can see in the Attackers section
SaltStack, DNS and TLSA
Lately I blogged about how am I managing my DNS entries via SaltStack. So far it was about being a great time saver, but nothing that you couldn’t do manually with considerably more effort. This time, let’s take a look at something that would be in some setups almost impossible manually – adding TLSA records for your webs.