- knot-dns-users - lists.nic.cz

Problem to import key material of softhsm into knot

by Christian Petrasch

Hi @ all, we are testing with softhsm 2.5 and KNOT 2.7.4... I try to import the keys inside softhsm into keymgr to sign with this a example zone. The keymaterial is shown via pkcs11-tool: [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module /usr/local/lib/softhsm/libsofthsm2.so Using slot 0 with a present token (0x285d1c08) Logging in to "testKSK_1". Please enter User PIN: Private Key Object; RSA label: testKSK_1 ID: a1a1 Usage: decrypt, sign, unwrap Public Key Object; RSA 1024 bits label: testZSK_1 ID: a1b1 Usage: encrypt, verify, wrap Private Key Object; RSA label: testZSK_1 ID: a1b1 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: testKSK_1 ID: a1a1 Usage: encrypt, verify, wrap ###### The KNOT config is : [root@centos-test2 ~]# cat /etc/knot/knot.conf # See knot.conf(5) manual page for documentation. server: listen: [ 127.0.0.1@53, ::1@53 ] keystore: - id: a1a1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" - id: a1b1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" policy: - id: manual manual: on nsec3: on nsec3-iterations: 16 nsec3-opt-out: on nsec3-salt-length: 8 zone: - domain: example.com dnssec-signing: on dnssec-policy: manual zonefile-load: difference file: example.com.zone storage: /etc/knot/ log: - target: syslog any: debug ################### And if I try to import the key into keymgr i run the command: [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y Error (not exists) ### I don't know how I can fix this.. maybe anybody can help me ? The documentation of KNOT is very good.. but at this point it is a little bit insufficient. Does anybody has examples for this ? Thanks a lot in advance for the help.. 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, 5 měsíců

3
5
0 0

mod-onlinesign in master-slave environment

by Oto Stefan

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

7 let, 5 měsíců

4
4
0 0

Define SALT String for NSEC3

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, 5 měsíců

4
6
0 0

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, 6 měsíců

1
0
0 0

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, 6 měsíců

1
0
0 0

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, 6 měsíců

2
1
0 0

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, 6 měsíců

2
1
0 0

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, 6 měsíců

1
0
0 0

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, 6 měsíců

2
1
0 0

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, 6 měsíců

2
1
0 0

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, 6 měsíců

2
2
0 0

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, 6 měsíců

3
4
0 0

Issue with set_timeout in the Python library

by Rick van Rein

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

7 let, 6 měsíců

2
2
0 0

KnotDNS on FreeBSD 11.2

by Thomas Belian

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

7 let, 6 měsíců

4
5
0 0

Knot refusing to use the PKCS #11 interface

by Full Name

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, 6 měsíců

2
1
0 0

Knot refusing to use the PKCS #11 interface II

by Full Name

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.

7 let, 6 měsíců

1
0
0 0

Re: [knot-dns-users] Best practices for knot inline DNSSEC signing and zone loading

by libor.peltan

Hi Sebastian, 1) that's OK. You don't need to worry about that warning unless you edit the zonefile on the signer manually. You can also consider zonefile-less signer, either completely headless (needs AXFR after each daemon start) or with the zone stored in journal (needs some thoughts regarding journal capacity policies). Check "zonefile-load", "journal-content", "max-journal-db-size" and "max-journal-usage" options in config. 2) No, "discontinuity in changes history" is not expected. Could you please describe what did you do before such warning appeared, with longer snippets of the log? In any case, there is no need to be scared of journal getting full, once you read the documentation ;) https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour BR, Libor Dne 29.10.18 v 13:07 Sebastian Wiesinger napsal(a): > Right now I have two zone types for my knot test setup, one where knot > is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and > one where the knot is the master for the zone and zone data is coming > out of a git repository and gets signed. > > Reading older threads on this ML and browsing the configuration has > led me to the following configuration and I wanted to make sure this > is actually supported or if there is a best practice that is > different. > > > 1) Inline DNSSEC signing for slave zone. > > zone: > - domain: example.com > serial-policy: unixtime > storage: "/var/lib/knot/slave" > file: "%s.zone" > zonefile-load: difference > dnssec-signing: on > dnssec-policy: rsa-de > master: ns1_signer > notify: ns1 > acl: acl_ns1 > > policy: > - id: rsa-de > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > ksk-submission: tld_de > > > This seems to work fine, zone gets transferred from master (with low > serial), signed and with a new unixtime serial transferred out again. > I'm not sure if "zonefile-load: difference " makes any difference for > a slave zone but without it I get warnings about possibly malformed > IXFRs... > > 2) Inline DNSSEC for master zone from git: > > zone: > - domain: dnssec-test.intern > serial-policy: unixtime > storage: "/var/lib/knot/master" > file: "%s.zone" > zonefile-sync: -1 > dnssec-signing: on > dnssec-policy: rsa > acl: acl_ns1 > zonefile-load: difference-no-serial > > policy: > - id: rsa > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > > > This also works but I get warnings like this: > > [dnssec-test.intern.] journal, discontinuity in changes history > (1540307365 -> 28), dropping older changesets > > Is this expected? Also I read in older threads that this might fill > up the journal. Is that still the case? > > > Best Regards > > Sebastian >

