If a zone is defined in Knot's configuration, but is not configured with dnssec-signing: on
, keymgr
emits a diagnostic message which, while correct, is not really helpful in diagnosing the problem.
$ preload keymgr . import-pkcs11 ea56bd06575e1315c33ed341e956c476 algorithm=rsasha256 ksk=yes zsk=no
error: not exists
This is likely a case of the code returning KNOT_ENOENT
without clarifying what the issue is.
It would be very helpful to be told exactly what doesn't exist (the zone, missing config, etc.)
knotd (Knot DNS), version 3.2.5
Thank you, Daniel.
Only if it simplifies your work in applying my occasionally uploaded .patch :-)
Hello, the attached patch contains slight rewordings for the catalog zone configuration section of the documentation.0001-slight-rephrasing-catz-section.patch
It looks okay to me ...
So I forgot the --patch option to create a unified patch, but nevertheless what I attached works for me with
patch -p0 < 0001-slight-rephrasing-catz-section.patch
But please do tell me how I should do this to improve your workflow :)
-JP
Thanks! How did you create the patche (and the previous one)? Git fails to apply it
oh, I'm sorry about that.
I normally give up completely on patches to projects on gitlab b/c it's so hard to do compared with using github, but this time I perservered, and I'm sad it's not working.
$ git clone knot $ git checkout -b new-branch-name $ vi ... $ git format-patch -1 HEAD
and then I attached the 0001-*.patch file.
It looks okay to me ...
What am I doing wrong?
-JP
Hello, the attached patch contains slight rewordings for the catalog zone configuration section of the documentation.0001-slight-rephrasing-catz-section.patch
I'm attaching a patch.
(I tried emailing this in as per click at the bottom of the Merge Requests page, but the patch was [Rejected]
:-)
0001-small-rephrasing-in-reference-for-unixtime-dateseria.patch
I'm attaching a patch.
(I tried emailing this in as per click at the bottom of the Merge Requests page, but the patch was [Rejected]
:-)
0001-small-rephrasing-in-reference-for-unixtime-dateseria.patch
I think the JSON is more useful with the zone name in it, so I have added that as well and cleaned up the patch.
There's not much that keymgr zone list | awk ...
won't manage, but doing this is also quite nice:
$ keymgr zone list -j | jq -r '.[] | "\(.tag) \(.algo)"'
16106 13
19517 13
10618 13
I think the simple domain list should probably also be JSON, so the above patch adds support for
$ keymgr -lj
[
"one.example.",
"two.example."
]
The attached patch adds support for printing keymgr zone list
in JSON as suggested earlier today.
JSON is triggered by option -j
(JSON). I have also used the json.[ch]
which have been used in the existing kdig and stats MR.
The list of keys is always a JSON array:
$ keymgr one.example list -j
[
{
"zone": "one.example.",
"id": "0735cbe3ae4e76e671037b079d004265edb89c09",
"ksk": true,
"zsk": false,
"tag": 16106,
"algo": 13,
"size": 256,
"public-only": false,
"pre-active": 0,
"publish": 1652185541,
"ready": 1652185541,
"active": 1652185541,
"retire-active": 0,
"retire": 0,
"post-active": 0,
"revoke": 0,
"remove": 0
}
]
Timestamps are integer if UNIX epoch format was requested, string otherwise:
"publish": "2022-05-10T12:25:58Z",
...
"publish": "-1h7m24s",
...
"publish": 1652185558,
A final bit of information: thanks to the support of the SmartCard-HSM vendor it turns out I've been mixing up drivers. After configuring the device properly to use the OpenSC pkcs11 driver only, Knot is now happily rolling ZSKs as though there were no tomorrow
% grep -c ZSK.rollover.started knot.log
15
Thanks again.
I'm running Knot 3.0.6 on Fedora 34 and experimenting with a SmartCard-HSM as described in this blog post I wrote.
During ZSK rollover, the server goes into what appears to be an endless loop attempting to generate a new key, but this occurs after a short while only, sometimes after having created 7, other time 4 keys successfully.
I have now compiled from source and have nailed the problem down to pkcs_generate_key(). After adding debugging statement, I see this output when the errors begin:
2021-06-07T12:36:17+0200 info: [example.net.] DNSSEC, signing zone
**** JP: gnutls_pkcs11_privkey_generate3: 0xFFFFFECC
2021-06-07T12:36:17+0200 warning: [example.net.] DNSSEC, key rollover, action generate (key generation error)
2021-06-07T12:36:17+0200 error: [example.net.] DNSSEC, failed to initialize (key generation error)
(The **** JP:
line is an fprintf())
I have pasted the full log here.
This machine is running Fedora 34 on a (physical) Thinkpad T420. As described in the blog, under the assumption that the issue is due to missing entropy, I have launched haveged, but that only slightly prolongs the duration until the error appears.
Is there something I can do to provide more information?
I'm closing this for now, as it's not a bug caused by Knot but rather the device. I would however recommend that Knot back off a bit more and/or maybe even consider "closing" and "reopening" the PKCS#11 interface if that's even possible.
Thank you very much for your help!
do you think that the issues with HSM might be related to its parallel usage in other software (or other zones in Knot)
What we're seeing occurs when Knot is using the device exclusively, and as can be seen from the logs, it's operating on a single zone (here: example.net
), so no.
Looking at the GnuTLS debug log, I don't think rrsig-prerefresh
is being used:
error: [example.net.] DNSSEC, failed to initialize (key generation error)
That message occurs about 4x per second.
Hi Libor, it would appear so, yes. I've just added GnuTLS logging so you might be able to confirm your finding.
I'm thinking it is indeed an issue with the HSM, but I wonder whether Knot should back off more thoroughly instead of filling up logs with attempts?
Upon looking at gnutls_pkcs11_privkey_generate3() I learn about debugging, so I launch Knot with
GNUTLS_DEBUG_LEVEL=999 /usr/local/knot306/sbin/knotd -v -c /etc/knot/knot.conf > gnu.log 2>&1
It looks to me as though the problem begins here:
gnutls[2]: p11: Cannot destroy object: An error occurred on the device
Knot catches the error and on the next iteration goes into the "loop" as I've called it.
I've paste the full log here.
I'm running Knot 3.0.6 on Fedora 34 and experimenting with a SmartCard-HSM as described in this blog post I wrote.
During ZSK rollover, the server goes into what appears to be an endless loop attempting to generate a new key, but this occurs after a short while only, sometimes after having created 7, other time 4 keys successfully.
I have now compiled from source and have nailed the problem down to pkcs_generate_key(). After adding debugging statement, I see this output when the errors begin:
2021-06-07T12:36:17+0200 info: [example.net.] DNSSEC, signing zone
**** JP: gnutls_pkcs11_privkey_generate3: 0xFFFFFECC
2021-06-07T12:36:17+0200 warning: [example.net.] DNSSEC, key rollover, action generate (key generation error)
2021-06-07T12:36:17+0200 error: [example.net.] DNSSEC, failed to initialize (key generation error)
(The **** JP:
line is an fprintf())
I have pasted the full log here.
This machine is running Fedora 34 on a (physical) Thinkpad T420. As described in the blog, under the assumption that the issue is due to missing entropy, I have launched haveged, but that only slightly prolongs the duration until the error appears.
Is there something I can do to provide more information?