Hello,
first of all I would like to express many thanks to the CZ.NIC DNS team
for an amazing piece of software which the KnotDNS in my view surely is.
Well, to my question. I run two instances of knot 2.6.9 in the
master-slave configuration which serve a couple of zones. The zones are
DNSSEC signed at master with an automated key management. This works
excellent even with the KSK rotation (I am under .cz TLD). However, I
also have a subdomain (i.e., 3rd order domain) with synthesized records.
The only way to allow DNSSEC for it I was able to find is:
- using mod-onlinesign on both the master and slave,
- generating a key externally (with bind-utils) and importing it into
KASP on both servers,
- configuring manual key policy,
- adding the appropriate DS record into the parent zone.
This seems to work fine, all the validation tests pass.
The question is: Is there a better way to achieve the goal (especially
with new features like automated key rotation in online signing of the
2.7 version in mind) or what is the recommended practice in a similar
situation?
Thanks in advance for any suggestion or advice,
Have a nice day,
Oto
Hi,
is there any knot-dns configuration parameter to define the SALT string
for NSEC3 ?
I have :
nsec3: BOOL
nsec3-iterations: INT
nsec3-opt-out: BOOL
nsec3-salt-length: INT
but nothing to configure the string..
Does anybody has an idea ?
Any help would be really appreciated..
thanks a lot
best regards
--
Christian Petrasch
Product Owner
Zone Creation & Signing
IT-Services
DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY
E-Mail: petrasch(a)denic.de
http://www.denic.de
PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841
549B E0AE
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg
Schweiger
Vorsitzender des Aufsichtsrats: Thomas Keller
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
Frankfurt am Main
Feedback much appreciated. Thanks.
-----Original Message-----
From: "" [daniel.salzman(a)nic.cz]
Date: 11/08/2018 03:43 AM
To: "Full Name" <nuncestbibendum(a)excite.com>
CC: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] Dealing with limited capacity key storage
On 2018-11-08 01:04, Full Name wrote:
> 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.
>
Yes, that is correct.
> 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?
The only solution with Knot DNS is using shared keys
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#ksk-shared.
Also Single-Type Signing Scheme could help to reduce the number of keys
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#single-type-signing.
Daniel
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
