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 record. It contains the next node in the lexicographical order and a bitmask of available RRTYPEs:
example. 300 IN NSEC ns1.example. A NS SOA RRSIG NSEC DNSKEY
In the trivial case, the node exists but lacks a RRSET of the queried type. This is easily verified with the types bitmap.
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.
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.
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.
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.
Knot Resolver 6.x News
In this post, I’d like to introduce the upcoming major version of Knot Resolver project, which is currently in the testing and debugging phase, and we would greatly appreciate if you could try it out and give us any feedback on it.
RFC 9432: DNS Catalog zones
A DNS zone is usually served by multiple authoritative servers, which is actually recommended for the sake of redundancy. Large authoritative DNS operators even combine different name server implementations to avoid complete infrastructure outage in case of any software error. For synchronizing zone contents between authoritative servers, a DNS-specific mechanism is available, called zone transfer. It is well established and supported by all common DNS implementations. It enables both full zone transfer (AXFR) and incremental update (IXFR).