7 let, 6 měsíců

2
7
0 0

(where) is the python control script packaged?

by Rick van Rein

Hi, You/Daniel pointed me to the Python control library, but I cannot find it in the 2.7.3 packages -- is that forgotten, or am I missing it? Thanks, -Rick

7 let, 6 měsíců

4
3
0 0

Question about obtaining information for parent zone of DNSSEC KSK rollover

by Maximilian Engelhardt

Hi, I'm having a question about DNSSEC KSK rollover and obtaining the relevant information for submission to the parent zone of the new key. I'm currently using these steps: - running "keymgr example.org list" - manually identifying the new key using the parameters "ksk=yes" and having a look at the created, publish, ready and active parameters. The new key always seems to be the one with active=0 and I also check the dates of the other parameters for plausibility. I then note the tag of the identified key. - using "keymgr example.org dnskey <keytag>" or "keymgr example.org ds <keytag>" to get the corresponding information for submission to the parent zone. Is there an easier way of achieving this, especially without the manual key identification step? Ideally would be a single command I can run and specify the zone of interest and it will output the dnskey and/or ds information of the new key. Thanks, Maxi

7 let, 6 měsíců

3
4
0 0

Best practices for knot inline DNSSEC signing and zone loading

by Sebastian Wiesinger

Right now I have two zone types for my knot test setup, one where knot is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and one where the knot is the master for the zone and zone data is coming out of a git repository and gets signed. Reading older threads on this ML and browsing the configuration has led me to the following configuration and I wanted to make sure this is actually supported or if there is a best practice that is different. 1) Inline DNSSEC signing for slave zone. zone: - domain: example.com serial-policy: unixtime storage: "/var/lib/knot/slave" file: "%s.zone" zonefile-load: difference dnssec-signing: on dnssec-policy: rsa-de master: ns1_signer notify: ns1 acl: acl_ns1 policy: - id: rsa-de algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 ksk-submission: tld_de This seems to work fine, zone gets transferred from master (with low serial), signed and with a new unixtime serial transferred out again. I'm not sure if "zonefile-load: difference " makes any difference for a slave zone but without it I get warnings about possibly malformed IXFRs... 2) Inline DNSSEC for master zone from git: zone: - domain: dnssec-test.intern serial-policy: unixtime storage: "/var/lib/knot/master" file: "%s.zone" zonefile-sync: -1 dnssec-signing: on dnssec-policy: rsa acl: acl_ns1 zonefile-load: difference-no-serial policy: - id: rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 This also works but I get warnings like this: [dnssec-test.intern.] journal, discontinuity in changes history (1540307365 -> 28), dropping older changesets Is this expected? Also I read in older threads that this might fill up the journal. Is that still the case? Best Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

7 let, 6 měsíců

1
0
0 0

KSK Algorithm Rollover Question

by Sebastian Wiesinger

