Hi,
i work on a python library based on python/libknot/control.py.
I'm at the point to add/remove resource record to a configured zone.
I have tried a lot, but got no positive result:
"invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1')"
The full test script debug output:
DEBUG: _openSocket
DEBUG: _zone-begin
DEBUG: _cmd: {'cmd': 'zone-begin'}
DEBUG: _cmd: {'cmd': 'zone-set', 'zone': 'domain.tld.', 'owner': 'www.domain.tld.', 'rtype': 'A', 'data': '127.0.0.1'}
DEBUG: _zone-abort
DEBUG: _cmd: {'cmd': 'zone-abort'}
invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1')
DEBUG: _zone-begin
DEBUG: _cmd: {'cmd': 'zone-begin'}
DEBUG: _cmd: {'cmd': 'zone-get', 'zone': 'domain.tld.', 'owner': 'ns1.domain.tld.'}
DEBUG: _zone-commit
DEBUG: _cmd: {'cmd': 'zone-commit'}
resp: {
"domain.tld.": {
"ns1.domain.tld.": {
"A": {
"ttl": "86400",
"data": [
"192.168.120.211"
]
}
}
}
}
DEBUG: _closeSocket
The "_cmd" call uses libknot.control.send_block[1] internally, the following
"{…}" held the function parameters.
[1] https://gitlab.labs.nic.cz/knot/knot-dns/blob/master/python/libknot/control…
It needs some time to discover "owner" as the query filter for "zone-get", which
wasn't that obvious.
Now I'm wondering how set the parameter, for adding a resource record to a
zone.
- 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
By default, Knot will use the local file system as its key storage. I believe that, when using the SoftHSM backend, the same is true. For most practical purposes, the implication is that the key storage has an unlimited capacity for keys. Now when using an actual HSM, that is not true - most HSMs will, in general, have a relatively modest keys storage capacity, especially when compared to that of a local filesystem.
Does Knot have with capabilities to deal with such situations? If I need to have 150 keys in my key storage, but my key storage can't hold more than 100, how does Knot deal with this? Conceptually, one only has to wrap the keys in the HSM appropriately and dump then to disk - where they will remain inaccessible to anybody but the HSM. After this, one can generate (or unwrap) more keys, and use them as necessary. Is this something that Knot can already do?
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.