9 Úno
2023
9 Úno
'23
12:55
Hello!
Knot 3.2.0 with a Thales HSM configured this way: (btw, I am not obfuscating
addresses or zone names -- these are actual testing names :)
keystore:
- id: thales
backend: pkcs11
config: "pkcs11:token=XX;pin-value=XXX
/opt/nfast/toolkits/pkcs11/libcknfast.so"
key-label: on
policy:
- id: manualHSM
keystore: thales
single-type-signing: off
manual: on
zone:
- domain: tt05
dnssec-signing: on
dnssec-policy: manualHSM
master: pdns
acl: [ xfr, notify_from_pdns ]
The zone `tt05' exists on the primary and can be transferred, as the following
logs will show.
I start off by generating a KSK and a ZSK, and verify that the keys are
actually on the HSM:
$ keymgr tt05 generate algorithm=8 size=2048 ksk=yes zsk=no
579f877d1739efb7bcf551e41c8777e965f8416f
$ keymgr tt05 generate algorithm=8 size=2048 ksk=no zsk=yes
eb8ef53ebffbd9950bfa914f7f2b0f1cd43bbe63
$ cklist -n | grep tt05
CKA_LABEL "tt05. KSK"
CKA_LABEL "tt05. ZSK"
I now reload Knot, and at this point I am actually expecting the server to
"see" the new zone, get the keys, perform the transfer (XFR) and sign the zone.
But all that doesn't happen:
$ knotc reload
Reloaded
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:10:10+0100
2023-02-09T12:10:10+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] zone event 'refresh' failed (not exists)
In the above, I don't understand why it's failed to load the keys. My
_assumption_ is that the server has enumerated the keys from the HSM but did
that before the two keys for this zone were created. Invoking `knotc
zone-keys-load' doesn't alter the situation.
I do understand the 'refresh' failing, as the zone tt05 doesn't as yet exist
on
this knot secondary.
So I initiate a zone transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:11:04+0100 info: [tt05.] control, received command
'zone-retransfer'
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:11:04+0100
2023-02-09T12:11:04+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] zone event 'refresh' failed (not exists)
It is clear that the transfer succeeds (the logs on the primary corroborate
this), and knot apparently knows the correct keys to use for the zone.
Why is it not signing it?
$ knotc zone-sign tt05
OK
2023-02-09T12:11:38+0100 info: [tt05.] control, received command 'zone-sign'
2023-02-09T12:11:38+0100 info: [tt05.] DNSSEC, dropping previous signatures, re-signing
zone
2023-02-09T12:11:38+0100 error: [tt05.] zone event 're-sign' failed (invalid
parameter)
I now restart the server:
# <restart knotd>
2023-02-09T12:12:16+0100 info: Knot DNS 3.2.0 starting
2023-02-09T12:12:16+0100 info: loaded configuration file '/etc/knot.conf', mapsize
500 MiB
2023-02-09T12:12:16+0100 info: using UDP reuseport, incoming TCP Fast Open
2023-02-09T12:12:16+0100 info: binding to interface 10.24.34.16@5353
2023-02-09T12:12:16+0100 info: changed directory to /
2023-02-09T12:12:16+0100 info: loading 7 zones
2023-02-09T12:12:16+0100 info: [tt05.] zone will be loaded
2023-02-09T12:12:16+0100 info: starting server
2023-02-09T12:12:18+0100 info: [tt05.] failed to parse zone file '/var/zones/tt05'
(not exists)
Here again, I understand it cannot parse the zone, because the transfer hasn't
actually been comitted to disk.
So I manually transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:13:23+0100 info: [tt05.] control, received command
'zone-retransfer'
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, signing started
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, successfully signed
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, next signing at 2023-02-23T11:13:24+0100
2023-02-09T12:13:23+0100 info: [tt05.] refresh, remote 192.168.33.31@53, zone updated,
0.44 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800
seconds
2023-02-09T12:13:23+0100 info: [tt05.] zone file updated, serial 2023010100
And now the zone is signed.
Is there some way to 'streamline' this? :-) Or am I just doing something wrong
or being too impatient?
Best regards,
-JP
9 Úno
9 Úno
15:19
Hello JP!
Do yo really use 3.2.0 or a newer 3.2.x version?
I'm trying to reproduce the issue without HSM but everything is ok so far. Will use
softhsm...
Daniel
On 2/9/23 12:55, Jan-Piet Mens wrote:
Hello!
Knot 3.2.0 with a Thales HSM configured this way: (btw, I am not obfuscating
addresses or zone names -- these are actual testing names :)
keystore:
- id: thales
backend: pkcs11
config: "pkcs11:token=XX;pin-value=XXX
/opt/nfast/toolkits/pkcs11/libcknfast.so"
key-label: on
policy:
- id: manualHSM
keystore: thales
single-type-signing: off
manual: on
zone:
- domain: tt05
dnssec-signing: on
dnssec-policy: manualHSM
master: pdns
acl: [ xfr, notify_from_pdns ]
The zone `tt05' exists on the primary and can be transferred, as the following
logs will show.
I start off by generating a KSK and a ZSK, and verify that the keys are
actually on the HSM:
$ keymgr tt05 generate algorithm=8 size=2048 ksk=yes zsk=no
579f877d1739efb7bcf551e41c8777e965f8416f
$ keymgr tt05 generate algorithm=8 size=2048 ksk=no zsk=yes
eb8ef53ebffbd9950bfa914f7f2b0f1cd43bbe63
$ cklist -n | grep tt05
CKA_LABEL "tt05. KSK"
CKA_LABEL "tt05. ZSK"
I now reload Knot, and at this point I am actually expecting the server to
"see" the new zone, get the keys, perform the transfer (XFR) and sign the
zone.
But all that doesn't happen:
$ knotc reload
Reloaded
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:10:10+0100
2023-02-09T12:10:10+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] zone event 'refresh' failed (not exists)
In the above, I don't understand why it's failed to load the keys. My
_assumption_ is that the server has enumerated the keys from the HSM but did
that before the two keys for this zone were created. Invoking `knotc
zone-keys-load' doesn't alter the situation.
I do understand the 'refresh' failing, as the zone tt05 doesn't as yet exist
on
this knot secondary.
So I initiate a zone transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:11:04+0100 info: [tt05.] control, received command
'zone-retransfer'
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:11:04+0100
2023-02-09T12:11:04+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] zone event 'refresh' failed (not exists)
It is clear that the transfer succeeds (the logs on the primary corroborate
this), and knot apparently knows the correct keys to use for the zone.
Why is it not signing it?
$ knotc zone-sign tt05
OK
2023-02-09T12:11:38+0100 info: [tt05.] control, received command 'zone-sign'
2023-02-09T12:11:38+0100 info: [tt05.] DNSSEC, dropping previous signatures, re-signing
zone
2023-02-09T12:11:38+0100 error: [tt05.] zone event 're-sign' failed (invalid
parameter)
I now restart the server:
# <restart knotd>
2023-02-09T12:12:16+0100 info: Knot DNS 3.2.0 starting
2023-02-09T12:12:16+0100 info: loaded configuration file '/etc/knot.conf',
mapsize 500 MiB
2023-02-09T12:12:16+0100 info: using UDP reuseport, incoming TCP Fast Open
2023-02-09T12:12:16+0100 info: binding to interface 10.24.34.16@5353
2023-02-09T12:12:16+0100 info: changed directory to /
2023-02-09T12:12:16+0100 info: loading 7 zones
2023-02-09T12:12:16+0100 info: [tt05.] zone will be loaded
2023-02-09T12:12:16+0100 info: starting server
2023-02-09T12:12:18+0100 info: [tt05.] failed to parse zone file
'/var/zones/tt05' (not exists)
Here again, I understand it cannot parse the zone, because the transfer hasn't
actually been comitted to disk.
So I manually transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:13:23+0100 info: [tt05.] control, received command
'zone-retransfer'
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK,
public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256,
public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, signing started
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, successfully signed
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, next signing at 2023-02-23T11:13:24+0100
2023-02-09T12:13:23+0100 info: [tt05.] refresh, remote 192.168.33.31@53, zone updated,
0.44 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800
seconds
2023-02-09T12:13:23+0100 info: [tt05.] zone file updated, serial 2023010100
And now the zone is signed.
Is there some way to 'streamline' this? :-) Or am I just doing something wrong
or being too impatient?
Best regards,
-JP
--
17:30
"Unfortunately", even with softhsm I cannot reproduce that.
On 2/9/23 16:57, Jan-Piet Mens wrote:
I'm trying
to reproduce the issue without HSM but everything is ok so far.
I can confirm that. With a key store on disk, as soon as the zone is configured
and I `knotc reload' the XFR takes place and the zone is signed.
-JP
--
10 Úno
10 Úno
12:43
Good news JP, I have reproduced the issue with Keyper HSM.
Daniel
On 2/9/23 18:05, Jan-Piet Mens wrote:
"Unfortunately", even with softhsm I cannot reproduce that.
I was a bit afraid of that, as it puts the blame on the HSM proper and
therefore becomes almost completely undebuggable (is that even a word?).
But thank you, Daniel, for looking into this.
-JP
--
16:26
Now it's obvious what's going on :-)
The problem isn't with HSM (of course it happens with SoftHSM too) but in the
configuration.
If the zone isn't configured, keymgr reads the defaults (PEM keystore). So you have to
add the
zone to the configuration before manual key generation or to set some policy with the
PKCS11
keystore in the default template.
I'm considering extending keymgr listing with the keystore type. Also it's
possible to forbid
generation for zones which aren't configured or to print some warning, but it would be
inconvenient.
Daniel
On 2/10/23 12:43, Daniel Salzman wrote:
Good news JP, I have reproduced the issue with Keyper
HSM.
Daniel
On 2/9/23 18:05, Jan-Piet Mens wrote:
--
"Unfortunately", even with softhsm I cannot reproduce that.
I was a bit afraid of that, as it puts the blame on the HSM proper and
therefore becomes almost completely undebuggable (is that even a word?).
But thank you, Daniel, for looking into this.
-JP
--
11 Úno
11 Úno
11:42
>Good news JP, I have reproduced the issue with
Keyper HSM.
I'm glad you can reproduce it, Daniel. :)
I'm considering extending keymgr listing with the
keystore type.
that would be useful.
The problem isn't with HSM (of course it happens
with SoftHSM too) but in the configuration.
If the zone isn't configured, keymgr reads the defaults (PEM keystore). So you have to
add the
zone to the configuration before manual key generation or to set some policy with the
PKCS11
keystore in the default template.
That's what I did. In order:
1. Add the zone to the configuration. Don't reload yet.
2. keymgr generate to create the keys on the HSM. (If I do this before step 1, then the
keys are obvously created on the default PEM keystore.)
3. Transfer the zone
If I change the order of activities, I still have to retransfer at least once:
1. Add zone to configuration
2. Reload knot conf
2023-02-11T11:35:05+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-11T11:35:05+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:35:05+0100 error: [tt06.] DNSSEC, no keys are available
2023-02-11T11:35:05+0100 error: [tt06.] DNSSEC, failed to load keys (no keys for signing)
2023-02-11T11:35:05+0100 info: [tt06.] DNSSEC, next signing at 2023-02-11T12:35:05+0100
2023-02-11T11:35:05+0100 error: [tt06.] refresh, failed (no keys for signing)
2023-02-11T11:35:05+0100 error: [tt06.] zone event 'refresh' failed (no keys for
signing)
3. Generate keys on PKCS11
4. zone-retransfer tt06
2023-02-11T11:36:32+0100 info: [tt06.] control, received command
'zone-retransfer'
2023-02-11T11:36:32+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-11T11:36:32+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, key, tag 59128, algorithm RSASHA256,
public, active
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, key, tag 7376, algorithm RSASHA256, KSK,
public, active
2023-02-11T11:36:32+0100 error: [tt06.] DNSSEC, failed to load private keys (not exists)
2023-02-11T11:36:32+0100 error: [tt06.] DNSSEC, failed to load keys (not exists)
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, next signing at 2023-02-11T12:36:32+0100
2023-02-11T11:36:32+0100 error: [tt06.] refresh, failed (not exists)
2023-02-11T11:36:32+0100 error: [tt06.] zone event 'refresh' failed (not exists)
5. restart server
2023-02-11T11:37:20+0100 info: [tt06.] failed to parse zone file 'tt06' (not
exists)
2023-02-11T11:37:20+0100 info: [tt06.] zone will be bootstrapped
6. zone-retransfer tt06
2023-02-11T11:37:57+0100 info: [tt06.] control, received command
'zone-retransfer'
2023-02-11T11:37:57+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-11T11:37:57+0100 info: [tt06.] AXFR, incoming, remote 192.168.33.31@53, finished,
0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:37:57+0100 info: [tt06.] DNSSEC, key, tag 59128, algorithm RSASHA256,
public, active
2023-02-11T11:37:57+0100 info: [tt06.] DNSSEC, key, tag 7376, algorithm RSASHA256, KSK,
public, active
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, signing started
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, successfully signed
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, next signing at 2023-02-25T10:37:58+0100
2023-02-11T11:37:58+0100 info: [tt06.] refresh, remote 192.168.33.31@53, zone updated,
0.45 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800
seconds
2023-02-11T11:37:58+0100 info: [tt06.] zone file updated, serial 2023010100
Best regards,
-JP
14:17
Hello!
Sorry, I'm confused. My test:
1) Secondary Knot is running without zone (055e.) configured.
2) The config file is extended with these lines without reload/restart:
keystore:
- id: hsm
backend: pkcs11
config: "pkcs11:token=knot;pin-value=1234
/home/keyper/Keyper/PKCS11Provider/pkcs11.so"
key-label: on
policy:
- id: pol
manual: on
keystore: hsm
zone:
- domain: 055e.
dnssec-signing: on
dnssec-policy: pol
3) Two new keys are generated:
$ keymgr 055e generate ksk=yes zsk=no
463b611ac6dd050fe682a0df5c53a7f5ab5ec1d5
$ keymgr 055e generate ksk=no zsk=yes
c6439fd3acd592817c46a22ac4f67475095f70ac
$ keymgr 055e list
463b611ac6dd050fe682a0df5c53a7f5ab5ec1d5 36332 KSK ECDSAP256SHA256
publish=1676120693 ready=1676120693 active=1676120693
c6439fd3acd592817c46a22ac4f67475095f70ac 55614 ZSK ECDSAP256SHA256
publish=1676120698 active=1676120698
4) The secondary Knot is reloaded:
2023-02-11T14:05:18+0100 info: control, received command 'reload'
2023-02-11T14:05:18+0100 info: reloading configuration file
'/etc/knot/knot.conf'
2023-02-11T14:05:18+0100 info: [055e.] zone will be loaded
2023-02-11T14:05:18+0100 info: configuration reloaded
2023-02-11T14:05:18+0100 info: [055e.] failed to parse zone file
'/tmp/055e.zone' (not exists)
2023-02-11T14:05:18+0100 info: [055e.] zone will be bootstrapped
2023-02-11T14:05:18+0100 info: [055e.] AXFR, incoming, remote ::1@3889,
started
2023-02-11T14:05:18+0100 info: [055e.] AXFR, incoming, remote ::1@3889,
finished, 0.00 seconds, 1 messages, 211 bytes
2023-02-11T14:05:18+0100 info: [055e.] DNSSEC, key, tag 36332, algorithm
ECDSAP256SHA256, KSK, public, active
2023-02-11T14:05:18+0100 info: [055e.] DNSSEC, key, tag 55614, algorithm
ECDSAP256SHA256, public, active
2023-02-11T14:05:19+0100 info: [055e.] DNSSEC, signing started
2023-02-11T14:05:19+0100 info: [055e.] DNSSEC, successfully signed
2023-02-11T14:05:19+0100 info: [055e.] DNSSEC, next signing at
2023-02-25T13:05:19+0100
2023-02-11T14:05:19+0100 info: [055e.] refresh, remote ::1@3889, zone
updated, 1.02 seconds, serial none -> 1480320382, remote serial
1480320382, expires in 2419200 seconds
What is different?
Daniel
Dne 2023-02-11 11:42, Jan-Piet Mens napsal:
> Good news
JP, I have reproduced the issue with Keyper HSM.
I'm glad you can reproduce it, Daniel. :)
I'm considering extending keymgr listing with
the keystore type.
that would be useful.
The problem isn't with HSM (of course it
happens with SoftHSM too) but
in the configuration.
If the zone isn't configured, keymgr reads the defaults (PEM
keystore). So you have to add the
zone to the configuration before manual key generation or to set some
policy with the PKCS11
keystore in the default template.
That's what I did. In order:
1. Add the zone to the configuration. Don't reload yet.
2. keymgr generate to create the keys on the HSM. (If I do this before
step 1, then the keys are obvously created on the default PEM
keystore.)
3. Transfer the zone
If I change the order of activities, I still have to retransfer at
least once:
1. Add zone to configuration
2. Reload knot conf
2023-02-11T11:35:05+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, started
2023-02-11T11:35:05+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:35:05+0100 error: [tt06.] DNSSEC, no keys are available
2023-02-11T11:35:05+0100 error: [tt06.] DNSSEC, failed to load keys
(no keys for signing)
2023-02-11T11:35:05+0100 info: [tt06.] DNSSEC, next signing at
2023-02-11T12:35:05+0100
2023-02-11T11:35:05+0100 error: [tt06.] refresh, failed (no keys for
signing)
2023-02-11T11:35:05+0100 error: [tt06.] zone event 'refresh' failed
(no keys for signing)
3. Generate keys on PKCS11
4. zone-retransfer tt06
2023-02-11T11:36:32+0100 info: [tt06.] control, received command
'zone-retransfer'
2023-02-11T11:36:32+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, started
2023-02-11T11:36:32+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, key, tag 59128,
algorithm RSASHA256, public, active
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, key, tag 7376,
algorithm RSASHA256, KSK, public, active
2023-02-11T11:36:32+0100 error: [tt06.] DNSSEC, failed to load private
keys (not exists)
2023-02-11T11:36:32+0100 error: [tt06.] DNSSEC, failed to load keys
(not exists)
2023-02-11T11:36:32+0100 info: [tt06.] DNSSEC, next signing at
2023-02-11T12:36:32+0100
2023-02-11T11:36:32+0100 error: [tt06.] refresh, failed (not exists)
2023-02-11T11:36:32+0100 error: [tt06.] zone event 'refresh' failed
(not exists)
5. restart server
2023-02-11T11:37:20+0100 info: [tt06.] failed to parse zone file
'tt06' (not exists)
2023-02-11T11:37:20+0100 info: [tt06.] zone will be bootstrapped
6. zone-retransfer tt06
2023-02-11T11:37:57+0100 info: [tt06.] control, received command
'zone-retransfer'
2023-02-11T11:37:57+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, started
2023-02-11T11:37:57+0100 info: [tt06.] AXFR, incoming, remote
192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-11T11:37:57+0100 info: [tt06.] DNSSEC, key, tag 59128,
algorithm RSASHA256, public, active
2023-02-11T11:37:57+0100 info: [tt06.] DNSSEC, key, tag 7376,
algorithm RSASHA256, KSK, public, active
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, signing started
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, successfully signed
2023-02-11T11:37:58+0100 info: [tt06.] DNSSEC, next signing at
2023-02-25T10:37:58+0100
2023-02-11T11:37:58+0100 info: [tt06.] refresh, remote
192.168.33.31@53, zone updated, 0.45 seconds, serial none ->
2023010100, remote serial 2023010100, expires in 604800 seconds
2023-02-11T11:37:58+0100 info: [tt06.] zone file updated, serial
2023010100
Best regards,
-JP
--
17:48
4) The secondary Knot is reloaded:
2023-02-11T14:05:18+0100 info: [055e.] zone will be bootstrapped
2023-02-11T14:05:18+0100 info: [055e.] AXFR, incoming, remote::1@3889, started
2023-02-11T14:05:18+0100 info: [055e.] AXFR, incoming, remote::1@3889, finished, 0.00
seconds, 1 messages, 211 bytes
2023-02-11T14:05:18+0100 info: [055e.] DNSSEC, key, tag 36332, algorithm ECDSAP256SHA256,
KSK, public, active
2023-02-11T14:05:18+0100 info: [055e.] DNSSEC, key, tag 55614, algorithm ECDSAP256SHA256,
public, active
2023-02-11T14:05:19+0100 info: [055e.] DNSSEC, signing started
2023-02-11T14:05:19+0100 info: [055e.] DNSSEC, successfully signed
What is different?
The only differences I see:
- no 'master' remote specified in the zone config (probably in template)
- you're using algo=13 keys, I algo=8
- different HSM type
- your example works, mine doesn't.
As soon as your AXFR completes, the server 'sees' the keys and signs, which is
precisely the behaviour I'd expect.
In my situations, the AXFR completes, and the next log is "DNSSEC, no keys are
available".
-JP
19:18
Daniel,
here I'm comparing apples and bits of bitter chocolate because a) version 3.2.5
instead of 3.2.0, and b) a much cheaper HSM.
I add the zone to the configuration, reload the server, and it works as
expected:
2023-02-11T19:12:07+0100 info: [tt10.] zone will be loaded
2023-02-11T19:12:07+0100 info: configuration reloaded
2023-02-11T19:12:07+0100 info: [tt10.] failed to parse zone file ... (not exists)
2023-02-11T19:12:07+0100 info: [tt10.] zone will be bootstrapped
2023-02-11T19:12:07+0100 info: [tt10.] AXFR, incoming, remote ... finished, 0.00 seconds,
1 messages, 449 bytes
2023-02-11T19:12:08+0100 info: [tt10.] DNSSEC, key, tag 34035, algorithm ECDSAP256SHA256,
KSK, public, active
2023-02-11T19:12:08+0100 info: [tt10.] DNSSEC, key, tag 29038, algorithm ECDSAP256SHA256,
public, active
2023-02-11T19:12:08+0100 info: [tt10.] DNSSEC, signing started
2023-02-11T19:12:11+0100 info: [tt10.] DNSSEC, successfully signed
2023-02-11T19:12:11+0100 info: [tt10.] DNSSEC, next signing at 2023-02-25T18:12:09+0100
2023-02-11T19:12:11+0100 info: [tt10.] zone file updated, serial 4
So, assuming your last test with the Keyper was with 3.2.5 we'll leave this as
is until we've been able to upgrade Knot to the latest version.
Thank you very much for your help!
Best regards,
-JP
10 Úno
10 Úno
13:05
Hi JP,
I can confirm that I'm testing Knot 3.2.4 at the moment and see similar
(somewhat expected) behaviour, only difference from your config is that
Knot is the master for my zones. If there are no zone files Knot will
not even generate DNS keys (automated in my setup). But when a zone file
becomes available and I issue `knotc zone-reload ZONE`, Knot will then
generate required keys and signing the zone will work just fine. And I'm
using Knot itself as a signing backend.
Kareem.
On 09/02/2023 14:19, Daniel Salzman wrote:
2023-02-09T12:12:18+0100 info: [tt05.] failed to parse
zone file
'/var/zones/tt05' (not exists)
--
*Abdulkareem H. Ali*
*Technical Product Owner, DNS*
kareem.ali(a)centralnic.com
Office: +44 (0)203 388 0600
Web: www.centralnic.com
/CentralNic Group PLC (LON: CNIC). CEO: Ben Crawford. Registered Office:
4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V
6BR. CentralNic is a company registered in England and Wales with the
company number 8576358./
627
days inactive
629
days old
14 comments
4 participants
participants (4)
-
Abdulkareem H. Ali -
Daniel Salzman -
daniel.salzman＠nic.cz
-
Jan-Piet Mens