Starting with version 3.5, Knot DNS allows you to perform an external validation of a new zone version before updating it. This article describes how is this feature used to validate (not only) .CZ zones.
0
This article is written in an effort to aid those who are considering Knot DNS as a replacement for OpenDNSSEC.
More specifically, in this article we’ll be showing how to:
If you’ve never interacted with Knot before, please familiarize yourself with the basics. Our documentation provides a great novice-friendly introduction.
2
Knot DNS has many powerful and useful features, but sometimes it might be difficult to see all the intricate ways in which they interact and complement each other. In this article I’ll attempt to clear up some of that confusion by showcasing a realistic moderately-complex DNS infrastructure built on instances of Knot. Our focus will be largely on DNSSEC.
0
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:
0
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.
0
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.
0
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:
0
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.
0
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.
0
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.
0
