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

by Thomas Küchenthal

Hi, for benchmark purpose I need to find out how log it takes to sign zone files in different sizes with different hardware. What is the best way to find out the exact time the signing process takes? Thanks! BR Thomas

1 týden, 3 dny

2
1
0 0

zone event 're-sign' failed (not enough space provided)

by Thomas Küchenthal

Hi, when signing a zone file I receive this error in the log: "zone event 're-sign' failed (not enough space provided)" Can you tell me what is the limiting factor here? Thanks! BR Thomas

1 týden, 3 dny

2
1
0 0

Trigger zone transfer from the master that sent NOTIFY

by Alexandr Basov

Hello, Could you please clarify whether Knot can perform a zone transfer not from the first master listed, but from the one that sent the NOTIFY? The masters are configured in the following order: remote: - id: master address: [ "192.168.58.151", "192.168.58.134" ] When a NOTIFY is sent from |192.168.58.134|, the zone transfer is still performed from |192.168.58.151|. Here are the relevant log entries: Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] notify, incoming, remote 192.168.58.134@32888 TCP, serial 2006 Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] refresh, remote 192.168.58.151@53, remote serial 2006, zone is outdated Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] IXFR, incoming, remote 192.168.58.151@53 TCP, receiving AXFR-style IXFR Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] AXFR, incoming, remote 192.168.58.151@53 TCP, started Thank you for your product and for your help! *Best regards,* *A.A. Basov*

4 týdny

4
4
0 0

CDS/CDNSKEY issue

by Michael Grimm

Hi, this happened to me for the second time, that https://dnsviz.net <https://dnsviz.net/> tells me: | enfer-du-nord.net/CDNSKEY: The CDNSKEY RRset must be signed with a key that is represented in both the | current DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1. | enfer-du-nord.net/CDS: The CDS RRset must be signed with a key that is represented in both the current | DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1. I do not understand what that means. #) I haven't modified my KSK for some time now #) I did notify my parent zone about a modified list of nameservers (via registrar's web portal) I am not absolutely sure if the latter is the cause for these error messages. I 'fixed' that issue by re-uploading my unmodified KSK DNSKEY (via registrar's web portal). Hmm, how can I fix that issue the right way? Any hints are highly welcome, Michael

1 měsíc

4
6
0 0

What is mod-synthrecord used for?

by Michael Grimm

Hi, given the case that a ip6/xy block might be delegated to me by my ISP, I began investigating Knot DNS' functionality with regard to ip6.arpa. Hereby I stumbled over the module synthrecord and do not really understand what it is used for. From https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#synthrecord-automati… "Records are synthesized only if the query can't be satisfied from the zone." Please excuse my ignorance, but why would/should/must one return something else than the following for hosts not in the zone? kbn> host 2001:dead:beef::1 Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN) Any feedback is highly appreciated, thanks. Regards, Michael

1 měsíc, 1 týden

4
12
0 0

Seperate config for zones

by Einar Bjarni Halldórsson

Hi, This is just a possible feature request. We’re planning on using Knot for user hosted domains. To do that we’ll have to add and remove zones dynamically, so we’ve enabled the config db. What surprised us is that this means that the config file isn’t used at all anymore (except you can use it to prime the config db). As it is, we’ll have to embrace the config db, which makes our ansible playbook more complicated. It’s easy to add a config file template in ansible, it’s more complicated to issue `knotc conf-begin; knotc conf-set; knotc conf-commit` logic. I wish knot was more like nsd, where you have the config file nsd.conf, but if you add zones with `nsd-control addzone ….` it gets added to a seperate zonelist file, which nsd reads on startup. It means we can have a static config file, but still be able to add and delete zones dynamically. nsd doesn’t have automatic DNSSEC key management and catalog zones in knot are really easy to use, which is why we’re going with knot for this project. I just wanted to lay it out there as an idea for the future :) .einar

1 měsíc, 1 týden

4
5
0 0

Knot DNS 3.4.6 release

by Daniel Salzman

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

1 měsíc, 2 týdny

1
0
0 0

Re: Configuration database vs file questions

by Daniel Salzman

Hi Bill, You can't mix a configuration database and a configuration file. You can initialize a database with `knotc conf-init` or `knotc conf-import`. Then if you start knotd, the database will be used for reading and persistent writing. The configuration database format is a custom format using LMDB. It's not intended to be accessed externally! Daniel On 3/29/25 19:56, Billiam Crashkopf wrote: > Hi all, > > I'm running Knot 3.4.4 on FreeBSD 14.2, installed from the distribution package repository. > > I'm trying to understand, is there a way to configure knotd using both the configuration file and the database? For example, can I use the configuration file for directives like listen and template, then use the configuration database for storing individual zone settings? So far, it appears that knotd only uses one or the other. Furthermore, there doesn't seem to be any command to explicitly load or flush configuration from the database. If I start with the config file, I can initialize the database, but upon stopping knotd nothing seems to be saved to the database. I also don't see any documentation on tooling to inspect the database on disk. What is the file format of the database? > > If anybody can help me to know more about how it works I would be most appreciative. > > Thanks, > > Bill >

1 měsíc, 3 týdny

2
1
0 0

HSM keystore-bench

by Jan-Piet Mens

Hello! In July 2024, in the Knot-DNS 3.3.8 release message, Daniel writes: >I would like to ask users with hardware HSMs to send us the output of `keymgr <hsm_keystore_id> keystore-test` >This will allow us to update https://www.knot-dns.cz/docs/latest/html/appendices.html#compatible-pkcs-11… We're now running Knot 3.4.4 against a Thales HSM (I have no details of the actual device/model in use at this time) and I see the following data: $ keymgr -c etc/knot.conf thales keystore-bench Keystore id 'thales', type PKCS #11, threads 1 Algorithm Sigs/sec RSASHA256 33 ECDSAP256SHA256 27 ED25519 n/a ED448 n/a My first reaction was "hmm, that's slow". Is there a list (above URL isn't it) of comparable results which I could show the HSM operators and/or is anybody willing to share their data? Thanks & regards, -JP

2 měsíce, 1 týden

2
3
0 0

Knot DNS 3.4.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.5! This is mostly a feature release. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.5 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

2 měsíce, 1 týden

1
0
0 0

Re: Knot compliance with

by Henry Birge-Lee

Hi Vladimir, I appreciate your response and it's great to know you validate by default. I apologize for posting to the wrong list. Best, Henry On Wed, Mar 12, 2025 at 9:14 AM Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote: > Hello. > On 10/03/2025 17.01, birgelee--- via knot-dns-users wrote: > > This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful. > > This is about resolvers apparently, so we're slightly off-topic here, as > we have a split knot-resolver-users(a)lists.nic.cz - but I expect this > thread to be very short. > > Knot Resolver *does support* modern DNSSEC validation, as described in RFC > 4035, 6840, and some others. And we validate by default, etc. > > --Vladimir >

2 měsíce, 1 týden

1
0
0 0

Knot compliance with

by birgelee＠princeton.edu

Hi all, I know this topic has been dead for a bit, but I did want to specifically find out if Knot is intended to be compliant with DNSSEC RFCs 4035 and 6840. I ask because I am computer security researcher and I do a lot of work with the CA/Browser Froum. I recently proposed a draft ballot that would mandate all publicly-trusted web CAs validate DNSSEC: https://github.com/cabforum/servercert/pull/571 This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful. Best, Henry https://henrybirgelee.com/

2 měsíce, 1 týden

2
1
0 0

mod-rrl

by Randy Bush

is there any guidance on using mod-rrl on a public server with a moderate load, say 6kqps? we have rtfm, and remain unsure of what we are doing. we want cookies, and therefore need to turn rrl on. but with it turned on, we seem to drop a *lot* of replies, a lot. mod-rrl: - id: default rate-limit: 200 slip: 2 randy

2 měsíce, 2 týdny

4
5
0 0

IXFR versions journaling without using file

by Jeremy C. Reed

I have static zones that are regenerated continually (every few seconds) with a knotc zone-reload _zonename_ after. Doing dig queries using ixfr= always used AXFR until I enabled per-zone zonefile-load: difference We saw logs periodically like: warning: [foo.bar.example.com.] failed to update zone file (operation not permitted) This is because the files created are a different user than the knotd. We are not doing automated signing nor dynamic updates. This is with Knot 3.2.6. 1) Why would it try writing to the source zone file? Anyways, we got rid of that warning with zonefile-sync: -1 And the time to between the zone-reload and serving the new zone data improved too. I noticed with experimenting with journal-db-max-size and journal-max-size the data.mdb was around 80% larger than the defined size. As I removed and added records, the number of differences reduced and I couldn't do IXFRs for many versions behind which I assume is default journal-max-depth: 20. I believe this means the journaling was dropping versions and does not require keeping at least 20 versions (not a "minimum". I am fine with that. I was able to trigger error like error: [foo.bar.example.com.] zone event 'load' failed (not enough space provided) which I assume was due to journaling even when dropping old versions still doesn't have enough space for most recent changes. We are experimenting with increasing journal-max-size to work around this. It appears that the differences are fully handled in memory first before updating to the journal file. I also see the journal file have large jump in file size and never small increments. 2) Since I have no purpose to reuse a journal file for system restart or recovery -- since I am building new zone files frequently, is there any way to not use a journal file and just have knotd do this all in memory? That way it is never writing to the journal every few seconds while I continue to offer IXFR out support? If not, maybe I will use memory file system for the journal files. By the way, this is for around ten zones varying from around 1000 records to over 8 million records for the larger zones, They are changing from a few records every few seconds to maybe a thousand records every 30 seconds. Thanks

2 měsíce, 2 týdny

2
1
0 0

IXFR response has interspersed IXFR and OPT records and more

by Jeremy C. Reed

I am testing IXFR for servers I did not install nor have easy access to. version.server. says it is 3.2.6. I know there are IXFR changes since then per the NEWS file and from git log. I don't see same behavior on my different version different systems but they are also configured differently. The knot.conf zones are not configured with "zonefile-load: difference" and the response effectively has the entire zone as if was AXFR and not the changes. If I pass the IXFR SOA SERIAL to latest it has no changes (answer has has the SOA only with same serial). I used dnspython to output the response from doing IXFR queries (IXFR question with SOA authoritative set with the serial in the query). I noticed the output abruptly stops when "dig" doesn't stop. So I used tcpdump many times to compare knot, named, and my other knot. I found an odd behavior in this knot 3.2.6 response which dig ignores and my dnspython fails. After the expect record it has 1) OPT record with the requestors pay load size (class 1232) and edns rcode and flags (all zeros ttl), then 00 rdlength and 00 rdata field. 2) then 28 bytes I don't understand such as: 40 11be dc80 0000 0101 fa00 0000 01 or 40 20be dc80 0000 0102 0300 0000 01 or 40 0fe1 6a81 0000 0102 0500 0000 00 or 12 8de1 6a81 0000 0100 9200 0000 00 3) then an IXFR record following other labels ... 0363 6f6d 00 three characters "com" and end of domain 00 fb IXFR record type 00 01 INternet class and then ends there, with NO ttl, rdlength, nor rdata. 4) followed by next label length, label ... etc with rrtype, class, ttl, rdlength, rdata and so on. This odd OPT, bytes I don't know, partial/broken IXFR record, may be repeated a few times. I assume these were interspersed where IXFR's SOA records should be. I couldn't find an RFC that suggested using interspersed OPT nor IXFR records. I find it odd that OPT record is in my ANSWER section. I find it odd that the IXFR record is incomplete. And I don't know what the other bytes are in-between. This recognizable to anyone? The IXFR works fine as seen with dig or when I use named as my secondary but I assume the named is ignoring the junk parts too.

