knot-dns-users

knot-dns-users@lists.nic.cz

8 participants
784 discussions

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.8! This version primarily fixes one bug in KSK rollover when the old key is removed early if automatic KSK submission is enabled and DNSKEY TTL is lower than the corresponding DS TTL in the parent zone. Affected versions are 3.0.6 and 3.0.7. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.8/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

5 let, 3 měsíce

trying to setup knot dns for my personal domain - server doesn't get accepted by my hoster

by J. Echter

Hi, i'm trying to setup a knot dns server for my personal domain. The servers are running and synchronizing between master and slave, but i cannot figure out why they do not get accepted by my domain hoster. I do get a 'Parameter value range error' response from them, so i figure it may be my configuration which is not right. I'm no pro in this stuff but i'm curious how it works, so if you don't mind i'll post it here and maybe someone has a thought what could be going on. Or maybe has some additional test i can run. I also checked them with nast from denic: https://www.denic.de/en/service/tools/nast/ (Nameserver Predelegation Check) Which doesn't complain, if i enter ns1.mydomain.de/ns2.domain.de and ipv4 / ipv6 ip's and click 'execute check'. I also checked with dig for response: dig @ns1.mydomain.de mydomain.de soa ;; BADCOOKIE, retrying. ; <<>> DiG 9.16.18 <<>> @ns1.mydomain.de mydomain.de soa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1174 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 270b9518832d67270100000060d6d65c1844d3479cc64453 (good) ;; QUESTION SECTION: ;mydomain.de. IN SOA ;; ANSWER SECTION: mydomain.de. 86400 IN SOA ns1.mydomain.de. dnsadmin.mydomain.de. 2021062526 14400 1800 2419200 900 ;; Query time: 63 msec ;; SERVER: aa.bb.cc.dd.ee#53(aa.bb.cc.dd) ;; WHEN: Sa Jun 26 09:25:16 CEST 2021 ;; MSG SIZE rcvd: 119 and here is my config: server: identity: ns1.mydomain.de nsid: ns1.mydomain.de rundir: "/run/knot" user: knot:knot listen: [ aa.bb.cc.dd.ee@53, aa:bb:cc:dd@53 ] mod-rrl: - id: default rate-limit: 200 slip: 2 log: - target: syslog any: info policy: - id: rsa2k algorithm: RSASHA256 ksk-size: 4096 zsk-size: 2048 nsec3: on - id: ececc algorithm: ecdsap384sha384 nsec3: on template: - id: default storage: "/var/lib/knot" dnssec-signing: on dnssec-policy: rsa2k global-module: mod-cookies global-module: mod-rrl/default database: storage: "/var/lib/knot" key: - id: dnsmaster algorithm: hmac-sha512 secret: secret - id: dnsslave algorithm: hmac-sha512 secret: secret remote: - id: secondary address: ee.ff.gg.hh@53 key: dnsslave acl: - id: acl_secondary address: ee.ff.gg.hh key: dnsmaster action: transfer zone: - domain: mydomain.de file: "/etc/knot/zones/mydomain.de.zone" notify: secondary acl: acl_secondary zonefile-load: difference and my zone file (without the keys and stuff added from knotd): ;; Zone dump (Knot DNS 3.0.7) mydomain.de. 86400 SOA ns1.mydomain.de. dnsadmin.mydomain.de. 2021062526 14400 1800 2419200 900 mydomain.de. 86400 AAAA aa:bb:cc:dd mydomain.de. 86400 A aa.bb.cc.dd mydomain.de. 86400 TXT "v=spf1 ip4:aa.bb.cc.dd -all" mydomain.de. 86400 NS ns1.mydomain.de. mydomain.de. 86400 NS ns2.mydomain.de. mydomain.de. 86400 MX 10 mail.mydomain.de. _dmarc.mydomain.de. 86400 TXT "v=DMARC1; p=reject; rua=mailto:postmaster@mydomain.de; pct=100; fo=0:d:s; aspf=r; adkim=r;" _token._dnswl.mydomain.de. 86400 TXT "somestuff" 2020._domainkey.mydomain.de. 86400 TXT "v=DKIM1;k=rsa;p=alongline" _mta-sts.mydomain.de. 86400 TXT "v=STSv1; id=20210519103000Z;" _smtp._tls.mydomain.de. 86400 TXT "v=TLSRPTv1; rua=mailto:postmaster@mydomain.de" autoconfig.mydomain.de. 86400 AAAA aa:bb:cc:dd autoconfig.mydomain.de. 86400 A aa.bb.cc.dd test.mydomain.de. 86400 AAAA ee:ff:gg:hh test.mydomain.de. 86400 A ee.ff.gg.hh imap.mydomain.de. 86400 AAAA aa:bb:cc:dd imap.mydomain.de. 86400 A aa.bb.cc.dd mail.mydomain.de. 86400 AAAA aa:bb:cc:dd mail.mydomain.de. 86400 A aa.bb.cc.dd mta-sts.mydomain.de. 86400 AAAA aa:bb:cc:dd mta-sts.mydomain.de. 86400 A aa.bb.cc.dd ns1.mydomain.de. 86400 AAAA aa:bb:cc:dd ns1.mydomain.de. 86400 A aa.bb.cc.dd ns2.mydomain.de. 86400 A ee.ff.gg.hh ns2.mydomain.de. 86400 AAAA ee:ff:gg:hh smtp.mydomain.de. 86400 AAAA aa:bb:cc:dd smtp.mydomain.de. 86400 A aa.bb.cc.dd wiki.mydomain.de. 86400 AAAA aa:bb:cc:dd wiki.mydomain.de. 86400 A aa.bb.cc.dd www.mydomain.de. 86400 AAAA aa:bb:cc:dd www.mydomain.de. 86400 A aa.bb.cc.dd thanks for listening! juergen