Hi, I'm currently testing a KSK algorithm rollover with my zone. I changed the signature scheme from RSA to ECDSA. Knot started adding new RRSIGs and new keys and now waits for the new DS to be published at the parent zone. One thing strikes me as odd though: http://dnsviz.net/d/6v6.de/W9AmtA/dnssec/ Looking at the graph the new KSK (54879) is not signing anything right now. Shouldn't it sign the DNSKEY records of the ZSKs so that the chain stays intact when the DS record changed at the parent zone? Kind Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

7 let, 6 měsíců

2
3
0 0

geoip secondary DNS with DNSSEC

by Mark Karpilovskij

Dear Volker, it is true that the method for creating a CSK is not explicitly mentioned in the documentation, we shall fix that. You can create a CSK using our keymgr utility by specifying both 'ksk=yes' and 'zsk=yes' parameters of the 'generate' command. E.g. $ keymgr -c /path/to/knot.conf example.com. generate ksk=yes zsk=yes remove=+1y creates an immediately active CSK with a 1 year lifetime. You can check out all possible timestamp settings in the docs <https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#generate-arguments>. Please note that the geoip module is currently not very well integrated into Knot's DNSSEC workflow. For instance, the only way to refresh RRSIGs precomputed by the module is to reload it (knotc zone-reload). One approach for now could be to create a CSK with a strong algorithm (e.g. the default ECDSAP256SHA256) and a long lifetime, e.g. 1 year, and to set the same lifetime for the RRSIGs. The policy configuration could look like this: policy: - id: manual manual: on algorithm: ECDSAP256SHA256 rrsig-lifetime: 365d zone: - domain: example.com. dnssec-signing: on dnssec-policy: manual Then you would only have to perform a manual key rollover while reloading the zone so that the module computes the new signatures. We will update the documentation to include this information. In addition, you can sync the key from one server to others by copying the KASP lmdb database e.g. using the mdb_dump and mdb_load tools. If you have any further questions, let us know! Best regards, Mark On 19.10.2018 10:13, Volker Janzen wrote: > Hi all, > > I'd like to test the geoip module with a signed zone. The > documentation recommends using manual mode for signing. As far as I > know, the geoip information is not transferred via AXFR. That would > mean, that I've to transfer the signing key to the secondary servers > along with the geoip (and zone) configuration. To reduce caveats with > ZSKs, I'd like to use CSK. As a result I just need to sync one key per > zone to secondary servers. I checked the Knot documentation on how to > use a CSK for a zone, but the CSK is only mentioned twice in the > documentation with no example on how to actually use it. Can someone > point me to a configuration example for setting up a CSK? > > > Kind regards, > Volker

7 let, 6 měsíců

3
2
0 0

geoip secondary DNS with DNSSEC

by Volker Janzen

Hi all, I'd like to test the geoip module with a signed zone. The documentation recommends using manual mode for signing. As far as I know, the geoip information is not transferred via AXFR. That would mean, that I've to transfer the signing key to the secondary servers along with the geoip (and zone) configuration. To reduce caveats with ZSKs, I'd like to use CSK. As a result I just need to sync one key per zone to secondary servers. I checked the Knot documentation on how to use a CSK for a zone, but the CSK is only mentioned twice in the documentation with no example on how to actually use it. Can someone point me to a configuration example for setting up a CSK? Kind regards, Volker

7 let, 7 měsíců

1
0
0 0

DDNS with DNSSEC, is this expected behavior or a bug

by Maximilian Engelhardt

Hi, I'm using a zone with DNSSEC signing enabled that is updated using DDNS. The update procedure is very simple and looks like this: ==> test_ddns.sh <== #! /bin/sh ZONE="example.org." cat << EOF | nsupdate server localhost zone ${ZONE} update delete ${ZONE} A update add ${ZONE} 60 IN A 127.0.0.1 send quit EOF And the corresponding output in the knot log is this: Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, successfully signed Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 2018-10-24T22:58:46 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, update finished, serial 1539809849 -> 1539809926, 0.02 seconds Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] zone file updated, serial 1539809849 -> 1539809926 I'm wondering if the "next signing at 1970-01-01T01:00:00" output is correct as this seems suspicious to me. Running "knotc zone-status example.org" gives the following output: [example.org.] role: master | serial: 1539809926 | transaction: none | freeze: no | refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: +29D23h53m28s | parent DS query: not scheduled Is this expected behavior or a bug in knot? I can give more information or create a proper bugreport if needed. I also recently had the problem that knot didn't respond to ddns updates until it was restarted. I don't know if this is related or a different problem, however I currently don't have more information about this. Thanks, Maxi

