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

by libor.peltan

Hi, thank you for contacting us with your issues with Knot DNS. However, you have hit wrong channel: knot-resolver-users mailing-list is intended for users of Knot Resolver. I'm sending this reply already to proper channel. You correctly pointed out that Knot did not delete old key after the delete-delay period. This seems to be an effect of an actually intentional, but perhaps tricky feature: Knot postpones this (relatively unnecessary) key deletion until next signing process. The point is, that initializing the whole "signing machinery" just in order to purge a deleted (marked as such) key might be an overkill (mostly on configurations with many many zones). You can see the next planned singing event when calling `knotc zone-status` or when inspecting the logfile for logs of the previous signing event. Please let me know if the deleted key disappears once the zone is re-signed. I guess it might take up to a week, since this long it takes between RRSIGs re-creation according to your configuration. If you need to delete the key immediately, you can use keymgr utility, or it might be also done with `knotc zone-keys-load` (basically triggering the zone signing process out of schedule). Thank you, Libor

2 roky, 10 měsíců

1
0
0 0

Knot DNS 3.1.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.9! It's a maintenance version with some fixes and improvements. Please note that 3.2.0 will be released in two weeks and 3.0 will no longer be officially supported. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.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

2 roky, 10 měsíců

1
0
0 0

db.storage

by Thomas

Hi, my knot installation (3.0.5) gives me this notice: notice: config, non-default 'template[default].storage' detected, please configure also 'db.storage' to avoid compatibility issues with future versions I have searched the docs to find out what I have to do, but did not find any specific information. Can you give me a hint what needs to be done here? Thanks a lot, Thomas

2 roky, 12 měsíců

2
1
0 0

keymgr del-all-old not only for offline KSK?

by Jan-Piet Mens

The documentation for `keymgr' says that the subcommand `del-all-old' is related to offline KSK, but it also seems to work for online KSK. Moments ago I had the following keys of which e381* had just been marked as removed: $ keymgr -c knot.conf tm list -b iso e381198aea254a1dbceb3c5b153cbefaa98c959a 31943 KSK ECDSAP256SHA256 publish=2022-05-12T11:43:56Z ready=2022-05-12T11:43:56Z active=2022-05-12T11:43:56Z retire=2022-05-12T12:35:42Z revoke=2022-05-12T12:33:42Z remove=2022-05-12T12:37:42Z d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256 publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256 publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z $ keymgr -c knot.conf tm del-all-old OK $ keymgr -c knot.conf tm list -b iso d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256 publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256 publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z and the PEM key file has also been removed. Is this to be expected? Would it be a good idea to add a note to the documentation clarifying this? Best regards, -JP

3 roky, 1 měsíc

2
2
0 0

manual KSK and automatic ZSK rollovers

by Jan-Piet Mens

Hello, I'd like to be able to do automatic ZSK and manual KSK rollovers. Basically the KSK should have an endless validity but I might want to roll it with (manually-trigerred) RFC 5011 semantics. It it permissible to have a policy such as shown below and then explicitly use `keymgr' commands to generate new keys and set `revoke', `retire' and `remove' timers on the older key? Testing indicates that it works as desired, I'm just unsure whether key manipulation is permitted. policy: - id: autoHSM keystore: pemstore single-type-signing: off manual: off ksk-shared: off ksk-lifetime: 0 zsk-lifetime: 30d cds-cdnskey-publish: rollover Thank you, -JP

3 roky, 1 měsíc

2
2
0 0

keymgr: list output in JSON?

by Jan-Piet Mens

Hello, keymgr(8) lists keys in plain text which is fine for processing with awk(1) et.al. Are there any plans to make it output JSON? I'm thinking along the lines of making parsing future-proof: [ { "id": "a982d72174a48a3ef083a97e5aae02cc47f58762", "ksk": true, "zsk": false, "key_tag": 61676, "algo": 8, "size": 2048, "public-only": false, "pre-active": 0, "publish": 1652161461, "ready": 1652161581, "active": 1652161642, "retire-active": 1652168902, "retire": 0, "post-active": 0, "revoke": 0, "remove": 1652168962 } ] keymgr_list_keys() calls either of print_key_full() / print_key_brief() to do the work, and I think it would be quite easy to add support for JSON. Is this something I should make happen? -JP

3 roky, 1 měsíc

2
2
0 0

Importing KSK/ZSK from HSM/PKCS#11 and rolling thereafter

by Jan-Piet Mens

Hello, I need to migrate away from an HSM-backed OpenDNSSEC installation which uses a Thales nCipher for key storage and am experimenting with Knot DNS 3.1.8 (on CentOS 7, FWIW). I've compiled Knot, and it is able to access said HSM via PKCS#11. I have configured a zone with a manual policy. policy: - id: manualHSM keystore: thales single-type-signing: on manual: on After importing keys from the HSM with `keymgr import-kcs11', knotd launches and signs the zone with KSK/ZSK as expected. What I would then like to have happen is to have periodic ZSK rollovers as well as periodic KSK rollovers. In order to accomplish this I have changed the zone's policy to policy: - id: autoHSM keystore: thales single-type-signing: off manual: off algorithm: rsasha256 ksk-size: 2048 zsk-size: 1024 zone-max-ttl: 60 dnskey-ttl: 60 propagation-delay: 60 nsec3: on nsec3-iterations: 0 nsec3-salt-length: 0 nsec3-salt-lifetime: 0 ksk-lifetime: 7200 zsk-lifetime: 3600 A restart of knotd then begins by creating a new ZSK and rolling it, and the KSK is rolled automatically after 7200 seconds. (These timers are for testing only.) So far no complaints whatsoever -- this is working exactly as I had hoped it would. I am assuming that it is permissible to change a zone's policy in flight. What I'd like is confirmation that the KSK roll will actually never occur immediately, but only after a first period has elapsed. Can I rely on this behavior, i.e. that the first KSK roll will occur only after a first `ksk-lifetime' period? Best regards, -JP

3 roky, 1 měsíc

2
1
0 0

Knot DNS 3.1.8 and 3.0.11 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.8 and 3.0.11! Both versions fix quite a serious bug in the TSIG processing when the server can crash if the TSIG is malformed. If you don't use TSIG, you are not affected. Special thanks go to 0x34d for finding this bug! In addition to some other fixes, the 3.1.8 version introduces a new automatic ACL mode that can help simplify complex configurations. This mode is disabled by default! Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.8/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.11/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, 1 měsíc

1
0
0 0

public-only key makes DNSSEC signing fail

by Thomas