5 let, 4 měsíce

Config Problems

by Günther J. Niederwimmer

Hello List, I like to change to knot but ..........;-) Can any help Please? 1. My config is working with the Master Domains but I have a problem to configure to allow update "AXFER" TO my SLAVE servers ? What is the way to allow this. 2. I have a internal zone "examle.com.lan" this is loading, but I have to configure a PTR Zone this is not working, have any a example to configure this out. also a in-addr-arpa zonen? 3. the same Problem I have with ip6-arpa, what is the way to configure my hurican Net reverse zone with my old server bind this is all working, but I like to change :-) for all Help / answers all thanks -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

5 let, 4 měsíce

Knot DNS 3.0.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.7! This version fixes various bugs and introduces a few requested features. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.7/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

5 let, 4 měsíce

Knot as Multi-Signer DNSSEC server with automatic key management

by Kadziolka, Marian

Hi, are there any plans to implement some multi-singner/multi-master dnsssec capabilities/solution? As far as i understand, there is no possibility to run two or more Knot servers with automatic key management [1] where all the servers use the same dnssec keys. Manual key management [2] can be used, but all the dnssec key automation of Knot will be lost. KASP DB sharing [3] or active and backup signer [4] is not a real multi-master solution. Some ideas: * Multi-Signer DNSSEC Models * https://datatracker.ietf.org/doc/html/rfc8901 * DNSSEC automation * https://www.ietf.org/staging/draft-wisser-dnssec-automation-00.html Or do you have any ideas/recommendations how to create multi-master dnssec setup and keep automatic key management [1]? Thanks Marian [1] https://www.knot-dns.cz/docs/3.0/html/configuration.html#dnssec-automatic-z… [2] https://www.knot-dns.cz/docs/3.0/html/configuration.html#dnssec-manual-key-… [3] https://lists.nic.cz/pipermail/knot-dns-users/2019-November/001716.html [4] https://lists.nic.cz/pipermail/knot-dns-users/2020-December/001943.html Je dobré vědět, že tento e-mail a přílohy jsou důvěrné. Pokud spolu jednáme o uzavření obchodu, vyhrazujeme si právo naše jednání kdykoli ukončit. Pro fanoušky právní mluvy - vylučujeme tím ustanovení občanského zákoníku o předsmluvní odpovědnosti. Pravidla o tom, kdo u nás a jak vystupuje za společnost a kdo může co a jak podepsat naleznete zde<https://onas.seznam.cz/cz/podpisovy-rad-cz.html> You should know that this e-mail and its attachments are confidential. If we are negotiating on the conclusion of a transaction, we reserve the right to terminate the negotiations at any time. For fans of legalese—we hereby exclude the provisions of the Civil Code on pre-contractual liability. The rules about who and how may act for the company and what are the signing procedures can be found here<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>.