7 let, 7 měsíců

3
6
0 0

Re: [knot-dns-users] Correct way to turn off dnssec-signing

by libor.peltan

Hi Oliver, > Ah, the mistake was that changing the dnssec-policy *and* dnssec-signing > in one go does not insert the delete-CDS/CDNSKEY records since knot > immediately stops all dnssec related actions. Thanks! You at least want to have the special CDNSKEY record -signed- anyway ;) > Am I right that, unlike the signing process (KSK submission attempts), > there is no built-in functionality in knot, that takes care about the > right time to remove the key material from the zone? Yes. We didn't care much for this usecase, sorry. I guess it's not so difficult to achieve this manually. We need to have automated just those processes, that start automatically (e.g. KSK rollover). > So, basically I should wait > [propagation-delay] + [max TTL seen in zone/knot_soa_minimum] > seconds until I manually remove the material. No, you first need to check when your parent zone removed the DS record. Afterwards wait for its TTL + propagation_delay. BR, Libor

7 let, 7 měsíců

1
0
0 0

Correct way to turn off dnssec-signing

by Oliver Peter

Hi, I am experimenting with latest knot and its wonderful dnssec autosigner functionality. It works pretty nice but I am a bit lost in the unsign process, my zone looks basically like this: zone: - domain: "domain.tld." storage: "/home/oliver/knot/zones" file: "sign.local" zonefile-load: "difference" dnssec-signing: "on" dnssec-policy: "dnssec-policy" serial-policy: "unixtime" policy: - id: "dnssec-policy" zsk-lifetime: "2592000" ksk-lifetime: "31536000" propagation-delay: "0" nsec3: "off" ksk-submission: "local" cds-cdnskey-publish: "always" What is the safe way to turn off dnssec once the DS has been seen by the resolver/knot? I tried to do dnssec-signing: "off" but that did not change anything; I also created a second policy called "unsign-policy" where I switched cds-cdnskey-publish to "cds-cdnskey-publish". I expected the CDNSKEY/CDS immediately turn into "0 3 0 AA==" and so on since my propagation-delay is 0 (for faster test results...) Thanks for any hints! -- Oliver PETER oliver(a)gfuzz.de 0x456D688F

7 let, 7 měsíců

2
2
0 0

Forcing AXFR for a master

by Aleš Rygl

Hello, Is there a way how to force AXFR for certain masters in the configuration? I have a situation with one of master serveres where IXFR fails - received response is "Format error". Knot does not fall back to AFXR in this case and the zone is going to expire. Using zone-retransfer can fix it. Transferring this zone using kdig is also ok. I can see this with Knot 2.7.2 and Knot 2.7.3 as well. BR Ales

7 let, 7 měsíců

2
1
0 0

Knot DNS 2.7.3 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.3! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.3 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.3.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 7 měsíců

1
0
0 0

DNS64 module only for specific subnets

by Antti Ristimäki

Hi, Is it possible to restrict DNS64 module only for specific IPv6 subnets in Knot Resolver? The reasoning behind this is that this would make it possible to run DNS64 resolver on the same instance with the "normal" resolver in a way that fake AAAA records are returned only to IPv6-only clients whereas normal dual-stack or IPv4-only clients are served with unmodified A records. I found an issue [1] that seems to be related to the very same thing, but I was left a little bit uncertain what the current situation is and how this should/could be configured. [1] https://gitlab.labs.nic.cz/knot/knot-resolver/issues/368 Cheers, Antti

7 let, 7 měsíců

2
1
0 0

signing parameters for number of cores

by Christian Petrasch

Hi folks, sorry for the spam.. now with the right subject.. Maybe anybody can help me.. Is there any possibility to sign with more than one core ? The "background-workers" parameter didn't help... KnotDNS is using only one core for signing.. thanks a lot best regards -- Christian Petrasch Senior System Engineer DNS/Infrastructure IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: petrasch(a)denic.de Fon: +49 69 27235-429 Fax: +49 69 27235-239 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, 8 měsíců

