|
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.
|
|
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.
|
|
|
|
|
|
## XDP
|
|
## XDP
|
|
|
|
|
|
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.
|
|
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 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.
|
|
|
|
|
|
Example:
|
|
Example:
|
|
```
|
|
```
|
... | @@ -12,9 +12,9 @@ This line in the configuration file turns on XDP for all UDP packets on port `53 |
... | @@ -12,9 +12,9 @@ This line in the configuration file turns on XDP for all UDP packets on port `53 |
|
|
|
|
|
## Catalog zones
|
|
## Catalog zones
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Example:
|
|
Example:
|
|
```
|
|
```
|
... | @@ -22,15 +22,15 @@ Example: |
... | @@ -22,15 +22,15 @@ Example: |
|
catalog-template: tpl_standard
|
|
catalog-template: tpl_standard
|
|
|
|
|
|
```
|
|
```
|
|
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.
|
|
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 is in compliance with the current (ongoing) proposal for an RFC standard regarding catalog zones.
|
|
Knot DNS complies with the current (ongoing) proposal for an RFC standard regarding catalog zones.
|
|
|
|
|
|
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.
|
|
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
|
|
## 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 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.
|
|
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.
|
|
|
|
|
|
Example:
|
|
Example:
|
|
```
|
|
```
|
... | @@ -42,17 +42,17 @@ This feature is especially useful when another implementation is used to sign th |
... | @@ -42,17 +42,17 @@ This feature is especially useful when another implementation is used to sign th |
|
|
|
|
|
## Minimization of answers on ANY and RRSIG queries
|
|
## 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 exist for the queried name. This resulted in a high answer-to-query size ratio which could be abused in amplification attacks.
|
|
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 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.
|
|
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.
|
|
|
|
|
|
## kzonesign utility
|
|
## kzonesign utility
|
|
|
|
|
|
Compared to other more modular DNS implementations, Knot DNS prefers zone signing directly inside the daemon. This brings 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.
|
|
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
|
|
## 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 between the data, it's necessary to freeze all zones before the backup to prevent changes in the meantime. New version of Knot DNS allows a safe data backup (and restore) to a selected directory with a single command.
|
|
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.
|
|
|
|
|
|
Example:
|
|
Example:
|
|
```
|
|
```
|
... | @@ -61,7 +61,9 @@ $ knotc zone-backup +backupdir /mnt/backup/auth_dns |
... | @@ -61,7 +61,9 @@ $ knotc zone-backup +backupdir /mnt/backup/auth_dns |
|
|
|
|
|
## Deterministic ECDSA
|
|
## Deterministic ECDSA
|
|
|
|
|
|
The ECDSA signing algorithm provides high cryptographic security while maintaining short keys and signatures. However, the verification of the signatures takes far more time than creating them. A random number generator is used during the signing procedure, therefore the signature of the same data may be different every time. This can be avoided by using Deterministic ECDSA, which 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 loading an already signed zone. It might also protect against attacks based on weak random number generators.
|
|
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.
|
|
|
|
|
|
Example:
|
|
Example:
|
|
```
|
|
```
|
... | @@ -81,8 +83,8 @@ $ kdig @193.17.47.1 +https=/doh example.com. |
... | @@ -81,8 +83,8 @@ $ kdig @193.17.47.1 +https=/doh example.com. |
|
|
|
|
|
## kxdpgun utility
|
|
## kxdpgun utility
|
|
|
|
|
|
With the implementation of powerful packet handling by XDP, we introduce a new testing and benchmarking utility. It is able to generate up to tens of millions 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 the return codes, which are displayed at the end of the run. The Knot DNS team is already using this tool to measure the performance of Knot DNS and other implementations of DNS servers.
|
|
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 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. |
|
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. |
|
\ No newline at end of file |
|
\ No newline at end of file |