2 měsíce, 3 týdny

2
3
0 0

mod-onlinesign: extra DNSKEY causes double signatures

by Peter Thomassen

Hi, Consider a zonefile with @ DNSKEY 257 3 13 ZAtZvaK2/uVw+LG2AA12Dt/ZZ+YN0IF3pFwjfBp8Jd2DXjVU0cdxfpkY StUdbFu24Js6T5uROHo8lSG9rhgduw== and configuration zone: - domain: example.com storage: /config/ file: example.com.zone module: mod-onlinesign -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525

3 měsíce, 1 týden

2
3
0 0

Dynamic update fails after zone creation via catalog

by Daniel Gröber

Hi Knots, I use catalog zones to sync the set of zones my (hidden)master and slaves handle. I'm trying to stop messing with zone files on my master, instead switching exclusively to nsupdate (along with Tony Finch's nsdiff). In my testing it seems updating the zone after adding it via a catalog is not possible: $ knotc zone-status dxld.at [dxld.at.] role: master | serial: - | catalog: dxld.catalog. | re-sign: +9D15h6m14s Yet the update fails: $ knsupdate -y $SECRET <<EOF > server ns0.dxld.at. > zone dxld.at. > add dxld.at. 3600 IN SOA ns0.dxld.at. hostmaster.dxld.at. 1 2m 5m 1w 5m > send update failed: SERVFAIL Nothing is logged with `logging: any: debug` except a "ACL, allowed, action update". As soon as I create the zone on the server with zone{-begin,-set,-commit} it starts working ofc. I guess this is just not supported, but is there a good reason? I would find it quite convenient to do all my DNS ops over port 53 without touching ssh ;-) Thanks, --Daniel

3 měsíce, 3 týdny

5
9
0 0

Issue - trailing data

by Артём Палецкий

Hello! I have an issue. Knot is configured as a secondary server, and when receiving a zone, a "trailing data" error occurs, preventing the zone from being loaded from the primary server. ``` Jan 30 11:03:40 hostname knotd[5407]: info: [domain.com.] refresh, remote 50788646-db98-4caa-b26e-95b30a470796, address 1.2.3.4@53, failed (trailing data) ``` The same warning appears when using the `kdig` utility: ```bash kdig @1.2.3.4 domain.com AXFR > /tmp/domain.com ;; WARNING: malformed reply packet (trailing data) ;; WARNING: malformed reply packet (trailing data) ``` The issue occurs specifically with large zones. If the zone requires 2 messages to be received (e.g., `Received 32720 B (2 messages, 442 records)`), one warning appears. If it requires 3 messages (e.g., `Received 49083 B (3 messages, 878 records)`), two warnings appear. However, if I place this zone (`/tmp/domain.com`) into `/var/lib/knot` and then execute: ```bash knotc reload knotc zone-refresh domain.com ``` Knot successfully loads the zone. Unfortunately, due to confidentiality, I cannot share the contents of the zone. Additionally, I do not have precise information about the software installed on the primary server. However, if BIND is used as the secondary server, there are no issues. A regular `dig` command also does not return any errors. Is there any way to make Knot ignore the "trailing data" error and successfully load the zone? Thank you for your help!

3 měsíce, 3 týdny

4
3
0 0

Knot DNS 3.4.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.4! This is a bugfix version with some improvements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.4 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

4 měsíce

1
0
0 0

knotc issue since 3.4.1

by Jean-Daniel Dupas

Hello, I have an issue with a behaviour change in knot 3.4.1. Before 3.4.1, trying to send a conf-abort command using knotc to knot when there was no pending transaction properly returned an error, but since 3.4.1, instead of receiving an error, the connection hangs, and failed after a timeout. Some digging shows that this is due to a change in commit 69328dd7799253978605f7dac29175945971e63f Instead of returning and error as it should, ctl_process skip the command processing when it does not expect a conf-abort command. Is this a bug, or is this behaviour intended ? Just to give you some context about my use case, I wrote a daemon that is using libknot to sync the dns configuration, and as knot does not supports multiple transaction, it has to make sure there is no dangling transaction before trying to apply changes (in case the daemon did crash while applying a previous change). Until 3.4.1, it did that by simply sending a conf-abort before starting the new transaction. Thanks

4 měsíce, 2 týdny

3
3
0 0

HSM support

by Thomas Kuechenthal

Hi Guys, a happy new year to all of you! Due to policy reasons we need to make knot use a HSM in the future. Is anybody successfully using some cloud based HSM services like Google Cloud HSM for DNSSEC signing? Any information is helpful, thanks! BR Thomas

4 měsíce, 2 týdny

4
3
0 0

Knot DNS 3.3.10 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.10! This version backports some fixes and improvements from 3.4. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.10 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

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

1
0
0 0

Change of default nsec3-salt-length

by Erwan David

Hello, My knot 3.4.3 gives me following notice : notice: config, policy 'rail_policy' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0 In order to avoid problems when .5 will arrive, I see 2 possibilities: * add an explicit nsec3-salt-length=8 to my policy * add an explicit nsec3-salt-length=0 to my policy and resign the zone. From https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-10.html#nam… I understand that 0 should be the new configuration, but what are the risks (considering eg. DNS caches) if I change the policy of the zone? I only have small zones, with very few dynamic changes, which I can delay for the time of the TTL if needed. -- Erwan David

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

2
1
0 0

Knot DNS 3.4.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.3! This is a bugfix version with some improvements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.3 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

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

1
0
0 0

Starting and stopping knotd

by Erik P. Ostlyngen

Hi, I'm running an instance of knotd for testing. It is installed with the official ubuntu debian package from kont-dns.cz. When I start the knot service, using systemctl, it takes a very long time to start up (sometimes 30 min). This seems to be related to the systemd unit which is set to type 'notify', and the fact that knot after starting up wants to re-sign all the zones which needs that before notifying. If I change the type to 'simple' or 'forked' (together with the knotd -d option), the start command returns more immediately. My test system has about 800 zonefiles in it. A large number of them want to be re-signed after each startup. My question is, what is the recommended way to start, stop and restart the server? Also, after starting I cannot find the /run/knot/knot.sock file, which is needed when stopping the service with 'knotc stop'. Knot version: 3.4.1-cznic.1~focal (debian package from knot-dns.cz) OS: Linux 5.4.0/Ubuntu 20.04 Focal amd64. Kind regards, Erik Østlyngen Norid

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

2
4
0 0

EPEL Packages

by Günther J. Niederwimmer

Hello Daniel, Are the EPEL packages no longer available (?), I'm stuck at 3.3.9. There have been no updates since then. Or can you download the .rpm from somewhere else now? -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

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

4
7
0 0

Knot DNS 3.4.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.2! This is a bugfix version with a few improvements. Upgrade from 3.4.0 and 3.4.1 is recommended. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.2 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

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

1
0
0 0

Knot DNS 3.4.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.1! This is a bugfix version with some new features. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.1 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

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

1
0
0 0

Knot DNS 3.4.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.0! This version brings DNS/XFR over TLS, DDNS over QUIC and TLS, continuous DNSSEC zone validation, XDP improvements, enhanced RRL, partially asynchronous processing of control commands, and more. See the changelog. Today, Knot DNS 3.2 reached its end-of-life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.4.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-3-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

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

5
10
0 0

Deny dynamic updates for certain owners/names

by Conrad Hoffmann

Hi all, we are using dynamic updates for solving ACME challenges. My goal is to restrict the key used for this as much as possible. However, I find it a bit difficult to do so while keeping the required flexibility. Maybe someone has some good recommendations for this? The key is already restricted to TXT records, so that's good. In a nutshell, I'd like to allow only "_acme-challenge.example.com" and "_acme-challenge.*.example.com". However, the latter cannot be expressed in the current config format. I would be fine allowing "*.example.com", if I could just deny a select few names (SPF, DKIM). But AFAICT, the "deny" option only works on action, key, and address, now owner matching. Is there any other way to achieve something like this? Thanks a lot, Conrad

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

2
3
0 0

Knot DNS 3.3.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.9! This is a bugfix version with a few improvements. Since version 3.3.4, there has been a bug in 'keymgr pregenerate', where future timestamps of existing keys are cleared and new overlapping keys are generated instead. An upgrade is recommended if you use this function or offline KSK. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.9 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

9 měsíců

1
0
0 0

$TTL default setting ignored for resource records without explicit TTL set

by Michael Grimm

Hi, I do have the following example zone files definitions: $ORIGIN example.tld. $INCLUDE ___TTL_SOA___ and so on My ___TTL_SOA___ looks as follows: $TTL 30m ; default expiration time of all resource records without their own TTL value ; @ IN SOA ns1.example.tld. hostmaster.example.tld. ( 2024042100 ; serial (increase after each change) 4h ; refresh (recommended >= 4h) 1h ; retry (recommended >= 1h) 14d ; expire (recommended between 7d and 14d) 600 ; negative caching (former minimum, recommended between 5m and 1d) ) Note: All of my subsequent $INCLUDDE files do *not* have TTL values set explicitly! But: I do end up in a mix of TTL values of 1800 and 3600 for my resource records. You can check that using my domain in my email address. I found the following thread about this issue at https://gitlab.nic.cz/knot/knot-dns/-/issues/751 and https://datatracker.ietf.org/doc/html/rfc2308#section-4 cited therein: "All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive." In my understanding Knot's behaviour has been set to follow this standard track. Thus, I do expect that all of my resource records should have a TTL set to my $TTL directive of 1800 seconds. I might have well overlooked something, though. Any feedback is highly appreciated, Michael

10 měsíců

5
13
0 0

Knot DNS 3.3.8 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.8! This version fixes a few bugs and brings some features. I would like to ask users with hardware HSMs to send us the output of `keymgr <hsm_keystore_id> keystore-test` along with a description of the HSM. This will allow us to update https://www.knot-dns.cz/docs/latest/html/appendices.html#compatible-pkcs-11… Thank you! Note that it's no longer possible to build packages for CentOS 7 using Copr! Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.8 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

10 měsíců

1
0
0 0

address lists

by Randy Bush

as yaml seems to vary widely, i worry that i may have over-induced knot yaml re address lists, see https://www.knot-dns.cz/docs/3.3/singlehtml/index.html#description remote: - id: foo address: 1.2.3.4 address: 2.3.4.5 address: 3.4.5.6 address: 6.7.8.9 is said to be the same as remote: - id: bar address: [1.2.3.4, 2.3.4.5, 3.4.5.6, 6.7.8.9] but is it also the same as remote: - id: feen address: [1.2.3.4, 2.3.4.5] address: [3.4.5.6, 6.7.8.9] feen does not result in a `knotc conf-check` syntax error, so i hope it is indeed equivalent. randy

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

