knot-dns-users

knot-dns-users@lists.nic.cz

2 participants
732 discussions

by Jan Včelák

Hello everyone. I'm glad to tell you that Knot DNS 2.1.0 by CZ.NIC Labs was just released. Thank you for the feedback on the release candidate. I believe we have addressed all the issues and bug reports we have received. Let me just quickly summarize the news in the 2.1.0 you already know about: SO_REUSEPORT support, binary configuration database, PKCS #11 support in DNSSEC, zone file name formatters, configurable location for timer database, experimental module for online signing, and many other improvements. If you are interested in details, please, see the 2.1.0-rc1 announcement. And now finally, we are getting to the news in the final release: - We have resolved the problem with the server crashing when configured with a high number of interfaces and threads. This problem started to affect more people because of the introduction of the SO_REUSEPORT support which causes a higher allocation of file descriptors. - We have changed the '%s' zone file name formatter behavior for the root zone. In the release candidate, the trailing dot was skipped for all zones except for the root zone. In 2.1.0, the trailing dot is skipped even for the root zone. The root zone therefore expands to an empty string. This should make your Ansible templates less hacky. - The keymgr now supports KASP database upgrade. So if you have initialized the database with Knot DNS 2.0, please, run 'keymgr init' in the KASP directory to avoid DNSSEC 'invalid parameter' errors. The command is idempotent, it won't rewrite your existing settings. - We have removed the possibility to run knotc over a network socket. The interface allows altering the configuration and possibly sensitive content (e.g. TSIG keys) could appear on the network in plain text. We are working on some better configuration interface which will (among other things) guarantee confidentiality. - We have also fixed a problem with slave zone bootstrapping when the server launches and the slave zone fails to load from a zone file. In this case, an immediate zone transfer is scheduled. Prior to this release, the transfer had to be initiated manually by knotc. Thank you for reading so far. Hopefully I haven't forgotten about anything important. And as always, we are here for you to answer any questions. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.0.tar.xz.asc Best Regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 4 měsíce

script to export config from knot 1.x to 2.x

by Josef Karliak

Good morning, do somebody (or knot dns) have script to migrate from knot dns 1.6 to knot 2.x version ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

9 let, 5 měsíců

Manage zonefile directory in git

by Tobias Brunner

Hi everyone, I'd like to manage the directory holding all the zonefiles in git to have a workflow like "git push -> webhook -> zonefiles git pull -> knotc reload". With Knot versions <2 this was working great because Knot did not change anything in this directory. But when using Knot 2.x with DNSSEC enabled, Knot rewrites the zonefiles of DNSSEC enabled zones, creates a timers subdirectory and puts some *.db files into the zones directory. Are there any configuration parameters to change this behaviour? So that the timers subdirectory is created outside the directory holding zonefiles (preferably configurable), the *.db files are also written into a dedicated directory and signed zonefiles are saved into a different subdirectory. Or are there any proposals how I could manage the zonefiles directory with git when using Knot 2.x with DNSSEC enabled? Thanks a lot for all input. Cheers and happy new year! Tobias

9 let, 5 měsíců

Knot Puppet module now 2.x ready

by Tobias Brunner

Hi all, The Knot Puppet module is now fully Knot 2.x compatible. It can be found on Puppet forge: https://forge.puppetlabs.com/tobru/knot Any feedback and all pull requests are highly appreciated. Cheers, Tobias

9 let, 5 měsíců

