I found out what the heck it was, at last. First, softhsm was correctly initialized - no problem there. The issue was that knot.conf file was the following ( the relevant portions alone):
keystore:
- id: SoftHSM
backend: pkcs11
config: "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=1eb6899f1f278686;token=SoftHSMToken;pin-value=SoftHSMPIN /usr/lib/softhsm/libsofthsm2.so"
policy:
- id: manual
manual: on
The policy section was missing a keystore entry, which caused Knot to fall back to the default key store. After I added
keystore: SoftHSM
everything worked as expected.
-----Original Message-----
From: "" [daniel.salzman(a)nic.cz]
Date: 11/07/2018 08:43 AM
To: "Full Name" <nuncestbibendum(a)excite.com>
CC: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface
On 2018-11-05 17:47, Full Name wrote:
> I am sorry; I made a mistake when pasting the knot.conf contents here
> - I am using the module path all right, and it makes no difference. In
> fact, the issue seems to be with the knot.conf parser - be it because
> I am doing things incorrectly myself, or because it is broken. I have
> noticed the same in Knot 2.6.9 and 2.7.3.
>
So what is your exact configuration of the keystore?
> Can anyone throw some light on this? What else has one got to do to
> get Knot to use the PKCS #11 interface for the key store? I have the
> necessary library (softHSM) plus the correct data in knot.conf. But
> the keymgr function is not using the PKCS #11 interface. What am I
> missing?
>
I think you have to learn how to initialize a PKCS #11 token first.
Try something like:
export SOFTHSM2_CONF=/path/to//softhsm.conf
softhsm2-util --init-token --slot=0 --label="knot" --pin=1234
--so-pin=12345 --module=/usr/lib/softhsm/libsofthsm2.so
and follow https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#config
...
> I provided some debugging traces in a separate message to
> illustrate the issue. I'll be happy to furnish more data, if somebody
> knowledgeable on the Knot internals lets me know what traces to
> provide. I really need to be able to get Knot to use the PKCS #11
> interface.
>
>
>
> -----Original Message-----
> From: "" [daniel.salzman(a)nic.cz]
> Date: 11/02/2018 05:39 AM
> To: "Full Name" <nuncestbibendum(a)excite.com>
> CC: knot-dns-users(a)lists.nic.cz
> Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11
> interface
>
> Hello Full Name,
>
> The pkcs11 keystore configuration should have the form of
> "<pkcs11-url> <module-path>". I will improve the documentation.
>
> Daniel
>
> On 2018-11-01 18:04, Full Name wrote:
>> I have a knot.conf file with the following keystore section:
>>
>> keystore:
>> - id: TheBackend
>> backend: pkcs11
>> config:
>> "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System
>> Trust"
>>
>> where the value assigned to the config keyword is obtained from the
>> output from the GnuTLS p11tool command:
>>
>> $ p11tool --list-tokens
>> Token 0:
>> URL:
>> pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
>> Label: System Trust
>> Type: Trust module
>> Flags: uPIN uninitialized
>> Manufacturer: PKCS#11 Kit
>> Model: p11-kit-trust
>> Serial: 1
>> Module: p11-kit-trust.so
>>
>> Also in knot.conf I have
>>
>> policy:
>> - id: manual
>> manual: on
>>
>> zone:
>> - domain: example.com
>> storage: /var/lib/knot/zones/
>> file: example.com.zone
>> dnssec-signing: on
>> dnssec-policy: manual
>>
>> With all this in place, I launched the following from the CLI:
>>
>> # keymgr example.com. generate algorithm=ECDSAP256SHA256
>>
>> This does not seem to be using the PKCS #11 library, as instructed in
>> knot.conf. I debugged the command above and noticed that, at some
>> before the signing operation itself is addressed, the keystore_load
>> function from the Knot code base is invoked. This function takes
>> several arguments, the second of which is a backend identifier.
>> According to the keystore entry in knot.conf, this should be the PKCS
>> #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the
>> debugger is that the backend argument is, in fact,
>> KEYSTORE_BACKEND_PEM.
>>
>> Even more intriguing (to somebody unfamiliar with the internal
>> workings of Knot, at least) is that, before keystore_load is invoked,
>> the check_keystore function is invoked and it evaluates the following
>> conditional:
>>
>> if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 &&
>> conf_str(&config) == NULL)
>>
>> This conditional clearly succeeds - i.e. at that point the backend has
>> been correctly identified as PKCS #11. But, like I said above, when
>> keystore_load gets called later on, such is not the case any longer.
>>
>> Any idea as to what is going on here? Why is PKCS #11 not being used?
>> In the config string above in knot.conf I tried replacing %23 and %20
>> with # and the space character, respectively. It made no difference.
>> This all is happening with Knot 2.7.3.
I am sorry; I made a mistake when pasting the knot.conf contents here - I am using the module path all right, and it makes no difference. In fact, the issue seems to be with the knot.conf parser - be it because I am doing things incorrectly myself, or because it is broken. I have noticed the same in Knot 2.6.9 and 2.7.3.
Can anyone throw some light on this? What else has one got to do to get Knot to use the PKCS #11 interface for the key store? I have the necessary library (softHSM) plus the correct data in knot.conf. But the keymgr function is not using the PKCS #11 interface. What am I missing?
I provided some debugging traces in a separate message to illustrate the issue. I'll be happy to furnish more data, if somebody knowledgeable on the Knot internals lets me know what traces to provide. I really need to be able to get Knot to use the PKCS #11 interface.
-----Original Message-----
From: "" [daniel.salzman(a)nic.cz]
Date: 11/02/2018 05:39 AM
To: "Full Name" <nuncestbibendum(a)excite.com>
CC: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface
Hello Full Name,
The pkcs11 keystore configuration should have the form of
"<pkcs11-url> <module-path>". I will improve the documentation.
Daniel
On 2018-11-01 18:04, Full Name wrote:
> I have a knot.conf file with the following keystore section:
>
> keystore:
> - id: TheBackend
> backend: pkcs11
> config:
> "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System
> Trust"
>
> where the value assigned to the config keyword is obtained from the
> output from the GnuTLS p11tool command:
>
> $ p11tool --list-tokens
> Token 0:
> URL:
> pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
> Label: System Trust
> Type: Trust module
> Flags: uPIN uninitialized
> Manufacturer: PKCS#11 Kit
> Model: p11-kit-trust
> Serial: 1
> Module: p11-kit-trust.so
>
> Also in knot.conf I have
>
> policy:
> - id: manual
> manual: on
>
> zone:
> - domain: example.com
> storage: /var/lib/knot/zones/
> file: example.com.zone
> dnssec-signing: on
> dnssec-policy: manual
>
> With all this in place, I launched the following from the CLI:
>
> # keymgr example.com. generate algorithm=ECDSAP256SHA256
>
> This does not seem to be using the PKCS #11 library, as instructed in
> knot.conf. I debugged the command above and noticed that, at some
> before the signing operation itself is addressed, the keystore_load
> function from the Knot code base is invoked. This function takes
> several arguments, the second of which is a backend identifier.
> According to the keystore entry in knot.conf, this should be the PKCS
> #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the
> debugger is that the backend argument is, in fact,
> KEYSTORE_BACKEND_PEM.
>
> Even more intriguing (to somebody unfamiliar with the internal
> workings of Knot, at least) is that, before keystore_load is invoked,
> the check_keystore function is invoked and it evaluates the following
> conditional:
>
> if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 &&
> conf_str(&config) == NULL)
>
> This conditional clearly succeeds - i.e. at that point the backend has
> been correctly identified as PKCS #11. But, like I said above, when
> keystore_load gets called later on, such is not the case any longer.
>
> Any idea as to what is going on here? Why is PKCS #11 not being used?
> In the config string above in knot.conf I tried replacing %23 and %20
> with # and the space character, respectively. It made no difference.
> This all is happening with Knot 2.7.3.
Hi,
i have the issue, that the example wont work, because there ist no "libknot.so"
on my system:
root@f-dns4:~# ldconfig -v 2>/dev/null | grep libknot
libknot.so.8 -> libknot.so.8.0.0
root@f-dns4:~# lsb_release -a; dpkg-query -W knot
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
root@f-dns4:~# dpkg-query -W knot
knot 2.7.3-1~ubuntu18.04.1ppa2
I has made a patch for that, with a search order, if no path is given.
Hopefully this help to solve this issue.
Greetings
Frank
--
Frank Matthieß Stapenhorster Straße 42b, DE 33615 Bielefeld
Mail: frank.matthiess(a)virtion.de
GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1
Hi,
I'm trying to spin a nice transaction model around libknot, intended for
better automation, as attached. I'm running into problems.
First and foremost, a lack of understanding what should go into what
fields when doing other commands than in the "stats" demos. Are there
more advanced explanations of what goes into what fields? I tried
looking into knotc, but it is rather long. Perhaps there is a log
somewhere with the stuff going into knotd?
Secondly, the model by which transactions abort is not always logical.
Like a commit() that fails but does not turn into an abort() when
semantic errors are found. I will run zone-check beforehand, to ensure
that this does not happen.
Thirdly, I found that the library freezes when supplied with unknown
commands or apparently funny data...
>>> import knotcontrol
>>> kc = knotcontrol.KnotControl()
>>> kc = knotcontrol.KnotControl ()
>>> kc.knot (cmd='stats')
KnotControl send {'cmd': 'stats'}
KnotControl recv {'server': {'zone-count': ['1']}}
{'server': {'zone-count': ['1']}}
>>> kc.knot (cmd='zone-stats',item='vanrein.org')
KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-stats'}
KnotControl recv {}
{}
>>> kc.knot (cmd='zone-recv',item='vanrein.org')
KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-recv'}
...and at this point it freezes, even to ^C -- before and after this
sequence, "kdig @localhost vanrein.org soa" worked to query the zone in
Knot DNS.
Sorry to be testing this early :-S but I'm eager to use it this way.
-Rick
Hello,
could you please send me a short guide how to delegate a zone subnet (class)
to different NS.
I have a zone i.e. 0.10.in-addr.arpa.zone
where I would like to delegate a part of the zone 10.0.0.104/29 (255.255.
255.248) to different NS. It includes 8 IP addresses (10.0.0.104, 10.0.
0.105, 10.0.0.106 .... 10.0.0.111)
then I create a record in the mentioned zone like
104/29.0.0.10.in-addr.arpa. 300 NS my.test.server.
I tried to understand the syntax in RFC 2317 (https://tools.ietf.org/html/
rfc2317) but it seems to be wrongly implemented from my side.
When I tried to "dig" records I have to ask next IP address in the row not
like dig -x 10.0.0.105 bud like dig -x 10.0.0.104/29.105
Many thanks for the clarification,
best regards
Milan.
Hi,
I am following Daniel's advise
> Consider controlling the server directly using our
> python wrapper:
in trying to get more transactional rigour through the Python library
from Git. The library certainly is easier to integrate!
But I think I hit upon a bug. The code
def __init__ (self, socketpath='/var/run/knot/knot.sock'):
"""Connect to knotd
"""
self.ctl = None
self.txn_conf = False
self.txn_zone = set ()
self.txn_success = True
self.ctl = libknot.control.KnotCtl ()
self.ctl.connect (socketpath)
self.ctl.set_timeout (3600)
seems to not set any timeout; it always cuts off after 5s sleep, and
never after 4s sleep. This is true for the first command as well as
later ones. Same when setting the timeout to 7200, so it's not a ms/s
issue.
This code is almost literally the same as in StatsServer, except that
demo runs too fast to detect timeout problems. I ran into it when
working interactively.
Ideally, I would want to disable connection timeouts altogether, so it
is possible to abort any open transactions upon whatever cause for
termination there might be; this should benefit stability.
-Rick
Hello,
I want to switch to KnotDNS on my private zone (bt909.de). I've installed the knot2 port as binary package within a FreeBSD jail. I configured my zones and zone transfer works fine, but KnotDNS didn't answer any query. I have a acl for the zone transfer, is there anything I need to do, that knot answers my queries? Knot is running, I found nothing in the logs, even the port ist open, but Knot just does nothing and my queries run into timeouts.
I tried NSD in the same jail, which works fine, but I want to use KnotDNS.
Regards, Thomas
--
Thomas Belian; https://bt909.de
I have a knot.conf file with the following keystore section:
keystore:
- id: TheBackend
backend: pkcs11
config: "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System Trust"
where the value assigned to the config keyword is obtained from the output from the GnuTLS p11tool command:
$ p11tool --list-tokens
Token 0:
URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Label: System Trust
Type: Trust module
Flags: uPIN uninitialized
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so
Also in knot.conf I have
policy:
- id: manual
manual: on
zone:
- domain: example.com
storage: /var/lib/knot/zones/
file: example.com.zone
dnssec-signing: on
dnssec-policy: manual
With all this in place, I launched the following from the CLI:
# keymgr example.com. generate algorithm=ECDSAP256SHA256
This does not seem to be using the PKCS #11 library, as instructed in knot.conf. I debugged the command above and noticed that, at some before the signing operation itself is addressed, the keystore_load function from the Knot code base is invoked. This function takes several arguments, the second of which is a backend identifier. According to the keystore entry in knot.conf, this should be the PKCS #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the debugger is that the backend argument is, in fact, KEYSTORE_BACKEND_PEM.
Even more intriguing (to somebody unfamiliar with the internal workings of Knot, at least) is that, before keystore_load is invoked, the check_keystore function is invoked and it evaluates the following conditional:
if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 && conf_str(&config) == NULL)
This conditional clearly succeeds - i.e. at that point the backend has been correctly identified as PKCS #11. But, like I said above, when keystore_load gets called later on, such is not the case any longer.
Any idea as to what is going on here? Why is PKCS #11 not being used? In the config string above in knot.conf I tried replacing %23 and %20 with # and the space character, respectively. It made no difference. This all is happening with Knot 2.7.3.
More info on this:
The keymgr command invokes first the init_confile function. This results in the following backtrace:
#0 conf_db_get (conf=0x6bfcc0, txn=0x7fffffffe1b0,
key0=0x47b76a "\bkeystore", key1=0x47b761 "\abackend",
id=0x6c6648 "TheBackend", id_len=11, data=0x7fffffffdf70)
at knot/conf/confdb.c:704
#1 0x0000000000410018 in conf_rawid_get_txn (conf=0x6bfcc0,
txn=0x7fffffffe1b0, key0_name=0x47b76a "\bkeystore",
key1_name=0x47b761 "\abackend", id=0x6c6648 "TheBackend", id_len=11)
at knot/conf/conf.c:78
#2 0x0000000000417f4a in check_keystore (args=0x7fffffffe090)
at knot/conf/tools.c:268
#3 0x000000000041777d in conf_exec_callbacks (args=0x7fffffffe090)
at knot/conf/tools.c:62
#4 0x000000000040ebaa in finalize_previous_section (conf=0x6bfcc0,
txn=0x7fffffffe1b0, parser=0x6ed560, ctx=0x6c6620) at knot/conf/base.c:506
#5 0x000000000040ee8d in conf_parse (conf=0x6bfcc0, txn=0x7fffffffe1b0,
input=0x4783c7 "/etc/knot/knot.conf", is_file=true)
at knot/conf/base.c:592
#6 0x000000000040f128 in conf_import (conf=0x6bfcc0,
input=0x4783c7 "/etc/knot/knot.conf", is_file=true)
at knot/conf/base.c:669
#7 0x000000000040b677 in init_confile (
confile=0x4783c7 "/etc/knot/knot.conf")
at utils/keymgr/main.c:240
#8 0x000000000040bb70 in main (argc=4, argv=0x7fffffffe488)
at utils/keymgr/main.c:349
A few lines later, keymgr invokes key_command. I get the following backtrace:
#0 conf_db_get (conf=0x6bfcc0, txn=0x6bfce0, key0=0x47c042 "\bkeystore",
key1=0x47c04c "\abackend", id=0x0, id_len=0, data=0x7fffffffdf90)
at knot/conf/confdb.c:705
#1 0x00000000004101a3 in conf_id_get_txn (conf=0x6bfcc0, txn=0x6bfce0,
key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend",
id=0x7fffffffe090) at knot/conf/conf.c:109
#2 0x0000000000419117 in conf_id_get (conf=0x6bfcc0,
key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend",
id=0x7fffffffe090) at ./knot/conf/conf.h:138
#3 0x000000000041a516 in kdnssec_ctx_init (conf=0x6bfcc0, ctx=0x7fffffffe180,
zone_name=0x6a81d0 "\aexample\003com", from_module=0x0)
at knot/dnssec/context.c:169
#4 0x000000000040aee4 in key_command (argc=3, argv=0x7fffffffe490, optind=1)
at utils/keymgr/main.c:113
#5 0x000000000040bba9 in main (argc=4, argv=0x7fffffffe488)
at utils/keymgr/main.c:359
In both cases conf_db_get is eventually invoked. With a big difference: the first time, the information concerning the keystore id is present, as the value of id - namely, "TheBackend". With this value, conf_db_get returns KNOT_EOK, and the backend id is retrieved as KEYSTORE_BACKEND_PKCS11.
The second time, however, the value of this argument is just the NULL pointer. This causes conf_db_get to return KNOT_ENOENT, and the value of the backend is therefore eventually set to the default - KEYSTORE_BACKEND_PEM.
What am I doing wrong? What is causing for the second invocation to of conf_db_get to receive an id argument set to NULL? Is this the way it is supposed to work, or is it a bug in the Knot 2.7.3 code? If it is not, what do I have to do in order to get Knot to use the PKCS #11 interface? By the way, I forgot to mention in my previous email that Knot was built with PKCS #11 support all right.
