The keymgr utility serves for manual key management in Knot DNS server.
Functions for DNSSEC keys and KASP (Key And Signature Policy) management are provided.
The DNSSEC and KASP configuration is stored in a so called KASP database. The database is backed by LMDB.
This utility sends Dynamic DNS update messages to a DNS server. Update content is read from a file (if the parameter filename is given) or from the standard input.
The format of updates is textual and is made up of commands. Every command is placed on the separate line of the input. Lines starting with a semicolon are comments and are not processed.
This program controls a running knotd process using a socket.
If an action is specified, it is performed and knotc exits, otherwise the program is executed in the interactive mode.
Knot DNS is a high-performance open-source DNS server. It implements only the authoritative domain name service. Knot DNS can reliably serve TLD domains as well as any other zones.
Knot DNS benefits from its multi-threaded and mostly lock-free implementation which allows it to scale well on SMP systems and operate non-stop even when adding or removing zones.
The server itself is accompanied by several utilities for general DNS operations or for maintaining the server.
For more info and downloads see www.knot-dns.cz.
In 2010, it was an easy decision to use a commercial DNSSEC signer to deploy DNSSEC on APNIC’s reverse zones. Because much of the signer’s management was automated, we only had to worry about updating the parent delegation signer (DS) record separately.
So, even though we had to consider the scheduled Key Signing Key (KSK) rollover, updating the parent DS record on time was never an issue, since it would not roll-off the old key unless the new DS record had been updated in the parent zone.
In 2019, RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) was released. The minimum recommended DNSKEY algorithm changed to RSASHA256, and there was a strong recommendation to use ECDSAP256SHA256 as it provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512.
RSASHA1 was APNIC’s DNSKEY algorithm for almost 10 years, so the need to upgrade was it was inevitable. When it was time to upgrade, algorithm rollover was supported and well documented.
Following the recommendations in RFC 8624, we decided to migrate APNIC’s existing DNSKEY algorithm from RSASHA1 to ECDSAP256SHA256. The whole process took about a week to complete, without breaking the DNSSEC chain of trust.
Once we’d migrated, it was great to see the new (short) signatures from our zones.
What else could we ask for?
Setting up and bootstrapping the zone catalog feature. The requierments are:
- a running knot dns server verion >= 3.0
- configured remote, acl and key sections for a primary/secondary zone transfer setup
Assumptions:
- nsp.domain.tld is the primary nameserver.
- ns1.domain.tld is the secondary nameserver
- There exist valid remote, acl and key configurations for this hosts on the other side
- special catalog zone is name "zone.catalog"
-
Create a zone template for the zones, which will be created on this zone catalog feature
- For the primary nameserver:
- id: "catalog-zone-template"
...
notify: ns1
acl: ns1
...- For the secondary nameserver:
- id: "catalog-zone-template"
...
notify: nsp
acl: nsp
... -
Create the special catalog zone for this feature
- For the primary nameserver:
zone:
- domain: "zone.catalog."
...
notify: ns1
acl: ns1
catalog-role: "interpret"
catalog-template: "catalog-zone-template"- For the secondary nameserver:
zone:
- domain: "zone.catalog."
...
notify: nsp
acl: nsp
catalog-role: "interpret"
catalog-template: "catalog-zone-template" -
Create the content for the special catalog zone. We need to have at least a SOA, NS and TXT resource record:
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog @ 60 NS nsp.REDACTED.DOM.
zone-set zone.catalog @ 60 SOA nsp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set zone.catalog version 0 TXT "2"
zone-commit zone.catalog
EOT -
Create on the primary nameserver member zone in the special catalog zone.
- Create an unique id for the first member zone:
ZUID="id-$RANDOM-$RANDOM" # generate a random id string
# ZUID="id-$(pwgen -AB 8 1)" # or other method of generating a random id string- And create this zone with the knotc command as user knot:
NEWDOMAIN="my-first-domain.invalid"
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog id-${ZUID}.zones 0 IN PTR ${NEWDOMAIN%.}.
zone-commit zone.catalog
EOT- The easy thing to oversee is ".zones" part in the in the PTR resource record.
-
Last step: Setup the new domain content.
NEWDOMAIN="my-first-domain.invalid"
cat<<EOZ | su -c /usr/bin/knotc knot
zone-begin ${NEWDOMAIN%.}
zone-set ${NEWDOMAIN%.} @ 60 SOA nshp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set ${NEWDOMAIN%.} @ 60 NS nshp.REDACTED.DOM.
zone-commit ${NEWDOMAIN%.}
EOZ -
Check this new domain content on your secondary nameserver:
NEWDOMAIN="my-first-domain.invalid"
su -c "/usr/bin/knotc zone-read ${NEWDOMAIN%.}." knot
Full caching DNS resolver implementation
The Knot Resolver is a caching full resolver implementation, including both a resolver library and a daemon.