2
1
0 0

kasp database: how to find orphaned keys?

by Michael Grimm

Hi, is there a functionality that identifies orphaned key in the kasp database and optionally deletes those? I had had a couple of orphaned pem files. I managed to identify and remove those with the help of 'keymgr' and Unix little helpers, though. Thus I am asking just out of curiosity, because I might have missed such a functionality. Thanks and regards, Michael

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

2
2
0 0

idn in axfr

by Randy Bush

knot fails to keep this zone updated. so i tested by hand ``` rip.psg.com:/home/randy# dig f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr ; <<>> DiG 9.18.24-1-Debian <<>> f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr ;; global options: +cmd ;; Warning: cannot represent 'xn--center-dla.test.globnix.net.' in the current localedig: Cannot represent 'xn--ls8h.test.globnix.net.' in the current locale nor ascii (string contains a disallowed character), use +noidnout or a different locale ``` `+noidnout` does fix it, but i am not sure i can get knot's axfr to do that the owner of the primary says Okay, this is the zone with a whole bunch of records designed to stress-test DNS implementations with things which are technically allowed in DNS at the protocol level but which apps might not handle well. Zonefile top comment: ; This is the /80 reverse DNS used for test entries which should never be ; assigned to hosts. This is </48-prefix>:DEAD:BEEF::/80 Those particular records were added on 2013-04-05 per `git blame`: 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 64) 0.6 PTR mid\194\183dle.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 65) 1.6 PTR xn--center-dla.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 66) 2.6 PTR \240\159\146\169.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 67) 3.6 PTR xn--ls8h.test.globnix.net. so, `noidnout` is not in knot doc html file. clue bat, please. randy

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

4
5
0 0

Knot DNS 3.3.7 and 3.2.13 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.7 This version primarily fixes an old bug in the journal where some SOA serial values are incorrectly evaluated, which can corrupt the journal. Upgrade is recommended. Version 3.2.13 backports this and some older bug fixes. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.7/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.13/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ů

3
5
0 0

question about unixtime

by Randy Bush

i have had a fun day chasing diags of the form ``` 2024-06-22T18:32:57.305472+00:00 ns knotd[24354]: info: [foo.com.] control, received command 'zone-reload' 2024-06-22T18:32:57.307532+00:00 ns knotd[24354]: info: [foo.com.] zone file parsed, serial 1719081134 2024-06-22T18:32:57.307669+00:00 ns knotd[24354]: warning: [foo.com.] zone file changed with decreased SOA serial 2024-06-22T18:32:57.307828+00:00 ns knotd[24354]: error: [foo.com.] zone event 'load' failed (value is out of range) ``` i have the following hypothesis: - `serial-policy: unixtime` is configured in `/etc/knot/knot.conf`. - emacs dns-mode sets the SOA serial to the current unixtime when one saves the zone file - a few seconds later, i do `knotc zone sign` and `knotc zone-reload` - knot then says "you have manually specified a new serial, but it is less than the current unixtime; i.e. you are trying to go backward. bad geek!" - i.e. knot did not like me mucking with the SOA serial in the zone file when `serial-policy: unixtime` was configured. i tested this hypothesis by putting the serial from the server's current SOA in the zone file and doing sign & reload. it succeeded, and the new zone in all servers is the unixtime of the signing, not of the zone file. my current conclusion is: do not have both emacs dns-mode with `serial-policy: unixtime`; use only one or t'other. especially if doing RFC 1982 serial stepping, remember to first turn off `serial-policy: unixtime` and `knotc reload`. does this make sense? randy

11 měsíců

2
3
0 0

tcp ddos

by Randy Bush

so, school is out and the children are on the loose 2024-06-10T21:27:24.199750+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2620:171:c2::49@33322 2024-06-10T21:27:24.200561+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 167.99.160.10@14871 2024-06-10T21:27:24.200642+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 34.223.46.240@53392 2024-06-10T21:27:24.201218+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 167.99.160.10@2011 2024-06-10T21:27:24.201422+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 81.106.125.151@54192 2024-06-10T21:27:24.203263+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 34.223.46.240@53398 2024-06-10T21:27:24.203643+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 139.99.166.37@42942 2024-06-10T21:27:25.199585+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 3.228.173.229@34084 2024-06-10T21:27:25.199678+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 76.93.200.106@10371 2024-06-10T21:27:25.200951+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2a02:6b8:c04:262:0:433f:1:3@33586 2024-06-10T21:27:25.201029+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2600:3c09::f03c:93ff:fea9:4de0@54166 2024-06-10T21:27:25.201207+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 118.99.2.29@33170 2024-06-10T21:27:25.201385+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 213.187.92.252@40559 2024-06-10T21:27:26.200340+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2a02:6b8:c04:262:0:433f:1:3@33594 2024-06-10T21:27:26.200529+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 40.79.144.82@59683 2024-06-10T21:27:26.203837+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 103.85.93.93@60578 2024-06-10T21:27:26.205102+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 13.244.33.51@33812 2024-06-10T21:27:27.208589+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 18.139.204.179@46824 2024-06-10T21:27:27.210062+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 20.125.201.35@63627 2024-06-10T21:27:27.331742+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 172.217.37.144@64719 2024-06-10T21:27:27.332050+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 191.233.201.73@61718 2024-06-10T21:27:27.391797+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 81.106.125.151@50624 like tens of thousands. some children are like that. so, we take this as an opportunity to learn a bit more about knot tuning we shortened `tcp-idle-timeout: 2` we set `tcp-max-clients: 20` rate limiting seems unlikely to improve things as it is many sources, a DDos what else are we missing? btw, it also whacked knot enough that it failed a resign cycle and we had to add `unsafe-operation: no-check-keyset` to get back to signing. clues appreciated. this can't be the only neighborhood with children. randy

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

6
16
0 0

DNSSEC debugging help wanted

by Korry Luke

Hi folks, Forwarding on behalf of Randy Bush since his mail server/DNS are being DDoSed right now. Trying to troubleshoot, but any knot DNS expertise would be greatly appreciated. Regards > debian 12 > knotc (Knot DNS), version 3.2.6 > (aside: the server is under serious TCP and UDP DDoS) > > all looks reasonable > > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] control, received command 'zone-sign' > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, dropping previous signatures, re-signing zone > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 53567, algorithm RSASHA256, KSK, public, active > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 25843, algorithm RSASHA256 > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 59161, algorithm RSASHA256 > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 5489, algorithm RSASHA256, KSK, public, active+ > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 22090, algorithm RSASHA256, public > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, signing started > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, successfully signed > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, next signing at 2024-06-25T02:36:17+0000 > > # keymgr psg.com list > 649b0d43d1493dd4ad30f8043ca4561c33c38b5a 53567 KSK RSASHA256/2048 publish=1078099200 active=1078099200 > 173597db4b4f2f072b568cb637710e891ac52246 25843 ZSK RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600 remove=1717977600 > 3194d896f2a64f10b103991e5018b72cd3f1cd28 59161 ZSK RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600 remove=1717977600 > 7b1bf414b34f605c68f9ddb7b52c32c6b53da8d3 5489 KSK RSASHA256/2048 publish=1718161132 > 902b8e02a5e75754bd69791735e76cb11c3e37af 22090 ZSK RSASHA256/2048 publish=1718161132 > > > but no rrsig > > # dig @localhost +vc +dnssec +norec -t dnskey psg.com > > ; <<>> DiG 9.18.24-1-Debian <<>> @localhost +vc +dnssec +norec -t dnskey psg.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42269 > ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ; COOKIE: 7f45da4f7305fdd5010000006669234c9ce14bdf78917f58 (good) > ;; QUESTION SECTION: > ;psg.com. IN DNSKEY > > ;; ANSWER SECTION: > psg.com. 86400 IN DNSKEY 256 3 8 AwEAAZfG8Y++ZmGXwa1sgmHpruUSPljDwMR2pY5bUjjOaJNyUBeLlEAP Fyya3MNAKryW26yTxFmwYmyt0UtXyc4L7Ib5/J/Ew+putYpjRfslwPlS 5TWblvnbiqGcY/ZMuGrtLeZkvK/o39vXM+Hy5y3xbG4Qu4ySiuW03xMM pN50cr8+VcM2RDQn6/W6kESdiY8WaXyD1DT9eIgIyi5zTaOfhSB7u/g7 H+7LltCAiCZIcIF08CGbS1VEh0YUyw3Th1I6jiQmYeGG6OSGaci5SkjV fGTDpHrJOjFlCnUVfg+cYc1YPEojbmo90qO/nG+VB5I+qDYtkU1IR8EB +qXNi7ZbBt8= > psg.com. 86400 IN DNSKEY 257 3 8 AwEAAaCgMhvfatdo1jeqr0AsHJY+QB/QVv2O+9W62Sfj+xKCbV5nGgvu XqPq2A8tXKT1lG1YF0pe3/ABH2iYNZs7v/a6QAb1wEAYasNz6ZlvRca2 bDs6KXz/n2B/Oeb2JoWBJ6OqdNtzkDl6CYEOkQoDWRnbR9jlyINOQ0mN xfTu2wbXMngSIz78yTadpieyuG/B/TsLQ1SlTUSf436G5NMdxzQ8r7j4 5nW7mEORzvvk5Z1mGtfX8v8taw4qFfoIlaf226N06lZ90jpnEHTOGSTA T/ii5WVqjBZGFWFYWrNcHR51zHm4QAGKlZ5hzr6lrGZaXqgY7jE3GaOc 86mZhSlyYIs= > psg.com. 86400 IN DNSKEY 257 3 8 AwEAAcXR1VhQRarToAaewor9xoQhrXbmUd9Ob0ruqOpDs5TO/jZLTOFE W/g4V1yllr9t7tyLVJWA5jdZyJZO3otyu6S+OKvSLD8er3alStkgqI2Q bLF3gUjtGxmcd/yIci4srWj401tv/6uWigN50+9Df0ClgUpmdjQ/ePq8 51DKtK51qGgc4vHwSYoWKQaGTofELiMDDXpzZSkQqAUveZYRzVTScUCQ woVjQANSmio/u6JZtkwRnnUF9bChN51ydUY+uVH9NuoY6jEKJ27ZlIAP 4UgQ0h9epWy5JYV9bNQlhV+qpW1G3Zg/l58Yz5mWwh107HQIUefCgVP+ TTIusTwWH0E= > > ;; Query time: 0 msec > ;; SERVER: ::1#53(localhost) (TCP) > ;; WHEN: Wed Jun 12 04:25:48 UTC 2024 > ;; MSG SIZE rcvd: 892 > > maybe 35 zones with same policy and tenplate. one has RRSIGs no others > do. > > mod-rrl: > - id: default > rate-limit: 12 # Allow 200 resp/s for each flow > slip: 2 # Approximately every other response slips > table-size: 900241 > > mod-cookies: > - id: default > secret-lifetime: 30h > badcookie-slip: 6 > Wrong Cookie > > Policy: > - Id: Pol-256-256 > Algorithm: Rsasha256 # Was Ecdsap256sha256 Sra Uses Ecdsap384sha384 > Manual: On > Delete-Delay: 30d > Unsafe-Operation: No-Check-Keyset > ... > template: > - id: default > storage: /var/lib/knot/primary > semantic-checks: on > file: %s > global-module: mod-rrl/default > global-module: mod-cookies/default > - id: signed > storage: /var/lib/knot/signed > dnssec-signing: on > dnssec-policy: pol-256-256 > semantic-checks: on > zonefile-sync: -1 > zonefile-load: difference > journal-content: all > serial-policy: unixtime > > sra and i have been beating our heads on this for two days. and there > are significant zones breaking > > randy -- Korry Luke ルーク,　コリー koluke(a)wide.ad.jp Graduate School of Media and Governance Keio University Shonan Fujisawa Campus 慶應義塾大学湘南藤沢キャンパス政策・メディア研究科

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

