|
|
Recently, Knot DNS, an open-source implementation of authoritative DNS server, has been released in version 3.0. Despite the version number, the software is not changing much: there are somewhat more new features than in common 2.9 release, but those features don't change any behaviour, unless the user turns them on. The migration is thus very easy.
|
|
|
|
|
|
## XDP
|
|
|
|
|
|
When maximal answering power is needed (mostly as a mitigation to flood attacks), kernel packet processing tends to be the bottleneck. In cases where the kernel is not used for advanced routing, firewalling or monitoring the traffic, it's more efficient to bypass it completely and pass the packets from the NIC to DNS daemon directly. This technology is called eXpress Data Path and with its implementation in Knot DNS, the DNS-over-UDP answering rate raised by tens of percent. Other traffic (DNS-over-TCP, management over SSH, ...) is untouched and processed by the kernel as usual.
|
|
|
|
|
|
An example:
|
|
|
```
|
|
|
listen-xdp: ens2f0@53
|
|
|
```
|
|
|
This line in the configuration file turns on answering through XDP for all UDP packets on port `53`, incomming at the interface `ens2f0`, regardless of the destination IP adress. The answer packet will be sent back the same way, i.e. with exchanged source and destionation IP and MAC adresses, respectively.
|
|
|
|
|
|
## Catalog zones
|
|
|
|
|
|
One of cruical problems of operators with huge amount of zones is that new zones are constantly being added and removed, and they must modify the configuration file not only at primary authoritative DNS servers, but also all secondaries, so that they serve an up-to-date set of zones. Catalog zone is a fake zone, which is not part of the global DNS tree, but it forms a basis to configure large number of regular zones, while it's easy to replicte it (even incrementally) by standard means to the secondaries. With every change to the catalog zone, each server reconfigures itself according to added and removed records.
|
|
|
|
|
|
An example:
|
|
|
```
|
|
|
catalog-role: interpret
|
|
|
catalog-template: tpl_standard
|
|
|
|
|
|
```
|
|
|
This lines in configuration file signalize a catalog zone. This zone won't answer normal DNS queries from the outside. Moreover, it will be intepreted as catalog zone: all `PTR` records will be listed and member zones configured based on them. Configuration of the member zone will be taken from the template named `tpl_standard` (in this case), where for example the set of secondaries to send NOTIFY to, or DNSSEC signing parameters can be defined.
|
|
|
|
|
|
Currently, a proposal of RFC standard of catalog zones is ongoing, the implementation in Knot DNS being in compliance with.
|
|
|
|
|
|
Further use cases of catalog zones, where they'll be not only interpreted, but also generated, are planned for next versions of Knot DNS.
|
|
|
|
|
|
## Continuous DNSSEC validation
|
|
|
|
|
|
While anycast can be used to distribute DNS answering between different DNS server implementations, DNSSEC signing is done at one site and the operator must choose a software to rely on. Already some software errors have lead to generating wrong NSEC3 records (proving non-existence), resulting in non-functioning domains. Big DNS operators thus verify each new version of signed zone by some verification tools, but it's a lenghty procedure limiting the speed and frequency of zone updates.
|
|
|
|
|
|
Configuration option
|
|
|
```
|
|
|
dnssec-validate: on
|
|
|
```
|
|
|
turns on DNSSEC validation of incomming zone changes. Incorrect zone version is denied. Verification of small update to huge zone is fast. Validating Knot can be for example configured as a secondary to the signer, and as a primary to public servers. Should any signing error occur, the last correct zone version will remain public.
|
|
|
|
|
|
This feature is obviously mostly useful when another implementation is used to sign the zone.
|
|
|
|
|
|
## Minimization of answers on ANY and RRSIG queries
|
|
|
|
|
|
Previously, a query on ANY or RRSIG type was answered with as many RRSets as exist for the queried name, leading to high answer-to-query size ratio, helping amplification attacks. Because legitimate sense of such queries is low, it's more proper to answer them a minimized way, according to RFC 8482. Since version 2.9.5 partially, and 3.0 completely, answers Knot DNS those queries with just one, arbitrarily chosen type. The answers amplification is thus not higher as for queries on specific RR type.
|
|
|
|
|
|
## kzonesign utility
|
|
|
|
|
|
Opposing to other, more modular DNS implemetations, Knot DNS prefers zone signing directly inside the daemon, with benefits such as speed or automatic key roll-overs timing. However, for testing or unusual use-cases, `kzonesign` utility is now available, working similarly to `dnssec-signzone`: it loads a zone file, signs the zone, and dumps it back to a text zone file. A difference is, that the signing paremeters are not taken from CLI, but from Knot-like configuration file. |
|
|
\ No newline at end of file |