Hi, for the transition of a TLD I need to import the current providers KSK into my zone. I use the "keymgr import-pub" command for this. I have done that a few times in the past and it worked very well. I have now installed the most current version of Knot (3.0.10) and did the same procedure. But after importing the KSK the zone can't be signed anymore. It seems like Knot doesn't recognize that this imported key is a "public-only" key. Knot throws an error and complains that the private key could not be loaded. The zone's keys (.example) before the import of the KSK: # keymgr example list 0b94a3f9fef3ae531fc5ee1334ddd2876db7cd9a ksk=yes zsk=no tag=12595 algorithm=7 size=2048 public-only=no pre-active=0 publish=1650495677 ready=1650495677 active=1650659051 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 13cc082655ddf7160787ef945ad7edb6406bb70e ksk=no zsk=yes tag=05477 algorithm=7 size=1024 public-only=no pre-active=0 publish=1650495677 ready=0 active=1650495677 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 Imported the KSK with the following command: # keymgr example import-pub /etc/knot/public.key 2c135e77b7f48475a837ad0d28a9459f0e7ce621 OK The zone's keys (.example) after the import of the KSK: # keymgr example list 0b94a3f9fef3ae531fc5ee1334ddd2876db7cd9a ksk=yes zsk=no tag=12595 algorithm=7 size=2048 public-only=no pre-active=0 publish=1650495677 ready=1650495677 active=1650659051 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 13cc082655ddf7160787ef945ad7edb6406bb70e ksk=no zsk=yes tag=05477 algorithm=7 size=1024 public-only=no pre-active=0 publish=1650495677 ready=0 active=1650495677 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 2c135e77b7f48475a837ad0d28a9459f0e7ce621 ksk=yes zsk=no tag=35421 algorithm=7 size=2048 public-only=yes pre-active=0 publish=1650660072 ready=0 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 The imported key (tag 35421) has the flag "public-only=yes", as expected. But when I now sign the zone, the log shows this errors: Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] control, received command 'zone-sign' Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, dropping previous signatures, re-signing zone Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag 12595, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag 35421, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active+ Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag 5477, algorithm RSASHA1_NSEC3_SHA1, public, active Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] DNSSEC, failed to load private keys (not exists) Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] DNSSEC, failed to load keys (not exists) Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, next signing at 2022-04-22T21:43:24+0000 Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] zone event 'DNSSEC re-sign' failed (not exists) The imported key should not have the "active" flag: info: [example.] DNSSEC, key, tag 35421, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active+ It seems to me that the imported key is not seen as a "public-only" key anymore and therefore Knot is looking for the corresponding private key, which of course fails. I attached an strace output, with the signing operation. But that doesn't seem to be helpful because the signing command itself doesn't fail. Thanks, Thomas

3 roky, 1 měsíc

3
4
0 0

Knot DNS 3.1.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.7! This version primarily fixes incomplete implementation of the Offline KSK signing mode in the IXFR and DDNS processing. Please note that the online signing still doesn't support Offline KSK! Also various fixes and improvements regarding catalog zones are included. Our donation page newly accepts EUR and USD: https://donations.nic.cz/donate/?project=knot-dns Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.7/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

3 roky, 2 měsíce

1
0
0 0

'remote' semantics

by Matthew Pounsett

Just to clarify some semantics of the config format. Is each individual 'remote' ID considered to be a single server, regardless of the number of addresses it has? For the notify case, it looks like knot will send to each address in a remote ID in serial, and stop as soon as one replies. That suggests the above semantics, but I wanted to make sure I'm interpreting this behaviour correctly before I complicate my config by adding a lot more remotes. I am currently treating each remote as an organisation, lumping all of that organisation's servers together under a single ID.

3 roky, 3 měsíce

5
5
0 0

Monitoring for "waiting for DS submission"

by Matthew Pounsett

I'm trying to find a way to poll for any zones where knot is currently waiting on DS submission to the parent. I'm aware of the structured logging sent to systemd-journald but I see this as not particularly useful for monitoring, as the event could be missed by a dead daemon, bug in code, etc. I'd much prefer to be able to actively monitor states by polling. It looks like the only way I can do that right now is to run `keymgr list` and analyze the output. If I'm reading the documentation correctly, all I need to look for is a key that is `ksk=yes`, `ready != 0`, and `active = 0`. Does that seem correct? Am I missing something simpler? :)

3 roky, 4 měsíce

5
5
0 0

Algorithm roll enhancement

by Matthew Pounsett

I have found a situation where I think the Knot behaviour around algorithm rolls could be better. It's one of those "prevent the user from hurting themselves" situations, in which I would have hurt myself if this had involved anything other than an old, unused zone. :) The suggestion is a simple one: when doing an automated algorithm roll, the KSK submission check should remain negative until the parental DS set exactly matches the set requested by the published CDS set (substitute DNSKEY/CDNSKEY as appropriate). In a situation where CDS scanning is not being done by my parent, I slipped up and only added the new DS record to the parent, leaving the old algorithm's DS record also present. Knot did its submission check, saw the new DS record, and happily continued on with the algorithm roll. This eventually led to a situation that was in violation of RFC 6840 § 5.11 [0]: A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. I ended up with a situation where I had the new and old DS, but only the new DNSKEY [1]. This seems like a situation that could be avoided by extending the logic of the KSK submission check. In addition to saving users from themselves, it would also help if a situation occurred where the parent had a bug in their CDS processing implementation and failed to remove the old DS. [0]: <https://datatracker.ietf.org/doc/html/rfc6840#section-5.11> [1]: <https://dnsviz.net/d/dns-oarc.org/Yg7ZDw/dnssec/>

3 roky, 4 měsíce

2
2
0 0

Start Warnings

by Günther J. Niederwimmer

Hello, what is wrong in my policy section? I can't found any in the docs ? Have I missing Parameters or .............. The Warning is, Feb 13 12:33:05 dns1 knotd[184636]: warning: config, policy[rsa2k].nsec3- iterations defaults to 10, since version 3.2 the default becomes 0 Feb 13 12:33:05 dns1 knotd[184636]: warning: config, policy[ececc1].nsec3- iterations defaults to 10, since version 3.2 the default becomes 0 Feb 13 12:33:05 dns1 knotd[184636]: 2022-02-13T12:33:05+0100 warning: config, policy[rsa2k].nsec3-iterations defaults to 10, since version 3.2 the default becomes 0 Feb 13 12:33:05 dns1 knotd[184636]: 2022-02-13T12:33:05+0100 warning: config, policy[ececc1].nsec3-iterations defaults to 10, since version 3.2 the default becomes 0 Feb 13 12:33:05 dns1 knotd[184636]: 2022-02-13T12:33:05+0100 warning: config, policy[ececc2].nsec3-iterations defaults to 10, since version 3.2 the default becomes 0 Feb 13 12:33:05 dns1 knotd[184636]: warning: config, policy[ececc2].nsec3- iterations defaults to 10, since version 3.2 the default becomes 0 my policy, policy: - id: rsa2k algorithm: RSASHA256 ksk-size: 4096 zsk-size: 2048 nsec3: on - id: ececc1 algorithm: ECDSAP256SHA256 nsec3: on - id: ececc2 algorithm: ecdsap384sha384 nsec3: on -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

3 roky, 4 měsíce

2
1
0 0

Memory usage sky rockets

by Einar Bjarni Halldórsson