3
3
0 0

Knot DNS 3.3.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.6! This is mostly a maintenance version with some improvements. Please note that Knot DNS 3.3 is the last major version officially supported on CentOS 7 (and similar), Debian 10, and Ubuntu 18.04. Version 3.4.0, which will be released in August, will not support them. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.6 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

1
0
0 0

Knot DNS serverupgrade tool (2.2.x->3.3.x)

by Josef Karliak

Good morning, is there some tool to migrate configuration from Knot 2.2 to actual 3.3.x ? There are some configuration changes, they're so far so good, but I'm stuck on migrating DNSSEC keys now. Thanks and best regards. J.Karliak

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

2
1
0 0

install package to freebsd

by André Cruz

Hi, When i try to install knot via ports as your documentation sayshttps://www.knot-dns.cz/docs/2.4/html/installation.html [cid:f31a0a83-7640-46e7-8586-d353f8c3d8f0] it points me to a verison of 2015 https://www.freshports.org/dns/knot Can you guys change the line to # cd /usr/ports/dns/knot3 just to be more clear for a new user of freebsd https://www.freshports.org/dns/knot3 Com os meus melhores cumprimentos, André Cruz

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

3
3
0 0

module 'mod-onlinesign/authsignal', incompatible with automatic signing

by Erwin Lansing