5 let, 4 měsíce

Knot DNS 3.0.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.6! This version fixes KSK rollover, zone file load with HTTPS/SVCB records, zone backup/restore, and more. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.6/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

5 let, 5 měsíců

Re: [knot-dns-users] keymgr and keystores

by Full Name

Thanks. You are right - once the keymgr operation is launched on a zone that is defined in knot.conf so that the SoftHSM policy applies to it, the keys involved are managed by the softhsm module. I have verified that such is the case for keymgr when using the generate command, and it stands to reason that the same would apply to other commands supported by keymgr. I haven't tried modifying the template section, as you suggest, but I am sure it works as expected. This all also explains and justifies why an option to specify a keystore for keymgr to work with, present in older versions, has been removed - it is not necessary. Thanks for your help/ -----Original Message----- From: "Daniel Salzman" [daniel.salzman(a)nic.cz] Date: 05/03/2021 01:57 AM To: "Full Name" <nuncestbibendum(a)excite.com>, knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] keymgr and keystores If you don't specify any configuration or kaspdb explicitly, keymgr uses default Knot configuration (file or database). So the problem probably is that you are generating keys for zones with default dnssec policy, which doesn't use the softhsm keystore. Try setting: template: - id: default ... dnssec-policy: RSAPol On 5/2/21 3:46 PM, Full Name wrote: > Thanks for your reply. Please see my comments below. > > -----Original Message----- > From: "Daniel Salzman" [daniel.salzman(a)nic.cz] > Date: 05/02/2021 04:51 AM > To: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] keymgr and keystores > > > On 4/30/21 7:47 PM, Full Name wrote: >> I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification: >> >> 1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file: >> >> server: >> listen: [10.0.0.1 ] >> >> log: >> - target: syslog >> any: info >> >> template: >> - id: default >> global-module: mod-stats >> >> mod-stats: >> - id: default >> >> policy: >> - id: RSAPol >> algorithm: RSASHA256 >> ksk-size: 2048 >> zsk-size: 1024 >> >> zone: >> - domain: s0.mydomain.com >> storage: /var/lib/MyZones/db >> file: db.s0 >> dnssec-signing: on >> dnssec-policy: RSAPol >> >> On launching Knot, this works as expected: >> >> - The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot. >> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. >> >> 2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes: >> >> - I added a keystore section: >> >> keystore: >> - id: SoftHSM >> backend: pkcs11 >> config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so" >> >> - I modified the zone section to use SoftHSM: > > [DS] I expect you modified the policy section! > > Yes, I added a line > > keystore: SoftHSM > > I.e. the policy section reads > > policy: > - id: RSAPol > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > keystore: SoftHSM > > I should have pointed this out explicitly - my mistake. > > >> >> zone: >> - domain: s0.mydomain.com >> storage: /var/lib/MyZones/db >> file: db.s0 >> dnssec-signing: on >> dnssec-policy: RSAPol >> keystore: SoftHMS >> > > Notice it should read keystore: SoftHSM. This is just a transcription error on my side - it is correct in the actual knot.conf file that I am using. > >> Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens: >> >> - data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys. >> - Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94. >> - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. >> >> This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module. >> >> Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use. > > [DS] What are your parameters to keymgr? Don't you use default configuration (-d parameter)? > > No parameters. I just invoke it as > > keymgr mydomain.com. generate algorithm=RSASHA256 > > Specifying -d /tmp will create db files under /tmp, and a keys directory under /tmp containing the actual keys in the clear. The essence of the issue remains the same though: the private keys are in the clear, and don't seem to have been generated by SoftHSM. > > >> Here is my question: >> >> Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM? > > [DS] Keymgr follows the zone's policy. So it uses the keystore which is configured for the zone. > > That's what I thought. Here's the thing though: in the knot.conf file above I changed the config entry in the keystore section, so that the wrong user PIN is supplied when attempting to access the services of the SoftHSM module. However, when using the keymgr command above, key pairs are are still generated without error, and stored outside the disk area allocated for SoftHSM. This makes me think that SoftHSM is not being used for this operation. This conclusion is reinforced by the fact that when I launch knot with that incorrect PIN in knot.conf, signatures are not computed and I get errors in syslog to that effect. > > The bottom line is that, although key pairs are definitely created by SoftHSM, and stored in the disk area for SoftHSM, when the automatic key generation process, as driven by knot.conf, kicks in, when using keymgr I have yet to be able to get SoftHSM to generate key pairs and store them in its disk area. What am I doing wrong? > > > >> >> I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals? >> >> Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs. >> >> >> >>

