2 Srp
2021
2 Srp
'21
17:23
On 02/08/2021 16:57, mj wrote:
Hi MJ,
By default, Knot flushes zone files to the disk in plain zone file
format. However, I have a suggestion for you. Instead of keeping the
signed zones on disk in zone file format, use Knot's journal. You should
use the following options for your zone, or your default template:
journal-content: all
zonefile-load: differences-no-serial
zonefile-sync: -1
With these settings, Knot will load the unsigned zone from your zone
file on disk. It will sign the zone, and store the file contents of the
zone into its journal. Knot will not touch your unsigned zone on disk.
Whenever you need to change the zone, you can edit the zone file in
/var/lib/knot/db.domain.com, and run:
knotc zone-reload domain.com
Knot will read the zone file, find the differences, re-sign the parts of
the zone that need to be re-signed, and store everything into the
journal. Also note that you don't need to remember to update the serial
number in the SOA record of the zone. Knot will automatically increment
it by one whenever it needs to re-sign the zone, and the correct serial
will be stored in the journal. If you don't like the serial number to be
just incremented, you can use a different policy, by setting
"serial-policy" to either "unixtime" or "dateserial" (this
latter
setting is only useful if your zone doesn't change more than 100 times
in one day).
Regards,
Anand Buddhdev
RIPE NCC
We are testing migration from bind to knot, to
implement dnssec. We like
many things about knot! Thank you for making it available!
This is great! You'll love Knot! I'm not a developer, but I use Knot,
and I can provide some answers.
1) I wanted to test the knotc zone-backup command, but
we're getting:
You should not need to backup your zone files with the "knotc
zone-backup" command. Instead, just do filesystem copy of the files.
error: backup init failed (operation not
permitted)
Is the zone-backup command geared towards binary zones? Are our static
zone files the reason this doesn't work? I realise we can simply copy
the zone files, so in our case, the backup command probably adds nothing. 2) I have enabled DNSSEC, and upon restart we saw the
keys being
generated, and files appeared under /var/lib/knot/keys
I guess keeping copies of the files there is adequate backup too? No
"knotc zone-backup" required here as well?
Yes, you can backup /var/lib/knot/keys, and that should be adequate.
Aug 2
16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.]
failed to update zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.]
zone event 'journal flush' failed (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning:
[1.2.3.4.in-addr.arpa.] failed to update zone file (operation not
permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error:
[1.2.3.4.in-addr.arpa.] zone event 'journal flush' failed (operation
not permitted)
We would like to understand the warnings/errors here too. Why would knot
try to update the zone files, and why it is failing? I have set the
permissions on the zone files 660 / knot:knot so it should be able edit
them. (but again: why would knot want to update them?)