Howdy, I’m trying to get Knot 3.3.5 to use authenticated DNSSEC bootstrapping following the blog article and docs. However, I’m getting an error for the signalling zones, but I fail to figure out what I may have overlooked. error: [_signal.ns2.droso.dk <http://signal.ns2.droso.dk/>.] module 'mod-onlinesign/authsignal', incompatible with automatic signing Relevant knot.conf snippets (in order): policy: - id: ecc algorithm: ecdsap256sha256 nsec3: on rrsig-refresh: 7d mod-onlinesign: - id: authsignal nsec-bitmap: [CDS, CDNSKEY] policy: ecc template: - id: default … dnssec-signing: on dnssec-policy: ecc … zone: - domain: _signal.ns2.droso.dk <http://signal.ns2.droso.dk/> module: [mod-authsignal, mod-onlinesign/authsignal] Any hint appreciated Best Erwin

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

3
3
0 0

KNOT resolver and NS serverers with CNAME

by Josef Karliak

Good morning, ISC bind is strict about CNAME of NS server: skipping nameserver 'aa.bb.cz' because it is a CNAME, while resolving '9.4/4.3.2.1.in-addr.arpa/PTR'. How about Knot resolver ? Thanks and best regards J.Karliak

1 rok

4
3
0 0

Remotely adding zones

by Einar Bjarni Halldórsson

Hi, I have a use case, where today we’re running BIND and a daemon uses rndc to create/remove/update zones on secondary servers. According to `man knotc` knotc only supports UNIX sockets (old ubuntu man page showed ‘-p’ parameter to specify port). I know I could use a catalog zone, but that would be a bigger change than I prefer right now. The primary server is running BIND+DLZ with a PostgreSQL backend. Replacing the primary is on the roadmap, but for now, I just want to replace the secondaries. Is there a good way to remotely add zones to a knot secondary? .einar

1 rok, 1 měsíc

3
3
0 0

knotc reload after updates to knot.conf

by Angus Clarke

Hello, When doing something quite dramatic in knot.conf like adding and/or removing a zone, is "knotc reload" a suitable approach to honour those changes or would you recommend restarting the whole process? "knotc reload" seems to work just fine in test, I'm just looking for some further confidence I suppose. Thanks Angus

1 rok, 1 měsíc

2
1
0 0

kzonecheck for bookworm

by Randy Bush

a bit confused here. knot package for bookworm does not seem to include kzonecheck. nor does knot-dnsutils. where/how to get? thanks randy

1 rok, 1 měsíc

2
2
0 0

AXFR sender FINs 10% of the way through transfer

by Randy Bush

debian 12 # uname -a Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux # knotc --version knotc (Knot DNS), version 3.2.6 AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern africa, ...) fails over v5 and v6, i.e. somewhat larger rtt same AXFR seattle seattle or seattle to ashburn works v4 and v6. seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop. when it fails, it is always within a hundred or so mytes of the same place, approximately 10% through the file. pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap the last payload is in frame 217. at 219, seattle (b) sends a FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil) FIN/ACKs seattle's FIN and we're dead. i am not positive this is the key question as my tcp fu is a bit rusty. but why did seattle send the FIN at 219, 10% through the file? randy

1 rok, 2 měsíce

3
7
0 0

silly nit

by Randy Bush

in address: [185.91.97.18, 2a05:e380:2:4::2] # nabil.beirutix.net if this is a tab character ^ # knotc conf-check error: config, file '/etc/knot/knot.conf', line 324, item 'address', value '2a05:e380:2:4::2' (tabulator character is not allowed) blanks are ok # knotc --version knotc (Knot DNS), version 3.2.6 yes, that is the latest on debian 12 randy

1 rok, 2 měsíce

1
0
0 0

bitw signing as secondary

by Randy Bush

server runs a tld as primary, but slds are hidden primaries which the server pulls as a secondary, wants to sign bump-in-the-wire, and then make available to public secondaries. i think that the doc says this is doable, but instructions are insufficiently explicit for this idjit. i am fetching the slds into policy: - id: pol-256-256 algorithm: rsasha256 # was ecdsap256sha256 sra uses ecdsap384sha384 manual: on ... template: - id: signed storage: /var/lib/knot/sec-sign dnssec-signing: on dnssec-policy: pol-256-256 zonefile-sync: -1 zonefile-load: difference journal-content: all serial-policy: unixtime ... zone: - domain: sld.tld file: tld.sld # sorry, i like alpha sort in `ls` :) master: hidden-fetch template: signed acl: [allow-local, secondaries-push] the policy and template are those from signing primary zone; which i suspect is ill advised. i did generate keying as i would when signing a primary zone # keymgr sld.tld generate algorithm=rsasha256 ksk=yes zsk=yes 7a618eaf94ea1d903233cb547faa24bae8cb49a5 # knotc zone-reload sld.tld OK # keymgr sld.tld ds sld.tld. DS 63562 8 2 2d25e465f131900413d7e8a90ad1b96c75ba835de63dfee08610b113a779d41f sld.tld. DS 63562 8 4 ed9c31c495703ec354f1a1835c9878339224cc06ac3001151c2ebb89524b25190efa424348c999b0c4df940edffa8409 any kind soul(s) care to whack me with a clue bat? randy

1 rok, 2 měsíce

3
5
0 0

Possible signing bug? Missing wildcard NSEC for RCODE 3 subdomains

by Matthew Pounsett

I got a report of an NSEC error from someone who tried to connect to a mistyped hostname. I've done a bit of poking, and it looks like we're seeing a missing wildcard NSEC for domain names that are two subdomains down from the apex, but not for subdomains of the apex. Though, I admit I can't see the problem myself. Querying by hand I see what looks like an identical response, but resolvers and DNSViz report problems with the deeper name. For example, nonexistent.dns-oarc.net and nonexistent.sjc.dns-oarc.net ( sjc.dns-oarc.net is a real subdomain with hosts in it, not an ENT)... kdig output and DNSViz results below. We're running knot/unknown,now 3.3.5-cznic.1~bullseye from deb.knot-dns.cz, and this is the relevant policy statement for the zone: policy: - id: ecdsa algorithm: ecdsap256sha256 ksk-lifetime: 365d ksk-submission: parent_zone_sbm zsk-lifetime: 30d rrsig-lifetime: 14d rrsig-refresh: 7d We are mid-KSK-roll, waiting on the DS submission check. Have I misconfigured something here, or is there a signing bug, or is this something else? Thanks! Matt --- nonexistent.sjc.dns-oarc.net: DNSviz reports this is fine. <https://dnsviz.net/d/nonexistent.dns-oarc.net/ZfNH1w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 9380 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 nfsen.dns-oarc.net. 3600 IN NSEC ns.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN NSEC fs1.10g.dns-oarc.net. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CDS CDNSKEY CAA dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] nfsen.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] dns-oarc.net. 3600 IN RRSIG NSEC 13 2 3600 20240322045130 20240308032130 6048 dns-oarc.net. [omitted] ;; Received 518 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms nonexistent.sjc.dns-oarc.net: resolvers and DNSViz report a missing wildcard NSEC <https://dnsviz.net/d/nonexistent.sjc.dns-oarc.net/ZfNH6w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 660 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.sjc.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 newmail.sjc.dns-oarc.net. 3600 IN NSEC pdu-7301.sjc.dns-oarc.net. A AAAA RRSIG NSEC shin-cubes.dns-oarc.net. 3600 IN NSEC an1.10g.sjc.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] newmail.sjc.dns-oarc.net. 3600 IN RRSIG NSEC 13 4 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] shin-cubes.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] ;; Received 544 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms

1 rok, 2 měsíce

4
4
0 0

Chained catalog zones

by Martin Huněk

Hi folks, Is it possible to chain multiple upstream catalog zones into one downstream one? I do have the following topology: Multiple DNS hidden masters <-> DNS signer / DNS master for public facing slaves <-> public facing slaves Can I define catalog zones on hidden masters and use them on public-facing signer/master to compose a catalog zone for the slaves? Best Regards, Martin Hunek Freenet Liberec, z.s.

1 rok, 2 měsíce

4
6
0 0

Knot DNS 3.3.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.5! This is a bugfix version with a few new features and enhancements. For those who use dnssec-validation, upgrade is recommended. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.5 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, 2 měsíce

2
3
0 0

zone lost its KSK

by Bastien Durel

Hello, today I had a long power outage that stopped my primary server for a dozen hours When I re-started the server, some zones refused to start : Feb 12 21:55:17 arrakeen knotd[20728]: info: [geekwu.org.] DNSSEC, signing zone Feb 12 21:55:17 arrakeen knotd[20728]: error: [geekwu.org.] zone event 're-sign' failed (invalid parameter) the invalid parameter was there was no active KSK for these zones, as a keymgr list show b37b6c2[...] 39945 KSK ECDSAP384SHA384 publish=1636966605 active=1637053005 7cc8622[...] 20799 ZSK ECDSAP384SHA384 created=1706695010 After manually setting published & active status in keygmr, reloading these zones succeeded, and knot restarted to serve them. Do you know how these zone could has failed as this ? They run fine on auto-sign for years now. should I monitor closely the ones that need a re-sign tomorrow ? Regards, -- Bastien

1 rok, 3 měsíce

4
9
0 0

error: [ellael.org.] zone event 'refresh' failed (operation not supported)

by Michael Grimm

Hi, after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I started to migrate my secondary NSDs to Knot DNS as well. Thanks to excellent documentation this migration went more or less flawless as well. BUT: I am somehow irritated about the following error messages at my hidden primary like: 2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote 10.1.1.201@27919, key primary-secondary. 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP, started, serial 2024021331 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP, finished, 0.00 seconds, 1 messages, 7774 bytes 2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote 10.1.1.201@40884, key primary-secondary. 2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884 TCP, serial 2024021331 >>>! 2024-02-16T10:54:09+0100 error: [ellael.org.] zone event 'refresh' failed (operation not supported) The log files at both secondary are identical, here one example: 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP, finished, 0.00 seconds, 1 messages, 7774 bytes 2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone updated, 0.03 seconds, serial none -> 2024021331,\ expires in 1209600 seconds 2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331 >>>! 2024-02-16T10:54:09+0100 info: [ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331 FYI: Those errors are only logged when a zone gets updated or using "knotc zone-notify" at the secondary site. Here are my essential config excerpts: Primary: acl: - id: aclTRANSACTIONS key: primary-secondary action: [notify, transfer] remote: - id: secondaryKBN key: primary-secondary address: 10.1.1.201 # KBN secondary via: 10.2.2.203 # outgoing interface Secondary: acl: - id: aclTRANSACTIONS key: primary-secondary action: [notify, transfer] remote: - id: primaryMWN key: primary-secondary address: 10.2.2.203@5333 # MWN hidden primary via: 10.2.2.201 # outgoing interface block-notify-after-transfer: on FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped those error messages. I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html : "I recommend not using this option unless you really know what you're doing and why this option is essential for you." Questions: #) I do have to admit, I don't understand what is going on without "block-notify-after-transfer: on"? #) Am I save in using "block-notify-after-transfer: on"? #) Or is the another config option? Thanks in advance and regards, Michael

1 rok, 3 měsíce

3
14
0 0

Secondary zones with some primary servers unreachable log interesting errors

by Juha Suhonen

Hello fellow Knot users, We're using Knot on some of our public authoritative servers. We operate a hidden primary configuration where there are two internal primary servers sending notifies to publicly accessible servers whenever zones change (ofc internal servers allow zone transfers & queries from the knot servers). By design, our hidden internal primary servers operate in a hot/cold setup - one of them is answering to zone transfers / sending out notifies and the other one is not (dns server software is not running on the cold server). This configuration causes knot to log alarming errors: Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote 10.54.54.1@8054, remote serial 2021083015, zone is up-to-date, expires in 864000 seconds Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address 10.54.54.2@8054, failed (connection reset) Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address [ipv6_address]@8054, failed (connection reset) Feb 1 17:28:45 ns2 knotd[624]: warning: [zone.fi.] refresh, remote hidden-ns-2.internal not usable Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] refresh, failed (no usable master), next retry at 2024-02-01T17:58:45+0200 Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] zone event 'refresh' failed (no usable master) Specifically, error "(no usable master)" is worrying - knot is able to reach hidden-ns-1.internal and verify that the zone it has is up-to-date. Also zone updates work normally and the zones don't seem to expire away (as zones should do if no master is reachable for an extended period of time). Looks like this error appeared in version 3.3.0. 3.2.9 did not log similar errors (except in cases where all primaries really were unreachable). Has there been some design change in 3.3.0 (ie is this intentional) or could this be a bug? Or could it be related to our configuration? Our configuration relies heavily on templates. These should be the important bits from knot's config, with ipv6 addresses hidden: acl: - id: "hidden-ns-1.internal" address: [ 10.54.54.1, ipv6_address ] action: notify - id: "hidden-ns-2.internal" address: [ 10.54.54.2, ipv6_address ] action: notify remote: - id: "hidden-ns-1.internal" address: [ 10.54.54.1@8054, ipv6_address@8054 ] via: [ x.x.x.x, ipv6_address ] - id: "hidden-ns-2.internal" address: [ 10.54.54.2@8054, ipv6_address@8054 ] via: [ x.x.x.x, ipv6_address ] template: - id: default storage: /var/lib/knot/zones master: hidden-ns-1.internal master: hidden-ns-2.internal acl: hidden-ns-1.internal acl: hidden-ns-2.internal semantic-checks: false global-module: mod-rrl/default zone: - domain: zone.fi -- Juha Suhonen Senior Systems Specialist CSC - Tieteen tietotekniikan keskus Oy juha.suhonen(a)csc.fi

1 rok, 3 měsíce

2
1
0 0

Set propagation-delay based on multiples of SOA TTL, doable?

by Michael Grimm

Hi, I wonder if it would be possible that one may use arithmetics in knot.conf such as: propagation-delay: 5 * dnskey-ttl I'd like to set a propagation-delay safety net during ZSK rotations depending on SOA TTL set for any given zone. As dnskey-ttl defaults to zone SOA TTL that would allow for propagation-delay definitions as multiples of SOA TTLs. As I couldn't find that in the documentation, I do assume that this cannot be done, right? Are there alternatives at hand I overlooked? Regards, Michael

1 rok, 3 měsíce

2
2
0 0

keymgr segmentation fault

by Erik P. Ostlyngen

Hi, I'm evaluating the Knot DNS server as a DNSSEC signer engine. I'm currently running version 3.2.6 together with SoftHSM version 2.6.1 on an Ubuntu 20.04 linux server. Now I have a problem with keymgr crashing with a segmentation fault and dumping core. This happens with some of the commands of keymgr, but not all (the command keymgr -l runs fine). The commands 'keymgr trondheim.no list' produces the correct output, but then crashes. /var/log/apport.log indicates that a dbus session is missing in the environment: ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: called for pid 811052, signal 11, core limit 0, dump mode 2 ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: not creating core for pid with dump mode of 2 ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: executable: /usr/sbin/keymgr (command line "keymgr trondheim.no list") ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: apport: report /var/crash/_usr_sbin_keymgr.0.crash already exists and unseen, skipping to avoid disk usage DoS Running the command as 'dbus-run-session keymgr trondheim.no list' gives: ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: called for pid 811173, signal 11, core limit 0, dump mode 2 ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: not creating core for pid with dump mode of 2 ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: executable: /usr/sbin/keymgr (command line "keymgr trondheim.no list") ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: is_closing_session(): Could not determine DBUS socket. ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: apport: report /var/crash/_usr_sbin_keymgr.0.crash already exists and unseen, skipping to avoid disk usage DoS I've tried to run the command as root and as the knot user, and I have to admit that I'm not very familiar with how to manage dbus sessions. I want to run the keymgr command from cron or from some other system shell, for periodically monitoring the keys. However, I'm unsure why keymgr wants to communicate on the dbus. Is it possible to disable this? Regards, Erik Østlyngen

1 rok, 3 měsíce

2
2
0 0

DDNS not working as expected

by JeeF Software spol. s r.o.

Hi Knot-DNS Support, I'm trying simple DDNS scenario (no keys, no DNSSEC) with failing result. Knot-DNS is installed from docker image. Could you let me know what is the issue (NOAUTH) and how can I solve it or if this scenario is not supported what exactly is required by DDNS? ------------------------------------------- knot.conf: server: rundir: "/rundir" user: knot:knot automatic-acl: on listen: 0.0.0.0@53 log: - target: stdout server: debug zone: debug any: debug database: storage: "/storage" acl: - id: acl_update action: update - id: acl_transfer action: transfer template: - id: default storage: "/storage" file: "%s.zone" zone: # Primary zone - domain: example.com acl: [acl_update, acl_transfer] ---------------------------------------------- update: server 10.2.0.88 zone exmaple.com update add _acme-challenge.example.com. 300 TXT "aaaaa" send -------------------------------------------- knsupdate -d < update ;; DEBUG: cmd_server: lp='10.2.0.88' ;; DEBUG: parse_host: parsed addr: 10.2.0.88 ;; DEBUG: cmd_zone: lp='exmaple.com' ;; DEBUG: cmd_update: lp='add _acme-challenge.example.com. 300 TXT "aaaaa"' ;; DEBUG: cmd_add: lp='_acme-challenge.example.com. 300 TXT "aaaaa"' ;; DEBUG: cmd_send: lp='' ;; DEBUG: sending packet ;; DEBUG: pkt_sendrecv: send_msg = 3 ;; DEBUG: pkt_sendrecv: receive_msg = 29 ;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 27029 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 0 ;; ZONE SECTION: ;; exmaple.com. IN SOA ;; ERROR: update failed with error 'NOTAUTH' ;; DEBUG: operation 'send' failed (failed) on line 'send' ;; DEBUG: srv_info_free: null parameter ----------------------------------------- knotd log 2023-09-05T17:16:35+0000 info: Knot DNS 3.3.0 starting 2023-09-05T17:16:35+0000 info: loaded configuration file '/config/knot.conf', mapsize 500 MiB 2023-09-05T17:16:35+0000 info: using UDP reuseport, incoming TCP Fast Open 2023-09-05T17:16:35+0000 info: binding to interface 0.0.0.0@53 2023-09-05T17:16:35+0000 info: changing GID to 8521 2023-09-05T17:16:35+0000 info: changing UID to 9396 2023-09-05T17:16:35+0000 info: loading 1 zones 2023-09-05T17:16:35+0000 info: [example.com.] zone will be loaded 2023-09-05T17:16:35+0000 info: starting server 2023-09-05T17:16:35+0000 info: [example.com.] zone file parsed, serial 2010111213 2023-09-05T17:16:35+0000 info: [example.com.] loaded, serial none -> 2010111213, 465 bytes 2023-09-05T17:16:35+0000 info: control, binding to '/rundir/knot.sock' 2023-09-05T17:16:35+0000 info: server started in the foreground, PID 8 2023-09-05T17:18:03+0000 info: [example.com.] control, received command 'zone-status' 2023-09-05T17:18:40+0000 info: [example.com.] control, received command 'zone-sign' 2023-09-05T17:18:40+0000 error: [example.com.] control, error (operation not supported) 2023-09-05T17:18:52+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:18:56+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:18:56+0000 error: [example.com.] control, error (no such node in zone found) 2023-09-05T17:19:00+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:19:45+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:19:45+0000 error: [example.com.] control, error (no active transaction) 2023-09-05T17:22:57+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:22:57+0000 error: [example.com.] control, error (no active transaction) 2023-09-05T17:23:49+0000 info: [example.com.] control, received command 'zone-begin' 2023-09-05T17:23:54+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:24:02+0000 info: [example.com.] control, received command 'zone-commit' 2023-09-05T17:24:02+0000 info: [example.com.] zone file updated, serial 2010111213 -> 2010111214 btw. no info positive/negative regarding the DDNS -------------------------------------- example.com.zone example.com. 3600 SOA dns1.example.com. hostmaster.example.com. 2010111214 21600 3600 604800 86400 example.com. 3600 A 1.2.3.4 example.com. 3600 NS dns1.example.com. example.com. 3600 NS dns2.example.com. example.com. 3600 MX 10 mail.example.com. dns1.example.com. 3600 A 192.0.2.1 dns1.example.com. 3600 AAAA 2001:db8::1 dns2.example.com. 3600 A 192.0.2.2 dns2.example.com. 3600 AAAA 2001:db8::2 mail.example.com. 3600 A 192.0.2.3 mail.example.com. 3600 AAAA 2001:db8::3 Thanks. Best Regards, JohnF

1 rok, 3 měsíce

2
1
0 0

NSEC3 RR not generated, dunno why.

by Michael Grimm

Hi, I am still very new to knot ;-) FYI: This is Knot DNS 3.3.3 because 3.3.4 hasn't been shown up in FreeBSD's ports collectioon, yet. Here are my settings regarding dnssec policy: policy: - id: ecdsa algorithm: ecdsap256sha256 ksk-lifetime: 3650d zsk-lifetime: 330d propagation-delay: 1d nsec3: on cds-cdnskey-publish: rollover Whatever I tell nsec3, either "on" or "true", only NSEC RR are generated, no NSEC3. dns> grep -i nsec3 zones/ellael.org dns> dns> grep -i nsec zones/ellael.org 3600 IN RRSIG NSEC 13 2 3600 20240226084528 20240212071528 9562 ellael.org. fkpFcgkVq8ZRZT0GX5kVcfPZBB5S/2Gvh4XqrkrywbZXFKiCttYqCX7rBdJSbyem5G8Bxg1LKaxu7LrIoxtyVA== 3600 IN NSEC _dmarc.ellael.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CAA 3600 IN RRSIG NSEC 13 3 3600 20240226084528 20240212071528 9562 ellael.org. R7Pz2JuKi7vQDe0KMt29NHGtKvuEnH2LPKcxTWLP9HyfuMxJx4BEyPE6i+JAw8RxfSIqWAcV/KMyCHaLgFtXXw== 3600 IN NSEC _token._dnswl.ellael.org. TXT RRSIG NSEC 3600 IN RRSIG NSEC 13 4 3600 20240226084528 20240212071528 9562 ellael.org. 3oUCWWTH2s9oH/Ea0b+MDrrQcOEuTbwx1iEuXaLq7wFribrnIGY8JeeiE3TO59n1lckKm4hia+2ox324xoxCzA== [snip] What am I doing wrong? Thanks in advance and kind regards, Michael

1 rok, 3 měsíce

2
4
0 0

How to check for next KSK or ZSK rollover dates?

by Michael Grimm

Hi, I am very new to Knot [1]. Excerpts from my knot.conf: policy: ... ksk-lifetime: 3650d zsk-lifetime: 330d propagation-delay: 1d ... dns> knotc zone-status ellael.org [ellael.org.] role: master | serial: 2024021201 | re-sign: +12D8h42m21s I am a bit puzzled by that "re-sign: +12D8h42m21s". Does that mean "time until newly issued signatures" and becomes triggered by default "rrsig-lifetime: 14d" value? If so, I am very much relieved, if not, what is going on, then? Here is my question: How can I find out the dates for upcoming KSK or ZSK rollovers? This I couldn't find in the documentation, sorry. Thanks and regards, Michael [1] I've been bitten by that subtle bug in mailing list processing system ;-) My questions regarding migration strategy has become obsolete in the meantime, because I managed to migrate successfully. Thanks to the great documentation of Knot I could help myself ;-)

