knot-dns-users

knot-dns-users@lists.nic.cz

2 participants
785 discussions

restore, key copy failed (already exists)

by Einar Bjarni Halldórsson

Hi, In our setup, we have one active signer and one backup signer. Both use softhsm, but only the active signer does automatic key management. There is an hourly cron job that syncs keys from active to backup signer. It runs knotc zone-backup on the active signer, only backing up the kaspdb. It then syncs the files over to the secondary and runs knotc zone-restore. This has been running for a few years now without problems. These last two weeks we’ve been performing algorithm rollovers for some of our zones, and after we run `knotc zone-ksk-submitted nic.is` we start seeing these errors when the zone-restore is run on the backup: error: [nic.is.] zone event 'backup/restore' failed (already exists) warning: [nic.is.] zone restore failed (already exists) warning: [nic.is.] restore, key copy failed (already exists) I searched the knot dns source code, but couldn't find where these errors are output. Like I said, we’ve been running like this for a few years, doing regular ZSK rollovers, and a few KSK rollovers, without problems. There’s something about the algorithm rollover that causes this problem with our setup. I assume I can just delete the keys on the secondary and sync again, but I want to understand what causes these errors so we can avoid them or at best document them in our process. .einar

11 měsíců, 1 týden

Knot DNS 3.5.2 and 3.4.9 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.2. This is a bug fix version with some improvements. Version 3.4.9 backports several bug fixes. Note that the previous Debian repositories https://deb.knot-dns.cz/knot-latest/ and https://deb.knot-dns.cz/knot/ will no longer be updated and you should use https://pkg.labs.nic.cz/ instead. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.2/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.4.9/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

11 měsíců, 2 týdny

cache problem

by Randy Bush

debian 12 knot 5 so i believe i have a server with antique data in cache. the net of a million lies says use `kresctl clear foo` but i can not find kresctl. clue bat please randy

11 měsíců, 3 týdny

pkcs11 broken after upgrade to trixie

by Bastien Durel