Knot DNS 2.1.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Have you been good this year? CZ.NIC Labs just released a Christmas present for all Knot DNS users — a new and shiny release candidate. This version contains a bunch of new features, quite a lot of improvements and also some bug fixes. Let's start with the features: - If you run Linux, you will get a higher packet throughput for UDP thanks to the SO_REUSEPORT socket option. In some cases, we have seen 100% packet rate increase. - As an alternative to the textual configuration file, we now support a binary configuration database. This is primarily intended for users with many zones who need to reconfigure their servers quickly. For this purpose, the knotc utility adds new conf-* commands, which can be used to query and modify the server configuration on-the-fly. - DNSSEC newly implements an interface to access cryptographic tokens via the PKCS #11. This means, that you can store the private key material for DNSSEC keys more securely than before. - We have also included an experimental module for DNSSEC online signing. This can be used for instance with the other modules synthesizing records on-the-fly. As for various improvements: - The zone file name can now include formatters, which will be later substituted. For example, if you have many zones and want to sort them into directories based on their TLD, you can use '%l[0]/%s.zone' as the 'file' config option, and the zone 'example.com' will be loaded from '$storage/com/example.com.zone'. - We have added the 'timer-db' option to customize path to the database with persistent zone timers. This is useful if you have multiple knotd instances sharing a zone storage directory. - After the recent DDoS attacks, we have improved the RRL documentation to include details about the effect of the individual rate-limit-slip configuration values. We also made this option to accept zero value which will make the server drop all responses exceeding the limit. - Other small changes in the server include improved networking code so we can better handle connection timeouts. The ACL failures are now logged. And some of the critical configuration values are cached for better performance. - The kdig utility now prints a warning instead of failing with an error when a TSIG validation failure is encountered. - We've also performed some cleanup of the support libraries: libknot, libzscanner, and libdnssec. So if you are developing your own DNS application, take a look at these. And that's it. Please, refer to the documentation for more information. And if something is not clear, just ask on the mailing list and we will try to clarify any ambiguities. You will find your present under our Christmas tree. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0-rc1/NEWS Source tarball: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz.asc On behalf of our development team, I wish you a merry Christmas and happy New Year. Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 5 měsíců

Knot DNS 1.6.6 and 2.0.2 (security patch release)

by Jan Včelák

Hello everyone. CZ.NIC Labs just released two security patch version of Knot DNS. Knot DNS 2.0.2 - We have recently extended our fuzzy-testing tool set by a new LibFuzzer tool, which lead to a discovery of a bug in the packet parser. A specially crafted packet with malformed NAPTR record can trigger an out-of-bound read, possibly leading to the knotd daemon crash. The new version fixes this bug. Knot DNS 1.6.6 - The 1.6 packet processing code contained the same issue in NAPTR parsing which was present in the 2.0. However, existing code paths to its occurrence were different. We are not aware of any possibility to remotely crash the server daemon at the moment. - The updated version also fixes systemd server startup notifications. - We have included the rosedb module, which has already been distributed as a separate tarball for a few releases. Users of rosedb should switch to the main releases. If you are a Knot DNS 2.0 user, we highly recommend to updated to version 2.0.2 because it is possible to cause a denial of service remotely. If you are a Knot DNS 1.6 user, we suggest to update to the latest release even though the fixed problems are not as critical as in the 2.0 branch. The sources are available as usual. Full changelogs: https://gitlab.labs.nic.cz/labs/knot/raw/v1.6.6/NEWS https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.2/NEWS Tarballs: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz.asc Best regards! And thank you for using Knot DNS. Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 6 měsíců

[Knot-Resolver] "I yielded, not you" issue

by Florian Maury