1 rok, 3 měsíce

2
2
0 0

GUI Frontends for Knot DNS Server

by Turritopsis Dohrnii Teo En Ming

Subject: GUI Frontends for Knot DNS Server Good day from Singapore, Are there any GUI frontends for configuring Knot DNS Server? I prefer GUI configuration interface. It is more efficient than command line interface (CLI). Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com

1 rok, 3 měsíce

2
1
0 0

kresd not starting with lua error

by Mike Wright

Hello, Running knot-resolver 5.6.0-1 amd64 (latest available via apt) on debian-12 bookworm, fully upgraded. systemctl start kresd@1 fails to run. systemctl status kresd@1 shows the following errors: [system] error while loading config: ...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad argument #1 to 'create' (table expected, got nil) (workdir '/var/lib/knot-resolver') Here is my kresd.conf. It had been running ok for a long time ( I don't recall making any changes) : - Default empty Knot DNS Resolver configuration in -*- lua -*- -- Bind ports as privileged user (root) -- net = { '127.0.53.0' } -- Switch to unprivileged user -- user('knot-resolver','knot-resolver') -- Unprivileged -- cache.size = 100*MB policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'127.53.0.0'}), internalDomains)) policy.TLS_FORWARD({ -- multiple servers can be specified for a single slice -- the one with lowest round-trip time will be used {'9.9.9.9', hostname='dns.quad9.net'}, {'149.112.112.112', hostname='dns.quad9.net'}, }) All help is greatly appreciated, Mike Wright

1 rok, 3 měsíce

2
1
0 0

warning - a few lost e-mails to the mailing list

by David Vasek

Dear mailing list subscribers, due to a subtle bug in our mailing list processing system, a few emails sent to the mailing list <knot-dns-users(a)lists.nic.cz> over the past two years were blocked and awaiting approval without our knowledge. After filtering out spam, we will review what we believe is still relevant and reach out to the senders directly in the coming days. If your email did not pass through the moderation phase, please resend it to the list after the middle of next week. We are sorry for this issue. Our thanks go to Juha Suhonen who helped us discover the problem by pointing out that his email is still waiting. Thank you, Juha. Best regards, David Vašek, Knot DNS team

1 rok, 3 měsíce

1
0
0 0

Knot DNS 3.3.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.4! This is a bugfix version with some enhancements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.4 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, 4 měsíce

1
0
0 0

TSIG key in remote and acl

by Einar Bjarni Halldórsson

Hi, I’m updating our config files and I’m wondering if we need to set ‘key’ in remotes section, and in acl section? If I have this in my config: remote: - id: remote01 address: 127.0.0.1 key: my_key acl: - id: allow_transfer address: 127.0.0.1 key: my_key action: transfer zone: - domain: example.com acl: [ allow_transfer ] notify: [ remote01 ] Couldn’t I just remove key attribute from the remote, since the acl declares the address and key that are allowed to transfer the zone? .einar

1 rok, 4 měsíce

4
6
0 0

Knot DNS 3.2.12 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.12! This version only backports some fixes from 3.3.3. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.2.12 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, 5 měsíců

1
0
0 0

Knot DNS 3.3.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.3! This is mostly a bugfix version. Upgrade is recommended for QUIC and TCP/XDP users. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.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, 5 měsíců

1
0
0 0

Knot DNS 3.2.11 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.11! This version only backports some fixes from 3.3.2. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.2.11 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, 6 měsíců

1
0
0 0

Message compression (was: Re: Knot DNS 3.3.2 release)

by Robert Edmonds

Daniel Salzman wrote: > Hello Knot DNS users, > > CZ.NIC has released Knot DNS 3.3.2! > > This version fixes various issues and introduces some features regarding IXFR. > Users of PKCS #11 keystore might appreciate improved signing performance using more thread. > > Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side! > > Changelog: > https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS Hi, I'm interested in this change: - knotd: failed to sign RRSet that fits to 64k only if compressed Which seems to be this commit: https://gitlab.nic.cz/knot/knot-dns/-/commit/f55037f6f39d0ddf6debac47fe168d… "libknot/knot: allow uncompressed wire conversion of rrset that fits to 64k only when compressed" It's not totally clear to me, but it seems like this would allow an RRset (or individual RR, if the number of RRs in the RRset is 1?) that, exceeds 64K, if name compression would reduce the size on the wire to <64K? (And the 64K isn't measured by just the RDATA/RDLEN fields, but rather the whole wire serialization of the record set, including owner name, type, class, TTL, etc.) If so, is this a safe and/or interoperable thing to do? DNS implementations are required to implement decompression, but compression is optional (RFC 1035 § 4.1.4). So a resolver might receive a compressed RRset, decompress it, and then be unable to represent that RRset to clients if it doesn't implement compression, or, more likely, implements compression but uses an algorithm that generates less optimal compression targets than the one used by the original nameserver. Or am I misunderstanding what this commit is doing? Thanks! -- Robert Edmonds edmonds(a)debian.org

1 rok, 7 měsíců

2
1
0 0

Knot DNS 3.3.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.2! This version fixes various issues and introduces some features regarding IXFR. Users of PKCS #11 keystore might appreciate improved signing performance using more thread. Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/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, 7 měsíců

1
0
0 0

Knot DNS 3.3.1 and 3.2.10 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.1 and 3.2.10! These versions fix several bugs. Upgrade is recommended. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.1/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.10/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, 8 měsíců

1
0
0 0

Knot DNS 3.3.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.0! This version brings full DNS/XFR over QUIC support, multi-signer operation mode, and many more. See the changelog. Debian and Ubuntu users can download the packages from a new repository https://pkg.labs.nic.cz/doc/?project=knot-dns This repository is common to both distributions and Knot versions (older versions must be pinned). Additionally, the repository will contain some historical Knot versions. Prometheus exporter https://github.com/salzmdan/knot_exporter (a fork of https://github.com/ghedo/knot_exporter) has been replaced with https://pypi.org/project/knot-exporter/ and distribution package knot-exporter (currently for Debian and Ubuntu). Today Knot DNS 3.1 reached its End-of-life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-2-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, 8 měsíců

3
3
0 0

Understanding block-notify-after-transfer

by Jan-Piet Mens

Hello! I have a Knot 3.2.5 server running here which, for most zones, acts as a bump-in-the-wire signer, and it's doing exactly what I expect it to do. The same server carries a few secondary zones which are not signed, and I notice that when Knot transfers these zones in, it doesn't NOTIFY its secondaries, something which works fine for DNSSEC signed zones. The following configuration is in place: remote: - id: pdns address: 192.168.25.45@53 key: dsupload block-notify-after-transfer: on # <------- automatic-acl: on template: - id: default zonefile-load: difference file: "%s" serial-policy: dateserial master: pdns catalog-role: member catalog-zone: katz1 acl: [ xfr, notify_from_pdns, xfer_to_bind ] notify: [ s1, s2, s3 ] policy: - id: manualHSM manual: on keystore: thales cds-cdnskey-publish: rollover ksk-submission: ds_checker ds-push: pdns zone: - domain: sig.example dnssec-policy: manualHSM dnssec-signing: on - domain: notsig.example dnssec-signing: off When sig.example is transferred in, Knot signs it, NOTIFYs its secondaries (s1--s3), they XFR the zone and all's well. When the unsigned notsig.example is transferred in, the logs indicate Knot is seeing the new serial, and that's it; the secondaries are not NOTIFYd. (I can manually `knotc notify', but that's not the point.) Setting `block-notify-after-transfer: off' on the remote remediates this. Knot then does NOTIFY its secondaries for the unsigned zone (and for the signed zone). The documentation states: "When incoming AXFR/IXFR from this remote (as a primary server), suppress sending NOTIFY messages to all configured secondary servers." However, if I swich it off (i.e. enable notification), I do not see the NOTIFY when knot initially transfers the unsigned zone which is then signed and hence then notified. Is this behavior expected, and have I interpreted it correctly? Thanks & best regards, -JP

