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

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

3 roky, 11 měsíců

1
0
0 0

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

3 roky, 12 měsíců

3
2
0 0

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

3 roky, 12 měsíců

2
3
0 0

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

4 roky

1
0
0 0

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>.

4 roky

2
1
0 0

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

4 roky, 1 měsíc

1
0
0 0

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. >> >> >> >>

4 roky, 1 měsíc

1
0
0 0

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

4 roky, 1 měsíc

2
1
0 0

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.

4 roky, 1 měsíc

2
1
0 0

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

4 roky, 2 měsíce

3
4
0 0

Preventing changes to zone files

by Matthew Pounsett

Is there a way to configure Knot to avoid overwriting a zone file when it's doing automatic signing? I was hoping some combination of zonefile-load and journal-content would tell Knot to store its internally managed data in the journal instead of in the zone file, but I haven't found that combination. I don't see any other likely candidates in the config options, but hoping I've missed something...

4 roky, 2 měsíce

2
2
0 0

Knot DNS 2.9.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.9! This version only backports some fixes from 3.0.5 version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.9/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

4 roky, 2 měsíce

1
0
0 0

Knot DNS 3.0.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.5! This version primarily fixes issues relating zone journal, zone backup, and DNSSEC key handling. The most serious bug might cause malformed zone journal if 'journal-contents: all' or 'zonefile-sync: -1' is configured. Besides the fix, an additional detection of this state is introduced. So if "malformed data" error appears after the upgrade, the journal data are already broken and there is unfortunately no better way than purging the journal (e.g. knotc -f zone-purge +journal affected.zone.net.). Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.5/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

4 roky, 3 měsíce

1
0
0 0

Change journal-content changes to all

by André Keller

Good afternoon, in preparation for Knot 3.1, I wanted to update our template that uses zonefile-load: difference-no-serial from journal-content: changes to journal-content: all. However, it seems that we somehow have to update the existing journal. Otherwise it seems the first change to a zone after that change, will lead to the following error (running knot 3.0.4): error: [example.net.] zone event 'load' failed (semantic check) Subsequent changes seem to be applied just fine. What is the proposed strategy to change this setting? Regards André

4 roky, 3 měsíce

2
4
0 0

Extended expiration of Knot DNS Packaging GPG key

by Daniel Salzman

