|
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.
|
|
Recently, version 3.0 of Knot DNS - an open-source implementation of 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 release such as 2.9. However, those features don't change any behaviour, unless the user turns them on. The migration from 2.9 to 3.0 is seamless.
|
|
|
|
|
|
## XDP
|
|
## 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.
|
|
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 case where the network stack isn't needed for advanced routing, firewall, traffic monitoring or shaping, it is possible to bypass the kernel and pass the packets from 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 percents. Other traffic (DNS-over-TCP, management over SSH, ...) remains unaffected and is processed by the kernel as usual.
|
|
|
|
|
|
An example:
|
|
Example:
|
|
```
|
|
```
|
|
listen-xdp: ens2f0@53
|
|
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.
|
|
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.
|
|
|
|
|
|
## Catalog zones
|
|
## 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.
|
|
One of crucial problems of operators with huge amount of zones is that new zones are constantly added and removed, and the operators have to modify the configuration file. They must 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.
|
|
|
|
|
|
An example:
|
|
Catalog zone is a fake zone, which is not part of the global DNS tree. Instead, it is used a basis to configure large number of regular zones. It's easy to replicate 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.
|
|
|
|
|
|
|
|
Example:
|
|
```
|
|
```
|
|
catalog-role: interpret
|
|
catalog-role: interpret
|
|
catalog-template: tpl_standard
|
|
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.
|
|
These lines in the configuration file signalize a catalog zone. This zone won't answer normal DNS queries from the outside. Moreover, it will 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.
|
|
|
|
|
|
Currently, a proposal of RFC standard of catalog zones is ongoing, the implementation in Knot DNS being in compliance with.
|
|
Knot DNS is in compliance with the current (ongoing) proposal for an RFC standard regarding catalog zones.
|
|
|
|
|
|
Further use cases of catalog zones, where they'll be not only interpreted, but also generated, are planned for next versions of Knot DNS.
|
|
Other use cases of catalog zones are planned for the future versions of Knot DNS. For example, it might be possible to generate the catalog zones in addition to just interpreting them.
|
|
|
|
|
|
## Continuous DNSSEC validation
|
|
## 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.
|
|
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 which lead to incorrect NSEC3 records that caused malfunctioning domains due the invalid non-existence proofs. Therefore, large DNS operators verify each new version of a signed zone by some verification tools, which is a lengthy procedure limiting the speed and frequency of zone updates.
|
|
|
|
|
|
Configuration option
|
|
Example:
|
|
```
|
|
```
|
|
dnssec-validate: on
|
|
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 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 obviously mostly useful when another implementation is used to sign the zone.
|
|
This feature is especially useful when another implementation is used to sign the zone.
|
|
|
|
|
|
## Minimization of answers on ANY and RRSIG queries
|
|
## 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.
|
|
Previously, querying the server for ANY or RRSING types lead to an answer with as many RRSets as exist 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 is low, it's preferable to answer them 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.
|
|
|
|
|
|
## kzonesign utility
|
|
## kzonesign utility
|
|
|
|
|
... | | ... | |