knot-dns-users

knot-dns-users@lists.nic.cz

6 participants
703 discussions

Re: [knot-dns-users] knot group in a FreeBSD jail -- Permission Denied to Knotc and Python API

by Daniel Salzman

I don't think the Makefile is wrong. If you call knotc with an explicit control socket specification, no configuration file is loaded because it's not needed. So there is an issue with the configuration access. But I don't understand why knotd is not affected? You could also test using configuration database. Daniel On 12/21/18 2:44 PM, Rick van Rein wrote: > Hi Daniel, > >> I guess it relates to a temporary confdb, which is created for storing configuration loaded from >> a config file and removed upon. Could you try calling knotc with explicit socket parameter (knotc -s ...)? > > Yes, that solved it. > > The default socket path is @run_dir@/knot.sock, and the ports tree > configures --with-rundir=/var/run/knot but, according to > https://github.com/freebsd/freebsd-ports/blob/master/dns/knot2/Makefile#L32… > it is under defined variables. I will ask Leo if this might need > correction. > > Thanks! > -Rick >

5 let, 9 měsíců

Question on KSK rollover

by Volker Janzen

Hi all, one of my zones made a ZSK rollover yesterday. I had an some recursive resolvers validation errors at different times. This is the log output from knot of the rollover: Dec 6 17:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, ZSK rollover started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T18:16:49 Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: started, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: finished, 0.00 seconds, 1 messages, 1329 bytes Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T19:16:49 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: started, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: finished, 0.00 seconds, 1 messages, 43889 bytes Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: started, serial 1544116609 Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: finished, 0.00 seconds, 1 messages, 28054 bytes Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-07T15:16:48 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: started, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: finished, 0.00 seconds, 1 messages, 1329 bytes 10.10.10.10 is the (anonymized) IP of the distribution server, which is a Bind server. The actual authorative nameservers get the zone from Bind with IFXR or AXFR. AXFR is used for distribution to a anycast nameserver pair. When looking at the ZSK rollover timing, I notice that after two hours Knot stopped signing with the old ZSK. Does this make sense? The last event before the rollover has been this resining: Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T17:16:48 Is it possible that this is an issue with a propagation-delay that is too low (default value applies). Regards Volker

5 let, 9 měsíců

Re: [knot-dns-users] Key sizes with ECDSA

by Full Name

OK, thanks. Just making sure I was not missing something obvious. -----Original Message----- From: "libor.peltan" [libor.peltan(a)nic.cz] Date: 11/29/2018 04:33 AM To: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Key sizes with ECDSA Hi Full Name, indeed, this is not possible. The ECC and EDD algorithm families always stick to one key size for any algorithm. You can't have your KSK and ZSK with different algorithms. On the other hand, this is no big deal. Those algorithms are considered safe enough even with small keys, so you can choose just e.g. ECDSA256 and profit from having small signatures. You can also think of using single-type signing scheme. BR, Libor Dne 28.11.18 v 22:58 Full Name napsal(a): > A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct? -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

5 let, 10 měsíců

Key sizes with ECDSA

by Full Name

A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct?

5 let, 10 měsíců

Re: [knot-dns-users] Problem to import key material of softhsm into knot

by mark.karpilovskij＠nic.cz

Hi Christian, I am glad to hear that. Let us know if you have any other issues. Best regards, Mark On 2018-11-27 14:04, Christian Petrasch wrote: > Hello Mark, > > I was able to sign with Knot and SoftHSM. I switched to an actual > version of gnutls and recompiled Knot. > > Thank you very much for your good support > > 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 > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Datum: 26.11.2018 16:22 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > also, did you build Knot manually or did you use a package? What is > your current GnuTLS version? It should be at least 3.4.6 for the HSM > to work, at least according to our documentation. > > BR, > > Mark > > On 26. 11. 18 16:09, Mark Karpilovskij wrote: > > Hi Christian, > > I have verified that it is indeed necessary for Knot to use full > length key IDs with PKCS #11, so make sure you do that. Other than > that, I am quite puzzled by the "FAILED TO INITIALIZE KASP (NOT > IMPLEMENTED)" error that you are getting and so far I have been unable > to reproduce it. I will spend some more time on it. Which version of > CentOS are you using? Meanwhile, see if both setting correct policy > configuration and using full length key IDs will help you. > > Best regards, > > Mark > > On 26. 11. 18 12:31, Christian Petrasch wrote: > Hi Mark, > > thanks a lot for you help.. > > I added the keystore to my config.. but I_m getting another error > now.. > > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > > # KSK > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > # ZSK > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > keystore: a1b1 > 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 > > ### > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1b1 algorithm=RSASHA256 size=2048 ksk=no > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Failed to initialize KASP (not implemented) > > I tried with the -d parameter as well.. but i got: > > keymgr -d /var/lib/knot/keys/ example.com. import-pkcs11 a1b1 > algorithm=RSASHA256 size=2048 ksk=no created=20181126090000 > publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > I read from former knot versions about the "keymgr init" command, but > it is not implemented anymore.. > > Do you have another idea whats going wrong.. ? > > Thanks a lot for your great 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 > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Kopie: knot-dns-users(a)lists.nic.cz > Datum: 26.11.2018 11:56 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > I have checked out your Knot configuration, and I suspect that the > issue might be a missing keystore option in the policy section of your > configuration. Try specifying the ID of the PKCS11 keystore in the > policy section as follows: > > 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 > KEYSTORE: A1A1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > Let us know if this helps. > > Best regards, > > Mark > > On 26. 11. 18 9:49, Christian Petrasch wrote: > 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

5 let, 10 měsíců

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

5 let, 10 měsíců

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

5 let, 10 měsíců

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

5 let, 10 měsíců

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

5 let, 10 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

5 let, 10 měsíců

← Newer
1
...
22
23
24
25
26
27
28
...
71
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users