Hello Knot DNS users, I would like to inform users of our Debian packages (https://deb.knot-dns.cz/knot and https://deb.knot-dns.cz/knot-latest) that the initial Knot DNS Packaging GPG key 8A0EFB02C84B1E9B expired on 2021-03-13. Its expiration time had already been extended to 2022-11-11 a few months ago. But still you can get a GPG error when refreshing the repository. Please update your apt.gpg file from https://deb.knot-dns.cz/knot/apt.gpg or https://deb.knot-dns.cz/knot-latest/apt.gpg. Thank you, Daniel

4 roky, 3 měsíce

1
0
0 0

Old key is being used

by Thomas

Hi, we performed successfully an algorithm rollover. After changing the algorithm in the configuration file everything worked as expected. All zones have been updated to the new algorithm. When I now sign a new zone the zone is being signed with the old algorithm's key and an algorithm rollover is being triggered immediately. Is this an expected behavior? How can I avoid this? Do I have to delete the old key? Thanks a lot, Thomas

4 roky, 3 měsíce

5
14
0 0

Figuring out inconsistent logging

by Matthew Pounsett

Hi! I have two Debian 10 Buster systems, both patched up current, and both running Knot 3.0.4-1~cz.nic~buster1 from the apt repository at https://deb.knot-dns.cz/knot-latest/. Both Knot installations have virtually identical configs .. really only different in the related hosts and zone lists. Their logging configs are both: log: - target: syslog any: info One of these Knot instances logs to syslog, and the other logs to systemd-journald. I'm trying to figure out why the difference, and I've come up empty. The Knot docs simply say that if Knot is compiled against systemd, then a 'syslog' setting will use systemd-journald. Mostly I want to know so that I can convince the one using journald to stop doing that. :) What other things might trigger Knot to use syslog on a systemd-managed host?

4 roky, 3 měsíce

2
6
0 0

usage of 2 different dnssec policies

by Thomas E.

Hi, is it possible to have two different DNSSEC policies in place? For example having one domain singed with Alg 8 and another one with Alg 13? Thanks a lot, Thomas

4 roky, 4 měsíce

2
1
0 0

Dynamic update for dnskey

by Ulrich Wisser

Hi! Today we tried to do a dynamic update to the dnskey set. What we want to do is to import the ZSK from another signer. Didn’t work so well. Feb 16 17:15:28 ip-172-31-38-41 knotd[24222]: warning: DDNS, refusing to update DNSSEC-related record I guess knot doesn’t like dynamic DNSSEC updates. I even tried with policy manual:on. What does one have to do to be allowed to add (or delete) DNSKEY records? /Ulrich

4 roky, 4 měsíce

2
3
0 0

Zone-freeze appears not to work

by James Garnett

Hello all, I am attempting to test freezing a zone, and something appears not to be working (that something could be my understanding of how it is supposed to work). Using a very simple example.com zone (the default that ships with v3.0.4), I am able to query for "mail.example.com" and get the correct response back. I then query for "test.example.com" and get an NXDOMAIN, as expected. Then I do the following: $ sudo knotc zone-freeze example.com OK $ Doing a zone-status, I see: $ sudo knotc zone-status example.com [example.com.] role: master | serial: 2010111219 | transaction: none | freeze: yes | expiration: not scheduled | notify: not scheduled $ sudo knotc zone-begin example.com OK $ sudo knotc zone-set example.com test 3600 A 150.150.150.150 OK $ sudo knotc zone-commit example.com OK $ sudo knotc zone-flush example.com OK $ After the zone-flush, I am able to query for "test.example.com" and I get back the A-record with address 150.150.150.150. I would have thought that with the zone frozen, the zone-flush would not go through and the A-record for "test" would not be added. Am I missing something obvious, or does zone-freeze just not work in version 3.0.4? Thanks in advance, ~J

4 roky, 4 měsíce

2
2
0 0

knot-3.0.4 continuously re-signing DNSSEC zone

by Marek Szuba

Hello, I have just run into a weird problem and since I have failed to look this up on the Web myself, I wonder if anyone here could give me a pointer regarding what to do with it. I run a Linux/arm DNS server based on knot-3.0.4. It used to serve as a slave in a zone whose master was a knot-2.9, with automatic DNSSEC signing _on master only_ set up and working. The zone configuration (minus "master" and "acl" keywords) looked as follows: zonefile-load: difference-no-serial journal-content: all semantic-checks: on # dnssec-signing: on # dnssec-policy: nsec3 where "nsec3" is a policy also defined in Knot configuration, identical to the one used on the master. In this role everything worked fine. Recently it has been decided to retire the original master server and replace it with the erstwhile slave. I removed the "master" line from the zone configuration in knot.conf (yes, I did leave the DNSSEC line commented out) in addition to setting up replication to a new slave server, copied the key files + the KASP dump from the old master and installed them in the right places, then restarted knot. Again, so far so good. I then attempted to re-enable DNSSEC by uncommenting those two lines - and immediately after I'd run 'knotc reload' Knot began spamming the system log with lines like info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 info: [example.com.] DNSSEC, key, tag 4533, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active info: [example.com.] DNSSEC, key, tag 10532, algorithm RSASHA1_NSEC3_SHA1, public, active info: [example.com.] DNSSEC, signing started info: [example.com.] DNSSEC, successfully signed info: [example.com.] loaded, serial 2021020302 -> 2021020303 -> 2021020302, 113233 bytes info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000 info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 info: [example.com.] DNSSEC, key, tag 4533, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active info: [example.com.] DNSSEC, key, tag 10532, algorithm RSASHA1_NSEC3_SHA1, public, active info: [example.com.] DNSSEC, signing started info: [example.com.] DNSSEC, successfully signed info: [example.com.] loaded, serial 2021020302 -> 2021020303 -> 2021020302, 113233 bytes info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000 info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 [...and so on...] This was accompanied by knot consistently requiring much more CPU power than usual. I also noticed that unlike before, running 'knotc zone-flush' or shutting Knot down does NOT update the plain-text zone files. From what I could see by removing old DNSSEC signatures and the NSEC3 chain from the zone file, restarting Knot and then querying the server with dig, the server does indeed sign the zone. Therefore, my current working hypothesis is that somehow Knot does not update its internal zone state following the successful signing, thus continuing to think the outdated zone file found on the file system is the latest available version. The problem is, I do not know why it does it or how I could make it stop. Any and all suggestions will be very much appreciated! Cheers, -- MS

4 roky, 4 měsíce

3
6
0 0

Knot DNS 3.0.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.4! This version mostly fixes some issues in 3.0 features. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.4/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

4 roky, 5 měsíců

1
0
0 0

Warning about NOTAUTH error from notify

by Sadiq Saif

Hi all, I can't quite figure this out, I have two servers running Knot DNS 3.0.3 on Ubuntu 20.04. horus.bastetrix.net is the primary, sekhmet.bastetrix.net is the secondary. One of the zones hosted on these servers is selfhosting.cloud. Whenever I commit a change to selfhosting.cloud, this happens in the log. As you can see, for some reason the IPv4 address returns a NOTAUTH error and then Knot successfully notifies over IPv6. Dec 27 00:53:37 horus.bastetrix.net knotd[174159]: warning: [selfhosting.cloud.] notify, outgoing, remote 192.195.251.53@53, server responded with error 'NOTAUTH' Dec 27 00:53:37 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] notify, outgoing, remote 2620:98:400c::53@53, serial 5 Dec 27 00:53:38 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] IXFR, outgoing, remote 2620:98:400c::53@36778, started, serial 4 -> 5 Dec 27 00:53:38 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] IXFR, outgoing, remote 2620:98:400c::53@36778, finished, 0.00 seconds, 1 messages, 295 bytes sekhmet only logs a successful notify and IXFR from the v6 address, nothing about the failed v4 notify: Dec 27 00:53:37 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] notify, incoming, remote 2620:98:400a::53@58782, serial 5 Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] refresh, remote 2620:98:400a::53@53, remote serial 5, zone is outdated Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] IXFR, incoming, remote 2620:98:400a::53@53, started Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] IXFR, incoming, remote 2620:98:400a::53@53, finished, 0.00 seconds, 1 messages, 295 bytes Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] refresh, remote 2620:98:400a::53@53, zone updated, 0.40 seconds, serial 4 -> 5 Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] zone file updated, serial 4 -> 5 I am attaching the knot.conf for both servers. I double checked both configs multiple times and don't see why that particular warning is happening during zone notify. Can someone shed some light on this mystery? -- Sadiq Saif https://bastetrix.com

4 roky, 5 měsíců

2
2
0 0

Knot DNS 3.0.3 and 2.9.8 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.3 and Knot DNS 2.9.8! These updates are recommended for users with on-slave DNSSEC signing deployments. Ubuntu/Debian packages of 3.0.3 version no longer link against jemalloc memory allocator. Because new versions of Knot DNS behave better with the default memory allocator. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.3/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.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

4 roky, 6 měsíců

1
0
0 0

Active and backup signer

by Einar Bjarni Halldórsson

Hi, We're migrating our signer from OpenDNSSEC to Knot 3.0. Our new design will have one active signer and at least one backup signer. Zone data is deployed from git to both signers. We've got syncing of the keys working using `knotc zone-backup +nozonefile` and `knotc zone-restore +nozonefile`. I'm still unsure of how hot to keep the standby. In the dev env now I have the standby set to a manual dnssec policy to keep it from rolling it's keys. The keys are synced from the active signer every hour. Both the active and the backup signers are creating signatures but SOA serials don't match. Both signers have `serial-policy: dateserial` and `zonefile-sync: -1` but we're considering adding `zonefile-load: difference-no-serial`. We've discussed stopping signing on the backup altogether and including the zonefiles in the backup. The problem we have with this idea is that problems with signing on the backup won't be discovered until it goes active. Are other people doing active-backup signers and how do you set it up? .einar

4 roky, 6 měsíců

5
5
0 0

Missing private keys in backup

by Thomas E.

Hi (again), I was trying to backup and restore a server with the new knotc zone-backup/restore command. I recognized that only half of the private keys were in the backup, which leads to an error: 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load private keys (not exists) 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load keys (not exists) Shouldn't the backup contain all private keys? Thanks, Thomas

4 roky, 6 měsíců

4
19
0 0

Algorithm Rollover

by Thomas E.

Hi, I was trying to backup and restore a server with the new knotc zone-backup/restore command. I recognized that only half of the private keys were in the backup, which leads to an error: 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load private keys (not exists) 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load keys (not exists) Shouldn't the backup contain all private keys? Thanks, Thomas

4 roky, 6 měsíců

1
1
0 0

Removing slave from confdb not working

by Zdenek Novy

Hello, I'm trying to remove the slave node from the master Knot, result code is 0, but no change happened. There is no information in the log file. Can you please help me, why does it happen? # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 # knotc conf-begin > OK # knotc conf-set -b template[default].notify 1 2 4 5 6 7 8 9 > OK # knotc conf-diff (no output) # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 Thanks for your help. -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

4 roky, 6 měsíců

4
6
0 0

Too many transactions error

by Zdenek Novy

Hello, we are facing the issue with "Too many transactions" during configuring knot via knotc - we are using confdb. We are using Python3 worker and popen function to knotc socket. This is the log from the Python worker: [2020-12-07 08:58:13,001] [INFO] adding zone xxxxxxxx [2020-12-07 08:58:13,016] [ERROR] [event worker.job] Exception in job 'dns.add_zone' Traceback (most recent call last): ...... ACK Exception: error running command: 'conf-begin' retcode: 1 out: error: (too many transactions) Is there any limitation for number of open transactions and are we able to increase it? Is it possible to see, how many open transactions there are now? I can't see any message in the log file, is it possible to log conf-begin requests? Or are there any other ways, how to determine and guard the situation? Many thanks for your help -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

4 roky, 6 měsíců

2
1
0 0

Removing slave from confdb not working

by Zdenek Novy

Hello, I'm trying to remove the slave node from the master Knot, result code is 0, but no change happen. There is no information in the log file. Can you please help me, why does it happen? # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 # knotc conf-begin > OK # knotc conf-set -b template[default].notify 1 2 4 5 6 7 8 9 > OK # knotc conf-diff (no output) # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 Thanks for your help. -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

4 roky, 6 měsíců

1
0
0 0

DNSSEC with multiple authoritative servers

by Nils Trampel

Hello, as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures. Best regards and thanks, Nils -- Nils Trampel GPG: 0x012BADD8

4 roky, 6 měsíců

5
10
0 0

Knot DNS 3.0.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.2! This version fixes several bugs and brings some improvements. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.2/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support: https://www.knot-dns.cz/support Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

4 roky, 7 měsíců

1
0
0 0

Query Log of Knot DNS

by Vu Thi Hoan

Dear! We are learning about the Knot DNS to apply to our DNS Authoritative Secondary. However, we are wondering about the query log, i have read the document of DNS Knot Software (Knot DNS Documentation Release 2.9.4/ 8.3 dnstap – Dnstap traffic logging), query log of Knot DNS cannot get directly like BIND9, query log can get by dnstap tool. For Knot DNS Software, we cannot get log query continuosly and directly to the current syslog server, since raw log need to capture and then read after stop capture. I wanna to know how to get the query log continously when using Knot DNS or softwares of your DNS and other DNS of organizations have already applied. Can you share with us and help us to deploy Knot DNS to our DNS Authoritative Secondary. Best Regards, Vũ Thị Hoàn ================================================= DNS & VNIX - Trung tâm Internet Việt Nam Mobile: +84 916 961 631 Email: hoanvt(a)vnnic.vn

4 roky, 7 měsíců

2
1
0 0

Algorithm Rollover

by Thomas

Hi, the doc says that changing the policy algorithm field will trigger an algorithm rollover. Is there anything else one must consider or is the algorithm rollover done fully automated like the normal rollovers? Thanks, Thomas

4 roky, 7 měsíců

2
2
0 0

Unknown algorithm: rsasha1-nsec3-sha1

by Thomas

Hi, I need to generate keys of algorithm 7. But I receive this error: # keymgr example generate algorithm=rsasha1-nsec3-sha1 size=2048 ksk=yes Unknown algorithm: rsasha1-nsec3-sha1 Error (invalid parameter) I'm using the latest version of knot. Do I get something wrong here? It you be supported, right? Thanks Thomas

4 roky, 7 měsíců

2
2
0 0

dynamic updates (DDNS)

by Thomas

Hi! Is it safe to mix dynamic updates and manual editing of a zone? Thanks! Thomas

4 roky, 7 měsíců

7
20
0 0

Inter-operability issues with other DNS Servers

by Evilham

Ahoj, I've searched through the archives and read documentation+RFCs to no avail, so I hope you can help out. I run the authoritative DNS servers for an associative ISP in Barcelona (eXO.cat), and we are running them in FreeBSD using Knot DNS (2.9.5, but .6 and .7's changelogs do not point to a similar issue being solved). We have since then gotten a few reports from different parties of "DNS issues", I am reasonably sure to have pinpointed this down to badly configured DNS resolvers, but our weight is really too tiny to force any change; and the doubt remains as to whether or not this is on us. Without access to the resolvers it's also a tad tricky for us to reproduce. Things do work beautifully with pretty much all of the internet. This appears to be related to: https://tools.ietf.org/html/rfc7873#section-5.2.3 (sometimes in connection with 5.2.4) Maybe someone with more experience and running at a larger scale has pointers on this topic. Specifically, I have observed: Case A: 1. (Probably Bind) Resolver contacts Knot DNS with Client Cookie and old Server Cookie 2. Knot DNS responds BADCOOKIE with the provided Client Cookie, Old Server Cookie, and adds the new server cookie. 3. Resolver contacts Knot DNS with the same Client Cookie and old Server Cokie 4. 2 and 3 repeat for a long time. 5. Domains end up not resolving. Case B: https://github.com/matrix-org/synapse/issues/8581 Their supplier says the DNS server "replies with BADCOOKIE to UDP queries", as if that were a bad thing; but from reading RFC7873, I understand that it is expected documented behaviour and the client ought to try again with the given Server Cookie. They say: "AIUI the resolver does retry, but again receives a BADCOOKIE response." I sadly don't have the tcpdump for those, but it could be just like case A again. These are the relevant bits from the config: server: rundir: "/var/run/knot" user: knot:knot listen: [ 0.0.0.0@53, ::@53 ] log: - target: syslog any: info statistics: append: off database: storage: "/var/db/knot" mod-cookies: - id: default badcookie-slip: 1 mod-rrl: - id: default rate-limit: 200 # Requests per second template: - id: default storage: "/var/db/knot/primary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" global-module: mod-cookies/default global-module: mod-rrl/default global-module: mod-stats - id: secondary storage: "/var/db/knot/secondary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats - id: signed storage: "/var/db/knot/primary" dnssec-signing: on zonefile-load: difference semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats We are not using anycast clusters or anything like that. A quick solution would be to disable cookies or to experiment with noudp, but that's something we'd like to avoid. The name servers in question are: - ns3.exo.cat - ns4.exo.cat - ns1.unchat.cat (not association, but identical setup) All tests I've ran against the servers and the associated domains (e.g. exo.cat + unchat.cat) appear to be fine. There is an odd one with https://dnsviz.net/d/unchat.cat/dnssec/, but other tests like https://www.zonemaster.net/result/d530cb253298b56c do not report any issues. Thank you in advance for any pointers you may have (and for Knot DNS!), -- Evilham

