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

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

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

4 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

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

4 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

4 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

4 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

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

4 roky, 7 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

4 roky, 7 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

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

4 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

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

4 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

4 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

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

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

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

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

4 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

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

4 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

4 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

4 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

4 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

4 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

4 roky, 10 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

4 roky, 10 měsíců

2
3
0 0

Knot DNS 3.0.7 release

by Daniel Salzman

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

4 roky, 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>.

4 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

5 let

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

5 let

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

5 let

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.

5 let

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

5 let, 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...

5 let, 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

5 let, 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

5 let, 1 měsíc

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é

5 let, 1 měsíc

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

5 let, 1 měsíc

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

5 let, 1 měsíc

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?

5 let, 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

5 let, 2 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

5 let, 2 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

5 let, 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

5 let, 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

5 let, 3 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

5 let, 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

5 let, 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

5 let, 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

5 let, 5 měsíců

4
19
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users