3
4
0 0

Massive iteration without apparent reason

by Rick van Rein

Hi, Every time we switch DNSSEC on for a single zone, it iterates over all zones (and logs something trivial about each). This appears to us as not very efficient. Is there a reason for it? Following the documentation we had not expected this behaviour, https://www.knot-dns.cz/docs/2.6/html/configuration.html#zone-signing We are running Knot DNS with ~3500 zones, so you can imagine this has a bit of an impact. Thanks, -Rick

7 let, 8 měsíců

3
5
0 0

Bug report: knotd crashes due to PCKS #11 race condition

by Rick van Rein

Hi, Roland and I ran into a crashing condition for knotd 2.6.[689], presumably caused by a race condition in the threaded use of PKCS #11 sessions. We use a commercial, replicated, networked HSM and not SoftHSM2. WORKAROUND: We do have a work-around with "conf-set server.background-workers 1" so this is not a blocking condition for us, but handling our ~1700 zones concurrency would be add back later. PROBLEM DESCRIPTION: Without this work-around, we see crashes quite reliably, on a load that does a number of zone-set/-unset commands, fired by sequentialised knotc processes to a knotd that continues to fire zone signing concurrently. The commands are generated with the knot-aware option -k from ldns-zonediff, https://github.com/SURFnet/ldns-zonediff ANALYSIS: Our HSM reports errors that look like a session handle is reused and then repeatedly logged into, but not always, so it looks like a race condition on a session variable, 27.08.2018 11:48:59 | [00006AE9:00006AEE] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:48:59 | [00006AE9:00006AEE] C_GetAttributeValue | E: Error CKR_USER_NOT_LOGGED_IN occurred. 27.08.2018 11:48:59 | [00006AE9:00006AED] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:48:59 | [00006AE9:00006AED] C_GetAttributeValue | E: Error CKR_USER_NOT_LOGGED_IN occurred. 27.08.2018 11:49:01 | [00006AE9:00006AED] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:49:01 | [00006AE9:00006AED] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:49:01 | [00006AE9:00006AED] C_GetAttributeValue | E: Error CKR_USER_NOT_LOGGED_IN occurred. 27.08.2018 11:49:02 | [00006AE9:00006AEE] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:49:03 | [00006AE9:00006AEE] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. 27.08.2018 11:55:50 | [0000744C:0000744E] C_Login | E: Error CKR_USER_ALREADY_LOGGED_IN occurred. These errors stopped being reported with the work-around configured. Until that time, we have crashes, of which the following dumps one: Thread 4 "knotd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffcd1bd700 (LWP 27375)] 0x00007ffff6967428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6967428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff696902a in __GI_abort () at abort.c:89 #2 0x00007ffff69a97ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff6ac2ed8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff69b237a in malloc_printerr (ar_ptr=, ptr=, str=0x7ffff6ac2fe8 "double free or corruption (out)", action=3) at malloc.c:5006 #4 _int_free (av=, p=, have_lock=0) at malloc.c:3867 #5 0x00007ffff69b653c in __GI___libc_free (mem=) at malloc.c:2968 #6 0x0000555555597ed3 in ?? () #7 0x00005555555987c2 in ?? () #8 0x000055555559ba01 in ?? () #9 0x00007ffff7120338 in ?? () from /usr/lib/x86_64-linux-gnu/liburcu.so.4 #10 0x00007ffff6d036ba in start_thread (arg=0x7fffcd1bd700) at pthread_create.c:333 #11 0x00007ffff6a3941d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 DEBUGGING HINTS: Our suspicion is that you may not have set the mutex callbacks when invoking C_Initialize() on PKCS #11, possibly due to the intermediate layers of abstraction hiding this from view. This happens more often. Then again, the double free might pose another hint. This is on our soon-to-go-live platform, so I'm afraid it'll be very difficult to do much more testing, I hope this suffices for your debugging! I hope this helps Knot DNS to move forward! -Rick

