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

dynamically add/delete zones on the fly?

by Mark Jeftovic

Hi, is there any way to dynamically add/delete zones on-the-fly other than to rebuild your master config and reload? Thx - mark

9 let, 5 měsíců

5
6
0 0

Knot 2.1.0-rc1

by Bastien Durel

Hello, Knot 2.1.0-rc1 made its way to the debian repository. I installed it as part of today's upgrade, but it seems to not like my configuration : For each zone I got these messages : 2016-01-14T10:07:00 error: [durel.org] DNSSEC, failed to initialize (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] failed to store changes into journal (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] zone load failed (invalid parameter) I log zone events up to notice level. my default template is : template: - id: "default" storage: "/var/lib/knot/external" ixfr-from-differences: "on" dnssec-signing: "on" kasp-db: "keys" serial-policy: "increment" And this zone is defined as : - domain: "durel.org." file: "durel.org" notify: "corrin" acl: "acl_corrin" Which is this "invalid parameter ?" Thanks, -- Bastien

9 let, 5 měsíců

2
4
0 0

Knot DNS 2.1.0 (final release)

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

1
0
0 0

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ů

3
2
0 0

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ů

6
9
0 0

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ů

1
0
0 0

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

1
1
0 0

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

2
2
0 0

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

2
3
0 0

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ů

4
4
0 0

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

1
0
0 0

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

1
0
0 0

[Knot-Resolver] Async module unloading and cleanup event idea

by Florian Maury