Hi, I've got a staging environment running, with two signers signing a staging version of the .is zone (~115k records). The staging servers are configured with 2 GB RAM and 4 CPU cores, running on FreeBSD 12.2. We've experienced that knot crashes because the server runs out of memory. The zone is configured with: zonefile-sync: -1 zonefile-load: difference-no-serial journal-content: all One of the signers, after an hour of running is showing 215 MB resident memory used. The other signer, that's been running for a whole day is showing 1582 MB resident memory. I attached a screenshot showing the amount of memory used over a period of time, and the graph shows that the amount of memory used very suddenly increases. I assume the servers are using a lot of memory for the journals, but I'd like to understand why the sudden increase in used memory, and what to expect about needed memory? .einar

3 roky, 4 měsíce

3
3
0 0

DNS cookie not configured correctly?

by J. Echter

Hi, i have knot dns setup with dns cookie module enabled but if i check with dnsviz.net i always get: The server appears to support DNS cookies but did not return a COOKIE option. Relevant parts of my knot.conf: template: - id: default storage: "/var/lib/knot" dnssec-signing: on dnssec-policy: rsa2048 global-module: [ "mod-cookies", "mod-rrl/default" ] mod-rrl: - id: default rate-limit: 200 slip: 2 - domain: mydomain.de file: "/etc/knot/zones/mydomain.de.zone" notify: secondary acl: acl_secondary zonefile-load: difference I thought about maybe it's the slip: 2, but that didn't change anything if set to 1 Do you guys see anything obvious causing this "issue"? Thanks for your time Juergen

3 roky, 4 měsíce

5
9
0 0

Knot DNS 3.1.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.6! It's mostly a maintenance version with some new features for those who need them. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.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

3 roky, 4 měsíce

1
0
0 0

zonefile-sync and strange SOA serial

by Einar Bjarni Halldórsson

Hi, For many months now, we've been preparing new signers for our internal zones and eventually .is. We've got the first of our test zones live on the production signers, but some things are troubling us. This is the config we're using for zones: template: - id: default semantic-checks: on storage: "/usr/local/etc/knot" file: "zones/unsigned/%s/%s-soa" serial-policy: dateserial zonefile-sync: -1 zonefile-load: difference-no-serial journal-content: all notify: hidden_primary acl: hidden_primary_acl policy: - id: isnic algorithm: RSASHA256 ksk-size: 4096 zsk-size: 2048 ksk-lifetime: 365d zsk-lifetime: 30d propagation-delay: 1h rrsig-lifetime: 14d rrsig-refresh: 7d rrsig-pre-refresh: 1h --- zones/unsigned is stored in a git repo and changes are deployed by an ansible playbook that checks out the latest revision and reloads the zones. Someone pointed out that zonefile-load: difference-no-serial was risky for something as important as a TLD, but what is the alternative when doing automatic DNSSEC signing on zone data from git? Also, we turned off zonefile-sync, since our current deployment script overwrites the zonefile. Is there a way to load initial zone data from one file, but do zonefile-sync to another? We're seeing this in our logs: Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] zone file parsed, serial corrected 1970010100 -> 2022012000 Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] loaded, serial 2022011900 -> 2022012000 -> 2022011900, 3830 bytes Any idea what's happening on the second line? It's like knot wants to increment the serial, but then changes it's mind :) .einar

3 roky, 5 měsíců

3
7
0 0