7 let, 8 měsíců

3
2
0 0

Knot DNS works with Utimaco HSM

by Rick van Rein

Hi, It may be useful to know that Knot DNS also works with the utimaco.com HSM of type CryptoServer. We have tested that. -Rick

7 let, 8 měsíců

2
1
0 0

Journal error with big zone

by Christian Petrasch

Hi folks, maybe anybody can help me.. Is there any possibility to sign with more than one core ? The "background-workers" parameter didn't help... KnotDNS is using only one core for signing.. thanks a lot best regards -- Christian Petrasch Senior System Engineer DNS/Infrastructure 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, 8 měsíců

1
0
0 0

Master - Slave configuration issues

by Innus Ali

Hi admin, I found your knot-dns is really amazing software but I have a issue during master & slaves configuration . While I configuring any domain zone in master. The zone details not propagate to slave until and unless I manually specifies the domain name in slave zone. Is there any way to configure this . I hope your reply soon after you receive the email. I'm doing it for my personal use and demo. Regard Innus Ali >From : India

7 let, 8 měsíců

2
1
0 0

KNOT-DNS issue during master / slaves

by Innus Ali

Hi admin, I found your knot-dns is really amazing software but I have a issue during master & slaves configuration . While I configuring any domain zone in master. The zone details not propagate to slave until and unless I manually specifies the domain name in slave zone. Is there any way to configure this . I hope your reply soon after you receive the email. I'm doing it for my personal use and demo. Regard Innus Ali >From : India

7 let, 8 měsíců

1
0
0 0

Force notify

by Jim Popovitch

Hello, How do I force a notify for a specific domain? (v2.4.0 Debian) tia, -Jim P.

7 let, 8 měsíců

3
3
0 0

Knot DNS 2.7.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.2! This version brings several bugfixes and minor improvements. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.2 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 8 měsíců

1
0
0 0

refresh, failed (no usable master) - possible TCP issue

by Aleš Rygl

Hello, I have an issue with a zone where KNOT is slave server. I am not able to transfer a zone: refresh, failed (no usable master). BIND is able to transfer this zone and with host command AXFR works as well. There are more domains on this master and the others are working. The thing is that I can see in Wireshark that the AXFR is started, zone transfer starts and for some reason KNOT after the 1st ACK to AXFR response terminates the TCP connection with RST resulting in AXFR fail. AXFR response is spread over several TCP segments. I can provide traces privately. KNOT 2.6.7-1+0~20180710153240.24+stretch~1.gbpfa6f52 Thanks for help. BR Ales Rygl

7 let, 8 měsíců

2
6
0 0

"cds-cdnskey-publish: always" ignored

by Daniel Stirnimann

Dear all, I use knot 2.7.1 with automatic DNSSEC signing and key management. For some zones I have used "cds-cdnskey-publish: none". As .CH/.LI is about to support CDS/CDNSKEY (rfc8078, rfc7344) I thought I should enable to publish the CDS/CDNSKEY RR for all my zones. However, the zones which are already secure (trust anchor in parent zone) do not publish the CDS/CDNSKEY record when the setting is changes to "cds-cdnskey-publish: always". I have not been able to reproduce this error on new zones or new zones signed and secured with a trust anchor in the parent zone for which I then change the cds-cdnskey-publish setting from "none" to "always". This indicates that there seems to be some state error for my existing zones only. I tried but w/o success: knotc zone-sign <zone> knotc -f zone-purge +journal <zone> ; publish a inactive KSK keymgr <zone> generate ... ; knotc zone-sign <zone> Completely removing the zone (and all keys) and restarting fixes the problem obviously. However, I cannot do this for all my zones as I would have to remove the DS record in the parent zone prior to this... Any idea? Daniel

7 let, 8 měsíců

3
3
0 0

KNOT Debian repository outdated

by Aleš Rygl

Hi all, I would like to kindly ask you to check the Debian repository state? It looks like it is a bit outdated... The latest version available is 2.6.7-1+0~20180710153240.24+stretch~1.gbpfa6f52 while 2.7.0 has been already released. Thanks BR Ales Rygl

7 let, 8 měsíců

