knot-dns-users

knot-dns-users@lists.nic.cz

2 participants
732 discussions

by Bastien Durel

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

3 roky, 7 měsíců

Data saved into the KASP

by Luveh Keraph

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

3 roky, 7 měsíců

dnsbenchmark issues

by Rhonda D'Vine

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

3 roky, 7 měsíců

Knot DNS 3.1.4 and 3.0.10 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.1.4 and 3.0.10! These versions primarily fixes a very old bug which can cause the server to crash if a query requests EDNS0/NSID option. Special thanks go to Romain Labolle! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.1.4/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.10/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

3 roky, 7 měsíců

Setting up zone file MX record to external mail server

by Dirk Segers

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

3 roky, 7 měsíců

Changing DNS Operators for DNSSEC signed Zones

by Luveh Keraph

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

3 roky, 7 měsíců

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ů

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ů

Zone Transfers fail if server has multiple IPs

by Schindler, Stefan

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

3 roky, 8 měsíců

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

by Daniel Gröber

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

3 roky, 8 měsíců

← Newer
1
...
10
11
12
13
14
15
16
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users