Knot DNS 3.1.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.5! - This version brings some new features useful for operators of many zones and fixes a few bugs. - Our Docker images are newly build with some hardening flags set, enabled dnstap in kdig, and with fast zone parser enabled. - Please note that the expiration of the GPG key for our Debian repositories (https://deb.knot-dns.cz/apt.gpg) has been extended: ``` pub rsa4096/0x8A0EFB02C84B1E9B 2019-03-14 [SC] [expires: 2026-11-11] Key fingerprint = 8C0A 90B7 DE9C AC3B 4A7B D579 8A0E FB02 C84B 1E9B uid Knot DNS Packaging <knot-dns(a)labs.nic.cz> ``` Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.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

3 roky, 6 měsíců

1
0
0 0

RSASHA1 --> RSASHA256 question

by Chris

OK I recently decided to change the algorithm on all our domains from RSASHA1 to RSASHA256. Before making the change globally; I experimented with one domain. I did so by adding a new policy: CURRENT policy: - id: rsa1 algorithm: RSASHA1 ksk-size: 2048 zsk-size: 1024 dnskey-ttl: 43200 zsk-lifetime: 30d ksk-lifetime: 365d NEW (PROPOSED) policy: - id: rsa2 algorithm: RSASHA256 ksk-size: 2048 zsk-size: 2048 dnskey-ttl: 43200 zsk-lifetime: 30d ksk-lifetime: 365d DOMAIN TESTED ON # a-domain - domain: a-domain file: "masters/a-domain" zonefile-load: difference dnssec-signing: on # dnssec-policy: rsa1 dnssec-policy: rsa2 semantic-checks: on serial-policy: dateserial acl: [locals, remotes01, remotes03, remotes04] To preform the intended change. I first set the the current keys on the test domain to: retire=+1hr I then added the new policy and assigned it to the testing domain. Then restarted the knot service. After the hour and some had passed. I performed a keymgr a-domain del-all-old which removed the old algorithm (RSASHA1) keys. But I think this was a mistake. How would I best make this change? Is it enough to simply change algorithm: and knot will just do the right thing? Thanks! -- Chris

3 roky, 6 měsíců

4
6
0 0

Migrate signed zone to knot

by Einar Bjarni Halldórsson

Hi, We're preparing to migrate our zones from OpenDNSSEC 1.4 to Knot DNS 3.1 (and eventually the .is zone). We've already migrated one unsigned zone to the new signers, but next on the list is first currently signed zone. We're going to migrate the zone by doing a key rollover, so we'll add DNSKEY records for the new keys to the zone on the old signer and vice versa. While we're migrating the zone we have to stop automatic key rollovers, and I planned to create a new policy 'dnssec_freeze' with `manual: on` and apply it to zones during migration. Am I correct that this will stop all automatic key rolloveres, but keep the signatures updated? The the migration is complete, DS records and delegations have been updated etc., I'll change the policy to an automatic policy. Will knot seamlessly start automatically rolling over keys according to the new policy? .einar

3 roky, 6 měsíců

3
4
0 0

Failure importing a public key from BIND

by Luveh Keraph

I am trying to import a public key generated by BIND into Knot, when using the SoftHSM2 key store. I have the following pieces of information: In my knot.conf file: policy: - id: SoftHSMRSAPolicy algorithm: RSASHA256 ksk-size: 2048 zsk-size: 2048 ksk-lifetime: 7h zsk-lifetime: 6h dnskey-ttl: 12s zone-max-ttl: 15s keystore: SoftHSM zone: - domain: 00.mydomain.com storage: /srv/knot file: db.mydomain00 dnssec-signing: on dnssec-policy: SoftHSMRSAPolicy The public key is in a file named pubkey, and has the following contents: ; This is a zone-signing key, keyid 14694, for 00.mydomain.com. ; Created: 20211109192137 (Tue Nov 9 12:21:37 2021) ; Publish: 20211109192137 (Tue Nov 9 12:21:37 2021) ; Activate: 20211109192137 (Tue Nov 9 12:21:37 2021) 00.mydomain.com. IN DNSKEY 256 3 8 AwEAAd1XmDMiF4/WWW+lneSg2hScxQl TJHU/cIyBnDJDnW3MFkuyR7e+y3UqZScTXz5tfcGkDYGpqFqZ3+RgyN7A3ZAC3RsayivUuE9lec25IT97 jPZaTsHUjalDQjXkBhCIHBb79vVsz0SMZOeez78qzhRtpdkFYVNRcAW4EZVgdQAdiuJGeDEuxsaTkRnLwujnaqURyAzevqfQfjz319CPsYr4tN4K9nu2Fc0Sh+b5pdM6ejRieLnUUgZpuefRfgsSHJQErNe FevdtihLpq93r E5OARwmK0c4vyzgpmREloMJlwV+lrZdlKqZnnIZIXgkD+59Tjh0XZ72exdvonun4uG8= (The DNSKEY record is in a single line.) The command I am using to import this key is # ./keymgr 00.mydomain.com. import-pub ./pubkey This spins for a few seconds and then prints out: Error: file error Any ideas as to what it is that I am doing wrong? The command that I am invoking to import this public key is the following:

3 roky, 7 měsíců

1
2
0 0

KSK rollover using alternate keystore

by Bastien Durel

Hello, Is there a way to perform a key rollover using a new keystore for the new KSK ? I'd like to switch from KASP DB pem files to HSM-backed keys I've tried to make a new zone test.test, using the default KASP, and then change the storage to HSM, but this leads to 'not exists' errors at reload : nov. 09 11:36:39 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, key, tag 4164, algorithm ECDSAP384SHA384, KSK, public, ready, active+ nov. 09 11:36:39 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, key, tag 15855, algorithm ECDSAP384SHA384, public, active nov. 09 11:36:39 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:36:39 arrakeen knotd[2144032]: 2021-11-09T11:36:39+0100 error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:36:39 arrakeen knotd[2144032]: 2021-11-09T11:36:39+0100 error: [test.test.] DNSSEC, failed to load keys (not exists) nov. 09 11:36:39 arrakeen knotd[2144032]: 2021-11-09T11:36:39+0100 error: [test.test.] zone event 'DNSSEC re-sign' failed (not exists) nov. 09 11:36:39 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load keys (not exists) nov. 09 11:36:39 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, next signing at 2021-11-09T12:36:39+0100 nov. 09 11:36:39 arrakeen knotd[2144032]: error: [test.test.] zone event 'DNSSEC re-sign' failed (not exists) nov. 09 11:36:40 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:36:40 arrakeen knotd[2144032]: 2021-11-09T11:36:40+0100 error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:36:40 arrakeen knotd[2144032]: 2021-11-09T11:36:40+0100 error: [test.test.] zone event 'DS check' failed (not exists) nov. 09 11:36:40 arrakeen knotd[2144032]: error: [test.test.] zone event 'DS check' failed (not exists) policy: - id: default algorithm: ECDSAP384SHA384 ksk-size: 384 zsk-size: 384 nsec3: on nsec3-salt-lifetime: 4d ksk-submission: validating-resolver - id: default_hsm keystore: hsmkey algorithm: ECDSAP384SHA384 ksk-size: 384 zsk-size: 384 nsec3: on nsec3-salt-lifetime: 4d ksk-submission: validating-resolver zone: - domain: "test.test." file: "test.test" # dnssec-policy: default dnssec-policy: default_hsm keymgr test.test list -> b63796b44dcfed7392639aec6fb4a7ca9ca446dd ksk=yes zsk=no tag=04164 algorithm=14 size=384 public-only=no pre-active=0 publish=1636454163 ready=1636454163 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 fdd7822a5498d6eda619092f01dffa41c285d00e ksk=no zsk=yes tag=15855 algorithm=14 size=384 public-only=no pre-active=0 publish=1636454163 ready=0 active=1636454163 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 knotc zone-key-rollover test.test ksk -> nov. 09 11:39:58 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, key, tag 4164, algorithm ECDSAP384SHA384, KSK, public, ready, active+ nov. 09 11:39:58 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, key, tag 15855, algorithm ECDSAP384SHA384, public, active nov. 09 11:39:58 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, key, tag 43192, algorithm ECDSAP384SHA384, KSK, public, active+ nov. 09 11:39:58 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: 2021-11-09T11:39:58+0100 error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: 2021-11-09T11:39:58+0100 error: [test.test.] DNSSEC, failed to load keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: info: [test.test.] DNSSEC, next signing at 2021-11-09T12:39:51+0100 nov. 09 11:39:58 arrakeen knotd[2144032]: 2021-11-09T11:39:58+0100 error: [test.test.] zone event 'DNSSEC re-sign' failed (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: error: [test.test.] zone event 'DNSSEC re-sign' failed (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: 2021-11-09T11:39:58+0100 error: [test.test.] DNSSEC, failed to load private keys (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: 2021-11-09T11:39:58+0100 error: [test.test.] zone event 'DS check' failed (not exists) nov. 09 11:39:58 arrakeen knotd[2144032]: error: [test.test.] zone event 'DS check' failed (not exists) keymgr test.test list -> b63796b44dcfed7392639aec6fb4a7ca9ca446dd ksk=yes zsk=no tag=04164 algorithm=14 size=384 public-only=no pre-active=0 publish=1636454163 ready=1636454163 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 fc4c2a4b6b43d0428a68b4e130232d261a5ee189 ksk=yes zsk=no tag=43192 algorithm=14 size=384 public-only=no pre-active=0 publish=1636454391 ready=0 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 fdd7822a5498d6eda619092f01dffa41c285d00e ksk=no zsk=yes tag=15855 algorithm=14 size=384 public-only=no pre-active=0 publish=1636454163 ready=0 active=1636454163 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 The DNSKEY was not changed when the new ksk was introduced, so I guess it's not visible : dig +dnssec @ns.geekwu.org dnskey test.test test.test. 86400 IN DNSKEY 256 3 14 f06gYOe4uyphbGuBAWvDFnkQDY8+3SrM4e8k9o86AcuD3OL14chmn+34 np03/qFI5HCxG688v+Krnm8MbOc+eEaCBHisJpWo8j9+ot/ct2rfJln3 96rNcQXCzUNzDaSZ test.test. 86400 IN DNSKEY 257 3 14 7qUXsDfMWc8D6rp9Rvt2QOORZi7/pTEclBawadkauau3xA9iTBwOsZ0G 0/6/O9PqrdQBrHP2K4sODOLSI685sOz5lZGRaUqPkuiZe2Gj1OwXsUz1 495W+GmnoAz26YHh test.test. 86400 IN RRSIG DNSKEY 14 2 86400 20211123103603 20211109090603 4164 test.test. 79XNugNJVXJktk7EpIf+0JlJUGDRrxRtbqKQqZouY1vViLn2PY+SVxPd msnQl5EEX9Cp3dHvAw1xOTYjupnYHj5FlA14g9tRPxD97jRylrXgg0rW TLU4he2ujC1rhcS4 Is this kind of rollover/keystore switch supported ? Thanks, -- Bastien

3 roky, 7 měsíců

2
4
0 0

Data saved into the KASP

by Luveh Keraph

I have been trying to get a better understanding concerning the information Knot stores in its KASP. Knot adds new key information into the KASP by means of the kasp_db_add_key function. One of the arguments to this function is a pointer to a key_params_t structure, one of whose members is called is_pub_only. This would seem to imply that the KASP may contain information about key pairs such that only the public component of the key pair is available to Knot. Under what set of circumstances would such a key be stored in the KASP? Since they are used for signing RRs, any KSKs and ZSKs in the KASP have to be complete, in that both the private and the public components are available to Knot (I know that the private component itself is not present in the KASP, but that's OK). A KASP key for which the private component is not available could be used for verifying signatures - but that's not something that Knot does, right? So, under what set circumstances would Knot add a key to the KASP such that the is_pub_only member is set to true?

3 roky, 7 měsíců

2
2
0 0

dnsbenchmark issues

by Rhonda D'Vine

Hi, I'm trying to dig into the dns-benchmark tools, but am running into a few issues. I realized that it requires some specific settings, like /home/dnsbench seems to be hardcoded for the logs somehow, and it being run as root, but now I see a lot of syntax error message flooding me, with lines in between about that hostname is an invalid number: standard_in) 2: syntax error (standard_in) 2: syntax error (standard_in) 2: syntax error (standard_in) 2: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error /tmp/benchmark-1636019360/modules/responses.sh: line 170: printf: hostname: invalid number knot2 ssh: % answered for Could q/s, not B avg (resolve a/s, 0 B avg) (repeated output) Anyone else using the tools and potentially can give me a prod in the right direction? We'd like to check how knot performs in our environment with the systems we have at hand. Thanks in advance for any advice, Rhonda

3 roky, 7 měsíců

2
1
0 0

Knot DNS 3.1.4 and 3.0.10 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.4 and 3.0.10! These versions primarily fixes a very old bug which can cause the server to crash if a query requests EDNS0/NSID option. Special thanks go to Romain Labolle! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.4/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.10/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, 7 měsíců

1
0
0 0

Setting up zone file MX record to external mail server

by Dirk Segers

Hi, we've had knot in use for years now and are still using version 1.6.7. I We've recently migrated e-mail to exchange online. I've been asked to update the MX record in the zone to point to mail.protection.outlook.com. I initially tried to simply replace the current value by mail.protection.outlook.com but then the name of the zone is added to the value. This is not a valid record. I see no way to update the MX record to this value. Any suggestions? Thanks in advance for the feedback. Kind regards, Dirk

3 roky, 7 měsíců

2
2
0 0

Changing DNS Operators for DNSSEC signed Zones

by Luveh Keraph

There is an Internet draft ( https://datatracker.ietf.org/doc/html/draft-koch-dnsop-dnssec-operator-chan…) that describes a mechanism to facilitate the operation consisting of changing the DNS delegation for a signed DNS zone. Since this is a draft, I do not expect for Knot to provide support for it already (in fact, I know it does not, for it involves signing a DNSKEY RR, which Knot does not do) but I wonder whether this is something that is in Knot's roadmap?

3 roky, 7 měsíců

2
1
0 0

Knot DNS 3.1.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.3! This is mostly a bugfix version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.3/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, 8 měsíců

1
0
0 0

Newbie Questions: how-to simultaneously DNSsec-sign a zone with two different algorithms

by Pirawat WATANAPONGSE

Dear Guru(s), If the following questions have already been asked, I do apologize and would very much appreciate the pointers to where I can read the answer(s). I am currently ‘running’ a DNSsec-signed zone using Alg-8 [RSA/SHA2-256]. However, I would very much like to DNSsec-sign and publish my zone with two different algorithms (say, Alg-8 [RSA/SHA2-256] + Alg-13 [ECDSA-P256/SHA2-256]) *simultaneously*, in case the client-validators out there cannot process one algorithm or the other (never mind that they both are the ‘MUST’ in RFC 8624). It also is an opportunity to train myself in case I need to ‘add’ the third one (say, Alg-15 [ED25519]) or ‘migrate’ to the Alg-13 + Alg-15 combination in the future. Background Information: 1. I have a ‘hidden server’ acting as ‘The Signer’. 2. ‘The Signer’ feeds the already-signed zone to the visible ‘Primary Server’. 3. The ‘Primary Server’, in turn, feeds all other ‘Secondary Servers’, some of which are not under my control. 4. Unfortunately, currently none of the above servers is a Knot, but I am switching The Signer to Knot. My questions are: 5. What will be the correct configuration for The Knot Signer? I don’t mind maintaining two completely separated ‘Signed Trees’ of the same zone, unless cross-signing (the keys) between algorithms is the best practice. 6. Will there be any special configuration for the ‘Primary/Secondary Servers’? If so, I will then need to inform admins of the servers outside my control. Thank you for any help you can offer, both on and off the mailing list. Gratefully, Pirawat. -- _/_/ _/_/ _/_/ _/_/ Assist.Prof. Pirawat WATANAPONGSE, Ph.D. _/_/ _/_/ _/_/ _/_/ Department of Computer Engineering _/_/ _/_/ _/_/ _/_/ Kasetsart University, Bangkhen (Main) Campus _/_/_/_/ _/_/ _/_/ Bangkok 10900, THAILAND _/_/_/_/ _/_/ _/_/ eMail: Pirawat.W(a)ku.th or Pirawat.W(a)ku.ac.th _/_/ _/_/ _/_/ _/_/ Tel: +66 2 797 0999 extension 1417 _/_/ _/_/ _/_/_/_/_/_/ Fax: +66 2 579 6245 _/_/ _/_/ _/_/_/_/ http://www.cpe.ku.ac.th/~pw/

3 roky, 8 měsíců

2
1
0 0

Zone Transfers fail if server has multiple IPs

by Schindler, Stefan

Hi all My server recently gained two more IPv6 & IPv4 addresses. That broke my transfer setup because for some reason knot is not using the address it is binding to for the requests but some of the other ones. Can I configure that? Best, Stefan

3 roky, 8 měsíců

2
1
0 0

Fixing broken AXFR zone transfer with knot slave and dnsmasq as master

by Daniel Gröber

Hi knot-dns-users, I have knotd as a slave for a dnsmasq and I'm seeing fallback from IXFR to AXFR not working properly. TLDR: I have patches and while I'm waiting for my gitlab access to be allowed to submit MRs I wrote this email :) What happens is that the first AXFR goes through and everything looks happy dandy, but if I restart dnsmasq to force a SOA update knot tries to do an IXFR which fails and doesn't fall back to AXFR. First the AXFR works: knotd: info: [myzone.example.net.] AXFR, incoming, remote 2001:db8::2@53, started knotd: [myzone.example.net.] AXFR, incoming, remote 2001:db8::2@53, finished, 0.00 seconds, 1 messages, 870 bytes knotd: info: [myzone.example.net.] refresh, remote 2001:db8::2@53, zone updated, 0.00 seconds, serial none -> 1632501860 when I restart dnsmasq to force a SOA update, the following IXFR fails: knotd: info: [myzone.example.net.] refresh, remote 2001:db8::2@53, remote serial 1632503553, zone is outdated knotd: warning: [myzone.example.net.] IXFR, incoming, remote 2001:db8::2@53, malformed response SOA knotd: warning: [myzone.example.net.] refresh, remote myremote-dnsmasq not usable knotd: error: [myzone.example.net.] refresh, failed (no usable master) I've been sitting on this bug for a while now since I couldn't make heads or tails of what the code is doing but my third try at debugging this finally worked out. If we look at the fallback logic in src/knot/events/handlers/refresh.c, in try_refresh(), it revolves around this kind of gnarly while statement: // while loop runs 0x or 1x; IXFR to AXFR failover while (ret = knot_requestor_exec(&requestor, req, timeout), ret = (data.ret == KNOT_EOK ? ret : data.ret), ixfr_error_failover(ret) && data.xfr_type == XFR_TYPE_IXFR && data.state != STATE_SOA_QUERY) { If the while loop is taken fallback to AXFR happens otherwise not. Attaching gdb to my running knot I can see that in my failure case all conditionals except `data.xfr_type == _IXFR` are true but xfr_type is in fact not _IXFR but _ERROR. As far as I can tell the only reason for this check is to terminate the loop once the fallback to AXFR has happened as `_AXFR != _IXFR`. I shall elaborate on this below. So where does xfr_type become _ERROR? In my case determine_xfr_type() returns _ERROR due to the first check, `answer->count < 1` and ixfr_consume assigns this to xfr_type which in turn happens as part of the knot_requestor_exec() call in the while. So how does the fallback usually happen then? Well ixfr_consume checks the RCODE and fails immediately, without modifying xfr_type that is, if it's no good. That way the while statement will run the fallback code. // Check RCODE if (knot_pkt_ext_rcode(pkt) != KNOT_RCODE_NOERROR) { [...] return KNOT_STATE_FAIL; } I'm not really familliar with the DNS RFCs so I'm not sure if dnsmasq is supposed to repond with an error to unsupported query types but from some quick experiments against prominent authorative DNS servers around the internet it does seem like it's behaviour, reponding with NOERROR, an empty answer section and a SOA in authority is what everyone else does too when they get an rrtype they don't care for. Why now would the fallback logic not want to fallback to AXFR in this case? I can't think of a reason it would really want to do that. Like I said above it seems to me the only reason for the _IXFR check in the while is to make sure the loop terminates. Though IMO this is a very roundabout way of doing that and just using an if would be cleaner to boot. Anyway, let's do some git archeology on that point. The first related commit I can find is commit 39e447e4590c7d5fc12a5c05ed11a45fd6561dda Author: Libor Peltan <libcha.p(a)gmail.com> Date: Wed Oct 17 10:08:53 2018 +0200 ixfr/axfr: failover even when the ixfr reply wasn't valid before: ixfr falls back to axfr only if valid, but negative reply, e.g. NOTAUTH, journal inconsistency.. after: ixfr falls back to axfr in any case ixfr fails, e.g. malformed reply packet This is the commit that introduced the while statement for the fallback in try_refresh. It looked like so back then: // while loop runs 0x or 1x; IXFR to AXFR failover while ((ret = knot_requestor_exec(&requestor, req, timeout)) != KNOT_EOK && data.xfr_type == XFR_TYPE_IXFR) { Much simpler, if knot_requestor_exec returns a failure and xfr_type is _IXFR the fallback to AXFR happens. Now what I don't understand is that from the commit message this fix sounds just like my issue. Dnsmasq sends back what knot considers an invalid reply so why didn't this fix my problem too? Weird. Looking further I find commit 5c1a5e28797f9c2eab1300247c052451ccd3be3e Author: Libor Peltan <libor.peltan(a)nic.cz> Date: Tue Jan 31 18:07:28 2017 +0100 XFR: proper handling of single-SOA first response message which introduced determine_xfr_type and the XFR_TYPE_ERROR distinction. If I build the commit just before that one a8237b1f8 xfr: separated functions consuming one rrset of [ai]xfr response and setup a config to reproduce my setup, then XFR against dnsmasq actually starts to work. Back at 5c1a5e287 things are broken with the "malformed SOA" message again. So we likely found the culprit. Ok so back at the bad commit 5c1a5e287 // IXFR to AXFR failover - if (data->is_ixfr && next == KNOT_STATE_FAIL) { + if (data->xfr_type == XFR_TYPE_IXFR && next == KNOT_STATE_FAIL) { This is what introduced the `xfr_type == _IXFR` check which later got moved from this if statement in transfer_consume() to the while loop in try_refresh() by 39e447e45. The check used to be just for is_ixfr which got initialized in refresh_begin to start with (in the good commit 5c1a5e287~1): if (data->soa) { data->state = STATE_SOA_QUERY; data->is_ixfr = true; } else { in bad commit 5c1a5e287: if (data->soa) { data->state = STATE_SOA_QUERY; data->xfr_type = XFR_TYPE_IXFR; data->initial_soa_copy = NULL; } else { and then got reset to false by the fallback code. So I'm pretty convinced at this point that 5c1a5e287 just messed up that logic and the specificity of the XFR_TYPE_IXFR check really is unintended. To fix this we simply replace that check with a counter that ensures the loop will run at most twice like so: --- a/src/knot/events/handlers/refresh.c +++ b/src/knot/events/handlers/refresh.c @@ -1188,12 +1188,12 @@ static int try_refresh(conf_t *conf, zone_t *zone, const conf_remote_t *master, int timeout = conf->cache.srv_tcp_remote_io_timeout; - int ret; + int ret, i; // while loop runs 0x or 1x; IXFR to AXFR failover while (ret = knot_requestor_exec(&requestor, req, timeout), ret = (data.ret == KNOT_EOK ? ret : data.ret), - ixfr_error_failover(ret) && data.xfr_type == XFR_TYPE_IXFR && + ixfr_error_failover(ret) && i++ <= 1 && data.state != STATE_SOA_QUERY) { REFRESH_LOG(LOG_WARNING, data.zone->name, data.remote, "fallback to AXFR (%s)", knot_strerror(ret)); --- Thoughts? Am I missing something this check is doing? --Daniel

3 roky, 8 měsíců

3
2
0 0

expiring/renewing dnssec keys

by mj

Hi, We're new in the dnssec field, and we hope we understand the basics, also thanks to the much appreciated help received through this list and through searching it's archives, thanks again! We would like to ask two more short questions, but first a we will explain how we currently understand things. Our dns domain is sub.company.com, and we will activate DNSSEC somewhere next week, by doing: - enable dnssec for the zone / reverse zone in knot.conf - restart knot - display the generated dnssec keys, using: > keymgr sub.company.com dnskey > keymgr sub.company.com ds (plus the reverse) - send the outputs of the above to the admins at company.com - after they have entered the keys in their dns, the world can check & verify our dnssec, and things are operational. - verify everything at https://dnssec-analyzer.verisignlabs.com/ Now the two questions. We have set in knot.conf: zsk-lifetime: 30d ksk-lifetime: 365d We understand that with the above config, monthly zsk key rollovers happen automatically "inside" knot, but the yearly rollover (ksk) needs to be manually propagated by us to the parent dns. (through for example secured email to the admins at company.com) Question one: Is there some kind of notification mechanism in knot, that reminds us (through email for example) that a ksk is about to expire, and keys need to be renewed at company.com dns? I cannot find such a function. Does it not exist? Or do we misunderstand something? It seems to be so vital. Question two: How unreasonable/insecure would it be to take a longer ksk lifetime than one year, let's say 10 years. With the idea that we can always manually renew keys earlier, in case we need to. Feedback on the above is welcome. We have scheduled a maintenance moment next week with the admins on company.com to send them the keys and activate dnssec. Thanks in advance for any feedback/pointers you can provide. Best regards, MJ

3 roky, 9 měsíců

5
12
0 0

EdDSA support over PKCS #11

by Luveh Keraph

I notice that knot 3.1 does not support EdDSA (22519 and 448) when using softhsm as a PKCS #11 backend. Since this is supported by knot when using the default cryptographic provider, and also by gnutls 3.6.0 (at least for the 25519 version) for release 3.6.0 and later, my guess is that this a limitation in softhsm itself. Could anybody in this forum with the necessary savvy please confirm (or not) this?

3 roky, 9 měsíců

2
6
0 0

KNOT Resolver DNS over TLS Error

by Günther J. Niederwimmer

Hello List, I would like to install KNOT-resolver, first test it with DNS over TLS, but that doesn't work? My system is an oracle Linux 8.4 I have a Letsencrypt certificate for this system and wanted to integrate it into kresd, but I get a GNUTLS error? Sep 22 18:27:30 bbs kresd[446005]: [tls ] gnutls_certificate_set_x509_key_file(/etc/letsencrypt/live/bbs.xxxx.xxxx/ fullchain_ecdsa.pem,/etc/pki/private/xxxx.xxxx_ec.key) failed: -64 (GNUTLS_E_FILE_ERROR) Sep 22 18:27:30 bbs kresd[446005]: [system] error while loading config: error occurred here (config filename:lineno is at the bottom, if config is involved):#012stack traceback:#012#011[C]: in function 'tls'#012#011/etc/knot- resolver/kresd.conf:24: in main chunk#012ERROR: Invalid argument (workdir '/ var/lib/knot-resolver') Sep 22 18:27:30 bbs systemd[1]: kresd(a)1.serbice.service: Main process exited, code=exited, status=1/FAILURE Does this not work with a Letsenkrypt certificate or I have another error in my configuration My config -- SPDX-License-Identifier: CC0-1.0 -- vim:syntax=lua:set ts=4 sw=4: -- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/ -- Uncomment this only if you need to debug problems -- verbose(true) log_level('debug') -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) --net.listen('127.0.0.1', 443, { kind = 'doh2' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) --net.listen('::1', 443, { kind = 'doh2' }) net.listen('xxx.xxx.xxx.1', 53, { kind = 'dns' }) net.listen('xxx.xxx.xxx.1', 853, { kind = 'tls' }) net.listen('192.168.100.200', 53, { kind = 'dns' }) net.listen('192.168.100.200', 853, { kind = 'tls' }) net.listen('xxx:xxxx:xxxx:xxx::200', 53, { kind = 'dns' }) net.listen('xxx:xxxx:xxxx:xxx::200', 853, { kind = 'tls' }) -- DNS over TLS net.tls("/etc/letsencrypt/live/bbs.xxxx.xxx/fullchain_ecdsa.pem", "/etc/pki/ tls/private/xxxx.xxx_ec.key") -- Load useful modules modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } The whole thing happens when I start kresd with "systemctl start kresd @ 1"? when I start kresd -v on the command line I don't see any errors but I don't know if he is using the "/etc/knot-resolver/kresd.conf"? -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

3 roky, 9 měsíců

3
3
0 0

Knot DNS 3.0.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.9! This version only backports some fixes from the 3.1 branch. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.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

3 roky, 9 měsíců

1
0
0 0

Old keys management

by Luveh Keraph

When Knot generates a key pair, it will save it in some directory in the filesystem - in the clear, when using the default cryptographic provider, or as an encrypted blob when using SoftHSM, or (possibly) a real HSM. Imagine that I have a setup with many zones, with a signing policy that causes them to be re-signed often - say, every hour or so. This implies that new key pairs will be generated all the time. My question is, how does Knot manage key pairs that it does not need any more? It does not seem to remove them automatically. Does it provide any mechanisms or tools to do so?

3 roky, 9 měsíců

3
3
0 0

Knot DNS 3.1.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.2! I would highlight new fancy keymgr mode `keymgr -b <zone> list [human | iso]` :-) Knot DNS 3.0.9 will follow soon. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.2/NEWS Migration: https://www.knot-dns.cz/docs/3.1/html/migration.html#upgrade-3-0-x-to-3-1-x 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, 9 měsíců

1
0
0 0

Key pre-generation

by Luveh Keraph

I have been looking into the key pre-generation capability of keymgr, and the following question has come up: Imagine I pre-generate, say, one month's worth of keys for a given zone. This zone is defined so that it will be signed automatically on bringing up the Knot server. Next I start the Knot server. What criteria are used in order to select the keys, among the pre-generated ones, to be used to sign this zone? The reason I am asking is because I pre-generated two years worth of keys for a particular zone, and when I started the Knot server it took a significant amount of time selecting the appropriate keys from among the pre-generated ones.

3 roky, 10 měsíců

2
4
0 0

Knot and OpenSC "use_file_caching" - possible ?

by Laura Smith

I am working on a Knot deployment that uses Nitrokey HSM[1] as a PKCS11 platform. As you might imagine, for a small USB device, the Nitrokey is not exactly the most performant HSM in the world. My configuration works great with one or two test zones. But when I start ramping up the number of zones, I start seeing weird problems with Knot (e.g. " blocked zone update due to open control transaction" errors ... which don't seem to be errors because my code debug shows the "zone-commit" being run, but it still leaves the Knot database in a weird corrupt state where I cannot even "conf-unset" a domain even if it is clearly existing in "conf-read"). Looking around the internet, it seems "OpenSC use_file_caching " might be the answer[2]. Does Knot support this ? [1] https://www.nitrokey.com/files/doc/Nitrokey_HSM_factsheet.pdf [2]https://support.nitrokey.com/t/slow-initialization-of-nitrokey-hsm/2906/6

3 roky, 10 měsíců

3
6
0 0

Problem with local Domains example.com.lan

by Günther J. Niederwimmer

Hello list, I am a newbie I have a problem with KNOT or I don't understand Knot? What do I have to configure so that knot also dissolves my internal zones? My config for the zones # Internal zone - domain: 4gjn.com.lan # notify: secondary file: "/var/lib/knot/zones/4gjn.com.lan.zone" dnssec-signing: off zonefile-sync: -1 zonefile-load: difference journal-content: changes # master: primary1 # acl: update_acl # Master zone - domain: 100.168.192.in-addr.arpa # notify: secondary file: "/var/lib/knot/zones/100.168.192.in-addr.arpa.zone" zonefile-sync: -1 zonefile-load: difference journal-content: changes dnssec-signing: off # master: primary # acl: acl_secondary with khost I have this answer on the knot-server khost 192.168.100.204 204.100.168.192.in-addr.arpa. points to ipa.4gjn.com.lan. khost ipa.4gjn.com.lan ipa.4gjn.com.lan. has IPv4 address 192.168.100.204 But with host do I get the answer back? host 192.168.100.204 Host 204.100.168.192.in-addr.arpa. not found: 3 (NXDOMAIN) host ipa.4gjn.com.lan Host ipa.4gjn.com.lan not found: 3 (NXDOMAIN) is that correct or do I have an error? ping seems to work ping ipa.4gjn.com.lan PING ipa.4gjn.com.lan (192.168.100.204) 56 (84) bytes of data. Thanks for an answer, -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

3 roky, 10 měsíců

2
4
0 0

knotc zone-backup : error: (operation not permitted)

by Laura Smith

Any ideas what might be causing the following error ? knotc (Knot DNS), version 3.1.0 $ sudo /usr/sbin/knotc zone-backup -- +backupdir /home/foo/test error: (operation not permitted) The destination directory exits. It doesn't matter if I run the command as root or knot user, the error is the same.

3 roky, 10 měsíců

4
9
0 0

Backing up keys

by Luveh Keraph

According to the documentation, one can back up the KASP using the mdb_dump command. Now I understand things correctly, this will just back up the public component of key pairs, plus some metadata for the zones the public keys are associated with. Are there any provisions in Knot concerning the backing up of the private components of key pairs, or is this something that must be done separately and within the context of whatever cryptographic provider is used?

3 roky, 10 měsíců

3
5
0 0

Question about keymgr

by Luveh Keraph

The documentation for keymgr describes the import-bind command as follows: import-bind BIND_key_file Imports a BIND-style key into KASP database (converting it to PEM format). Takes one argument: path to BIND key file (private or public, but both MUST exist). What is imported into the KASP exactly? I thought that the KASP database consisted of public keys alone. This aside, importing a private key will depend on whether the cryptographic provider supports such an operation - many HSMs, in particular those with stringent FIPS 140-compliance requirements, will in general refuse to do so. So, what does this command do with the private key? Is it turned over to the cryptographic provider, returning an error if this provider refuses to import private keys? If such is the case, is the public key still imported into the KASP, even though there will be no matching private key for it anywhere in the system? One can of course use a public key without a matching private key, but in a DNSSEC software framework like Knot, where the bulk of the activity consists of carrying out signing operations, the presence of a complete key pair would seem to be essential.

3 roky, 10 měsíců

2
2
0 0

knotc conf-set - (invalid item)

by Laura Smith

Hi, For various reasons I need to write a Go wrapper around knotc conf. The problem is I am seeing weird behaviour (the below is stdout from my Go script): ######## Command being run: /usr/sbin/knotc conf-begin OK Command being run: /usr/sbin/knotc conf-set 'server.version' '299'error: (invalid item) 'server.version' = '299' Command being run: /usr/sbin/knotc conf-abortOK ######## If I take the "usr/sbin/knotc conf-set 'server.version' '299'" string generated by Go and paste it onto CLI, it returns OK ? I have tried adding "-v" flag but that does not produce any interesting output. Any idea where I might be going wrong here ? Why am I getting "error: (invalid item)" when Go executes the command, but not when I run it manually ? Thanks !

3 roky, 10 měsíců

2
2
0 0

Knot DNS 3.1.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.1! This version fixes several bugs and reverts one recent change in libzscanner. It emerged that the previous implementation of how omitted TTL is interpreted is closer to what the users expect. I'm sorry for this confusion! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.1/NEWS Migration: https://www.knot-dns.cz/docs/3.1/html/migration.html#upgrade-3-0-x-to-3-1-x 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, 10 měsíců

1
0
0 0

Question about key generation with keymgr

by Luveh Keraph

Tha man page for keymgr says that the keymgr generate command (quote) Generates new DNSSEC key and stores it in KASP database. (unquote) What is exactly stored in the KASP database? The reason I am asking is because the actual cryptographic key will be available in the clear only when using the default key store. When using an HSM (or event softhsm) only the HSM will have access to the key in the clear. So, what is it that gets stored in the KASP database when an HSM is used for generating keys?

3 roky, 10 měsíců

2
3
0 0

migrating from bind to knot

by mj

Hi, We are testing migration from bind to knot, to implement dnssec. We like many things about knot! Thank you for making it available! So far many things work, but we do have some uncertainties. Hope they're not too basic to ask here... We are using ubuntu, knot 3.1.0, our static bind zone files saved as /var/lib/knot/zones/db.domain.com and also the non-binary knot config. (in /etc/knot/knot.conf) 1) I wanted to test the knotc zone-backup command, but we're getting: > error: backup init failed (operation not permitted) Is the zone-backup command geared towards binary zones? Are our static zone files the reason this doesn't work? I realise we can simply copy the zone files, so in our case, the backup command probably adds nothing. 2) I have enabled DNSSEC, and upon restart we saw the keys being generated, and files appeared under /var/lib/knot/keys I guess keeping copies of the files there is adequate backup too? No "knotc zone-backup" required here as well? 3) After each knot restart, we are seeing: > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] DNSSEC, zone is up-to-date > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] loaded, serial none -> 2017041004, 106139 bytes > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] DNSSEC, next signing at 2021-08-09T16:10:10+0200 > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, zone is up-to-date > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] loaded, serial none -> 2021072903, 183151 bytes > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, next signing at 2021-08-09T16:10:10+0200 > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.] failed to update zone file (operation not permitted) > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.] zone event 'journal flush' failed (operation not permitted) > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning: [1.2.3.4.in-addr.arpa.] failed to update zone file (operation not permitted) > Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [1.2.3.4.in-addr.arpa.] zone event 'journal flush' failed (operation not permitted) We would like to understand the warnings/errors here too. Why would knot try to update the zone files, and why it is failing? I have set the permissions on the zone files 660 / knot:knot so it should be able edit them. (but again: why would knot want to update them?) Thanks for any feedback! MJ

3 roky, 10 měsíců

5
14
0 0

Enabling RSA2k and ED25519 at the same time

by Schindler, Stefan

Hi all I am currently running these two policies: ``` policy: - id: edecc algorithm: ed25519 nsec3: on - id: rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 2048 nsec3: on ``` I tried enabling both with this command, but to no effect: ``` dnssec-policy: [ edecc, rsa ] ``` Is there a way to do both at the same time in one zone? I am currently running knot 3.0.8 Cheers, Stefan

3 roky, 10 měsíců

3
6
0 0

Knot DNS 3.1.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.0! This major version brings lots of new features and improvements. Please, check the changelog. As usual, today Knot DNS 2.9 reached its End-of-life. The official repositories are being updated this way: current stable -> 3.1.0, previous stable -> 3.0.8. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.0/NEWS Benchmarks: https://www.knot-dns.cz/benchmark/ Migration: https://www.knot-dns.cz/docs/3.1/html/migration.html#upgrade-3-0-x-to-3-1-x 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, 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