4
5
0 0

Knot DNS 2.7.1 and Knot DNS 2.6.9 releases

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.1 and Knot DNS 2.6.9! The former release mostly fixes some TTL issues important for the upcoming major version of Knot Resolver. The latter one just backports older fixes. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.7.1/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.6.9/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.1.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.6.9.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.6.9.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html https://www.knot-dns.cz/docs/2.6/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 9 měsíců

1
0
0 0

Feature Request: Improved rigour for knotc

by Rick van Rein

Hey, We're scripting around Knot, and for that we pipe sequences of commands to knotc. We're running into a few wishes for improved rigour that look like they are generic: 1. WAITING FOR TRANSACTION LOCKS This would make our scripts more reliably, especially when we need to do manual operations on the command line as well. There should be no hurry for detecting lock freeing operations immediately, so retries with exponential backoff would be quite alright for us. Deadlocks are an issue when these are nested, so this would at best be an option to knotc, but many applications call for a single level and these could benefit from the added sureness of holding the lock. 2. FAILING ON PARTIAL OPERATIONS When we script a *-begin, act1, act2, *-commit, and pipe it into knotc it is not possible to see intermediate results. This could be solved when any failures (including for non-locking *-begin) would *-abort and return a suitable exit code. Only success in *-commit would exit(0) and that would allow us to detect overall success. We've considered making a wrapper around knotc, but that might actually reduce its quality and stability, so instead we now propose these features. Just let me know if you'd like to see the above as a patch (and a repo to use for it). Cheers, -Rick

7 let, 9 měsíců

1
0
0 0

Segfaults during zone edit/commit

by Rick van Rein

Hello, I am seeing segfault crashes from knot + libknot7 version 2.6.8-1~ubuntu for amd64, during a zone commit cycle. The transaction is empty by the way, but in general we use a utility to compare Ist to Soll. This came up while editing a zone that hasn't been configured yet, so we are obviously doing something strange. (The reason is I'm trying to switch DNSSEC on/off in a manner orthogonal to the zone data transport, which is quite clearly not what Knot DNS was designed for. I will post a feature request that could really help with orthogonality.) I'll attach two flows, occurring virtually at the same time on our two machines while doing the same thing locally; so the bug looks reproducable. If you need more information, I'll try to see what I can do. Cheers, -Rick Jul 24 14:22:59 menezes knotd[17733]: info: [example.com.] control, received command 'zone-commit' Jul 24 14:22:59 menezes kernel: [1800163.196199] knotd[17733]: segfault at 0 ip 00007f375a659410 sp 00007ffde37d46d8 error 4 in libknot.so.7.0.0[7f375a64b000+2d000] Jul 24 14:22:59 menezes systemd[1]: knot.service: Main process exited, code=killed, status=11/SEGV Jul 24 14:22:59 menezes systemd[1]: knot.service: Unit entered failed state. Jul 24 14:22:59 menezes systemd[1]: knot.service: Failed with result 'signal'. Jul 24 14:22:59 vanstone knotd[6473]: info: [example.com.] control, received command 'zone-commit' Jul 24 14:22:59 vanstone kernel: [3451862.795573] knotd[6473]: segfault at 0 ip 00007ffb6e817410 sp 00007ffd2b6e1d58 error 4 in libknot.so.7.0.0[7ffb6e809000+2d000] Jul 24 14:22:59 vanstone systemd[1]: knot.service: Main process exited, code=killed, status=11/SEGV Jul 24 14:22:59 vanstone systemd[1]: knot.service: Unit entered failed state. Jul 24 14:22:59 vanstone systemd[1]: knot.service: Failed with result 'signal'.

7 let, 9 měsíců

2
3
0 0

After update to 2.7.0: failed to load persistent timers (invalid parameter)

by Bjoern Franke

Hi, after updating from 2.6.8 to 2.7.0 none of my zones gets loaded: failed to load persistent timers (invalid parameter) error: [nord-west.org.] zone cannot be created How can I fix this? Kind Regards Bjoern

7 let, 9 měsíců

3
5
0 0