4 roky, 7 měsíců

4
6
0 0

Knot upgrade

by Oto Stefan

Hallo everybody, this is just a little remark concerning the 'knot' upgrade from 2.9.x to 3.0.x. The 'update-owner-name' in the 'acl' section of the configuration file can now be either the FQDN (with trailing dot) or a relative name to the zone, while it used to be a domain name before (without obligatory dot at the end). The documentation was updated correctly: Doc for 2.9: acl - id: owner_type_rule action: update update-type: [A, AAAA, MX] # Updates are only allowed to update records of the specified types update-owner: name # The allowed owners are specified by the list on the next line update-owner-name: [a.example.com, b.example.com, c.example.com] update-owner-match: equal # The owners of records in an update must be exactly equal to the names in the list Doc for 3.0: acl - id: owner_type_rule action: update update-type: [A, AAAA, MX] # Updates are only allowed to update records of the specified types update-owner: name # The allowed owners are specified by the list on the next line update-owner-name: [a, b.example.com.] # Non-FQDN names are relative to the effective zone name update-owner-match: equal # The owners of records in an update must be exactly equal to the names in the list However; I did not notice the subtle change and was struggling for a while to bring the dynamic zone update into a working state again . Maybe, this saves a little time to someone else. Regards and thanks for a great piece of software, Oto Stefan