Hi everyone, While working on my Knot-Resolver (kr) module, I came to think that the current YIELD mechanism for layers will not work properly, if multiple YIELD-enabled modules are loaded simultaneously. My understanding of how the current YIELD system works is as follows. A layer receives the current state through ((knot_layer_t*) ctx)->state. The current state can be modified by previous layers returned value. When a layer returns a YIELD state, the chain of responsability, maintained by the lib/resolve.c:ITERATE_LAYERS macro is broken (break;) and the resolution plan is evaluated once more to handle the tail element of the rplan. Once the rplan popped up all rplan_pushed queries, then the query that yielded is once more the last element of the rplan stack. This element is then evaluated, calling once more all layers, starting with the first layer. This time, the state that is provided to the layers is YIELD, except if a layer returns another value instead of returning the state as is. A layer could behave differently, based on whether it receives a YIELD state or not as "input state". This is, in fact, what is provided as example in the documentation: >>> consume = function (state, req, answer) answer = kres.pkt_t(answer) if state == kres.YIELD then print('continuing yielded layer') return kres.DONE else if answer:qtype() == kres.type.NS then req = kres.request_t(req) local qry = req:push(answer:qname(), kres.type.SOA, kres.class.IN) qry.flags = kres.query.AWAIT_CUT print('planned SOA query, yielding') return kres.YIELD end return state end end <<< The issue, I think, is that a module has no way of knowing whether it is the one that yielded or not. Let's say I have three module, A, B, and C. B and C can yield, and A only returns YIELD, when it receives YIELD as input state. On the first evaluation, A and B returns DONE. C yields. Then on the second evaluation, A returns YIELD, because it does not handle this state and only passes it along. B receives the YIELD from A. B, as said above, may yield in some cases. B will therefore handle the YIELD, and do his "YIELD" actions, ignoring the fact that the module that actually yielded was C. I suppose B and C could define flags to be capable of remembering whether they yielded on this query or not. Unfortunately, there is currently no framework to ensure uniqueness of these flags. Sadly, this email does not come up with a proposed solution. I'm only sharing a thought about what I think could be an issue. What is your take on this? Have I missed something or misunderstood how the yield state works? Thank you. Cheers, Florian

9 let, 6 měsíců

Re: [knot-dns-users] knot 1.4.4 and problem with journal size - zone not loaded

by Daniel Salzman

Hi, You can try setting https://www.knot-dns.cz/docs/1.6/singlehtml/index.html#ixfr-fslimit or simply deleting the journal file corresponding to the ajetaci.cz zone. Dan > > Good morning, > where is problem with zone ? > Error : > journal size is too small to fit the changes. > > Knot is owner of this directory. > > After loading zone I found that record on some line in the zone file is > invalid, I deleted it, increased serial and after reloading zone I could > not set it UP > > > Log records about the zone: > Nov 9 08:22:14 celer knot[20407]: Semantic checks completed for > zone=ajetaci.cz. > Nov 9 08:22:14 celer knot[20407]: Zone 'ajetaci.cz.' loaded (serial > 2015110901) > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - Signing > started... > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 36256, file Kajetaci.cz.+005+36256.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 11937, file Kajetaci.cz.+005+11937.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 5300, file Kajetaci.cz.+007+05300.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 58830, file Kajetaci.cz.+007+58830.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: [error] Zone 'ajetaci.cz.' journal size > is too small to fit the changes. > Nov 9 08:22:14 celer knot[20407]: Loaded 2 out of 3 zones. > Nov 9 08:22:14 celer knot[20407]: [warning] Not all the zones were loaded. > > > Any ideas ? > Thanks and best regards > J.

9 let, 7 měsíců

*****SPAM***** knot 1.4.4 and problem with journal size - zone not loaded

by Josef Karliak

Spam detection software, running on the system "mail.nic.cz", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Good morning, where is problem with zone ? Error : journal size is too small to fit the changes. Knot is owner of this directory. After loading zone I found that record on some line in the zone file is invalid, I deleted it, increased serial and after reloading zone I could not set it UP [...] Content analysis details: (5.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4973] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 3.0 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

9 let, 7 měsíců

[Knot-Resolver] Modules meddling with the NS selection feature request

by Florian Maury

Hi everyone, While I was working on my Knot-Resolver (kr) module, I wondered how I could be able to ratelimit the trafic toward specific nameservers or influence the NS selection algorithm, in general. Unfortunately, the current NS election algorithm that is present in the lib/resolve.c driver and in lib/nsrep.c does not allow a module to register a layer to influence the NS selection. Is there any plan to add event listeners to influence NS selection, for instance by giving layers the opportunity to "congregate" and return a modifier, a lot like the "favour" IPv6 modifier/variable that is done in lib/nsrep.c:eval_addr_set? Thanks. Cheers, Florian

9 let, 7 měsíců

← Newer
1
...
48
49
50
51
52
53
54
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users