Knot DNS 2.7.0 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.0! Based on the security audit funded by Mozilla Open Source Support, we improved and fixed some security-related parts of the libraries and the server. Furthermore, we spent lots of time on code cleanup, optimizations, and new features. As this version is full of improvements, visit the following links to get more details. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.7.0/NEWS Security audit: https://wiki.mozilla.org/MOSS/Secure_Open_Source/Completed#Knot_DNS Benchmark: https://www.knot-dns.cz/benchmark/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html If you like or depend on this project, please consider one of our support programmes at https://www.knot-dns.cz/support. Regards, Daniel

7 let, 9 měsíců

1
0
0 0

error: zone event 'journal flush' failed (not enough space provided)

by Aleš Rygl

Hi all, I would kindly ask for help. After a tiny zone record modification I am receiving following error(s) when trying to access zone data (zone-read): Aug 02 15:09:34 idunn knotd[779]: warning: [xxxxxxxx.] failed to update zone file (not enough space provided) Aug 02 15:09:34 idunn knotd[779]: error: [xxxxxxx.] zone event 'journal flush' failed (not enough space provided) There is a plenty of space on the server, I suppose it is related to journal and db. Many thanks in advance, it is quite important zone. KNOT 2.6.7-1+0~20180710153240.24+stretch~1.gbpfa6f52 BR Ales Rygl

7 let, 9 měsíců

2
3
0 0

Does all RR in RRSet need to have same TTL

by Zdenek Novy

Hi, I would like to ask about the implementation of the Resource records in RRSet in KnotDNS. I have the domain with the three TXT record with same class IN for the same label ('@') and with the different TTLs. In nsd and bind DNS servers seems everything fine, but in KnotDNS I got the warning and error: knotd[551]: warning: [xxxxxxx.xxx.] zone loader, RRSet TTLs mismatched, node 'xxxxxxx.xxx.' (record type TXT) knotd[551]: error: [xxxxxxx.xxx.] zone loader, failed to load zone, file '/etc/knot/files/master.gen/xxxxxxx.xxx' (TTL mismatch) knotd[551]: error: [xxxxxxx.xxx.] failed to parse zonefile (failed) knotd[551]: error: [xxxxxxx.xxx.] zone event 'load' failed (failed) Is it a correct behavior and other DNS servers don't check it or is it a bug in KnotDNS? Thank you for reply. Cheers, -- Zdenek

7 let, 9 měsíců

3
2
0 0

Feature Request: Opportunistic dnssec-signing

by Rick van Rein

Hi, I am trying to make DNSSEC signing orthogonal to zone data transport in the DNSSEC signer solution for SURFnet. This translates directly to an intuitive user interface, where domain owners can toggle DNSSEC on and off with a flick of a switch. Interestingly, keymgr can work orthogonally to zone data; keys can be added and removed, regardless of whether a zone has been setup in Knot DNS. Where the orthogonality is broken, is that I need to explicitly set dnssec-signing: to on or off. This means that I need to create a zone, just to be able to tell Knot DNS about the keys. Of course there are complaints when configuring Knot DNS without a zone data file present. The most elegant approach would be to setup dnssec-signing as opportunistic option, meaning "precisely then when there are keys available in the keymgr for this zone". Such a setting could then end up in the policy for any such zone, and that can be done when the zone data is first sent, without regards of what we try to make an orthogonal dimension. I have no idea if this is difficult to make. I do think it may be a use case that wasn't considered before, which is why I'm posting it here. If this is easy and doable, please let me know; otherwise I will have to work around Knot DNS (ignoring errors, overruling previously set content just to be sure it is set, and so on) to achieve the desired orthogonality. Cheers, -Rick

7 let, 9 měsíců

2
1
0 0

Knot DNS 2.6.8 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.6.8! The most important bugfix relates to creeping memory consumption upon server reload. New 'import-pkcs11' command in keymgr allows the server to reuse DNSKEYs already stored in a PKCS #11 storage. And some corner case crashes and other smaller issues were resolved. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.6.8/NEWS Documentation: https://www.knot-dns.cz/docs/2.6/html/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.6.8.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.6.8.tar.xz.asc Regards, Daniel

7 let, 10 měsíců

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users