4 roky, 8 měsíců

2
1
0 0

Warning - TCP ports binding in Knot DNS versions 3.0.0 and 3.0.1

by David Vasek

Hello Knot DNS users! We would like to inform you about a change in Knot DNS behaviour in versions 3.0.0 and 3.0.1. These two versions don't allow sharing of TCP ports between programs, including other knotd instances (SO_REUSEADDR isn't set). While this behaviour is better from point of view of security, the downside of it is that when restarting a knotd daemon, binding to a TCP port may fail after a restart if the restart is immediate. In such a case, an error is logged and Knot starts its operation on other configured ports only. To verify that all TCP ports have been bound successfully after Knot restart, please always check the log for possible errors. Such errors would be close to the initial message about Knot DNS starting. Since there was a complaint about this change, we plan to re-enable TCP ports reuse in future releases. We also ponder making knotd exit if it fails to bind to any of configured TCP ports. We would like hear from you whether such a behaviour is what you, users, want best. Please, let us know if you prefer this or a different solution. With regards, David Vašek CZ.NIC

4 roky, 8 měsíců

4
3
0 0

Knot DNS 3.0.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.1! It's recommended to update from 3.0.0 version if you serve DNSSEC signed zones with NSEC3. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.1/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

4 roky, 8 měsíců