Hello, I upgraded my signing server to Debian 13, but I have a problem with my HSM : Oct 15 21:09:18 arrakeen knotd[29552]: error: [durel.org.] zone event 'load' failed (PKCS #11 token not available) Oct 15 21:09:18 arrakeen knotd[29552]: error: [geekwu.org.] zone event 'load' failed (PKCS #11 token not available) keymgr gives me the same error : # keymgr geekwu.org list error: failed to initialize KASP (PKCS #11 token not available) despite hsmwiz being able to access the key : # hsmwiz identify Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00 Version : 3.4 Config options : User PIN reset with SO-PIN enabled SO-PIN tries left : 15 User PIN tries left : 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Default SO-PIN: 3537363231383830 Default PIN: 648219 Now executing: pkcs15-tool --dump Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00 PKCS#15 Card [knot]: Version : 0 Serial number : DENK0106796 Manufacturer ID: www.CardContact.de Flags : PRN generation[...] Public EC Key [Private Key] Object Flags : [0x00] Usage : [0x140], verify, derive Access Flags : [0x02], extract FieldLength : 384 Key ref : 0 (0x00) Native : no ID : 74f59bc17317bfccc5806108d84df1abd275faef DirectValue : <present> Knot is using this keystore : keystore: - id: nitrokey backend: pkcs11 config: "pkcs11:pin-value=*** /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so" I verified /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so still exists, and ldd doesn't report any missing dependency strace let me see communication with pcscd, whose logs have these : Oct 15 21:20:14 arrakeen systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon. Oct 15 21:20:20 arrakeen pcscd[33186]: 00000000 ../src/auth.c:166:IsClientAuthorized() Process 33204 (user: 134) is NOT authorized for action: access_pcsc Oct 15 21:20:20 arrakeen pcscd[33186]: 00000071 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client After a bit of digging, I found it's controlled by polkit, and added a brutal rule : cat /etc/polkit-1/rules.d/pcsc.rules /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ polkit.addRule(function(action, subject) { if (subject.isInGroup("pcsc")) { return polkit.Result.YES; } }) with knot added to the pcsc group, it can access the HSM again. Do you know of a better way to configure ? NB: I'm using another account, as I began to write this with no DNS server running Regards, -- Bastien Durel

1 rok

Knot DNS 3.5.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.1! This is mostly a bugfix version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.0/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok

knot 3.5.0 conf-set include not working correctly

by Robert Mueller

Hi We recently tried to upgrade to knot 3.5.0, but ran into a problem. It appears zones added via `conf-set include` are not working until knot is reloaded. So to reduce calls to knotc when inserting a number of domains, we build a config fragment and then use `knotc conf-set include fragment.conf` to load it With 3.4.8 this worked fine. For example: # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version 3.4.8 # dig +short foo.com @10.37.129.215 SOA # cat > /local/knot_dns/zones/foo.com.zone <<EOF foo.com. 3600 IN SOA ( ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 ;serial 86133 ;refresh 600 ;retry 1209600 ;expire 3600 ;minimum ) foo.com. 3600 IN NS ns1.fastmaildev.com. foo.com. 3600 IN NS ns2.fastmaildev.com. EOF # cat > /tmp/zone.conf <<EOF zone: - domain: foo.com template: "default" EOF # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit OK # dig +short foo.com @10.37.129.215 SOA ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600 As you can see, immediately after the `conf-commit`, the zone can be queried via dig. However this doesn't work in 3.5.0. # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version 3.5.0 # dig +short foo2.com @10.37.129.215 SOA # cat > /local/knot_dns/zones/foo2.com.zone <<EOF foo2.com. 3600 IN SOA ( ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 ;serial 86133 ;refresh 600 ;retry 1209600 ;expire 3600 ;minimum ) foo2.com. 3600 IN NS ns1.fastmaildev.com. foo2.com. 3600 IN NS ns2.fastmaildev.com. EOF # cat > /tmp/zone.conf <<EOF zone: - domain: foo2.com template: "default" EOF # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit OK # dig +short foo2.com @10.37.129.215 SOA # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com error: [foo2.com] (no such zone found) # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-reload foo2.com error: [foo2.com] (no such zone found) # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-check foo2.com # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock reload Reloaded # dig +short foo2.com @10.37.129.215 SOA ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600 # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com [foo2.com.] role: master | serial: 2025091802 As you can see, after the `conf-commit` the zone isn't visible in knot at all, either via dig or even via knotc commands `zone-status` or `zone-reload`. However immediately after a knot server `reload`, it does become visible. This feels like a bug and regression in 3.5.0 to me, or am I holding something wrong? Rob Mueller robm(a)fastmail.com

1 rok, 1 měsíc

Knot DNS 3.5.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.0! This version introduces support for a database zone backend using Redis/Valkey, external zone validation, multiple control sockets, various optimizations, and much more. See the changelog. Today Knot DNS 3.3 has reached its end of life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-4-x-to-3-… Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 1 měsíc

Re: Catalog zones when secondary to other servers

by Chris Wopat

I am definitely interested in examples! Reading up on groups, is it that 'group A' may represent 'customer A' and have a specific set of Primary/Master nameservers, Group B == Customer B, different Primary, and so on? (also fixed to be plain text - hope this is more legible in the archives) --Chris

1 rok, 3 měsíce

Catalog zones when secondary to other servers

by Chris Wopat

Hello DNS people, I am exploring migrating from PowerDNS where we have a hidden primary (ns0) and two public resolvers (ns1/ns2) using SQL replication, to instead use Knot DNS for ns1/ns2 and Catalog zones to update them. ns0 would remain Powerdns (frontend, zone edits for customers, etc). We are looking at changing due to performance issues - "dns water torture" or "random subdomain attacks" or whatever we're calling this these days. Our test environment is more or less setup as listed here: * https://nick.bouwhuis.net/posts/2024-12-31-catalog-zones-powerdns-knot/ This is similar to the architectured listed here: * https://indico.dns-oarc.net/event/47/contributions/1008/attachments/963/185… (Klaus from nic.at) For some zones, we're secondary to a customer's zone. In this case the Primariy IPs are listed in PowerDNS metadata. I am trying to wrap my head around how this could work seamlessly, where we keep the same workflow - add the zone to PowerDNS, then it gets replicated with catalog zone to ns1/ns2 (knot). Does anyone have this working? Secondary is mentioned in the PDF above but no details about that are listed. The issues appear to be at least these two things: 1) How to tell ns1/ns2 (knot) which IP's are its primaries in these zones? The only thing I can think of is a separate script to generate a knot config file with this info - effectively the same as "back in the day" with BIND. This completely negates the function of catalog zones that are secondaries. rfc9432 does address this: "Catalog zones on secondary name servers would have to be set up manually, perhaps as static configuration, similar to how ordinary DNS zones are configured when catalog zones or another automatic configuration mechanism are not in place. " That RFC then says you still have to keep it in the catalog anyhow - it's not immediately clear to me how/why - and how it could be configured per the lasts sentence (manually in knot conf) as well as in the catalog - wouldn't this be two declarations of the same zone? "Additionally, the secondary needs to be configured as a catalog consumer for the catalog zone to enable processing of the member zones in the catalog, such as automatic synchronization of the member zones for secondary service" 2) How would NOTIFY work? our hidden ns0 (powerdns) runs a copy of the zones, but ns1/ns2 would be notified from the actual primary, and our ns0 would become out of date. Does knot have something like also-notify to always notify that server? This may or may not be a problem, but the zone data would completely become stale without this. Some customers log into our web portal to view records of their secondaries and expect them to match. If anyone has operational experience with this or just a big cluebat to hit me with - let me know. Cheers, Chris

1 rok, 3 měsíce

Slow performance adding or deleting zones with large-ish (>480k) zones database

by robm＠fastmail.com