5 let, 5 měsíců

Re: [knot-dns-users] keymgr and keystores

by Full Name

Thanks for your reply. Please see my comments below. -----Original Message----- From: "Daniel Salzman" [daniel.salzman(a)nic.cz] Date: 05/02/2021 04:51 AM To: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] keymgr and keystores On 4/30/21 7:47 PM, Full Name wrote: > I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification: > > 1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file: > > server: > listen: [10.0.0.1 ] > > log: > - target: syslog > any: info > > template: > - id: default > global-module: mod-stats > > mod-stats: > - id: default > > policy: > - id: RSAPol > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > > zone: > - domain: s0.mydomain.com > storage: /var/lib/MyZones/db > file: db.s0 > dnssec-signing: on > dnssec-policy: RSAPol > > On launching Knot, this works as expected: > > - The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot. > - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. > > 2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes: > > - I added a keystore section: > > keystore: > - id: SoftHSM > backend: pkcs11 > config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so" > > - I modified the zone section to use SoftHSM: [DS] I expect you modified the policy section! Yes, I added a line keystore: SoftHSM I.e. the policy section reads policy: - id: RSAPol algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 keystore: SoftHSM I should have pointed this out explicitly - my mistake. > > zone: > - domain: s0.mydomain.com > storage: /var/lib/MyZones/db > file: db.s0 > dnssec-signing: on > dnssec-policy: RSAPol > keystore: SoftHMS > Notice it should read keystore: SoftHSM. This is just a transcription error on my side - it is correct in the actual knot.conf file that I am using. > Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens: > > - data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys. > - Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94. > - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. > > This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module. > > Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use. [DS] What are your parameters to keymgr? Don't you use default configuration (-d parameter)? No parameters. I just invoke it as keymgr mydomain.com. generate algorithm=RSASHA256 Specifying -d /tmp will create db files under /tmp, and a keys directory under /tmp containing the actual keys in the clear. The essence of the issue remains the same though: the private keys are in the clear, and don't seem to have been generated by SoftHSM. > Here is my question: > > Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM? [DS] Keymgr follows the zone's policy. So it uses the keystore which is configured for the zone. That's what I thought. Here's the thing though: in the knot.conf file above I changed the config entry in the keystore section, so that the wrong user PIN is supplied when attempting to access the services of the SoftHSM module. However, when using the keymgr command above, key pairs are are still generated without error, and stored outside the disk area allocated for SoftHSM. This makes me think that SoftHSM is not being used for this operation. This conclusion is reinforced by the fact that when I launch knot with that incorrect PIN in knot.conf, signatures are not computed and I get errors in syslog to that effect. The bottom line is that, although key pairs are definitely created by SoftHSM, and stored in the disk area for SoftHSM, when the automatic key generation process, as driven by knot.conf, kicks in, when using keymgr I have yet to be able to get SoftHSM to generate key pairs and store them in its disk area. What am I doing wrong? > > I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals? > > Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs. > > > > -- https://lists.nic.cz/mailman/listinfo/knot-dns-user

