knot-dns-users

knot-dns-users@lists.nic.cz

1 participants
756 discussions

by Christian Petrasch

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

7 let, 4 měsíce

Knot DNS 2.7.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.4! This version mainly fixes DNSSEC-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.4 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 5 měsíců

Re: [knot-dns-users] Dealing with limited capacity key storage

by Full Name

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

7 let, 5 měsíců

python-libknot: How to do "zone-set" command to add resource records

by Frank Matthieß

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

7 let, 5 měsíců

Dealing with limited capacity key storage

by Full Name

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?

7 let, 5 měsíců

Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface

by Full Name

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.

7 let, 5 měsíců

Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface

by Full Name

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.

7 let, 5 měsíců

Python libknot: Failed to load libknot.so, patch attached

by Frank Matthieß

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

7 let, 5 měsíců

Python library behaviours

by Rick van Rein

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

7 let, 5 měsíců

zone delagation format?

by Milan Sýkora

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.

7 let, 5 měsíců

← Newer
1
...
28
29
30
31
32
33
34
...
76
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users