... | ... | @@ -48,32 +48,31 @@ Because the legitimate use of such queries is low, it's preferable to answer the |
|
|
|
|
|
## 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.
|
|
|
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.
|
|
|
|
|
|
## Backup of persistent data
|
|
|
|
|
|
Besides zone file and configuration, Knot DNS stores more data like journal (change-sets of last zone updates), signing keys with their metadata, and zone timers (last NOTIFY, last refresh, etc.). Those data are spread across the filesystem and their backup is problematic: it's needed to freeze all zones before the backup to prevent changes in the meantime, which would lead in inconsistencies. New Knot version allows data backup (and restore) safely to selected folder 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 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.
|
|
|
|
|
|
An example:
|
|
|
Example:
|
|
|
```
|
|
|
$ knotc zone-backup +backupdir /mnt/backup/auth_dns
|
|
|
```
|
|
|
|
|
|
## Deterministic ECDSA
|
|
|
|
|
|
The ECDSA signing algorithm has advantages in high cryptographic security with short keys and signatures. Its specific is that verification of the signatures takes far more time than creating them. During signing, it also uses a random generator, so the signatures of the same data by the same key are different each time. These properties can be avoided by using Deterministic ECDSA, which generates the same signature each time, thus enabling verification by re-creation and comparison, if the private key is available. This speeds up loading an already signed zone. It also might protect against attacks based on random generator weakening.
|
|
|
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.
|
|
|
|
|
|
An example:
|
|
|
Example:
|
|
|
```
|
|
|
policy:
|
|
|
algorithm: ECDSAP256SHA256
|
|
|
reproducible-sign: on
|
|
|
|
|
|
```
|
|
|
|
|
|
## DoH querying with kdig
|
|
|
|
|
|
The `kdig` utility, intended mostly for admins to check the functonality of DNS servers and resolvers, now enables DNS-over-HTTPS (DoH) queries.
|
|
|
The `kdig` utility, intended mostly for admins to check the functionality of DNS servers and resolvers, now supports DNS-over-HTTPS (DoH) queries.
|
|
|
|
|
|
Example:
|
|
|
```
|
... | ... | @@ -82,8 +81,8 @@ $ kdig @193.17.47.1 +https=/doh example.com. |
|
|
|
|
|
## kxdpgun utility
|
|
|
|
|
|
With the implementation of powerful packet handling by XDP, new testing and benchmarking utility is introduced, able to generate up to tens of millions queries per second in extreme cases. `kxdpgun` allows to configure speed and further parameters of a benchmark, and views statistics, such that an overview of return codes, at the end of the run. Knot DNS team is already using this tool to measure their and other implementations of DNS servers.
|
|
|
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.
|
|
|
|
|
|
## Trust Anchor Roll-over
|
|
|
|
|
|
Mostly in situations, when a signed zone is a sub-zone of an unsigned one, Trust Anchor management is used according to RFC 5011. During such key roll-over, it's required to set the 'revoked' flag. Knot DNS 3.0 enables this, although just manually. |
|
|
\ No newline at end of file |
|
|
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 |