1 rok, 9 měsíců

2
2
0 0

Knot DNS 3.2.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.9! This is a bug fix version. Upgrade is recommended. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.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

1 rok, 10 měsíců

1
0
0 0

Is it safe to alter dnssec-policy for a zone?

by Jan-Piet Mens

I have a zone for which I'd like to ensure an admin cannot mistakenly kick off a KSK rollover, so I am considering setting configuring its dnssec-policy to one with `manual: on' which prevents even a `knotc zone-key-rollover' on it. I have experimented with switching `manual: on' to `manual: off', and the idea seems to work. I have also apparently successfully been able to alter `ksk-lifetime', and have not noticed anything going wrong. Based on this, I wish to know if it is considered safe to alter many (all?) of a policy's settings, as long as neither algorithm nor key sizes are changed, and whether it is safe to alter the policy itself (i.e. also change a policy name for a zone). ksk-lifetime, delays, rrsig-lifetimes, ksk-submission, etc.: can all these be changed without breaking signing of a zone? Thank you & regards, -JP

1 rok, 10 měsíců

2
2
0 0

zone event 'flush' on catalog?

by Jan-Piet Mens

Hello! I have here a catalog zone with roughly 230 member zones in it, and I occasionally see the following warning/error in the log: 2023-07-12T18:01:17+0200 warning: [k-catalog.] failed to update zone file (operation not permitted) 2023-07-12T18:01:17+0200 error: [k-catalog.] zone event 'flush' failed (operation not permitted) The catalog itself appears to work correctly; it's transferred to secondary BIND servers and they correctly process member zones. template: - id: default storage: "..." zonefile-load: difference file: "%s" serial-policy: dateserial master: pdns catalog-role: member catalog-zone: k-catalog acl: [ xfr, notify_from_pdns, xfer_to_bind ] - id: catzonetemplate catalog-role: generate acl: xfer_to_bind zone: - domain: k-catalog semantic-checks: off template: catzonetemplate journal-content: none acl: [ xfr, xfer_to_bind ] While pasting the configuration it occurs to me it might be due to there not being a 'backing' file for the catalog. Is that the problem? Is it even possible on a catalog-role:generate to have a file? Thanks for your help. -JP

1 rok, 10 měsíců

2
2
0 0

catalog-role:interpret broken since upgrade to knot 3.2.6

by Daniel Gröber

Hi Knotty people, I've started uprading my infrastructure to Debian 12 which comes with knot 3.2.6 (instead of 3.0.5) and since the upgrade my catalog zone configuration doesn't seem to work anymore. I have this in knot.conf: zone: - domain: dxld.catalog catalog-role: interpret catalog-template: dxld-master template: dxld-master dxld.catalog gets loaded properly, `knotc zone-read dxld.catalog`: [dxld.catalog.] dxld.catalog. 0 SOA ns0.dxld.at. hostmaster.dxld.at. 2023070601 900 300 86400 300 [dxld.catalog.] version.dxld.catalog. 0 TXT "2" [dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.at. [dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.net. [dxld.catalog.] zones.dxld.catalog. 0 PTR darkboxed.org. but the zones pointed to don't get instantiated (as seen by `knotc zone-status`). Any ideas what could have changed to break this? Thanks, --Daniel

1 rok, 10 měsíců

4
5
0 0

Knot DNS 3.2.8 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.8! This is a bug fix version. Upgrade is recommended for users of version 3.2.7 with journal enabled. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.8/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, 11 měsíců

1
0
0 0

Failed to load journal (loop detected)

by Ondřej Caletka

Hey, after an (unattended) upgrade to 3.2,7, one of my zones (the one that does rapid KSK rollovers) failed to load. Trying ro reload emits these errors in the log: info: [83.204.91.in-addr.arpa.] zone file parsed, serial 1622013488 error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial 1622013488 -> 1686209286 (loop detected) 2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial 1622013488 -> 1686209286 (loop detected) warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected) 2023-06-23T12:11:57+0200 warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected) info: [83.204.91.in-addr.arpa.] zone not found error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists) 2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists) Calling `kjournalprint 83.204.91.in-addr.arpa` yields 600 lines of journal full of both additions and deletions, nothing seems particularly wrong. Is there anything I should try before purging the journal and starting from scratch? There are other zones on the same server with similar config that just work normally, so I guess this is somehow related to the size of the journal for this zone, which rotates DNSSEC keys very often. -- Cheers, Ondřej Caletka

1 rok, 11 měsíců

2
1
0 0

TCP requirement for catalog zones breaks interoperability

by Matthew Pounsett

The 3.0 documentation for catalog zones says the following: «The difference is that standard DNS queries to a catalog zone are answered with REFUSED as though the zone doesn’t exist, unless querying over TCP from an address with transfers enabled by ACL.» This seems like an odd requirement, and it breaks interoperability with other vendors' authoritative servers. BIND, for example, does not send the SOA check for a zone transfer over TCP, and so it's impossible to use a Knot primary and BIND secondary with catalog zones. Is there some way to work around this?

1 rok, 11 měsíců

2
2
0 0

Knot DNS 3.2.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.7! This is a bugfix version with some improvements. Please note that the 3.3.0 version will be released in August and the 3.1 branch will no longer be officially supported. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.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

1 rok, 11 měsíců

1
0
0 0

Monitor journal usage

by Einar Bjarni Halldórsson

Hi, Yesterday we got hit by the per-zone journal becoming full [1] As a result we're looking into how we can monitor the status to warn us if we're near the journal limits, but I can't find a way to report the currant journal usage (global and per-zone). Any ideas? [1] https://gitlab.nic.cz/knot/knot-dns/-/issues/842

2 roky

3
4
0 0

Knot DNS 3.2.6 release

by Daniel Salzman

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

2 roky, 1 měsíc

1
0
0 0

kresd 5.4.4 socket bug

by Mike Wright

Hi, Just upgraded knot-resolver on ubuntu-22.04. It installs and runs but shows that the socket is not where it thinks it is. Socket is at /run/knot-resolver/control@1 but the new version is looking for it at /run/knot-resolver/control/1 systemctl status is available here: https://pastebin.com/56g22e2a Thanks for the great software! Mike Wright

2 roky, 2 měsíce

1
0
0 0

Why does knot need so much prodding to XFR and sign my zones?

by Jan-Piet Mens

Hello! Knot 3.2.0 with a Thales HSM configured this way: (btw, I am not obfuscating addresses or zone names -- these are actual testing names :) keystore: - id: thales backend: pkcs11 config: "pkcs11:token=XX;pin-value=XXX /opt/nfast/toolkits/pkcs11/libcknfast.so" key-label: on policy: - id: manualHSM keystore: thales single-type-signing: off manual: on zone: - domain: tt05 dnssec-signing: on dnssec-policy: manualHSM master: pdns acl: [ xfr, notify_from_pdns ] The zone `tt05' exists on the primary and can be transferred, as the following logs will show. I start off by generating a KSK and a ZSK, and verify that the keys are actually on the HSM: $ keymgr tt05 generate algorithm=8 size=2048 ksk=yes zsk=no 579f877d1739efb7bcf551e41c8777e965f8416f $ keymgr tt05 generate algorithm=8 size=2048 ksk=no zsk=yes eb8ef53ebffbd9950bfa914f7f2b0f1cd43bbe63 $ cklist -n | grep tt05 CKA_LABEL "tt05. KSK" CKA_LABEL "tt05. ZSK" I now reload Knot, and at this point I am actually expecting the server to "see" the new zone, get the keys, perform the transfer (XFR) and sign the zone. But all that doesn't happen: $ knotc reload Reloaded 2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists) 2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load keys (not exists) 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:10:10+0100 2023-02-09T12:10:10+0100 error: [tt05.] refresh, failed (not exists) 2023-02-09T12:10:10+0100 error: [tt05.] zone event 'refresh' failed (not exists) In the above, I don't understand why it's failed to load the keys. My _assumption_ is that the server has enumerated the keys from the HSM but did that before the two keys for this zone were created. Invoking `knotc zone-keys-load' doesn't alter the situation. I do understand the 'refresh' failing, as the zone tt05 doesn't as yet exist on this knot secondary. So I initiate a zone transfer: $ knotc zone-retransfer tt05 OK 2023-02-09T12:11:04+0100 info: [tt05.] control, received command 'zone-retransfer' 2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists) 2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load keys (not exists) 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:11:04+0100 2023-02-09T12:11:04+0100 error: [tt05.] refresh, failed (not exists) 2023-02-09T12:11:04+0100 error: [tt05.] zone event 'refresh' failed (not exists) It is clear that the transfer succeeds (the logs on the primary corroborate this), and knot apparently knows the correct keys to use for the zone. Why is it not signing it? $ knotc zone-sign tt05 OK 2023-02-09T12:11:38+0100 info: [tt05.] control, received command 'zone-sign' 2023-02-09T12:11:38+0100 info: [tt05.] DNSSEC, dropping previous signatures, re-signing zone 2023-02-09T12:11:38+0100 error: [tt05.] zone event 're-sign' failed (invalid parameter) I now restart the server: # <restart knotd> 2023-02-09T12:12:16+0100 info: Knot DNS 3.2.0 starting 2023-02-09T12:12:16+0100 info: loaded configuration file '/etc/knot.conf', mapsize 500 MiB 2023-02-09T12:12:16+0100 info: using UDP reuseport, incoming TCP Fast Open 2023-02-09T12:12:16+0100 info: binding to interface 10.24.34.16@5353 2023-02-09T12:12:16+0100 info: changed directory to / 2023-02-09T12:12:16+0100 info: loading 7 zones 2023-02-09T12:12:16+0100 info: [tt05.] zone will be loaded 2023-02-09T12:12:16+0100 info: starting server 2023-02-09T12:12:18+0100 info: [tt05.] failed to parse zone file '/var/zones/tt05' (not exists) Here again, I understand it cannot parse the zone, because the transfer hasn't actually been comitted to disk. So I manually transfer: $ knotc zone-retransfer tt05 OK 2023-02-09T12:13:23+0100 info: [tt05.] control, received command 'zone-retransfer' 2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, signing started 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, successfully signed 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, next signing at 2023-02-23T11:13:24+0100 2023-02-09T12:13:23+0100 info: [tt05.] refresh, remote 192.168.33.31@53, zone updated, 0.44 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800 seconds 2023-02-09T12:13:23+0100 info: [tt05.] zone file updated, serial 2023010100 And now the zone is signed. Is there some way to 'streamline' this? :-) Or am I just doing something wrong or being too impatient? Best regards, -JP

2 roky, 3 měsíce

4
14
0 0

Knot DNS 3.2.5 release

by Daniel Salzman

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

2 roky, 3 měsíce

1
0
0 0

PKCS#11 label is not set on keys created by Knot

by Jan-Piet Mens

I note that the key label is not set when Knot generates new keys via PKCS#11. Invoking `p11tool --list-all' shows a key as Object 449: URL: pkcs11:model=;manufacturer=nCipher%20Corp.%20Ltd;serial=xxx;\ token=YYY;\ id=%04%66%D0%9C%0D%9E%24%D9%79%0A%17%D3%5D%A0%CC%5A%3F%E2%A3%26;\ type=public Type: Public key (RSA-2048) Label: ID: 04:66:d0:9c:0d:9e:24:d9:79:0a:17:d3:5d:a0:cc:5a:3f:e2:a3:26 The ID is that which `keymgr list' displays (with colons in it), but the label is empty. Is this by design? Would it be possible for Knot to actually set the label (e.g. zone name - key type: example.com-ksk)? Best regards, -JP

