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.
Sentinel View report – November 2023
Iran decreased its efforts, and for a change, most active attackers occupying all top three positions are from Romania. There is a new interesting IP that emerged last month, and that is an attacker from Panama. Small port scans for port 53 were at their record this month; we could not help but dig deeper. For more information: Sentinel View report – November 2023.
SaltStack, DNS and ssh
In my last post, I showed, how we can combine SaltStack and Knot to have some basic records filled in your zone. As I was introducing the concept, I picked the most obvious and basic entries. But since we have a hammer now, everything starts to look like a nail. And there is much more that can be stored in DNS apart from IP addresses. Let’s take a look at some other examples and how to get them automatically filled in by SaltStack.
Managing DNS via SaltStack
Running services online without domain is hard. More services you run, more DNS entries you need to manage. More services you run, more servers you need to manage. And when you manage several servers, it’s time to use some orchestration. But what about all those domains associated with those servers and services? Can’t that be also part of the orchestration? Somehow automated? Of course it can. Let me tell you how am I handling it for my domains and servers.
Orchestration via SaltStack
This post will be about my approach to something, that is almost obsolete. It is about orchestration. Back in the old days, people used to have a real computers or virtual machines and used to install and configure software. And also maintain it for years to come. I know that nowadays, you just create a bunch of pods, each one consisting from multiple containers you downloaded from DockerHub and whenever you need to reconfigure or update something, you just throw them away. Or even the whole datacenter. But I’m old and I still maintain individual systems with multiple services running. And jokes aside, when you do that, you want to have some automation to make it easier. That is what orchestration is for – to manage multiple machines from one central point and to make sure that everything is up to date and configured consistently.
Datacenter scale by XKCD