Knot DNS Signing Your Zones Itself, Transfers By Key Only

knot

Knot DNS from EPEL as an authoritative server that signs your zones itself: DNSSEC with ECDSA P-256 and NSEC3 as RFC 9276 recommends, zone files you own and Knot never rewrites, a change served after a reload with no serial to bump, transfers only with a TSIG key the role makes, no recursion, and each file checked by Knot's own parser before it lands. Original role for EL 10, live-tested with podman on Rocky Linux 10.

No download, and no version to pin. EL 10 packages knot in EPEL, so the role installs it by name and takes what the distribution ships: a security update arrives through dnf, not through a new release of this role. What the role owns is the configuration and the proof that the service works.

The distribution's unit, our configuration. The role installs knot and knot-utils from EPEL, writes /etc/knot/knot.conf (root:knot 0640: it holds the transfer key) and one zone file per entry in knot_zones under /etc/knot/zones, and enables the package's knot.service, which runs as the knot user. The listener is 127.0.0.1:53 (TCP and UDP) by default; an authoritative server answers on the host's public address, so set knot_listen_address or add knot_extra_listen_addresses. The live test reads the TCP and UDP sockets and expects loopback only.

The package cannot start as installed. dnf prints "warning: group knot does not exist - using root": /etc/knot and knot.conf land root:root, knotd runs as knot, and the unit fails on "no configuration source available" with the package's own file (measured; rpm -V knot shows the group). The role gives /etc/knot back to the knot group.

Signed, and checked from the outside. The live test builds a trust anchor from the zone's own key and validates with delv: a name answers "fully validated", a missing one "negative response, fully validated". NSEC3 uses no salt and no extra iterations (1 0 0 -), as RFC 9276 recommends. To make the zone validate on the internet, publish the DS records keymgr <zone> ds prints at your registrar.

Your zone file stays yours. Knot keeps the signed zone in its journal and never tries to write into the file (zonefile-sync: -1). The file is root:knot 0640, which Knot could not write anyway: with zonefile-sync: 0 it tries after every change and logs "failed to update zone file (operation not permitted)" (measured). A record added to the file with no serial bump is served, signed, after a reload, Knot raising the served serial itself - and Knot's default zonefile-load does that too (measured). What zonefile-load: difference-no-serial adds is a journal that stays consistent: without it, Knot says whole "not compatible with 'journal-content: all'" and warns that with signing and outgoing transfers "'zonefile-load: difference' should be set to avoid malformed IXFR after manual zone file update" (measured). The live test reads Knot's journal for both.

Transfers by key only, and no recursion. A transfer without the key fails, one with a wrong key gets BADSIG, and the key the role makes (/etc/knot/iacbazaar-tsig, root 0600) transfers the zone. A name the server does not hold is REFUSED, and version.bind and id.server answer nothing.

Each file checked first. knot.conf by knotc conf-check; each zone file by Knot's own loader through a throwaway configuration that names the candidate, which refuses a syntax error, a CNAME beside other data and a missing SOA (a missing glue record is only a warning).

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.