2 roky, 3 měsíce

2
7
0 0

Knot DNS 3.2.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.4! This version improves catalog zone performance and fixes some issues mostly related to zone transfers. Update from previous 3.2.x versions is recommended if primary nameserver isn't Knot DNS. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.4/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

2 roky, 5 měsíců

1
0
0 0

Knot DNS 3.2.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.3! This version fixes broken knsupdate and some QUIC-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.3/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

2 roky, 6 měsíců

1
0
0 0

knsupdate Segmentation fault

by Bastien Durel

Hello, Since I upgraded to 3.2.2-cznic.1~bullseye, my scripts using knsupdate fails, on every machine they run on. I can reproduce this with gdb, here is the trace I get in this case : Starting program: /usr/bin/knsupdate -k /etc/letsencrypt.sh/hooks/tsig.key /tmp/tmp.17EBRdeI8j [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000055555556161c in net_send (net=net@entry=0x7ffffffcbb80, buf=0x555555592a10 "\345\327(", buf_len=196) at utils/common/netio.c:587 587 utils/common/netio.c: No such file or directory. (gdb) where #0 0x000055555556161c in net_send (net=net@entry=0x7ffffffcbb80, buf=0x555555592a10 "\345\327(", buf_len=196) at utils/common/netio.c:587 #1 0x000055555555adee in pkt_sendrecv (params=params@entry=0x7ffffffcbdd0) at utils/knsupdate/knsupdate_exec.c:456 #2 0x000055555555ba01 in cmd_send (lp=<optimized out>, params=0x7ffffffcbdd0) at utils/knsupdate/knsupdate_exec.c:851 #3 0x000055555555b3e6 in knsupdate_process_line (line=line@entry=0x5555555755e0 "send", params=params@entry=0x7ffffffcbdd0) at utils/knsupdate/knsupdate_exec.c:498 #4 0x000055555555b5ed in knsupdate_process_line (params=0x7ffffffcbdd0, line=0x5555555755e0 "send") at utils/knsupdate/knsupdate_exec.c:486 #5 process_lines (params=params@entry=0x7ffffffcbdd0, input=input@entry=0x5555555910f0) at utils/knsupdate/knsupdate_exec.c:527 #6 0x000055555555bd3e in knsupdate_exec (params=params@entry=0x7ffffffcbdd0) at utils/knsupdate/knsupdate_exec.c:575 #7 0x0000555555559dc9 in main (argc=<optimized out>, argv=0x7fffffffe548) at utils/knsupdate/knsupdate_main.c:35 The nsupdate script (/tmp/tmp.17EBRdeI8j) is here (with truncated TXT) : server 10.42.42.21 zone durel.eu. origin durel.eu. ttl 600 add _acme-challenge.ns.durel.eu. 600 in TXT "qLH_KkbQ_IUVr[...]7rs-iUE" send quit As I can reproduce this with any tsig key, I can provide a core if you need it. -- Bastien Durel

2 roky, 6 měsíců

2
2
0 0

Knot DNS 3.2.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.2! This version brings a few new features and some fixes. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.2/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, 6 měsíců

1
0
0 0

Knot DNS 3.2.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.1! This version adds compatibility with libbpf 1.0 and fixes mostly XDP-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.1/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, 8 měsíců

1
0
0 0

policy.rrsig-refresh in Knot 3.2.0

by André Keller

Good morning, In Knot 3.2.0 the rrsig-refresh default changed, excerpt changlog: knotd: default value for 'policy.rrsig-refresh' is propagation delay + zone maximum TTL I'd like to understand the rationale behind this change and whether or not we should tune this parameter in our deployment. We currently have monitoring in place to ensure that we always serve valid signatures. In my understanding with the old defaults < 3.2.0 of rrsig-refresh of 7d and rrsig-lifetime of 14d, we always ended up with signatures that were at least valid for 7 days. As I understand, with the new defaults, signatures might be refreshed way closer to their expiry date. This makes me a bit uneasy, as if there are issues with signing this gives us hardly any time to react and fix potential issues before the current signatures expire. I assume setting rrsig-refresh explicitly to 7d would restore the old behavior, but I'm wondering if this is somehow bad practice and if we are overly paranoid with our monitoring. How do other people handle this? Are there any downsides of setting a higher value of rrsig-refresh that we are not aware of? Regards André

2 roky, 8 měsíců

3
6
0 0

knot 3.2 fails to access HSM key

by Bastien Durel

Hello, I tried to upgrade to knot 3.2 using the debian packages from https://deb.knot-dns.cz/knot-latest bullseye/main, but the server does not use my HSM anymore. All zones fails with : août 22 14:38:13 arrakeen knotd[1285865]: info: [durel.org.] zone file parsed, serial 2021120479 août 22 14:38:13 arrakeen knotd[1285865]: error: [durel.org.] DNSSEC, failed to initialize signing context (PKCS #11 token not available) août 22 14:38:13 arrakeen knotd[1285865]: 2022-08-22T14:38:13+0200 error: [durel.org.] DNSSEC, failed to initialize signing context (PKCS #11 token not available) août 22 14:38:13 arrakeen knotd[1285865]: 2022-08-22T14:38:13+0200 error: [durel.org.] zone event 'load' failed (PKCS #11 token not available) août 22 14:38:13 arrakeen knotd[1285865]: error: [durel.org.] zone event 'load' failed (PKCS #11 token not available) debug log does not seems to print more details about error keystore is defined as : keystore: - id: hsmkey backend: pkcs11 config: "pkcs11:pin-value=REDACTED /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so" The HSM itself is an USB key from CardContact.de Downgrading to 3.1.9-cznic.1~bullseye re-enable signing Is there anything I can do to debug/solves this problem ? Regards, -- Bastien

2 roky, 9 měsíců

2
9
0 0

Knot DNS 3.2.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.0! This version brings various XDP-related features and improvements (namely QUIC and TCP) and many more. See the changelog. As usual, today Knot DNS 3.0 reached its End-of-life. The official repositories are being updated this way: current stable -> 3.2.0, previous stable -> 3.1.9. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.0/NEWS Migration: https://www.knot-dns.cz/docs/3.1/html/migration.html#upgrade-3-1-x-to-3-2-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

2 roky, 9 měsíců

1
0
0 0

When knot delete old ksk key ?

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, 9 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, 9 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, 10 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

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

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

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

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

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, 1 měsíc

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, 2 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 4 měsíce

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, 5 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, 5 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, 5 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 7 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, 7 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, 7 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, 7 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, 7 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, 8 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 měsíců

1
0
0 0

Knot DNS 3.0.8 release

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, 10 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, 11 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, 11 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

3 roky, 11 měsíců

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

3 roky, 11 měsíců

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

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

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, 1 měsíc

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, 1 měsíc

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, 1 měsíc

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, 2 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, 2 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, 2 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, 2 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, 2 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, 3 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, 3 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, 3 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, 3 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, 4 měsíce

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, 4 měsíce

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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 měsíců

1
0
0 0

re-sign zone

by Thomas

Hi, I have the requirement to re-sign my zones exactly every 24 hours. I'm not sure how to achieve this, because I'm not clear about the correlation of the following parameters: zsk-lifetime propagation-delay rrsig-lifetime rrsig-refresh rrsig-pre-refresh Can anybody give a hint what values I need to have an exact re-signing period of 24 hours? Thanks a lot, Thomas

4 roky, 9 měsíců

3
3
0 0

Is cds-cdnskey-publish doing too many publishes?

by Jan-Piet Mens

I have the following signing policy configured in a test environment: - id: rsadefault algorithm: RSASHA256 ksk-size: 2048 ksk-lifetime: 30m zsk-size: 1024 zsk-lifetime: 2h propagation-delay: 2s dnskey-ttl: 10s zone-max-ttl: 15s nsec3: on nsec3-iterations: 5 nsec3-salt-length: 8 nsec3-salt-lifetime: 100d cds-cdnskey-publish: always ksk-submission: ds_checker ds-push: hidden-primary I notice that every five minutes Knot is updating the DS in the parent zone hosted on a BIND server. It appears that every time Knot refreshes the secondary it also updates the DS in the parent. (Logs below.) Isn't that a bit much? I realize I've configured `cds-cdnskey-publish: always', but I was expecting "always if something changes" :-) I would prefer on CDS publishing on "rollover", but then the DS record isn't added to the parent when a zone is first signed. Is this expected behaviour, respectively, is there a different configuration I should set? Thank you, -JP zone aa.tm. has an SOA refresh of 300s (5 minutes) Knot console: Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success BIND console: 15-Jul-2020 16:38:23.946 client @0x7fd5bc7f8568 192.168.1.150#58386 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140) 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140) 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: signer "k-signer" approved 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648 ... after five minutes ... Knot console: Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success BIND console: 15-Jul-2020 16:43:24.016 client @0x7fd56c220d68 192.168.1.150#58390 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140) 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140) 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: signer "k-signer" approved 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648

4 roky, 10 měsíců

3
5
0 0

Revoking DNSSEC KSK (a la RFC 5011)

by Jan-Piet Mens

Hello! first of all, thank you for a wonderful authoritative DNS server; as mentioned a while back, I'm loving the automatic key management and DS push; both work a treat. I have a requirement for manual key management and that is to be able to roll KSK keys a la RFC 5011 for both BIND and Unbound instances to automatically change their trust anchors. In Knot I can retire a key and subsequently have it removed, but the key isn't revoked (a.k.a. key flags 257+128 == 385). keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi As such, BIND will, when this particular KSK is removed from the DNSKEY RRset, (rightly) complain: managed-keys-zone: Active key 41155 for zone . unexpectedly missing managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete) I've not found the word 'revoke' in the documentation, and no flags I can set with keymgr(8) seem to indicate that I can revoke a key. Can you help me, please? As an aside, I've noticed that when keymgr's `remove' time is reached, the key is removed from the zone (which is expected), however the key itself remains in the key store. From there, I can delete it, but I can also set flags on it in such a way as that it's brought *back* into the zone. Is that expected behaviour? It's not a problem per se, I'd just like to know whether I've understood the system. Thank you and kind regards, -JP

4 roky, 10 měsíců

3
4
0 0