1
0
0 0

Knot DNS 2.9.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.7! This is a bugfix version of previous stable branch. It's recommended to update from older 2.9.x versions if you serve DNSSEC signed zones with NSEC3. Knot DNS 3.0.1 will be released tomorrow. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.7/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/2.9/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

4 roky, 8 měsíců

1
0
0 0

Debugging high CPU / Load - normal?

by Jonathan Hewlett

Hi, We run around 50 knot servers around the world, with great success - thanks for the software! We are just a little curious about seemingly high CPU usage, and how best to interpret the results, if someone could advise? Specifically, we are seeing the majority of the cpu time in 'system' and not 'user', what would that suggest is happening perhaps? Any tuning help gratefully received! Our platform (sample) 24 Core CPU E5-2440 0 @ 2.40 64Gb RAM SSD knot-2.9.5, running on Centos 8.2 Currently receiving around 4k pps Server is authoritative for a 278 zones, the largest zone file being around 600Mb Output of top top - 20:50:38 up 6 days, 4:49, 2 users, load average: 13.47, 12.34, 11.83 Tasks: 321 total, 2 running, 318 sleeping, 0 stopped, 1 zombie %Cpu0 : 4.0 us, 34.1 sy, 0.0 ni, 60.3 id, 0.3 wa, 0.7 hi, 0.7 si, 0.0 st %Cpu1 : 4.3 us, 19.4 sy, 0.0 ni, 75.3 id, 0.0 wa, 0.3 hi, 0.7 si, 0.0 st %Cpu2 : 4.3 us, 33.8 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.7 hi, 0.3 si, 0.0 st %Cpu3 : 5.0 us, 21.2 sy, 0.0 ni, 73.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu4 : 3.3 us, 34.9 sy, 0.0 ni, 61.5 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu5 : 3.0 us, 20.2 sy, 0.0 ni, 76.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu6 : 4.0 us, 35.2 sy, 0.0 ni, 60.4 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu7 : 5.0 us, 18.7 sy, 0.0 ni, 76.0 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu8 : 2.0 us, 35.0 sy, 0.0 ni, 62.3 id, 0.0 wa, 0.7 hi, 0.0 si, 0.0 st %Cpu9 : 2.0 us, 20.0 sy, 0.0 ni, 77.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu10 : 3.7 us, 34.4 sy, 0.0 ni, 61.2 id, 0.0 wa, 0.7 hi, 0.0 si, 0.0 st %Cpu11 : 3.3 us, 20.7 sy, 0.0 ni, 75.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu12 : 2.3 us, 34.6 sy, 0.0 ni, 62.1 id, 0.0 wa, 0.7 hi, 0.3 si, 0.0 st %Cpu13 : 3.3 us, 20.7 sy, 0.0 ni, 75.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu14 : 2.3 us, 33.6 sy, 0.0 ni, 59.7 id, 0.0 wa, 0.7 hi, 3.7 si, 0.0 st %Cpu15 : 3.3 us, 19.7 sy, 0.0 ni, 76.3 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu16 : 2.3 us, 34.0 sy, 0.0 ni, 58.7 id, 0.0 wa, 1.0 hi, 4.0 si, 0.0 st %Cpu17 : 2.3 us, 21.5 sy, 0.0 ni, 75.8 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu18 : 3.3 us, 34.8 sy, 0.0 ni, 57.2 id, 0.0 wa, 0.7 hi, 4.0 si, 0.0 st %Cpu19 : 5.0 us, 19.3 sy, 0.0 ni, 75.1 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu20 : 2.7 us, 35.3 sy, 0.0 ni, 60.0 id, 0.0 wa, 0.7 hi, 1.3 si, 0.0 st %Cpu21 : 1.7 us, 20.5 sy, 0.0 ni, 77.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu22 : 4.7 us, 32.4 sy, 0.0 ni, 58.5 id, 0.0 wa, 0.7 hi, 3.7 si, 0.0 st %Cpu23 : 2.3 us, 19.0 sy, 0.0 ni, 78.3 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st MiB Mem : 64107.4 total, 46764.9 free, 11733.6 used, 5608.8 buff/cache MiB Swap: 32248.0 total, 32248.0 free, 0.0 used. 51670.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 213370 knot 20 0 34.0g 9.6g 41784 S 644.9 15.3 1319:12 /usr/sbin/knotd Thanks again for this great product. Jonathan