Hi everyone, While working on a Knot-Resolver (kr) C module, I stumbled on a limitation of the current way layers are loaded and unloaded. My understanding is that, currently, C modules are loaded via a dlopen call, and then a callback "moduleName_init" symbol is searched and called. On unloading, a symbol "moduleName_deinit" is searched and called, and upon completion of the deinit function, a dlclose call is made to unload the module from memory. This occurs in lib/modules.c. As it happens, my C module provides callbacks (cb) for several layer hooks. Some of these cb perform potentially long-lived I/O operations. Since functions are not supposed to take a lot of CPU time, in order to maintain kr responsiveness and with respect to the event-oriented design, I chose to embrace libuv and use the uv_* functions to perform these I/O operations. This means I inserted in the uv_default_loop several cb for network or filesystem events. These cb need to be called for some operations to be successfully completed. Think about SQL commit statements and whatnot. Currently when a user wants to stop the daemon, the "graceful" procedure is to call quit() on the CLI. This procedure calls uv_stop on the uv_default_loop, thus stopping abruptly all registered cb from being ever called again. Then, modules are unloaded one by one. These unloading calls to moduleName_deinit can be blocking because no service requires responsiveness anymore. On the other hand, if a module is shutdown during normal operations, for instance, via a call to "modules.unload" from the CLI, the unloading procedure cannot perform blocking actions without generating a negative impact on the overall responsiveness. The problem is that it cannot perform non-blocking actions either because as soon as the deinit function returns, the code for the non-blocking actions "to wrap up" currently registered callbacks in the uv_default_loop is removed from memory. To solve this problem, I would suggest creating a cleanup event, sent to modules that should be unloaded. A module receiving a call to its handler for this event would be expected to wrap it up ASAP. It would, however not be expected to have completed everything at handler return time. The sender of the cleanup event could then register a uv_idle handler that would call the deinit function. The deinit function would then be in charge of ensuring the module no longer have any event handler registered in the uv loop. If no cb are present in the loop, it would return a status code allowing the caller to dlclose the module. With this approach, calling the "graceful" quit procedure would then send a cleanup event to all modules, including iterate, cache, etc. uv_stop would not need to be called anymore because the idle handler would be able to know that no handler are in the uv_loop except itself: it would then unregister itself and the uv_run call would terminate spontaneously. What is your take on this issue? Do you think the proposed solution would be acceptable? Would it work with all kind of modules (I'm thinking about the lua and go modules)? I, sadly, currently have no code to do this. I just thought it might be useful to document this on the mailing list and share ideas about it. Thank you. Cheers, Florian

9 let, 7 měsíců

1
0
0 0

[Knot-Resolver] kr_zonecut_find_cached seemingly incorrect result

by Florian Maury

Hi everyone, I have been recently working on a Knot-Resolver (kr) module for some research work. This led me to push new queries into the resolution plan, wait for the answer and then resume the "standard" kr-spooled queries. Once all queries are resolved, when my finish module callback (cb) is invoked, I write down some statistics that were collected throughout the various queries. Among the thing that I write down, I inspect some data in the cache, including zonecuts. I discovered that some information returned by lib/zonecut.c:kr_zonecut_find_cached were different from what I expected. I am not sure if this is because my call to kr_zonecut_find_cached is incorrect, if I messed up some kr internal logic or if I stumbled on a bug. Here follows a made-up domain name tree similar to what made me stumbled on this issue, what I thought should be returned by kr_zonecut_find_cached, and what is actually returned. The original query qname is example.com.. Example.com. is delegated to a company owning example.net, a DNS reseller providing DNS hosting for its clients. example.com. is gluelessly delegated to ns1.example.net. and ns2.example.net.. example.net. is gluelessly delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net.. some-famous-registrar.net. is also delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net. thus using a glued delegation. When I call kr_zonecut_find_cached in my module finish cb, with a "name" param whose value is srv1.some-famous-registrar.net., I expected the cut out-param to be filled with a kr_zonecut structure with a "name" equal to some-famous-registrar.net. and a nsset equal to srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net. Unfortunately, cut->name values net., which is of course incorrect, since some-famous-registrar is a delegated name. My call to kr_zonecut_find_cached is using a kr_cache_txn structure created by the finish cb, using the cache in ((knot_layer_t*) ctx)->((kr_request*) data)->ctx->cache. It may also be worth noting that I use "false" for the secured param of the kr_zonecut_find_cached call. If this is indeed a bug, my guess would be that example.com. delegation leads kr to ask to net. nameservers for the delegation information for example.net.. net. nameservers answer that the delegation to example.net. is through srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net.. At the same time, net. nameservers also provide the *glues* for srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net., since the net. zone contains non-authoritative IP address records for these names for the glued delegation of some-famous-registrar.net. This could make kr to believe that net. is "authoritative" in some way for srv1.some-famous-registrar.net. and therefore to think that the some-famous-registrar.net is not a delegated zone. It is however possible that I completely crashed kr zonecut logic with the additional queries that I pushed from time to time, though. Does that ring a bell to anyone? What would be, according to you, the next step I should take to better understand what is going on? Thanks for your help! Cheers, Florian

9 let, 7 měsíců

1
0
0 0

Dynamic Update

by Ulrich Wisser

Hi! Just a short feedback. Today I got the latest source from git and it compiled on my Raspberry Pi. The Dynamic Update "bug" or incompatibility is fixed. Thanks for all your help! And thanks for fixing it so fast! /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 8 měsíců

1
0
0 0

subscription

by Yves Bovard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Community A I am a Knot DNS user, I would like to subscribe to your mailing list. How can I do that? Best regards Yves Bovard - -- SWITCH - -------------------------- Yves Bovard, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 31 yves.bovard(a)switch.ch, http://www.switch.ch -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJWJNm7AAoJEOgRvbd1sr4QoV8QAK//5Hio41UtP56JWvnBxyLo gmQRXZrD2Q6B97e0OfvFA2CLnmmKfmQwHniCWG4prgktdtsiwLscWFhBdTGk4OW9 0w9VHWc+Jvl3gDv18kmGaN9azMsoqiZ6ws3CsnEq/WdObR0a0KwJHuy3yJBJleXz NpUN58qp+kaPQ46a0o2WKgAtDpilg30tWX2k2gLPXlNfu7IGPkmp+sXrPwWFtim5 CZHeDFfPYCWlaD8Lw1VC/7u8dKUMk4yYE35ioXlMxt2Xgdeagu70ZW9EyC7Xx4EZ iPFDKdvxRpBljhc8YchXSldkg4rqtsQwE4h4Q07s7RAv/tkZKxAllodtiRtFC/TP oVQ4QUjFcbUKC5dUWCQnGVbyyzBVgdWsBnhhQKiuM1477dwKe2ugMFNvIGo7GqAJ 3HDqL+L1FteBbW9iBvHN3XRcXk4bdKBm2MvbJ3KN6SptvM7n85jhLNIV+Tao+UGP uVi3+f4KC9m2H9D7GnIjsWZQkxCfAo0di1RYG9L57wOIm/cCJYbn90nDm7sAvomb hxRAdJYCTM+xVvlhoiANqcXll9MS4yZTD5KhZR5DgZpCoJPbatxbEy3l3r9ZTFYb Xh3+plCk67mYClcbIo7Ln5+kWJMLKObTcSvHaApWJiMhrbU3eKoXNMZE+w90NSOW wcgyCg0F+VtwoN+EVWXv =9ZJL -----END PGP SIGNATURE-----

9 let, 8 měsíců

2
1
0 0

knot 1.6 an non-locl interfaces

by Peter Hudec

Hi, I need to listen on inteface which may not be present at start time. I want to ask if there is a way to enable non-local interface bind on KnotDNS 1.6. The version 2.X supports this feature, but thos version os nt available for CentOS /as I read in maliling list archive and seen the build for EPEL/. best regards Peter Hudec -- *Peter Hudec* Infraštruktúrny architekt phudec(a)cnc.sk <mailto:phduec@cnc.sk> *CNC, a.s.* Borská 6, 841 04 Bratislava Recepcia: +421 2 35 000 100 Mobil:+421 905 997 203 *www.cnc.sk* <http:///www.cnc.sk>

9 let, 8 měsíců

2
4
0 0

DDNS with python

by Ulrich Wisser

Hi! In the last few days I have tried a new service for DDNS, nsupdate.info. I have some problems with the service and I have been able to reproduce the problem in a small sample script. The attached script does update my bind9 instance but reports SERVFAIL for Knot. Unfortunately I still have not been able to get Knot to write more extensive log entries. The script uses the Python dns library from Nominum. This is the output of the script (first update to bind then to knot) $ python example.py performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 DNS error [SERVFAIL] performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 Knot didn't log anything at all. (Any hints for that config would be welcome.) Bind did log the following Oct 5 21:07:49 localhost named[23792]: client beef::cafe#59322/key example.com: updating zone 'example.com/IN': adding an RR at ' ddns.example.com.' A Some error in the script? Could someone point me to a working script? Any hints are welcome! Kind regards from Stockholm Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 8 měsíců

4
13
0 0

Knot DNS 2.0.1 patch release

by Jan Včelák

Hello everyone! CZ.NIC Labs just released Knot DNS 2.0.1. There is a lot of bug fixes, new features, and improvements since the final release. Let's start with the bug fixes: - The 2.0.1 received all the relevant bug fixes included in the 1.6.5. Namely fix for expired zones reloading, fix for race-condition in event scheduling, fix for NSEC proofs with zones containing lots of delegations, fix for TC flag setting in RRL slipped answers, fix for root label compression, and fix for journald logging without systemd. - The old version was incorrectly following CNAME when queried for the NSEC record. This is fixed in the new version. - There was a bug in the code planning DNSSEC resigning. The code hadn't considered expiration of DNSKEY RRSIGs and therefore these signatures could have had expired. This problem is resolved now. - Binding to an unavailable IPv6 address was broken on Linux (IP_FREEBIND). When the daemon was started before the network was fully up, the daemon failed to bind IPv6 addresses. This problem is fixed as well. - The knotc utility entered an infinite loop when the zonestatus or memstats command was executed for an individual zone. This shouldn't happen any more. - The dnsproxy module was not working properly as we have changed the request processing code without updating the module. This has been addressed. - There was a problem with parsing time stamps in the DNSSEC KASP database when compiled against the uClibc standard C library (e.g., in Alpine Linux). The parsing has been rewritten to work in strict POSIX environment. - We have fixed multiple problems related to endianness. We have eliminated compilation warnings on OpenBSD related to endian conversion functions. The multi-value config options parsing didn't work on big-endian machines. And we also added detection of the Nettle library version, because the version 3 changed the Base64 decoding API incompatibly. As for the new features: - The keymgr utility now supports 'zone key ds' command to retrieve DS records for a key. And also 'tsig generate' command to generate TSIG key in the format accepted by Knot DNS. - We have added module scoping. So the modules can be configured either to process all queries received by the server. Or their scope is limited to individual zones. - The 'include' config directive supports file name globbing. So you can import multiple files at once (e.g., include: conf.d/*.conf). - Same as in the 1.6.5, the 2.0.1 supports the 'request-edns-option' config option allowing to add custom EDNS0 options into the DNS queries initiated by the server. And at last but not least, the improvements: - We have decided to remove NS record from the Authority section for NOERROR responses. We used to put these records there because BIND and NSD did it. But these records are not required by any RFC and just increase the size of the response. - The persistent zone timers are written only on server shutdown for better startup performance. - The change of TTL over DDNS is now allowed without removing the existing records. - We have reviewed the documentation and fixed a couple of grammar mistakes, updated some sections, and improved formatting a little bit. - The yparser and zscanner header files are now installed. As you may see, we are not lagging behind. This list is quite long for a patch release. And we have much more up in our sleeve. Thank you for reading this far. And we are looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.1.tar.xz.asc Cheers, 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, 9 měsíců

4
6
0 0

Knot on Raspberry Pi (armhf)

by Ulrich Wisser

Hello! I have tried to get the latest version of Knot running on my Raspberry Pi 2. Unfortunately does Raspian only have packages for an old version. I updated my Pi to debian jessie. There is actually a version of Raspian based on jessie. That version of Raspian does come with slightly newer packages, but still not up to date. So I compiled my own version. 2.1.0-dev Everything works fine until the moment I try to start knotd. IT will crash with a segfault. I did recompile with --enable-debug but I do not get any debug output in syslog. I did run with gdb and got the following information SYSLOG: Sep 16 22:36:57 localhost knotd[3522]: info: Knot DNS 2.1.0-dev starting Sep 16 22:36:57 localhost knotd[3522]: info: binding to interface '2001:470:28:193::53@53' Sep 16 22:36:57 localhost knotd[3522]: info: configured 1 zones Sep 16 22:36:57 localhost knotd[3522]: info: changing GID to '1003' Sep 16 22:36:57 localhost knotd[3522]: info: changing UID to '1002' Sep 16 22:36:57 localhost knotd[3522]: info: loading zones Sep 16 22:36:57 localhost knotd[3522]: info: [example.com] zone will be loaded, serial 0 Sep 16 22:36:57 localhost knotd[3522]: info: starting server GDB: [New Thread 0x50baa200 (LWP 3526)] [New Thread 0x50aaa200 (LWP 3527)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x50baa200 (LWP 3526)] scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 152 if (zc->ret != KNOT_EOK) { (gdb) bt #0 scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 #1 0x76d80a14 in ?? () from /usr/lib/arm-linux-gnueabihf/libzscanner.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 147 148 /*! \brief Creates RR from parser input, passes it to handling function. */ 149 static void scanner_process(zs_scanner_t *scanner) 150 { 151 zcreator_t *zc = scanner->data; 152 if (zc->ret != KNOT_EOK) { 153 scanner->stop = true; 154 return; 155 } 156 (gdb) It seems that the scanner thread is somehow missing. But why? Anybody with experience with knot on armhf? /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 9 měsíců

2
1
0 0

Knot 2.0.1 debian 8 (jessie) builds

by Petr Jediný

Hello, are there any plans to publish latest builds (2.0.1) for jessie? The most current package I can find is knot_2.0.0-1+0~bpo80+1_amd64.deb. Regards, PJ

9 let, 9 měsíců

2
1
0 0

Knot DNS 1.6.5 patch release

by Jan Včelák

Hello list. Today, CZ.NIC Labs releases Knot DNS 1.6.5. This patch release contains quite a lot of non-critical bug fixes and some minor improvements. Everyone is advised to upgrade. Let's go through the fixed bugs quickly: - The server no longer loads expired zones on 'knotc reload' and server startup. - We have fixed a rare race-condition in the event scheduling code. The race caused that events for some zones were significantly delayed. (We were reported that the server is occasionally ignoring notify messages for random zones when the server is receiving many notifies. We believe this bug was the cause and the problem should no longer appear.) - There was a bug in the NSEC proofs construction. When the zone contained many delegations, the NSEC proving non-existence of a covering wildcard was incorrect. The problem is fixed now. - The TC flag was not set correctly for RRL slipped answers. This problem is resolved as well. - We have disabled domain name compression for the root label '.' because it caused negative compression and some client implementations (like Go DNS) might have problem decoding these answers. - The server is now checking whether it is executed in the systemd enviroment before using journald as a sink for log messages. Also the systemd library detection at a build time was improved. - We have also eliminated compilation warnings in endian-conversion functions on OpenBSD. And as for the new features: - The persistent timers are now written to the on-disk database only on server shutdown. This change was done mainly to improve startup and reload performance. - The 'max-conn-idle', 'max-conn-handshake', 'max-conn-reply', and 'notify-timeout' config options now accept time units specification (e.g., one can use 2m instead of 120). - We have added 'request-edns-option' config option, which allows inserting custom EDNS0 options into all queries initiated by the server. And that's all folks. I would like to thank everyone involved in making this release, especially bug reporters. We are looking forward to your feedback. The sources are available as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/1.6/NEWS Source archives: https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz.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, 9 měsíců

2
2
0 0

Refreshing DNSKEY RRset signatures

by Antti Ristimäki

Hi, I'm running Knot 2.0.0 and automatically signing my zone with manual key management policy. When I manually refreshed the signatures by running "knotc signzone <zone>", all the signatures were refreshed as expected, except the DNSKEY RRset, whose signature remained untouched. I thought this wouldn't be a big deal, as Knot would probably automatically refresh DNSKEY RRset signature when about 1/10 of its lifetime will be remaining. However, when I now look at "knotc zonestatus", it shows that the next resigning is scheduled far beyond the exipration of the DNSKEY RRset signature. So, is my DNSKEY RRset signature going to be expired or is DNSKEY handled in some special way so that it will be eventually refreshed before expiring? My current DNSKEY RRSIG will expire at 20150828172101: nxdomain.fi. 600 IN RRSIG DNSKEY 8 2 600 20150828172101 20150729172101 61894 nxdomain.fi. qQJm..... But the next resigning is scheduled on 2015-09-14: nxdomain.fi. type=master | serial=2015081708 | DNSSEC resign in 647h56m43s | automatic DNSSEC, resigning at: 2015-09-14T02:26:59 Thanks, Antti

9 let, 10 měsíců

2
1
0 0

first time install got failed

by Ken Peng

Hi, My system is debian 6.0 (yes I know it's out of date). When I installed knot from source following the document, I got failed as below. How can I get continued? thanks. $ autoreconf -i -f libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:35: error: possibly undefined macro: AC_SUBST If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:93: error: possibly undefined macro: AS_IF configure.ac:102: error: possibly undefined macro: AC_MSG_WARN configure.ac:122: error: possibly undefined macro: AC_DEFINE configure.ac:163: error: possibly undefined macro: AC_MSG_ERROR configure.ac:251: error: possibly undefined macro: AC_SEARCH_LIBS autoreconf: /usr/bin/autoconf failed with exit status: 1

9 let, 10 měsíců

2
8
0 0

More fine-grained ACLs

by Matthias-Christian Ott

Network renumbering requires that A and AAAA RRs are directly or indirectly (DHCP) updated. This in turn requires dynamic DNS updates (RFC 2136). Although Knot DNS allows dynamic updates, it is not really prepared to securely handle this scenario. Knot DNS can either allow an address or key to update RRs in a zone via ACLs which is not fine-grained enough to useful for this purpose because it is questionable from a security perspective (under a certain threat model etc.). Assume that example.com uses dynamic DNS updates to update A and AAAA RRs to be prepared to renumber its network. If example.com uses a DHCP server to update the RRs, it suffices to take over the DHCP server of example.com to update any RRs in the zone of example.com, including NS, MX, TLSA and SSHFP RRs. If every host of example.com updates its own A and AAAA RRs directly and indirectly via a DHCP server, the problem is still the same, even if you move every hostname in a separate zone, for example it suffices to take over the webserver that serves example.com to change the MX RRs of example.com. With more fine-grained ACLs the problem would not exist. Currently ACLs consist of a subject (address and key), operation (transfer, notify, update, control) and object (zone). I think it would suffice to extend the object of an ACL to a triple (zone, name, type) similar to dynamic update policies in BIND. Perhaps it would also be useful to be able to use wildcards and negation. Are there any plans to extend the ACL mechanism in this way? Regards, Matthias-Christian

9 let, 10 měsíců

2
1
0 0

Keymgr broken?

by shadice＠arcor.de

Hi Is keymgr broken or what am I doing wrong? /knot# mkdir kasp /knot# cd kasp /knot/kasp# keymgr init /knot/kasp# keymgr zone add example.com policy none /knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 2048 ksk id 36b49807bcdf448c5034cf37688b99616760529c keytag 24400 knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 1024 Cannot retrieve zone from KASP (malformed config value). Regards, shadice

9 let, 10 měsíců

2
2
0 0

knot 2.0.0 and systemd type notify

by Daniel Stirnimann

Hello I've built knot 2.0.0 and created a rpm for redhat 7 and have a problem with the knot.service systemd file. I've used the rpm SPECS and knot.conf, knot.service file from the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=670057 and adapted the SPECS file slightly to get it working on redhat 7. The knot.service file has the following Service section: [Service] Type=notify ExecStart=/usr/sbin/knotd ExecReload=/usr/sbin/knotc reload Restart=on-abort ExecStartPre=/usr/sbin/knotc checkconf If I use the type "notify" and start the service (systemctl start knot) the command does not complete but stays in the foreground. After a few seconds, minutes systemd gets a timeout and terminates the service: systemd: knot.service operation timed out. Terminating. knot[32446]: info: stopping server knot[32446]: info: shutting down systemd: Failed to start Knot DNS server daemon. systemd: Unit knot.service entered failed state. I now changed the knot.service file to use type "simple" [1] and that works and resolves the problem. However, I believe to have read that type "notify" should work. Is this a bug? Daniel [1] http://www.freedesktop.org/software/systemd/man/systemd.service.html

9 let, 10 měsíců

2
2
0 0

Problems with serial-policy

by shadice＠arcor.de

Hi I have problems in v2.0.0 with the serial-policy definition as it is not working as expected. Here is my knot.conf which I am using: # knot.conf server: user: knot:knot udp-workers: 1 tcp-workers: 1 background-workers: 1 listen: 0.0.0.0@53 listen: ::@53 log: - target: syslog any: debug template: - id: default storage: /opt/knot semantic-checks: on dnssec-signing: on kasp-db: kasp serial-policy: increment zone: - domain: example.com dnssec-signing: off 2015-08-11T18:27:33 info: configuration is valid Using increment as serial-policy, first the serial gets incremented by 1. After that, it will stay at 1, nevertheless how many changes I make. info: [example.com] loaded, serial 0 -> 1 info: [example.com] loaded, serial 1 -> 1 info: [example.com] loaded, serial 1 -> 1 info: [example.com] loaded, serial 1 -> 1 Using unixtime as serial-policy, the serial stays always at 0. info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 Am I doing it wrong? Do you use in anyway a RTC? because I do not have it. Regards shadice

9 let, 10 měsíců

2
1
0 0

RoseDB & DNSProxy performance in production

by iorecvsendclose

Has anyone used the rosedb or dnsproxy modules extensively in production? I'm concerned about whether it would reliably scale as well as Knot does without it. I'm evaluating knot in hopes that I can use it to offer part of my would-be service to potentially millions of websites. I'm planning a free usage tier would would hopefully be heavily utilized. Regarding the specific implementation, I want to provide an authoritative DNS server that returns predefined values based on record types/host (rosedb). If the host/record combo conditions aren't met, proxy the request to the original nameserver(s). After reviewing the nightly code it looks like I'll likely need to invest a lot of time in order to support that chained query plan. Thank you for any feedback in advance. -Anonymous Coward

9 let, 10 měsíců

2
1
0 0

Reduce memory usage

by shadice＠arcor.de

Hi Knot DNS v2.0.0 reserves up to 620 MB memory on my Raspberry Pi. But it actually uses only 0.4 % of the available 512 MB memory. How can I limit the memory reservation/allocation to 100 MB? Regards shadice

9 let, 10 měsíců

2
1
0 0

prepare-environment

by Antti Ristimäki

Hi, I just upgraded to Knot 2.0 from the PPA repository and noticed that the script /usr/lib/knot/prepare-environment is still expecting the old style configuration format and as such is not working with the new YAML formatted configuration. As a consequence the /run/knot directory is not chown'ed to the configured user:group and the control socket creation fails. Cheers, Antti

9 let, 10 měsíců

2
1
0 0

Changes in Knot DNS repositories for Debian and Ubuntu

by Ondřej Surý

Hey all, if you are using Knot DNS repositories for Debian and/or Ubuntu, the repositories with just 'knot' will start shipping (or already started) shipping Knot DNS 2.0. There will be no Knot DNS 2.0 packages for Debian wheezy, since we don't want to backport that many libraries. If you absolutely have to stay on Debian wheezy, please switch to Knot DNS LTS. if you want to stay with Knot DNS LTS (1.6.x) replace the part that says /debian or /knot with /knot-lts or /knot-dns with /knot-dns-lts The full instructions should be soon up on the webpages, but TL;DR for Knot DNS LTS: Debian: su - wget -O - http://deb.knot-dns.cz/knot-lts/apt.key | apt-key add - rm -f /etc/apt/sources.list.d/knot.list echo "deb http://deb.knot-dns.cz/knot-lts/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/knot-lts.list apt-get update apt-get install knot Ubuntu: # remove ppa-purge ppa:cz.nic-labs sudo add-apt-repository -r ppa:cz.nic-labs/knot-dns sudo add-apt-repository ppa:cz.nic-labs/knot-dns-lts sudo apt-get update sudo apt-get install knot Cheers, -- Ondřej Surý -- Chief Science Officer -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 11 měsíců

3
4
0 0

AXFR - RFC1912

by Filipe Cifali

I'm migration from PowerDNS using AXFR and some of the domains fall on Section 2.4 having CNAME on top domains. Is there a way to ignore the warning and receive the query? An example of troublesome domain transfer: Jun 30 11:33:40 p-01 knot[2930]: info: [strangedomain.com] AXFR, incoming, 127.0.0.1@53: starting Jun 30 11:33:40 p-01 knot[2930]: warning: [strangedomain.com] semantic check, node 'strangedomain.com.' (CNAME, node contains other records than RRSIG and NSEC/NSEC3) Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] AXFR, incoming, 127.0.0.1@53: failed (failed) Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] transfer, failed (no active master) I'm running on Gentoo compiling Knotd 1.6.4 from source w/ no special flags. Thanks in advance! -- [ ]'s Filipe Cifali Stangler

9 let, 11 měsíců

5
13
0 0

Re: [knot-dns-users] AXFR - RFC1912

by Filipe Cifali

Sure, but was a silly mistake I made, Since I was testing on localhost over to another IP on the same machine, all the queries where going from the Local IP to loopback (even though I forced on the remotes flag w/ "via"). So all I had to do was actually serve everything through loopback (only different ports) to make things work. The debug showed the incoming query via *127.0.0.1 <http://127.0.0.1>:<randomport>* The wrong setup I made was: Knotd listening on 192.168.0.1:53; PowerDNS listening on 127.0.0.1:53; PowerDNS couldn't talk to Knotd there, so I changed to: Knotd listening on 127.0.0.1:*53*; PowerDNS listening on 127.0.0.1:*54*; And then they started talking AXFR properly Since this is only a test setup to a larger scale migration I was just testing how AXFR performs w/ tons of data to load (250mb of zone files) and frequent updates that I was running in the same virtual machine. BTW, is a good practice to use the zones over tmpfs or since the knotd already throw everything at RAM on the runtime I don't need it? I didn't liked the load times (but I do understand the existence of knotc and why I should not keep "restarting" knotd). On Tue, Jul 7, 2015 at 4:34 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote: > Hi Filipe, > > could you share your findings? We would like to know what was the solution > if another user happens to have the same problem. > > Feel free to share them in private if you don't want to do that publicly. > > Cheers, > -- > Ondřej Surý -- Chief Science Officer > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ------------------------------ > > *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com> > *To: *"Ondřej Surý" <ondrej.sury(a)nic.cz> > *Cc: *knot-dns-users(a)lists.nic.cz > *Sent: *Tuesday, July 7, 2015 9:26:03 PM > > *Subject: *Re: [knot-dns-users] AXFR - RFC1912 > > Oh I made it work after debugging enough I could get the info needed. > Without debug is very hard to understand why AXFR fails, it only returns > "connection refused". > > Thanks for the attention anyway :) > > On Tue, Jul 7, 2015 at 3:10 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote: > >> Also what does the Knot DNS logs say at debug level? >> >> We definitely have a user with similar setup (I'm Bccing him, so he can >> respond at his will) - PowerDNS as a primary and Knot DNS as a secondary. >> >> If you are into a deeper debugging, could you capture the packets between >> Knot secondary and PowerDNS primary? >> >> Cheers, >> Ondrej >> -- >> Ondřej Surý -- Chief Science Officer >> -------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC >> Milesovska 5, 130 00 Praha 3, Czech Republic >> mailto:ondrej.sury@nic.cz https://nic.cz/ >> -------------------------------------------- >> >> ------------------------------ >> >> *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com> >> *Cc: *knot-dns-users(a)lists.nic.cz >> *Sent: *Tuesday, July 7, 2015 5:41:17 PM >> *Subject: *Re: [knot-dns-users] AXFR - RFC1912 >> >> Yes, w/ aa flag and all the SOA record >> >> >> On Tue, Jul 7, 2015 at 12:12 PM, Jan Včelák <jan.vcelak(a)nic.cz> wrote: >> >>> Hello Filipe, >>> >>> does the PowerDNS server respond to SOA queries over TCP? >>> >>> $ dig +tcp @127.0.0.1 zone.name SOA >>> >>> Cheers, >>> >>> Jan >>> >>> On Tuesday, July 07, 2015 11:59:00 AM Filipe Cifali wrote: >>> > Thanks, I finished fixing all the zones now, finally. >>> > >>> > Anyone has ever used PowerDNS as master of a Knotd slave? I'm missing >>> > something since PowerDNS returns connection refused after the initial >>> > transfer, like it's not responding correctly to PowerDNS. >>> > >>> > Since I can dig AXFR @127.0.0.1 (which has PowerDNS running) I don't >>> see >>> > how he can be wrong. >>> > >>> > I'm not sure where to go looking for the problem here. >>> > >>> > Best Regards, >>> > >>> > [ ]'s >>> > >>> > On Thu, Jul 2, 2015 at 8:49 AM, Jan Včelák <jan.vcelak(a)nic.cz> wrote: >>> > > Hello Filipe, >>> > > >>> > > On Thursday, July 02, 2015 07:57:46 AM Filipe Cifali wrote: >>> > > > it's only failing for the zones w/ problems w/ CNAMEs, ignoring the >>> > > > semantic-check off on the config. >>> > > >>> > > I have just taken a look to make sure: This particular check is >>> mandatory >>> > > and >>> > > cannot be disabled. And I'm quite sure I want to keep it that way. >>> The >>> > > CNAME >>> > > in apex is not allowed. And we would have to define some behavior >>> how to >>> > > answer when this happens, which makes a little sense. >>> > > >>> > > You should rather urge your clients to fix their zones because this >>> > > problem >>> > > can lead to random resolution failures. >>> > > >>> > > Cheers, >>> > > >>> > > Jan >>> > > _______________________________________________ >>> > > knot-dns-users mailing list >>> > > knot-dns-users(a)lists.nic.cz >>> > > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>> >>> _______________________________________________ >>> knot-dns-users mailing list >>> knot-dns-users(a)lists.nic.cz >>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>> >> >> >> >> -- >> [ ]'s >> >> Filipe Cifali Stangler >> >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >> >> > > > -- > [ ]'s > > Filipe Cifali Stangler > > -- [ ]'s Filipe Cifali Stangler

9 let, 11 měsíců

1
0
0 0

Knot DNS 2.0.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs just released a final version of Knot DNS 2.0. There are only a few changes since the release candidate. The synchronization of zone file can be now disabled; knsupdate was improved to accept TSIG algorithm in interactive mode; and some small bugs have been resolved. I believe you are tuned to this channel and it makes a little sense to repeat all the new features we put into 2.0 in details. Just to sum up the most important things: - Knot DNS 2.0 uses new configuration format based on YAML. The new format adds zone templates, improves remotes and ACLs specification, and in general makes the configuration more readable. You can convert your existing 1.6 configuration using the knot1to2 utility. - We have a new DNSSEC backend. It is based on GnuTLS instead of OpenSSL. And it contains basic support for KASP (Key And Signature Policy). At the moment, it can generate initial zone signing keys and perform automatic ZSK rollover. For more details, please, take a look at the full change log, previous release e-mails, documentation, or just ask. We are looking forward to your feedback, feature requests, and even bug reports. And thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.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, 11 měsíců

7
15
0 0

Knot DNS 1.6.4 patch release

by Jan Včelák

Hello everyone! On behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.4. The patch release contains a bunch of non-critical bug fixes and a few improvements. The update is recommended but not necessary. Lots of changes are related to zone transfers. We resolved a problem where an incoming NOTIFY message was lost during ongoing transfer of the same zone. The AA flag in AXFR/IXFR queries is no longer set as recommended by the RFC. And in multi-master environment, if a master server is not available then the other master servers are tried immediately without waiting a SOA retry time. The kdig utility was also updated. A new '+generic' option causes printing of all resource records as if they were unknown records (according to RFC 3597). The '+noall' option now hides the TSIG section. And the Dnstap SocketProtocol is logged correctly if there is a failover from UDP to TCP. The zone parsing and dumping was improved as well. The zone parser can now read TXT/SPF strings longer than 255 characters which are automatically chopped into multiple strings. And the zone dumps will no longer print class name with the SOA record, which unifies the behavior across all resource record types, making the text processing of a zone file easier. Last but not least, we have resolved two build issues: Knot DNS can be now compiled against LibreSSL instead of OpenSSL without patching. And fast zone parser is forcibly disabled when compiling with Clang (this is a workaround for a bug in Clang optimizer which emits invalid code for the scanner). Thank you for attention. You can grab the sources as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/1.6/NEWS Source archives: https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.gz.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

10 let

1
0
0 0

Additional section

by Charles Musser

Hi, We've been running Knot 1.6.3 as a slave server and it's been working well. However, I notice that a "dig" against this slave for a domain does not return an "ADDITIONAL" section, but the same query against another slave that runs BIND does return one. I couldn't find any Knot configuration directive that would control this. Is there something I missed or additional configuration needed elsewhere to make the ADDITIONAL info available? Thanks, Chuck

10 let

2
3
0 0

Knot DNS 2.0.0-rc1 (release candidate)

by Jan Včelák

Hello list! The first release candidate of Knot DNS 2.0 by CZ.NIC Labs is available. The most significant changes since 2.0.0-beta are related to the server configuration. We have renamed a few configuration options for the sake of consistency and intuitiveness. And we have significantly improved the way how remotes and ACLs are defined. In prior version, each remote was assigned just one address, which led to quite long configuration files. The updated version allows specification of multiple addresses (and multiple TSIG keys), making the configuration file shorter and more readable. We have also added a basic support for zone file name patterns. At the moment, you can use the '%s' pattern in the template/file configuration option and the pattern will be substituted by a zone name. We would like to add another patterns in future. Feel free to let us know which patterns you would find useful. The 2.0.0-rc1 version also contains all bug fixes and improvements, which are included in the upcoming 1.6.4 stable release. And the icing on the cake is Bash and ZSH completion scripts for keymgr. Please, give the release candidate a try. We are looking forward to your feedback and bug reports. And as always, thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.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

10 let

1
0
0 0

[PATCH] kdig: Record the dnstap SocketProtocol correctly when retrying over TCP

by Robert Edmonds

Previously, kdig's write_dnstap() function passed net->srv->ai_protocol as dt_message_fill()'s 'protocol' parameter, but net->srv->ai_protocol is not actually guaranteed to be the socket protocol used for the query/response. When kdig's process_query_packet() retries over TCP, it only sets net->socktype to SOCK_STREAM in an already initialized net_t and calls itself. The addrinfo's in the net_t aren't updated, so they have the original values from the first invocation of process_query_packet(), i.e., the lookup that occurred over UDP. However, net->socktype is actually what controls whether TCP or UDP is ultimately used in net_connect(). Instead of passing net->srv->ai_protocol to dt_message_fill(), map net->socktype to an IPPROTO_* value. (Which is what kdig does elsewhere via get_sockname(), which is why the formatted output written to stdout at the same time, e.g. "127.0.0.1@53(TCP)" doesn't have a similiar bug.) --- src/utils/kdig/kdig_exec.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/utils/kdig/kdig_exec.c b/src/utils/kdig/kdig_exec.c index b91a958..1f6a64d 100644 --- a/src/utils/kdig/kdig_exec.c +++ b/src/utils/kdig/kdig_exec.c @@ -44,6 +44,7 @@ static int write_dnstap(dt_writer_t *writer, Dnstap__Message msg; Dnstap__Message__Type msg_type; int ret; + int protocol = 0; if (writer == NULL) { return KNOT_EOK; @@ -54,8 +55,14 @@ static int write_dnstap(dt_writer_t *writer, msg_type = is_response ? DNSTAP__MESSAGE__TYPE__TOOL_RESPONSE : DNSTAP__MESSAGE__TYPE__TOOL_QUERY; + if (net->socktype == SOCK_DGRAM) { + protocol = IPPROTO_UDP; + } else if (net->socktype == SOCK_STREAM) { + protocol = IPPROTO_TCP; + } + ret = dt_message_fill(&msg, msg_type, net->local_info->ai_addr, - net->srv->ai_addr, net->srv->ai_protocol, + net->srv->ai_addr, protocol, wire, wire_len, qtime, rtime); if (ret != KNOT_EOK) { return ret; -- 2.1.4

10 let, 1 měsíc

2
1
0 0

Updating slaves

by Amar Cosic

Hello list, anyone can point me to documentation or manual what is right way to update slaves. What I want to is when I change record X on master that slaves also pick that change without me manualy have to do this. My configuration is OK as on initial zone transfers slaves got data/zones OK. I tried knotc reload knotc flush knotc refresh and restarting knotc service. On all this there was nothing in syslog and slaves are not updating ty. -- Amar Ćosić amar.cosic(a)gmail.com amar(a)amar.ba

10 let, 1 měsíc

3
3
0 0

Knot DNS 1.6.3 patch release

by Jan Včelák

Hello list, CZ.NIC Labs just released Knot DNS 1.6.3. This patch release contains a few rather serious bug fixes and some minor improvements. Update is highly recommended. When performing our internal benchmarking, we discovered a serious performance drop for large NSEC-signed zones (not NSEC3). In construction of NSEC proofs for NXDOMAIN responses, the server got into a loop possibly causing iteration over all domain names in the zone. The problem was present in Knot DNS since the beginning of the project. We are sorry for not noticing this earlier. The new version also handles TCP short-writes properly. Prior to this fix, sending a response over TCP could fail if the socket send buffer was small (e.g., in default configuration on FreeBSD). In addition, if the buffers are too small, we increase their size on server initialization to make fast-path processing more likely. We also fixed possible out-of-bound memory accesses revealed by American Fuzzy Lop fuzzer. One such an access was in the zone parser (long domain names in zone origin) and two in the packet parser (TSIG with empty RDATA and malformed NAPTR). As for the improvements: The zone parser now supports CDS and CDNSKEY RR types, the documentation now includes default values for TCP config options, and more detailed message is emitted when a zone reload fails. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz.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

10 let, 1 měsíc

3
2
0 0

Knot DNS 2.0.0-beta release

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs releases Knot DNS 2.0.0-beta. We finally managed to complete, stabilize, and document all new features of the upcoming Knot DNS version. We are aware of some glitches in this release, however we think that it is ready to be tested by a wider audience. There are two key features of Knot DNS 2.0: # New DNSSEC implementation I wrote quite a lot about the new DNSSEC in the 1.99.1 release announcement. Since then, only a few things changed. There was a bug in the ZSK rotation algorithm. The old DNSKEY was removed too soon possibly breaking the validation. This problem is resolved now. The keymgr utility has a new manual page. And the documentation was updated to reflect all changes. # New configuration format This change is quite significant for the future development of Knot DNS. And it will affect everyone using the software. We decided to switch from a custom configuration format to YAML. Internally, the configuration is stored in a binary database (LMDB). At the moment, you won't probably notice anything about the database. However we are working on a new interface, which will allow making changes into the configuration without a full server reload. If you have Knot DNS with thousands of zones, you will benefit this for sure. We don't support full YAML specification, but there is a certain level of compatibility. We plan to extend the support so you can generate the config from your favorite scripting language. Some configuration options (and configuration sections) were renamed. We changed the concept how the incoming and outgoing connections are configured. We split 'remotes' to 'remote' and 'acl'. 'remote' defines target for outgoing connection (zone transfer source, notification target). And 'acl' defines rules for accepting connections initiated by a remote client (outgoing transfer, incoming notification, and incoming update). At the moment, only one address can be specified for each 'remote' or 'acl'. In addition, we removed 'groups' as it was complicating the implementation. We are aware that the current state is not ideal. And we are looking for feedback and suggestions from the community. We are not just removing and changing things - we added support for zone templates, which is something a lot of our users asked for. A template allows you to configure options shared among multiple zones. A change in the template affects all zones, which use the template. To convert the configuration from the 1.6 to the 2.0 format, the knot1to2 tool is provided. The tool doesn't support conversion for answering modules (e.g. synth_record), but should handle anything else. Please, review the configuration after performing the automatic conversion. That's all, folks! Please, give it a try. Experiment with the new DNSSEC and play around with the new configuration. And most importantly, let us know what do you think. Thank you for using Knot DNS! Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz.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

10 let, 2 měsíce

2
3
0 0

Work-around for Knot's configuration syntax

by Anand Buddhdev

I'm generating my Knot's config from a Jinja2 template, and I'm having a problem with one thing. For example, if I have a list of elements, [e1,e2,e3,e4], and I want to generate a "groups" config for these based on a condition, and I do: groups { mygroup { {% for x in list %} {% if condition %} {{ x }}, {% endif %} {% endfor %} } However, this results in a syntax error, because the last element ends with a comma, and then there's a closing bracket. I tried to insert the comma conditionally, by checking to see if it was the last element, but this can also fail if the last element didn't match the condition. So I thought about this ugly hack: groups { mygroup { {% for x in list %} {% if condition %} ,{{ x }} {% endif %} {% endfor %} } Notice that I have the comma *before* each element. This results in an opening brace, a comma, and then the other elements. My supposition is that Knot's syntax parser is okay with this, because it just sees a null first element. If I check this with knotc's "checkconf", it says the syntax is okay. Can I safely use such a config? Regards, Anand

10 let, 2 měsíce

4
4
0 0

Use of recvmmsg in Knot

by Anand Buddhdev

Dear Knot developers, In Knot 1.6.3, is it safe to leave out the "interfaces" section of the config on a multi-homed server? Will Knot enumerate all the addresses on the host and bind to them, or will it bind to 0.0.0.0 and ::? Secondly, if bound to 0.0.0.0 and ::, will Knot use recvmmsg correctly and set the source address in UDP reply packets to the address the query was sent to? Regards, Anand

10 let, 2 měsíce

2
1
0 0

key file format for nsupdate

by Andrew Stevenson

Hi, I am trying to use nsupdate from knot 1.6.1. I have generated key files using dnssec-keygen from BIND 9.9.5. i.e. dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com Whenever I try to use the files with nsupdate -k <file> though I get: ; Error: failed to read key file: public key file is invalid I have also tried without the “-C” to dnssec-keygen. Are there different flags I need? Or does someone have an example of the file format required? Thanks, Andrew

10 let, 3 měsíce

2
2
0 0

Short write?

by Linus Nordberg

Hi, I'm looking at knot-1.6.1 after have experienced failure with sending AXFR after a zone grew due to enabling DNSSEC, adding a lot of records. I don't know much about iovecs, but isn't this a short write? --8<---------------cut here---------------start------------->8--- libknot/internal/errcode.h: enum knot_error { ... KNOT_ECONNREFUSED = -ECONNREFUSED, ... KNOT_ERROR_MIN = -1000, ... KNOT_ERROR = KNOT_ERROR_MIN, ... KNOT_ECONN, ... }; libknot/internal/net.c: int tcp_send_msg(int fd, const uint8_t *msg, size_t msglen) { ... int total_len = iov[0].iov_len + iov[1].iov_len; int sent = writev(fd, iov, 2); if (sent != total_len) { return KNOT_ECONN; } ... } knot/server/tcp-handler.c: tcp_handle() { ... while (state & (NS_PROC_FULL|NS_PROC_FAIL)) { uint16_t tx_len = tx->iov_len; state = knot_process_out(tx->iov_base, &tx_len, &tcp->query_ctx); /* If it has response, send it. */ if (tx_len > 0) { if (tcp_send_msg(fd, tx->iov_base, tx_len) != tx_len) { ret = KNOT_ECONNREFUSED; break; } } } ... } --8<---------------cut here---------------end--------------->8--- Happy to file a bug report if that's a more proper way of reporting bugs.

10 let, 3 měsíce

2
1
0 0

[PATCH] Add "forced generic" dump style, and kdig +generic option

by Robert Edmonds

This patch adds a new "forced generic" dump style which dumps resource record types and data in the generic RFC 3597 representation format, even for known resource record types. A corresponding +generic option to kdig enables this dump style. Generic representation format is very handy when dealing with older DNS software that may not support a new resource record type, or with systems where it is more convenient to use the generic format even with known types. It is also a nice debugging / educational feature. (No need to fire up Wireshark.) --- man/kdig.1.in | 3 +++ src/libknot/rrset-dump.c | 10 +++++++++- src/libknot/rrset-dump.h | 2 ++ src/utils/kdig/kdig_params.c | 13 +++++++++++++ 4 files changed, 27 insertions(+), 1 deletion(-) diff --git a/man/kdig.1.in b/man/kdig.1.in index 4772e27..b6f2286 100644 --- a/man/kdig.1.in +++ b/man/kdig.1.in @@ -178,6 +178,9 @@ Use EDNS version (default is 0). Disable IDN transformation to ASCII and vice versa. IDNA2003 support depends on libidn availability during project building! .TP +.BR +generic +Use the generic representation format when printing resource record types and data. +.TP .BI +client= SUBN Set EDNS client subnet SUBN=IP/prefix. .TP diff --git a/src/libknot/rrset-dump.c b/src/libknot/rrset-dump.c index dd4625d..2f503c1 100644 --- a/src/libknot/rrset-dump.c +++ b/src/libknot/rrset-dump.c @@ -1774,6 +1774,10 @@ int knot_rrset_txt_dump_data(const knot_rrset_t *rrset, return ret; } + if (style->generic) { + return dump_unknown(&p); + } + switch (rrset->type) { case KNOT_RRTYPE_A: ret = dump_a(&p); @@ -1941,7 +1945,11 @@ int knot_rrset_txt_dump_header(const knot_rrset_t *rrset, } // Dump rrset type. - if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { + if (style->generic) { + if (snprintf(buf, sizeof(buf), "TYPE%u", rrset->type) < 0) { + return KNOT_ESPACE; + } + } else if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { return KNOT_ESPACE; } if (rrset->rrs.rr_count > 0) { diff --git a/src/libknot/rrset-dump.h b/src/libknot/rrset-dump.h index 4519159..e44cca3 100644 --- a/src/libknot/rrset-dump.h +++ b/src/libknot/rrset-dump.h @@ -46,6 +46,8 @@ typedef struct { bool human_ttl; /*!< Format timestamp as YYYYMMDDHHmmSS. */ bool human_tmstamp; + /*!< Force generic data representation. */ + bool generic; /*!< ASCII string to IDN string transformation callback. */ void (*ascii_to_idn)(char **name); } knot_dump_style_t; diff --git a/src/utils/kdig/kdig_params.c b/src/utils/kdig/kdig_params.c index ec7ec9f..6fafb22 100644 --- a/src/utils/kdig/kdig_params.c +++ b/src/utils/kdig/kdig_params.c @@ -54,6 +54,7 @@ static const style_t DEFAULT_STYLE_DIG = { .empty_ttl = false, .human_ttl = false, .human_tmstamp = true, + .generic = false, .ascii_to_idn = name_to_idn }, .show_query = false, @@ -551,6 +552,15 @@ static int opt_noidn(const char *arg, void *query) return KNOT_EOK; } +static int opt_generic(const char *arg, void *query) +{ + query_t *q = query; + + q->style.style.generic = true; + + return KNOT_EOK; +} + static int opt_nsid(const char *arg, void *query) { query_t *q = query; @@ -805,6 +815,8 @@ static const param_t kdig_opts2[] = { /* "idn" doesn't work since it must be called before query creation. */ { "noidn", ARG_NONE, opt_noidn }, + { "generic", ARG_NONE, opt_generic }, + { "client", ARG_REQUIRED, opt_client }, { "time", ARG_REQUIRED, opt_time }, @@ -1363,6 +1375,7 @@ static void kdig_help(void) " +[no]nsid Request NSID.\n" " +[no]edns=N Use EDNS (=version).\n" " +noidn Disable IDN transformation.\n" + " +generic Use generic representation format.\n" " +client=SUBN Set EDNS client subnet IP/prefix.\n" " +time=T Set wait for reply interval in seconds.\n" " +retry=N Set number of retries.\n" -- 2.1.4

10 let, 3 měsíce

2
1
0 0

Statistics

by Julian Brost

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, does Knot have a feature like "rndc stats" in BIND or "nsd-control stats" that allows you to get some statistics about how many queries were handled and what their result were (like SERVFAIL etc.)? Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU8zytAAoJECLcYT6QIdBtLg8P/2wF5gwHQigZ5dI5S2pztM0C ryKAV5h6mqSuO91S+qA7IAP3GpAlzs5GrNYW9kGXspo+w9mwb/D5+mNhDSOGyoW9 iItT16TATzwpNK89Gw2uRhVJ2BhYTuQTmrp3WwAYHAe6wYGOQdBtZoel5UzSrm5e I//3DFgmpGHSwITRcxOBl2MYhRpHEhiBQdUjk2MmTcy/L3GF1HMlY2oHuy4sFZk+ lL6x9N/NX/6K5OspF8p8eoNQ7LIBIA6OKNhz08SdsAKSe1F76pL+FPnb8iQUC6Ao EXkdeFftxOxocL+TTSpAhqEF86IXvRsiNSic8wjYXt9blsMcOAJQFNgU25Bs5+IV u8EtZgcusq5SbHD0Dp5wYkNV4BYYmjU2omzjxMtqV4MFZG9V8XFlXbfVwC64fsUe YfYjvK071EK2hVHTrui637tnS8uEcTJa0X8lpCEgYsy+6/EGyQ3H/8eyu77jZT57 yeZnfG4Ai/QrgS6w3jEu3+uk+kwds2wYHqHbIIw3o0GQ8awQ0kPC6tKg0dXI7aFN tlYBM0mycQv3hFSk7x6jxJ1UPWVxdIOrNg8Vgg8FsgWnXu+JHJJxEV7uoj5DogTJ PaSFOQccTrVoa1vwJgiHLmOALdY/5FDb9cddN1GBgj2wqcUkS/hR8tSRNXkLShhX BTijrkJTR8qeiEEFgthp =bPR2 -----END PGP SIGNATURE-----

10 let, 3 měsíce

2
1
0 0

Knot DNS 1.6.2 patch release

by Jan Včelák

Hello everyone, on behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.2. The patch release contains one new feature and a few small bug fixes. With the new version, a number of concurrent TCP clients connected to the server can be limited. The limit is set using the 'max-tcp-clients' configuration option in the 'system' section. Purpose of this setting is to avoid resource exhaustion when the server is under a load. And the default value for the option is 100. When the limit is hit, new connections are not being accepted for a few seconds. Active connections are not affected. Please note, that we have also slightly lowered defaults for TCP idling timeouts. As for the bug fixes: A possible file descriptor leak when terminating inactive TCP clients was fixed. Scheduled events for zones switched from slave mode to master mode are handled correctly. And compilation of Dnstap features on FreeBSD works now. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz.asc Thank you for using Knot DNS. 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

10 let, 4 měsíce

2
2
0 0

Knot DNS 1.99.1 (preview of DNSSEC with KASP)

by Jan Včelák

Hello everyone! After months of keeping our secrets, we would like to share with you a preview of a new DNSSEC implementation in Knot DNS. The new DNSSEC will be one of the key features for the upcoming Knot DNS 2.0. If you are watching our source repository, you may have noticed a tag v1.99.0 appearing silently at the end of 2014. At that time, Knot DNS was already using the newly implemented DNSSEC, but the only visible change was a different key format. And internally, GnuTLS/Nettle was replaced OpenSSL for cryptographic operations. Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next step towards the 2.0. Knot DNS 1.99.1 adds initial support for DNSSEC KASP (Key And Signature Policy). This is our vision of real-world DNSSEC deployment. Essentially, you define a policy (used algorithm, key sizes, key lifetime, signature lifetime, etc.) and the server will do the heavy lifting. It will generate keys and publish/roll them correctly, so you don't have to compute and set timing meta-data on private keys manually. At the moment, the KASP support is quite limited: Single algorithm, single KSK, and single ZSK can be specified in the policy. The server is able to generate initial keys and perform ZSK rollovers (key pre-publish method). More features are coming soon. A documentation on KASP [1] is currently available on the project wiki, including the reference manual for a new management utility keymgr [2]. [1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup [2] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-keymgr-reference Source archives are available as usual: https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.gz Please note, that Knot DNS 1.99.1 is not ready to replace Knot DNS 1.6.x. We are looking forward to hear some feedback from you. And we are happy to answer all your questions and concerns. 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

10 let, 4 měsíce

5
14
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users