Any ideas what might be causing the following error ?
knotc (Knot DNS), version 3.1.0
$ sudo /usr/sbin/knotc zone-backup -- +backupdir /home/foo/test
error: (operation not permitted)
The destination directory exits. It doesn't matter if I run the command as root or knot user, the error is the same.
According to the documentation, one can back up the KASP using the mdb_dump
command. Now I understand things correctly, this will just back up the
public component of key pairs, plus some metadata for the zones the public
keys are associated with.
Are there any provisions in Knot concerning the backing up of the private
components of key pairs, or is this something that must be done separately
and within the context of whatever cryptographic provider is used?
The documentation for keymgr describes the import-bind command as follows:
import-bind BIND_key_file
Imports a BIND-style key into KASP database (converting it to PEM format).
Takes one argument: path to BIND key file (private or public, but both MUST
exist).
What is imported into the KASP exactly? I thought that the KASP database
consisted of public keys alone. This aside, importing a private key will
depend on whether the cryptographic provider supports such an operation -
many HSMs, in particular those with stringent FIPS 140-compliance
requirements, will in general refuse to do so.
So, what does this command do with the private key? Is it turned over to
the cryptographic provider, returning an error if this provider refuses to
import private keys? If such is the case, is the public key still imported
into the KASP, even though there will be no matching private key for it
anywhere in the system?
One can of course use a public key without a matching private key, but in a
DNSSEC software framework like Knot, where the bulk of the activity
consists of carrying out signing operations, the presence of a complete key
pair would seem to be essential.
Hi,
For various reasons I need to write a Go wrapper around knotc conf.
The problem is I am seeing weird behaviour (the below is stdout from my Go script):
########
Command being run: /usr/sbin/knotc conf-begin
OK
Command being run: /usr/sbin/knotc conf-set 'server.version' '299'error: (invalid item) 'server.version' = '299'
Command being run: /usr/sbin/knotc conf-abortOK
########
If I take the "usr/sbin/knotc conf-set 'server.version' '299'" string generated by Go and paste it onto CLI, it returns OK ?
I have tried adding "-v" flag but that does not produce any interesting output.
Any idea where I might be going wrong here ? Why am I getting "error: (invalid item)" when Go executes the command, but not when I run it manually ?
Thanks !
Tha man page for keymgr says that the keymgr generate command
(quote) Generates new DNSSEC key and stores it in KASP database. (unquote)
What is exactly stored in the KASP database?
The reason I am asking is because the actual cryptographic key will be
available in the clear only when using the default key store. When using an
HSM (or event softhsm) only the HSM will have access to the key in the
clear. So, what is it that gets stored in the KASP database when an HSM is
used for generating keys?
Hi,
We are testing migration from bind to knot, to implement dnssec. We like
many things about knot! Thank you for making it available!
So far many things work, but we do have some uncertainties. Hope they're
not too basic to ask here...
We are using ubuntu, knot 3.1.0, our static bind zone files saved as
/var/lib/knot/zones/db.domain.com and also the non-binary knot config.
(in /etc/knot/knot.conf)
1) I wanted to test the knotc zone-backup command, but we're getting:
> 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?
3) After each knot restart, we are seeing:
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] DNSSEC, zone is up-to-date
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] loaded, serial none -> 2017041004, 106139 bytes
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] DNSSEC, next signing at 2021-08-09T16:10:10+0200
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, zone is up-to-date
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] loaded, serial none -> 2021072903, 183151 bytes
> Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, next signing at 2021-08-09T16:10:10+0200
> 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?)
Thanks for any feedback!
MJ
Hi all
I am currently running these two policies:
```
policy:
- id: edecc
algorithm: ed25519
nsec3: on
- id: rsa
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 2048
nsec3: on
```
I tried enabling both with this command, but to no effect:
```
dnssec-policy: [ edecc, rsa ]
```
Is there a way to do both at the same time in one zone?
I am currently running knot 3.0.8
Cheers,
Stefan
