Recently, version 3.0 of Knot DNS – an open-source implementation of an authoritative DNS server – has been released. Despite the version number, the software isn’t changing much. There are slightly more new features than in common feature releases such as 2.9. However, the features added in 3.0 don’t change any behaviour, unless the user turns them on. The migration from 2.9 to 3.0 is therefore seamless.
When trying to maximize the UDP throughput (e.g. to mitigate flood attacks), processing packets in the kernel tends to limit the overall performance. In the case where the network stack isn’t needed for advanced routing, firewall, traffic monitoring, or shaping, it is possible to bypass the (modern Linux) kernel and pass the packets from the NIC directly to the DNS daemon. This technology is called eXpress Data Path (XDP). When using the XDP implementation in Knot DNS, the maximum DNS-over-UDP throughput is increased by tens of percent. Other traffic (DNS-over-TCP, management over SSH, …) remains unaffected and is processed by the kernel as usual.
This line in the configuration file turns on XDP for all UDP packets on port 53 on the interface ens2f0, regardless of the destination IP address. The answer packet will be sent back using the same route, i.e. with exchanged source and destination IP and MAC addresses, respectively.
One of the crucial problems operators with a huge amount of zones face is that new zones are constantly added and removed, and the operators have to modify the configuration file. They have to do so for all primary authoritative DNS servers as well as all secondary DNS servers to ensure they serve an up-to-date set of zones.
A catalog zone is a fake zone, which is not part of the global DNS tree. Instead, it is used as a basis to configure a large number of regular zones. It’s easy to push the catalog zone to the secondary servers by the usual means (even incrementally). After each change to the catalog zone, every server re-configures itself according to added and removed records.
These lines in the configuration file signalize a catalog zone. This zone won’t answer normal DNS queries from the outside. It will instead be interpreted as a catalog zone: all the PTR records will be used as a basis to configure the member zones. Configuration of each member zone will be taken from the template named tpl_standard (in this case). This specific template can be used to define a set of secondaries to send NOTIFY to, or to configure DNSSEC signing parameters.
Knot DNS complies with the current (ongoing) proposal of RFC standard regarding catalog zones.
Other use cases of catalog zones are planned for future versions of Knot DNS. For example, it might be possible to generate catalog zones in addition to just interpreting them.
Continuous DNSSEC validation
While anycast can be used to distribute DNS traffic to obtain answers from different DNS server implementations, DNSSEC signing is done at a single site and the operator must choose which implementation to rely on. In the past, there have been software errors that lead to incorrect NSEC3 records. These in turn caused domains to malfunction due to invalid non-existence proofs. Therefore, large DNS operators verify each new version of a signed zone using a set of verification tools, which is a lengthy procedure limiting speed and frequency of zone updates.
This option enables DNSSEC validation of incoming zone changes. Incorrectly signed zone changes are rejected. It is fast to verify small changes to a huge zone. Validating Knot DNS can be used as a secondary to the signer and as a primary to the public servers at the same time. Should any signing error occur, the last correct zone version will remain public.
This feature is especially useful when another implementation is used to sign the zone.
Minimization of answers on ANY and RRSIG queries
Previously, querying the server for ANY or RRSIG types lead to an answer with as many RRSets as there are for the queried name. This resulted in a high answer-to-query size ratio which could be abused in amplification attacks.
Because the legitimate use of such queries isn’t frequent, it’s preferable to answer them in a minimized way, according to RFC 8482. Knot DNS answers those queries with just one, arbitrarily chosen, type (partially since version 2.9.4, fully since 3.0). Therefore, the amplification factor isn’t any higher than querying a specific RR type.
Compared to other more modular DNS implementations, Knot DNS prefers zone signing directly inside the daemon. This comes with benefits such as speed or automatic key roll-overs timing. However, for testing or unusual use-cases kzonesign, utility is now available. It works similarly to dnssec-signzone: it loads a zone file, signs the zone, and dumps it back to a text zone file. The signing parameters are passed via a Knot-like configuration file instead of the CLI.
Backup of persistent data
In addition to the zone or configuration files, Knot DNS stores other data, such as a journal (change-sets of last zone updates), signing keys along with their metadata, and zone timers (last NOTIFY, last refresh, etc.). This data is spread across the filesystem and its backup is problematic. To avoid inconsistencies, it’s necessary to freeze all zones before the backup to prevent changes in the meantime. The new version of Knot DNS allows safe data backup (and restore) to a selected directory with a single command.
$ knotc zone-backup +backupdir /mnt/backup/auth_dns
The ECDSA signing algorithm provides high cryptographic security while maintaining short keys and signatures. This comes with some a downside: the verification of signatures takes a lot longer than their creation. A random number generator is used during the signing procedure, the signature of the same data may therefore be different every time.
This can be avoided by using Deterministic ECDSA, which (as the name suggests) generates the same signature every time. Once the signatures are deterministic, it is possible to verify them by re-signing and comparing the results (when the private key is available). This speeds up the loading of already signed zones. It might also protect against attacks based on weak random number generators.
DoH querying with kdig
The kdig utility, intended mostly for admins to check the functionality of DNS servers and resolvers, now supports DNS-over-HTTPS (DoH) queries.
$ kdig @188.8.131.52 +https=/doh example.com.
With the implementation of powerful packet handling by XDP, we introduce a new testing and benchmarking utility. It can generate up to tens of millions of queries per second in extreme cases. kxdpgun can be configured with various speeds and other benchmark parameters. It also collects statistics, such as an overview of response codes, which are displayed at the end of the run. The Knot DNS team is currently using this new tool to measure the performance of Knot DNS and other implementations of DNS servers.
Trust Anchor Roll-over
Trust anchor management is mostly useful when a signed zone is a sub-zone of an unsigned zone. When trust anchors management is used according to RFC 5011, it’s required to set the revoked flag to the former key during a key roll-over. Knot DNS 3.0 makes this possible, although it requires manual configuration.