knot-dns-users

knot-dns-users@lists.nic.cz

3 participants
780 discussions

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

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

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

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

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

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

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

5 let

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

5 let

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

5 let

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?

5 let

← Newer
1
...
15
16
17
18
19
20
21
...
78
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users