5 let, 5 měsíců

keymgr and keystores

by Full Name

I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification: 1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file: server: listen: [10.0.0.1 ] log: - target: syslog any: info template: - id: default global-module: mod-stats mod-stats: - id: default policy: - id: RSAPol algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 zone: - domain: s0.mydomain.com storage: /var/lib/MyZones/db file: db.s0 dnssec-signing: on dnssec-policy: RSAPol On launching Knot, this works as expected: - The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot. - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. 2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes: - I added a keystore section: keystore: - id: SoftHSM backend: pkcs11 config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so" - I modified the zone section to use SoftHSM: zone: - domain: s0.mydomain.com storage: /var/lib/MyZones/db file: db.s0 dnssec-signing: on dnssec-policy: RSAPol keystore: SoftHMS Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens: - data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys. - Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94. - The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db. This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module. Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use. Here is my question: Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM? I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals? Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs.

5 let, 5 měsíců

Re: [knot-dns-users] Fwd: [knot-resolver-users] Any "gothcas" going from 2.65 to 3.04 I should know about?

by libor.peltan

Hi Chris, first of all, you seem to be talking about Knot DNS, so it's proper to switch to correct mailing list, instead of Knot Resolver's one. I assume you have read all the single-version migration guides below https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#upgrade-2-6-x-to-2-7… . It's clear that when migrating over multiple versions, you need to take care about all the notes at once. What databases exactly are you talking about? Knot DNS uses multiple databases for different purposes, e.g. journal or KASP DB. The good news is, their format does not change much, and when it does, it's usually backwards-compatible, with some exceptions. I would strongly recommend that you clone your environment, perform the migration in some "playground" setup first, and observe if everything went well; all before migration your production setup ;) Should you encounter any issues, please contact us on our mailing-list. Anyway, you might consider a multi-step migration, so that you would migrate by just one (major) version at once, like this: 2.6.5 -> 2.7.8 -> 2.8.5 -> 2.9.9 -> 3.0.5. Thanks! Libor Dne 09. 04. 21 v 8:13 Daniel Salzman napsal(a): > > > -------- Forwarded Message -------- > Subject: [knot-resolver-users] Any "gothcas" going from 2.65 to 3.04 I should know about? > Date: Thu, 08 Apr 2021 23:03:54 -0700 > From: Chris <knot(a)tacomawireless.net> > Reply-To: Knot Resolver Users List <knot-resolver-users(a)lists.nic.cz> > To: knot-resolver-users <knot-resolver-users(a)lists.nic.cz> > > Hi. Moving a couple of our servers to new hardware, and > taking that opportunity to upgrade some of the services > at the same time. The main one being knot. Moving from > a 2.65 context to 3.04. I've read the upgrade doc, and > while there isn't a 2.65 --> 3.04. It appears for our > environment that the changed/removed stanzas won't > have much of an impact *except* as they relate to the > database. That is; it appears that it isn't going to > be a smooth transition, as they appear to be incompatible. > Is that right? Do I need to rewrite all the keys && > serials, and start from scratch? If so, as we have > a huge number of domains, this will be an enormous task. > Is this avoidable? > > Thank you for any and all insight into this transition. > > --Chris

5 let, 6 měsíců

← Newer
1
...
18
19
20
21
22
23
24
...
79
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users