4 roky, 8 měsíců

3
9
0 0

Catalog zone configuration/zone auto configuration bootstrapping

by Frank Matthieß

Hello all, i stuck a little bit with the configuration of the new catalog zone feature in knot dns 3.0.0. The catalog zone replication is running quite well, but bootstrapping this feature to replicate the config for zones wont work for me. The zone name of the catalog zone is "zone.catalog". The primary name server uses this config: > # Configuration export (Knot DNS 3.0.0) > zone: > - domain: "zone.catalog." > file: "%s" > notify: [ "ns1.frank.REDACTED.DOM", "ns2.frank.REDACTED.DOM" ] > acl: [ "ns1.frank.REDACTED.DOM", "ns2.frank.REDACTED.DOM" ] > catalog-role: "interpret" > catalog-template: "catalog-zone-template" > > - domain: "dom-siew9tho.invalid." The zone has this content: > [zone.catalog.] zone.catalog. 60 NS nshp.frank.REDACTED.DOM. > [zone.catalog.] zone.catalog. 60 SOA nshp.frank.REDACTED.DOM. hostmaster.REDACTED.DOM. 1601540072 16384 2048 1048576 2560 > [zone.catalog.] id-ies3eidiev4ooquahgoh.zone.catalog. 0 PTR dom-siew9tho.invalid. > [zone.catalog.] version.zone.catalog. 0 TXT "2" Adding the following config to the primary works: > conf-begin > conf-set zone.domain "dom-siew9tho.invalid." > conf-commit > zone-begin dom-siew9tho.invalid. > zone-set dom-siew9tho.invalid. @ 60 SOA nshp.frank.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560 > zone-set dom-siew9tho.invalid. @ 60 NS nshp.REDACTED.DOM. > zone-commit dom-siew9tho.invalid. Query one of the secondaries (ns1) gives me: > error: (no such zone found) [dom-siew9tho.invalid.] The config of ns1: > # Configuration export (Knot DNS 3.0.0) > template: > - id: "catalog-zone-template" > storage: "/var/lib/knot/zones" > file: "%s" > semantic-checks: "on" > dnssec-signing: "off" > serial-policy: "unixtime" > kasp-db: "/var/lib/knot/kasp-db" > > zone: > - domain: "zone.catalog." > file: "%s" > master: "nshp.frank.REDACTED.DOM" > acl: "nshp.frank.REDACTED.DOM" > catalog-role: "interpret" > catalog-template: "catalog-zone-template" I'm sure i miss one or more parts and/or i have a serious misunderstanding of the bootstrapping setup for this feature. - frank -- Frank Matthieß Mail: frank.matthiess(a)virtion.de phone: +49 521 44 81 58 17 GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1 virtion GmbH Südring 11, DE 33647 Bielefeld Geschäftsführer: Michael Kutzner Handelsregister HRB 40374, Amtsgericht Bielefeld, USt-IdNr.: DE278312983