Hi We're noticing that as our list of zones gets larger (about 480k right now), adding a new zone or deleting an existing zone seems to continue to get slower. We are always doing our modifications as part of a transaction, and the time appears to occur in the commit phase. An example timing. # time /opt/knot/sbin/knotc ... conf-begin OK real 0m0.010s user 0m0.000s sys 0m0.010s # time /opt/knot/sbin/knotc ... conf-unset zone.domain example.com OK real 0m0.010s user 0m0.000s sys 0m0.010s # time /opt/knot/sbin/knotc ... conf-commit OK real 0m2.330s user 0m0.000s sys 0m0.009s # As you can see, it took > 2 seconds to commit the transaction that removes just the example.com zone. Similarly, it takes > 2 seconds to commit the transaction that adds the zone back. Given the time is real time and not sys/user, I presume knotc is waiting on knotd to complete the work. I used perf to record a CPU profile of knotd while the commit was running, but nothing hugely stuck out at me. 10.75% knotd libc.so.6 [.] __memcmp_avx2_movbe ◆ 6.03% knotd knotd [.] __popcountdi2 ▒ 5.89% knotd knotd [.] ns_first_leaf ▒ 5.25% knotd libc.so.6 [.] pthread_mutex_lock@@GLIBC_2.2.5 ▒ 3.85% knotd liblmdb.so.0.0.0 [.] 0x0000000000003706 ▒ 3.72% knotd knotd [.] ns_find_branch.part.0 ▒ 2.76% knotd knotd [.] trie_get_try ▒ 2.63% knotd liblmdb.so.0.0.0 [.] 0x00000000000069d2 ▒ 2.34% knotd libknot.so.14.0.0 [.] knot_dname_lf ▒ 1.92% knotd liblmdb.so.0.0.0 [.] mdb_cursor_get ▒ 1.72% knotd knotd [.] create_zonedb ▒ 1.68% knotd knotd [.] twigbit.isra.0 ▒ 1.68% knotd knotd [.] catalogs_generate ▒ 1.36% knotd knotd [.] twigoff.isra.0 ▒ 1.28% knotd knotd [.] hastwig.isra.0 ▒ 1.28% knotd knotd [.] db_code ▒ 1.27% knotd libknot.so.14.0.0 [.] find_item ▒ 1.11% knotd libknot.so.14.0.0 [.] knot_dname_size ▒ 1.04% knotd knotd [.] zonedb_reload ▒ 0.99% knotd libc.so.6 [.] _int_free ▒ 0.99% knotd liblmdb.so.0.0.0 [.] 0x0000000000003ce8 ▒ 0.96% knotd liblmdb.so.0.0.0 [.] memcmp@plt ▒ 0.95% knotd liblmdb.so.0.0.0 [.] mdb_cursor_open ▒ 0.88% knotd libc.so.6 [.] malloc ▒ 0.88% knotd knotd [.] conf_db_get ▒ 0.87% knotd knotd [.] ns_next_leaf ▒ 0.82% knotd libknot.so.14.0.0 [.] iter_set ▒ 0.75% knotd knotd [.] evsched_cancel ▒ 0.73% knotd libknot.so.14.0.0 [.] find ▒ ... Our config is pretty simple, conf-export looks like: server: rundir: "/local/knot_dns/run/" user: "nobody" pidfile: "/local/knot_dns/run/knot.pid" listen: [ ... ] log: - target: "syslog" any: "info" statistics: timer: "10" file: "/tmpfs/knot_dns_stats.yaml" database: storage: "/local/knot_dns/data" mod-stats: - id: "default" request-protocol: "on" server-operation: "on" request-bytes: "on" response-bytes: "on" edns-presence: "on" flag-presence: "on" response-code: "on" request-edns-option: "on" response-edns-option: "on" reply-nodata: "on" query-type: "on" query-size: "on" reply-size: "on" template: - id: "default" global-module: "mod-stats/default" storage: "/local/knot_dns/zones/" zone: - domain: "example.com." template: "default" ... 478,000 more domains all the same ... Current files on disk are: # ls -l /local/knot_dns/data/* /local/knot_dns/data/catalog: total 0 /local/knot_dns/data/journal: total 0 /local/knot_dns/data/keys: total 0 /local/knot_dns/data/timers: total 75880 -rw-rw---- 1 root root 77697024 Jun 24 09:26 data.mdb -rw-rw---- 1 root root 2432 Jul 17 01:05 lock.mdb /local/knot_dns/data/timing: total 0 This machine is not slow or constrained in any way. It's 24 core, 3.6Ghz, 64Gb, NVMe drives, etc. Load is very low (<1) with plenty of free resources. So what I'm wondering is: 1. Is this normal? It doesn't feel right that adding/removing a single domain takes > 2 seconds regardless of the size of the existing zone database 2. Is there any way to improve this? Doing multiple adds/deletes at once within a transaction works and we do that where we can, but there are cases where we can't do that and I'd really like to understand why this is as slow as it is. Thanks in advance Rob

1 rok, 3 měsíce

← Newer
1
2
3
4
5
6
7
8
...
79
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users