4 roky, 8 měsíců

3
4
0 0

copy key from one instance to another

by Ulrich Wisser

Hi! For a special project I need to sign the same zone on two servers with the same key. How can I create a key and import it in both instances? Or export an automatically generated key from one instance and import in the other instance? Kind regards from Stockholm /Ulrich

4 roky, 9 měsíců

2
1
0 0

termination of obsolete Knot DNS OBS repos

by Jakub Ružička

Following obsolete OBS package repositories will be terminated without mercy on Friday 18th September 2020: * [knot-dns](https://build.opensuse.org/project/show/home:CZ-NIC:knot-dns) * [knot-dns-latest](https://build.opensuse.org/package/show/home:CZ-NIC:knot-d… If you are using these repos, please refer to [Knot DNS download page](https://www.knot-dns.cz/download/) for links to current package repos for your favourite distribution. Jakub Ružička CZ.NIC packager

4 roky, 9 měsíců

1
0
0 0

Knot DNS 3.0.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.0! This version introduces lots of new features. You can read more about them on this blog post https://en.blog.nic.cz/2020/09/09/knot-dns-3-0-news/ Don't forget to check the updated benchmarks https://www.knot-dns.cz/benchmark/ Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.0/NEWS Migration: https://www.knot-dns.cz/docs/3.0/html/migration.html#upgrade-2-9-x-to-3-0-x Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

4 roky, 9 měsíců

1
0
0 0

Knot DNS 2.9.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.6! This is mostly a bug fix version with some small improvements. Just a notice, on September 9th we are going to release Knot DNS 3.0.0, which will become a new Current Latest version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.6/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.6.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

4 roky, 9 měsíců

1
0
0 0

keymgr doesn't delete (remove) keys

by Chris

I'm currently on 2.6.5, and am moving everything to a new server I've created that's using the newest version. However, I've got a couple of zones I am trying to clean up before the move. In my effort to resign these zones, I'm retiring/removing keys associated with these zones prior to resigning them. But keymgr(8) isn't working as expected. eg; 12:25pm Fri, 21 # keymgr some.zone. set 09696 retire=20200821122736 remove=20200821122755 12:28pm Fri, 21 # keymgr some.zone. list iso ... 83ded1e7f4375657fe12ca666d4bbc6c33b7edea ksk=no zsk=yes tag=09696 algorithm=5 public-only=no created=2020-05-06T04:42:32 pre-active=2020-05-06T04:42:32 publish=2020-05-06T05:42:32 ready=1970-01-01T00:00:00 active=2020-05-06T18:42:32 retire-active=1970-01-01T00:00:00 retire=2020-08-21T12:27:36 post-active=1970-01-01T00:00:00 remove=2020-08-21T12:27:55 ... As you can see, it's 12:28 but the key was not removed. What am I (missing/misunderstanding? Thanks. --Chris

4 roky, 10 měsíců

2
2
0 0

KSK and ZKS roll-overs on schedule

by Thomas

Hi, I have another requirement for a capability test. I need to perform ZSK and KSK rollovers on specific times. Something like KSK rollover after exactly 60 hours. Or ZSK rollover after exactly 24 hours and another one after another 24 hours. And so on... One additional requirement is that I need to pre-generate the keys. I was thinking of doing it with manual key management enabled and to use the keymgr tool for it. But I'm unsure about how to set the key attributes correctly an in what order. At what point I have to set the new key to active, and how can I remove the old key, and so on... I have never done it manually as I normally use Knots automatic key management. Is the "knotc zone-key-rollover" useful here, or is it only useful in an automatic key management set up? I really appreciate any help here! Thanks a lot, Thomas

4 roky, 10 měsíců

3
2
0 0

Re: [knot-dns-users] Unexpected behaviour of `knotc zone-set` when adding a TXT record

by Daniel Salzman

Hello, You have to escape the quotes: zone-set bastetrix.com @ 86400 TXT \"v=spf1 include:spf.messagingengine.com -all\" Regards, Daniel On 8/9/20 4:47 AM, Sadiq Saif wrote: > Hi all, > > Today I ran into some unexpected behaviour, I wanted to make a modification to the TTL (3600->86400) for the SPF TXT record for bastetrix.com, so I did the following: > > zone-set bastetrix.com @ 86400 TXT "v=spf1 include:spf.messagingengine.com -all" > > But the result was unexpected, instead of modifying the record, I got a new record that looked like this: > > bastetrix.com. 86400 IN TXT "v=spf1" "include:spf.messagingengine.com" " -all" > > RFC 7208 Section 3.3: > > 3.3. Multiple Strings in a Single DNS Record > > As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS > record can be composed of more than one string. If a published > record contains multiple character-strings, then the record MUST be > treated as if those strings are concatenated together without adding > spaces. For example: > > IN TXT "v=spf1 .... first" "second string..." > > is equivalent to: > > IN TXT "v=spf1 .... firstsecond string..." > > TXT records containing multiple strings are useful in constructing > records that would exceed the 255-octet maximum length of a > character-string within a single TXT record. > > If I'm not misreading this bit of the RFC, that record would result in a wrongly formatted SPF record without the correct spaces. > > And indeed when I added the same SPF record to another zone (bastetrix.net) using `knotc zone set` Fastmail's DNS record checker said that I had not added a SPF record. I had to edit the zone by hand in a text editor to fix the issue. > > Is this a bug in `knotc zone-set` or intended behaviour? Am I misunderstanding some implementation detail in TXT records or the RFC? > -- > Sadiq Saif > Bastetrix LLC >

4 roky, 10 měsíců

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users