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

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, 6 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, 6 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

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

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, 3 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, 3 měsíce

5
14
0 0

DNSSEC and slave zones?

by Jan-Piet Mens

Good evening, I don't seem to be able to configure Knot 1.6.1 to sign a zone it slaves in: example.com { file "/usr/local/etc/knot/aa/example.com.zone"; xfr-in home; dnssec-keydir "/usr/local/etc/knot/aa"; dnssec-enable on; } If I omit the two 'dnssec-*' parameters, the zone is slaved in. Adding them, however, results in no transfer; log shows: notice: [example.com] automatic DNSSEC signing enabled, disabling incoming XFRs Is it currently possible with Knot to sign a slaved zone? Regards, -JP

10 let, 4 měsíce

2
1
0 0

Re: [knot-dns-users] Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Leo

Hi, > How would one go about converting from PowerDNS to KnotDNS on an active > realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary > disruption of services to existing DNS users? > If it's truly anycast it should only be easier, I would simply: - stop announcing the anycasted prefix at node #1 - once you see no queries anymore: convert and test - after finishing: switch on routing - repeat untill node #last Unless you have bizarre performance complications, above would be more safe than converting an active node. Did I maybe misunderstand the question? Or did you mean: "how to convert from pdns with a transactional SQL backend to a conventional DNS setup with Knot" ..? Leo

10 let, 4 měsíce

1
0
0 0

Knot DNS and IN NS records

by Eugene Bolshakoff

Hello All, I've decided to use Knot DNS as secondary nameserver for my local zone. I have several subnets connected via VPN and they have their own nameservers. So, there are records in my zone zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 zu.mithril. 3600 IN NS zu-gw.vpn.mithril. and I want to resolve domain in zu.mithril: BIND (master): # dig @tessa.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @tessa.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7626 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; ANSWER SECTION: melissa.zu.mithril. 0 IN A 172.19.3.1 ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 143 msec ;; SERVER: 172.19.37.1#53(172.19.37.1) ;; WHEN: Wed Jan 14 19:24:27 2015 ;; MSG SIZE rcvd: 92 KNOT (secondary): # dig @mira.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @mira.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10182 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 0 msec ;; SERVER: 172.19.38.2#53(172.19.38.2) ;; WHEN: Wed Jan 14 19:24:51 2015 ;; MSG SIZE rcvd: 76 I understand that it's happening because of recursion in bind, but how can I solve this problem in knot? -- With best regards, Eugene Bolshakoff

10 let, 5 měsíců

2
1
0 0

Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Ret Law

How would one go about converting from PowerDNS to KnotDNS on an active realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary disruption of services to existing DNS users?

10 let, 5 měsíců

3
2
0 0

Knot DNS v1.6.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing a new version of Knot DNS. This release introduces a new feature and fixes few bugs. The new feature is a support for Single Type Signing Scheme in automatic DNSSEC implementation. As far as bugfixes are concerned, we've fixed a couple of problems with IXFR/DDNS journal file. Most importantly, it was sometimes not respecting its file size limit (ixfr-fslimit configuration option). We've also fixed incompatibility with OpenSSL 0.9.8. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz.asc There are not many changes in this release, but those of your who use IXFR or DDNS should definitely upgrade. Regards and thanks for using Knot DNS, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 5 měsíců

6
7
0 0

Knot 1.6.1 and journal size tuning

by Anand Buddhdev

Hi Knot developers, I've now installed version 1.6.1 on some servers, and I'm observing some journal related issues, and I have questions about them. First off, here's one issue: 2014-12-15T06:00:56 info: [203.in-addr.arpa] NOTIFY, incoming, 193.0.0.198@53535: received serial 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] refresh, outgoing, 193.0.0.198@53: master has newer serial 3006121317 -> 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:57 warning: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: failed to write changes to journal (not enough space provided) 2014-12-15T06:00:58 notice: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: fallback to AXFR 2014-12-15T06:00:58 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:59 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: finished, serial 3006121317 -> 3006121318, 0.65 seconds, 171 messages, 7960312 bytes So it looks like the IXFR is too big, and won't fit into the journal, and Knot is falling back to AXFR. When I requested this IXFR by hand, I got: $ dig ixfr=3006121317 203.in-addr.arpa @193.0.0.198 ... ... ;; XFR size: 121779 records (messages 170, bytes 7963389) The size of the IXFR in bytes is below the configured file size limit (10M), but I suspect that 7963389 bytes probably take up more room in the journal, so Knot can't write into it, and is falling back to AXFR. Are you able to tell me (approximately of course), how much disk space is required for a given number of bytes of IXFR? This will help me tune the setting of ixfr-fslimit to avoid this unnecessary fallback to AXFR.

10 let, 6 měsíců

3
2
0 0

Knot 1.6.1 and full journal

by Anand Buddhdev

Hi Knot developers, I have another question about journals. I've noticed that for one zone, the journal size is 9M (with my configured limit at 10M). Now, I see this each time in the logs: 2014-12-15T07:56:02 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:13:09 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:16:35 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:20:27 notice: [103.in-addr.arpa] journal is full, flushing It looks like once a journal is close to the maximum size, then it just remains at that size, with the result that each time an IXFR comes in, and overflows the journal, Knot wants to flush the changes to disk immediately. Does Knot discard old records from the journal at this point? Anand

10 let, 6 měsíců

3
2
0 0

zlib dependency

by Matthias-Christian Ott

Knot DNS depends on zlib to calculate Adler-32 checksums. A comment in crc.h states that it “should be removed”. I want to use knsupdate on OpenWRT and would also like to remove the dependency. Unfortunately, there is no single library that provides only Adler-32 checksums and every examined software either relies on zlib or its bundled implementation of varying quality and speed. Other projects seem to use CRC32C because there is an instruction to calculate it in the SSE4.2 instruction set. But again there is no library that only implements only CRC32C checksums. Switching to CRC32C would also make the journal format incompatible. I'm inclined to just copy the reference implementation from RFC 1950 for my purposes but wanted to check with the upstream maintainers whether there are any plans or ideas. It would also be nice if the configure script would have an option to not include and compile unused functionality from libknot and libzscanner to minimize binaries sizes. - Matthias-Christian

10 let, 6 měsíců

3
4
0 0

failed (connection refused)

by Eric Kom

Good day All, Please I got a connection refused when trying to setup a master and slave on the same network. THIS IS AN EXTRACT FROM MY MASTER KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { storage "/var/lib/knot"; metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-out slaveOnKnot; notify-out slaveOnKnot; } } root@ns1:~# knotc reload OK root@ns1:~# grep knot /var/log/syslog Nov 27 07:10:41 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 07:10:41 ns1 knotd[469]: 2014-11-27T07:10:41 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: 2014-11-27T08:08:09 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 09:27:33 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:27:33 ns1 knotd[469]: info: reloading configuration Nov 27 09:27:34 ns1 knotd[469]: info: configuration reloaded Nov 27 09:27:34 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014102701 -> 2014112700 Nov 27 09:27:34 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) Nov 27 09:29:46 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:29:46 ns1 knotd[469]: info: reloading configuration Nov 27 09:29:47 ns1 knotd[469]: info: configuration reloaded Nov 27 10:13:37 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:13:37 ns1 knotd[469]: info: reloading configuration Nov 27 10:13:37 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:14:15 ns1 knotd[469]: info: reloading configuration Nov 27 10:14:15 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014112700 -> 2014112701 Nov 27 10:14:15 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) THIS IS AN EXTRACT FROM MY SLAVE KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/var/lib/knot"; # # # Example slave zone metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-in masterOnKnot; notify-in masterOnKnot; } } root@ns2:~# knotc reload OK root@ns2:~# grep knot /var/log/syslog Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@10548: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@13456: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@60566: unauthorized request Nov 27 08:47:30 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@54094: unauthorized request Nov 27 09:28:36 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:28:36 ns2 knotd[397]: info: reloading configuration Nov 27 09:28:36 ns2 knotd[397]: info: [metropolitanbuntu.co.za] zone will be bootstrapped, serial 0 Nov 27 09:28:36 ns2 knotd[397]: info: configuration reloaded Nov 27 09:28:36 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:28:36 ns2 knotd[397]: 2014-11-27T09:28:36 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: 2014-11-27T09:29:01 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: 2014-11-27T09:29:54 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:30:02 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:30:02 ns2 knotd[397]: info: reloading configuration Nov 27 09:30:02 ns2 knotd[397]: info: configuration reloaded Nov 27 09:31:49 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:49 ns2 knotd[397]: 2014-11-27T09:31:49 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: 2014-11-27T09:31:56 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: 2014-11-27T09:32:34 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: 2014-11-27T09:34:15 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: 2014-11-27T09:37:59 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: 2014-11-27T09:45:29 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: 2014-11-27T10:00:45 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:14:26 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 10:14:26 ns2 knotd[397]: info: reloading configuration Nov 27 10:14:26 ns2 knotd[397]: info: configuration reloaded -- -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

10 let, 6 měsíců

3
4
0 0

When will you remove the limitation that a zone be signed by a KSK and ZSK ?

by Olafur Gudmundsson

In your documentation you say: Single-Type Signing Scheme is not supported. I only want to sign with a single key in some cases, i.e. there is no value in having the split as updating my parent is easy. Olafur

10 let, 7 měsíců

2
2
0 0

Rhel 6.3 RPM ?

by Lynch Davis

I am looking around for an rpm deployment since I have a "hardened" box that I wanted to install this on. Was going to try to build my own, but it looks like libucru is not readily available for the this distribution either. help or links? Thanks, Lynch

10 let, 7 měsíců

2
1
0 0

synchronized processing for specific RR Type

by Lynch Davis

Hi - I was reading on the faq about zone events serialization. Has this feature been implemented? I am experimenting with a processing that would require this feature, and if I could simply add a query processor and specify serialization, a majority of my problem (I think) would be solved. I have yet to explore the full feature set of the query_processor to know if this is a correct statement, but I am hopefull. Thanks, Lynch

10 let, 7 měsíců

2
1
0 0

Knot DNS 1.6.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs proudly presents the final release of Knot DNS 1.6.0. This version also becomes an LTS (Long-term support) version of the Knot DNS software. We added two more bugfixes on top of the features covered by the previous e-mails announcing the release candidates. And as this is the final release, let's highlight the most important changes: The only new feature in Knot 1.6.0 is 'persistent zone timers'. The refresh, expire, and flush zone timers are now stored in file-backed database. Thus, the state of the timers survives a complete restart of the server. (Please note that the feature is optional and requires the LMDB library.) The processing of letter case in RDATA domain names was modified: In most cases, the names are converted to lower-case letters. The exception are RR types, which are treated case-sensitively in DNSSEC. With this change, some Knot DNS internals were simplified and also problems with invalid signatures issued by Knot DNS for mixed-case RR sets should be gone. A few minor bugs in EDNS processing were resolved. And since the -rc2, we fixed forced zone retransfer (knotc refresh -f <zone>), which got broken at some point during 1.5 development. And we also corrected slave zone expiration, when the master is responding to SOA queries but refusing the transfer. We would like to thank Anand Buddhdev for helping us in testing the release candidates and also for reporting the last two bugs. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz.asc Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 7 měsíců

3
4
0 0

How to allow certain hosts to do AXFR?

by Rainer Duffner

Hi, is it possible to allow certain IPs to AXFR all zones? I need this for our helpdesk, so they can send zonefiles to customers etc. I don’t want knot to send ixfrs etc. to these IPs.

10 let, 7 měsíců

3
2
0 0

KNOT zone file

by Eric Kom

Hi all, I'm new on KNOT, and has been running BIND for many years now and would like to set up another master server to serve the domain metropolitanbuntu.co.za on a different network based on Debian and Knot. The Knot-DNS server its running fine: root@ns1:/etc/knot# knotc status OK The metropolitanbuntu.co.za zone was defined in the knot.conf file, just simple definition: zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage storage "/var/lib/knot"; # # Example master zone # example.com { # file "/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } metropolitanbuntu.co.za { file "/var/lib/knot/metropolitanbuntu.co.za.zone"; } } After ran: root@ns1:/etc/knot# knotc -c knot.conf reload OK And checked the Syslog: root@ns1:/etc/knot# grep knot /var/log/syslog Oct 18 09:33:23 ns1 knotd[414]: info: remote control, received command 'refresh' Oct 18 09:33:47 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:33:47 ns1 knotd[414]: info: reloading configuration Oct 18 09:33:47 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:33:47 ns1 knotd[414]: info: configuration reloaded Oct 18 09:42:24 ns1 knotd[414]: info: remote control, received command 'status' Oct 18 09:45:03 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:45:03 ns1 knotd[414]: info: reloading configuration Oct 18 09:45:03 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:45:03 ns1 knotd[414]: info: configuration reloaded The metropolitanbuntu.co.za zone look up to date. My question is: its the zone file looks like the BIND one? do I have to create it, may be I missed the zone declaration in the Knot manual? It is possible to do the master to master replication from BIND to KNOT? Thanks for your support. -- -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

10 let, 8 měsíců

2
3
0 0

Subject: how to assign multiple addresses for one zone?

by Junyoung Park

Hi! I have a question to configure knot dns for split-dns server. (only master , no slaves) If my router have two interfaces, eth0 (connected with ISP) and eth1 (internal private). About same zone (ex. example.com), i want to responses different ways for eth0, eth1. (ex. eth0, www.example.com -> read /etc/knot/external.example.zone, eth1, www.example.com -> /etc/knot/internal.example.zone) How can i configure it?

10 let, 8 měsíců

5
4
0 0

DNSSEC and Zone files

by dptrash＠arcor.de

I have DNSSEC in knot-dns activated. It always signs my file and it is very difficult to change my zone file with the dnssec stuff inside. Is it possible, to keep the zone file clean and it creates a .signed file for dnssec?

10 let, 8 měsíců

2
1
0 0

Knot DNS 1.6.0-rc2 (release candidate)

by Jan Včelák

Hello list! The second release candidate of Knot DNS 1.6.0 by CZ.NIC Labs is here! The update contains just a few changes, which improve the new persistent slave zones timers feature. The database for the zone timers was being opened before the privileges were dropped and UID/GID changed. As a result, the database could not be reopened after invoking the "knotc reload" command and updated timers could not be written into the database. This problem is resolved now. If you are updating from -rc1, you will need to fix the database ownership to match your knotd user. We also increased the maximal size of the database from 10 MB to 100 MB. This should be enough for thousands of slave zones. And finally, we improved a logging of errors related to database operations. If you have a time to try the new release candidate, please, do so. The final release will probably slip a few days, but it is still scheduled for the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.xz Have a nice weekend! Best regards, Jan, CZ.NIC Labs

10 let, 8 měsíců

1
0
0 0

Knot DNS 1.6.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs presents the first release candidate of Knot DNS 1.6.0. This comes quite soon after the release of the 1.5.3, which took place about a month ago. For this time, we were really conservative about inclusion of new features. We want to maintain Knot DNS 1.6.0 as a stable version and we intend to provide bug fixes for this release for a longer period of time. The 1.6.0 brings just one new feature - persistent timers for slave zones: The server stores zone expire, refresh, and flush timers in the file-backed database. The timers are written whenever they change and are recovered when the server is started. As a result, the timers will survive a full server restart. The persistent timers feature is an optional feature and depends on the LMDB library. Please, make sure the library is available at the build time and check the output of the 'configure' script, if you want to use this feature. We also modified domain names letter-case handling in RDATA. Previously, we preserved letter case of domain names in RDATA fields. With the 1.6.0, the domain names are converted to lower-case letters, unless the RR type is "new" and should be handled case-sensitively for compatibility with old servers. We believe that this approach is RFC-compliant. The letter case handling modification allowed us to simplify the DNSSEC signing code a little bit and also resolved problems with invalid signatures issued by Knot DNS for some mixed-case RR sets. All the other changes are various small bug fixes. Please, give Knot DNS 1.6.0-rc1 a try and report any troubles you encounter. We are looking forward to your feedback. If everything goes well, we plan to release the final version at the beginning of the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.xz Best regards, Jan, CZ.NIC Labs

10 let, 8 měsíců

1
0
0 0

Feature requests

by josten＠no-io.net

Hey everyone, I have a production Knot DNS setup; there are two features that I believe would make it even better than what it is now. * Under the zones section a way to just "push" all master zones to slaves; the slaves should just accept any zone from a verified master in the slaves knot.conf. * The ability to just load zones from disk without explicitly stating the zone in knot.conf. For example in /var/lib/knot/example.com.zone; Knot DNS automatically loads the example.com.zone without it being identified in the knot.conf under the zone section. Of course it should do checks (like it does now) before loading the zone, and then gracefully fail and log to the logging mechanism. Other than that; awesome DNS server!

10 let, 8 měsíců

2
1
0 0

[PATCH] dnstap: Fix ProtobufCBufferSimple usage that is incorrect as of protobuf-c 1.0.0

by Robert Edmonds

protobuf-c 1.0.0 added a new 'allocator' field to ProtobufCBufferSimple that controls memory allocation, which must be NULL in order to request the default system allocator. Allocating ProtobufCBufferSimple objects on the stack without zeroing the entire object can result in protobuf-c's memory allocation functions dereferencing a garbage pointer. Note that the use of the zero initializer in this instance generates a warning on some gcc versions: dnstap.c: In function 'dt_pack': dnstap.c:26:2: warning: missing braces around initializer [-Wmissing-braces] ProtobufCBufferSimple sbuf = {0}; ^ dnstap.c:26:2: warning: (near initialization for 'sbuf.base') [-Wmissing-braces] This warning is spurious and was fixed recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211289 --- src/dnstap/dnstap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dnstap/dnstap.c b/src/dnstap/dnstap.c index 41d42e7..cf3770c 100644 --- a/src/dnstap/dnstap.c +++ b/src/dnstap/dnstap.c @@ -23,7 +23,7 @@ uint8_t* dt_pack(const Dnstap__Dnstap *d, uint8_t **buf, size_t *sz) { - ProtobufCBufferSimple sbuf; + ProtobufCBufferSimple sbuf = {0}; sbuf.base.append = protobuf_c_buffer_simple_append; sbuf.len = 0; -- 2.0.0

10 let, 8 měsíců

2
1
0 0

knot-1.4.4-49.1.i586 on opensuse 12.2 and automatic resign zone not approved ?

by Josef Karliak

Good afternoon, I made a change in our zone, changed serial of the zone and reload the zone. When I check the syslog, I saw some complains, that the signatures was out of date. For example: Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: A. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: AAAA. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: NSEC. This happens for all records in the zone. Last change was 11.8.2014, knot signed it and planned resign to 7.9.2014: Aug 11 13:39:10 slimak knot[22992]: Semantic checks completed for zone=fnhk.cz. Aug 11 13:39:10 slimak knot[22992]: Zone 'fnhk.cz.' reloaded (serial 2014081101) Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing started... Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-09-07T11:39:10. Aug 11 13:39:10 slimak knot[22992]: Loaded 5 out of 5 zones. Aug 11 13:39:10 slimak knot[22992]: Applied differences of 'fnhk.cz.' to zonefile. Aug 11 13:39:10 slimak knot[22992]: Configuration reloaded. Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081102). on 7.9.2014 the zone was resigned automatically: Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing zone... Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-10-04T11:39:10. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Started (serial 2014081102 -> 2014081103). Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Serial 2014081102 -> 2014081103. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Finished in 0.01s. And after today's changes knot told me that the signatures was out of date. I've this similar version of knot on my own server, there is no problem Any ideas ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (with ADSP) . 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 check. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

10 let, 8 měsíců

2
2
0 0

Problem with CNAME in uppercase

by Didier ALBENQUE

Hi, I am currently testing knot and I have found a problem when CNAME are in uppercase. My primary server is running with BIND. I have these two declarations : myserver IN A 10.1.1.1 myserver-alias IN CNAME MYSERVER On the knot secondary server, after zone transfer, all seems ok : myserver.mydomain.fr. 900 A 10.1.1.1 myserver-alias.mydomain.fr. 900 CNAME MYSERVER.mydomain.fr. But when I ask knot for myserver-alias, I have a NXDOMAIN response (tcpdump output below) : 17:00:29.718834 IP dns-client.38146 > knot-server.domain: 4787+ A? myserver-alias.mydomain.fr. (43) 17:00:29.719011 IP knot-server.domain > dns-client.38146: 4787 NXDomain*- 1/1/0 CNAME MYSERVER.mydomain.fr. (123) 17:00:29.719555 IP dns-client.54520 > knot-server.domain: 2945+ A? myserver-alias.mydomain.fr.mydomain.fr. (54) 17:00:29.719637 IP knot-server.domain > dns-client.54520: 2945 NXDomain*- 0/1/0 (111) Tested with knot 1.5.1 and 1.5.2 Best regards, -- Didier ALBENQUE SG/SDSI/BSE Architecte technique Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais ---------------------------------------------------------------------- Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

10 let, 8 měsíců

2
2
0 0

Debian archive signing key, available over https?

by Andreas Olsson

Greetings Regarding the gpg key used to sign http://deb.knot-dns.cz/debian/. Any chance that that key could be available for downloaded by way of https://, or perhaps just have its fingerprinted listed on https://www.knot-dns.cz/pages/download.html? While the https:// CA model is far from perfect it'd still like to think it being a step up compared to regular http://, and at the same time a lot easier to document than the process of following the signatures in a gpg web of trust. // Andreas

10 let, 8 měsíců

2
2
0 0

Knot DNS v1.5.3 bugfix release

by Jan Kadlec

Hello list! CZ.NIC Labs are releasing a new version of Knot DNS today. This release fixes a regression that got introduced in the 1.5.2 release. This bug was causing Knot slaves to crash when receiving some specific IXFRs (more info: https://gitlab.labs.nic.cz/labs/knot/issues/294). Users that use Knot DNS as a slave should definitely upgrade. We've also added fixes for other issues we've recently discovered. Among those fixes are a fix to a very rare synchronization error during server reload (https://gitlab.labs.nic.cz/labs/knot/issues/296) and a fix to make dynamic query modules work properly with DNSSEC (https://gitlab.labs.nic.cz/labs/knot/issues/295). Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz.asc We apologize for two bugfix releases in such a short time, please be assured that we're expanding our tests and we'll also be changing our release policy to try to prevent any future regressions. Special thanks for bug reports go to Anand Buddhdev and Bastien Durel. Regards and thanks for using Knot DNS, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 9 měsíců

1
0
0 0

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

JFTR I did push the 1.5.2 to wheezy-backports directly since 1.5.2 contains a remote vulnerability, so it's available there - see https://tracker.debian.org/knot Cheers, -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 9 měsíců

1
0
0 0

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

Could you please flush your DNS cache (deb.knot-dns.cz should point to sophie.nic.cz now) and try again? The debarchive got broken and I couldn't fix it, so it has been replaced by reprepro. In case you can't flush your caches, please just temporarily change deb.knot-dns.cz to sophie.nic.cz. Also the repository is now signed: # wget -O - http://deb.knot-dns.cz/debian/apt.key | apt-key add - Full instructions can be found here: http://deb.knot-dns.cz/debian/README.txt Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 9 měsíců

1
0
0 0

problem with debian repository

by Peter Hudec

Hi, this mail is directed for debian repository maintainers. The debian repository is not working properly, the Packages(.gz) and Sources(.gz) files are empty. http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources .... I tested only wheezy distribution release. best regards Peter Hudec

10 let, 9 měsíců

3
2
0 0

Knot DNS 1.5.2 bugfix release

by Jan Kadlec

Hello list! Today, Knot DNS version 1.5.2 has been released by CZ.NIC Labs. This is a bugfix release. Unfortunately, while doing some internal testing, we've found a remote vulnerability that can crash the server. So far, we've had no reports that would suggest that someone else has discovered this vulnerability, but it is important all users upgrade as soon as possible. CVE for this vulnerability is CVE-2014-0486. We've also included a couple more fixes: Knot was refusing AXFR-style IXFR transfers, meaning these transfers had to be sent twice. Further, Knot was not properly escaping the hash character in domain names when saving the text zone file. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz.asc Again, we advise all users to upgrade immediately. We are truly sorry for any inconvenience caused by this. Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 9 měsíců

2
1
0 0

knot init in Debian

by Zdeněk Zámečník

I have following issue with Knot: when I try to stop it by command /etc/init.d/knot stop then the daemon is still running. If i run command knotc stop then it's stopped but immediately run again. If I kill it by command kill, it's the same... As I found the /etc/init.d/knot is not working at all and Knot is probably run during boot by /etc/init/knot.conf and I'm not able to control it. The "unkillable" proccess is named /usr/sbin/knotd -c /etc/knot/knot.conf My environment: Debian 7 AMD64, OpenVZ container, kernel 2.6.32-openvz-042stab092.2-amd64, Knot 1.5.0-1 I tried to install Knot on another older machine where is Debian 7 too but upgraded from 6 and it's KVM virtual machine. There it works correctly via init.d script and the proccess is named /usr/sbin/knotd *-d* -c /etc/knot/knot.conf Do you have an idea why it's working on older machine correctly and on the second with OpenVZ not? Thanks for any help. Zdenek Z.

10 let, 9 měsíců

6
10
0 0

multimaster docs?

by Nicolás Reynolds

hi, i see knot 1.5.0 has multimaster support but i can't find more info/docs on this, can you point me to it? -- D

10 let, 9 měsíců

3
3
0 0

Knot and systemd

by Anand Buddhdev

Hello Knot folk, I'm building Knot RPM packages for use on CentOS 7, and I have to write systemd unit files. Before I write anything, I'd love to hear from others who may already have done such work, to learn from it. Let me describe my ideas. On my existing Knot servers running on CentOS 6 with upstart, I have 2 upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf upstart script looks in /etc/knot for .conf files, and for each one, runs knot-instance with the config file as a parameter. This way, a simple "start knot" will start all instances. In systemd, there is better support for instances, so I want to create a knot@.service template unit, and a knot.target target unit. Then, I can create new instances with "systemctl enable knot(a)conf1.conf" and "systemctl enable knot(a)conf2.conf". Finally, running "systemctl start knot.target" should start all configured instances. Does this sound reasonable? I would also like to know about Knot's built-in support for systemd. I can't find any documentation about it. Could one of the devs please describe what Knot actually does if it's compiled with systemd support? Would you mind adding this information to the online documentation? Regards, Anand

10 let, 9 měsíců

2
3
0 0

Knot DNS 1.5.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing Knot DNS version 1.5.1! Let's discuss bugfixes first. Most notably, we've fixed a bug in automatic DNSSEC signing: domain names in RDATA were not lowercased before signing, resulting in bogus signatures. Other interesting bugfixes include proper handling of DDNS prerequisites and some TSIG and EDNS corner cases. As for the new features, we've added a basic support for logging using systemd journal. At the moment, log messages related to zone have the ZONE field set, which means that you can easily filter log messages based on zone name criteria. We plan to add more fields in the future to allow more fine-grained filtering. We're looking forward to your suggestions in this area. Moreover, we've improved DDNS performance for large zones by grouping incoming updates together and executing them as a bulk. This partially mitigates problems with RCU and copying the zone structure, but dynamic updates' running time is still proportional to size of the zone and not to the size of the actual updates. Improving this is one of our top priorities, and code in this release will help us to do so. Finally, we've improved and unified format of logging messages. Most notable, each logging message concerning a zone is now prepended with [zone name]. If you parse the output of log files, be sure to update your scripts. Further, we now enforce a more strict policy for DNSSEC signing keys: at least one active pair of KSK and ZSK keys of the same algorithm must be present at all times, or Knot will refuse to sign the zone. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz.asc Be sure to let us know if you run into any problems. Have a nice day and thanks for using Knot DNS! Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 10 měsíců

1
0
0 0

workflow for zone signing on master

by chrysn

hello, i'm operating a small hidden master server (four zones spread out to two external NS servers), and want to introduce dnssec. so far, i have kept my zone files in /etc under version control, but now knot starts overwriting them, which is kind of important because of the serial number increments, but also removes file structure, and comments and generally messes with the changelog. i could not quite infer from the documentation what the recommended work flow is in this situation: * will things work if i just make the zone files read-only for bind? * should i keep the original files separate and copy them over to the knot-writable destinations for each refresh? if yes, can that be automated from within knot? in either case, i have to take care of the serial numbers. my current numbering scheme (YYYYMMDDXX with year, month, day and per-day number) produces sufficiently few automated changes that incrementing by 10 each time i edit the unsigned file on one deay would work, but what is best practice there? best regards chrysn ps. please keep me in cc when replying, as i'm not subscribed to the list. -- There's always a bigger fish. -- Qui-Gon Jinn

10 let, 11 měsíců

4
4
0 0

Knot DNS 1.5.0 final release

by Jan Kadlec

Hello Knot DNS users! After two release candidates, CZ.NIC Labs proudly release Knot DNS 1.5.0 final. This new version differs greatly from the old 1.4 branch - we've rewritten quite a big portion of our code, and we've built a foundation for next cool features to come. But you've probably read about the changes in 1.5.0 in the previous release messages, so here's just a brief list of improvements that are visible to users: Optional query modules (currently we have dnstap and response synthesization modules implemented), lower memory footprint and improved zone events handling (for those of you with problems with zone expiring, 1.5.0 should not have this problem). We've also done a lot of under-the-hood changes, with lots of refactoring and massive code reductions. Apart from all this, we've been very busy writing tests - our current test code coverage is around 75 percent. Here are the changes we've made from 1.5.0-rc2: Features: - DDNS forwarding reimplemented Improvements: - Transfer sizes logged in bytes if needed - Logging outgoing NOTIFY messages - Logging unauthorized incoming NOTIFYs Bugfixes: - Zone flush planning after bootstrap - Incorrect incoming AXFR message sizes - DDNS signing changes were freed too soon, with possibility of stale data - knotc remote control key handling Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz.asc We've done all we could to test Knot DNS 1.5.0 on our end, now it's time you gave it a try! We hope you'll be as happy with it as we are. Today's thanks for bug reports go to Anand Buddhdev and Motomu Utsumi. Have a nice day and thanks for using Knot DNS! Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 11 měsíců

1
0
0 0

Re: [knot-dns-users] Two hidden masters - sending notifications to public slaves.

by Ondřej Surý

Hi Maren, you should turn the explicit notification both in bind and knot. For Knot use "notify-out <slave1> <slave2>;" + "xfr-out <slave1> <slave2>;" See the documentation: https://www.knot-dns.cz/static/documentation/html/configuration.html#master… For Bind use "notify explicit;" + "also-notify;", see: http://www.zytrax.com/books/dns/ch7/xfer.html#notify Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Monday, July 7, 2014 1:32:52 PM > Subject: [knot-dns-users] Two hidden masters - sending notifications to public slaves. > Hi, > > We are setting up to do zone generations of two separate hidden masters > which will take turns on the zone generation. > > Public/visible DNS servers "should" get notifies from both servers and > select the one with the with the highest serial number. > > I am planning to run bind on one server and knot on the other. On bind i > have the issue that it would not send notifies to the name servers until > I turned on "notify-soa yes;". However I realise that his will only > notify one single DNS server and introduces a single point of failure. > > Does Knot have any issues sending the notifies. How do I go about > getting this done? > > Regards, > Maren > > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 11 měsíců

4
5
0 0

Problem with expiring zones - new stable version

by Jakub Stollmann

Hello, after upgrading to new stable version 1.4.7 we noticed a problem with zones, which are expiring (i've seen some bugfix -expiration timer). It happened second time now, and i think its happening every week (7days). Zones, which expired are selected randomly, count of expired zones is ~8. expired zones are listed like this: somezone.net. type=slave | serial=0 | bootstrap idle | After manually refreshing zone everything works fine. TTL is 86400 - 1 day We are using knot as slave dns. Bind9 is master. Thanks for some advices. Jakub

10 let, 11 měsíců

2
1
0 0

Random source port for incoming NOTIFY

by Gonzalo Muñoz

Hello everybody, We're currently testing Knot for a slave server with a BIND master, and we've noticed that NOTIFY messages from this master are not being processed by Knot. As I understand, BIND uses a random source port for NOTIFY messages, as a precaution against attacks. Also, if I understand correctly, when I add a remote master to a zone in Knot, if I don't specify a port for it then it defaults to 53- This leads me to believe that Knot is rejecting NOTIFY messages from the BIND master, because they come from an unexpected, random port. Is this correct? Can this situation be rectified to allow NOTIFY messages from random ports? Thank you very much in advance. Gonzalo Muñoz NIC Chile

10 let, 11 měsíců

3
4
0 0

Two hidden masters - sending notifications to public slaves.

by Maren S. Leizaola

Hi, We are setting up to do zone generations of two separate hidden masters which will take turns on the zone generation. Public/visible DNS servers "should" get notifies from both servers and select the one with the with the highest serial number. I am planning to run bind on one server and knot on the other. On bind i have the issue that it would not send notifies to the name servers until I turned on "notify-soa yes;". However I realise that his will only notify one single DNS server and introduces a single point of failure. Does Knot have any issues sending the notifies. How do I go about getting this done? Regards, Maren

10 let, 11 měsíců

1
0
0 0

Knot DNS 1.4.7 patch & 1.5.0-rc2 releases

by Jan Kadlec

Hello list! Today we release two new versions of Knot DNS: 1.4.7 patch release and a second release candidate of 1.5.0: 1.4.7 patch release fixes few minor issues and one major one, here they are in the order of their importance: - Assertion failure when serializing NAPTR records - this error can pop up with DDNS and transfers, regular queries are safe. - Knot could send mismatched IXFRs with automatic DNSSEC enabled. - Some DDNS corner cases were not handled properly. - Slave zone EXPIRE timer could be improperly set. - Zone semantic checks gave some false positive warnings. The NAPTR assertion failure is quite serious, so we recommend all users to update. We sincerely apologize for this. Hopefully all the code reduction and refactoring we did will pay off and versions 1.5 and beyond will see fewer patch releases. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.7/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz.asc 1.5.0 second release candidate contains two new features: - edns-client-subnet support for kdig, see https://gitlab.labs.nic.cz/labs/knot/issues/252 for more info - Asynchronous startup is now configurable (config option "asynchronous-start"). Two minor improvements: - Faster zone reload. - Text zone files are no longer written to disk right after bootstrap, but are flushed in accordance with the "zonefile-sync" config option. And the following bugfixes: - Knot did not close connection with remote during transfer when the remote replied with SERVFAIL. - Knot was giving wrong log message during IXFR -> AXFR fallbacks. - Some zone events were not handled properly during reloads. We encourage everyone to give the second release candidate a try and send us as much feedback as possible :) Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz.asc We'd like to thank Anand Buddhdev, Alex Massover and Bastien Durel for feedback and bug reports. Have a nice day and thanks for using Knot DNS! Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

10 let, 12 měsíců

1
0
0 0

Parallel dynamic DNS updates

by Alex Massover

Hello, I'm trying to understand if Knot can solve our performance problem with big scale dynamic DNS deployment. Currently we use BIND and the performance of Dynamic Updates is insufficient for our requirements. Doing some research I understood that BIND processes updates sequentially and can't really benefit from SMP. I understand how RCU allows parallel reads with updates. But reads is not an issue in our deployment. My question is, does Knot able to process multiple updates in parallel (and not sequentially) and provide a better scale for _updates_? As far as I understand it depends on data structure hierarchy implemented in Knot. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let

3
7
0 0

Knot 1.4.6 Aborted on NAPTR ddns update

by Alex Massover

Hello, We have Knot 1.4.6 on CentOS installation. When doing NAPTR ddns update, like this: nsupdate > server x.x.x.x > update add 3.1.1.1.1.1.1.1.1.2.7.9.9.our.domain.com. 172800 NAPTR 1 1 "u" "E2U+sip" "!^.*$!sip:123@freeswitch.org!" . > send ; Communication with server failed: timed out It fails with: knotd: libknot/rrset.c:1703: rrset_serialize: Assertion `size_one == rr_size' failed. Aborted No issues with ddns updates with TXT records. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let

2
2
0 0

Re: [knot-dns-users] Master-slave replication

by Bastien Durel

Le samedi 14 juin 2014 à 00:10 +0200, Jan Kadlec a écrit : > Hello, > one more thought: Could you please check your master log file for this > warning message: (log for category: zones and severity: warning has to > be enabled) "Zone file for '...' changed, but serial didn't - won't > create changesets."? This happens when you change the zone, but the > serial remains the same. > Note that Knot will change the serial when automatic DNSSEC is enabled, > so before creating the zone file in the script, you have to get the > current serial from server and increment that serial. Updating your zone > files using this approach might help you, but it is nevertheless a bug. Hello, I had this warning sometimes. I edit my zone files with emacs in zone mode, so the serial is auto-incrementing, but I have to save it twice to pass over the dnssec auto-increment. I put a check in my makefiles to ensure the old serial is lower than the new one. Look like it works with that, here was my mistake :) Thanks a lot ! Regards, -- Bastien Durel <bastien+knot(a)durel.org>

11 let

1
0
0 0

Master-slave replication

by Bastien Durel

Hello I have some zones in 2 knots in a master-slave relation When I update zones in master, there are replications issues in slave: - sometime changed records are duplicated (old and new value) - sometime removed records persists - sometime the RRSIG records are duplicated (old and new value) I often have to erase slave zones and to restart knot to get correct zone. I update master zone via makefiles that re-create (unsigned) zone files and then reload knot via knotc What is my mistake ? Regards, -- Bastien

11 let

2
3
0 0

Re: [knot-dns-users] Parking page with a large number of zones pointing the the same file.

by Ondřej Surý

Hi Maren, it would never be the 'same' zone file, since you have different full labels (foo.example.net is different from foo.example.com) per zone after loading them into the memory. I would suggest that this use case scenario would be best served by some new query processing dynamic module[1] that you would configure for all those zones and that would always respond with the same data. 1. See the Knot DNS 1.5.0rc1 release notes and documentation Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Thursday, June 12, 2014 7:50:02 PM > Subject: [knot-dns-users] Parking page with a large number of zones pointing the the same file. > Hello, > I would like to know what the memory allocation/usage > would be like if say I point 1M zones to the same zone file. > > Will it allocate memory for each of the zones or can it just allocate > memory once as it is the same zone file ? > > Regards, > Maren. > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

11 let

2
1
0 0

Parking page with a large number of zones pointing the the same file.

by Maren S. Leizaola

Hello, I would like to know what the memory allocation/usage would be like if say I point 1M zones to the same zone file. Will it allocate memory for each of the zones or can it just allocate memory once as it is the same zone file ? Regards, Maren.

11 let

1
0
0 0

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

11 let

1
0
0 0

Fwd: Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Peter, On 4 June 2014 12:08, Peter Andreev <andreev.peter(a)gmail.com> wrote: > Just a few thoughts to start from: > > 1. Masters have to have possibility to exchange their states to each > other, including zones, journals. This means that "multi-master" > should be a "per-zone" feature; It is, the multi-master is enabled like: example.com { xfr-in master1, master2; } and the "master2" is then used for failover if the zone transfer with "master1" fails for example. Usually, you don't need multiple masters until you have a specific use case for that. > 2. Each master in case of dynamic update has to forward this update to > other masters. This means that server should look to its configuration > rather than to mname field; That is true, but this may also cause problems with some specific setups. Like for example hidden master that can only sign the zone, but can't forward dynamic updates and such. That is not to say relying on mname is always the best. Truth is, I don't like the idea of authoritative servers forwarding messages, but it seems there are legitimate use cases for that. Maybe we could let the zone operator override the mname with the configuration and put a warning in there, or is there a complete error-proof solution I'm not aware of? > 3. In case of first start there should be option for operator to tell > server if it starts as slave and has to sync from other masters, or it > should consider itself as master and provide data to others. As of now, the zone is treated as master unless it has at least one remote in the "xfr-in" option. Maybe it's not very intuitive, but we have a new configuration (to allow remote configuration as well) in planning, so this could be something to consider. > There is a lot to discuss actually, for example, what to do with > DNSSec? How to handle requests from slaves on first start? > > As for me, such master should be specialized software with main focus > not on performance, but on management and inter-server communication. I tend to agree, I originally wanted to support multiple masters only to provide failover for zone transfers. > 2014-06-04 13:35 GMT+04:00 Alex Massover <alex(a)jajah.com>: >> Hi, >> >> >> >> Please see inline >> >> >> >> From: marek(a)vavrusa.com [mailto:marek@vavrusa.com] On Behalf Of Marek >> Vavruša >> Sent: 04 June 2014 11:13 >> To: Alex Massover >> Cc: knot-dns-users(a)lists.nic.cz >> >> >> Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate! >> >> >> >> Hi Alex, the "xfr-in" statement always allowed a list of remotes as masters. >> However, only the first one was always used. With the 1.5.0, other remotes >> are used for >> >> failover should the first master be inaccessible or returning lame answers. >> There isn't any advanced functionality like load balancing or anything, do >> you need something like that? >> >> Also, the update forwarding to primary master is not reimplemented in the >> rc1 (but will be in final, see KNOWN_ISSUES). In that case, the things get >> tricky - in past, we used the first remote in the list >> >> as a primary. With the list now, we should probably take the primary NS as >> is in the SOA of the zone. Thoughts? >> >> >> >> [Alex] Will this guarantee data consistency, providing there are a number of >> slave servers with update forwarding? >> >> Also, I'm not sure I understand how the second master gets the updated zone, >> when the first fails. >> >> >> >> >> >> Best, >> >> Marek >> >> >> >> On 4 June 2014 09:35, Alex Massover <alex(a)jajah.com> wrote: >> >> Hello, >> >> >> >> I'm not able to find any information about how multi-master works. >> >> >> >> Can someone point me to the info, please? Does it work with dynamic updates? >> >> >> >> BR, Alex. >> >> >> >> From: knot-dns-users-bounces(a)lists.nic.cz >> [mailto:knot-dns-users-bounces@lists.nic.cz] On Behalf Of Marek Vavruša >> Sent: 03 June 2014 21:31 >> To: knot-dns-users(a)lists.nic.cz >> Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate! >> >> >> >> Here are the correct links for those baffled by my (admittedly) poor mail >> formatting skills. >> >> >> >> Changelog: >> https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS >> >> Sources: >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz >> >> GPG signatures: >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc >> >> >> >> Marek >> >> >> >> -- >> >> Marek Vavrusa, Knot DNS >> >> CZ.NIC Labs http://www.knot-dns.cz >> >> ------------------------------------------- >> >> Americká 23, 120 00 Praha 2, Czech Republic >> >> WWW: http://labs.nic.cz http://www.nic.cz >> >> >> On 3 June 2014 20:10, Marek Vavruša <marek.vavrusa(a)nic.cz> wrote: >>> >>> Hi Everyone, >>> >>> with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs >>> thought >>> that the time has come to share it with you in form of a first release >>> candidate. >>> I'd like to tell you a story first - I was browsing through the NEWS file, >>> looking back >>> at the things we've done since the 1.0.0 two years ago. Oddly enough, one >>> of the new >>> features was an "optimized memory consumption", and I've seen this repeat >>> a few times. >>> I would have thought that the Knot DNS consumes zero memory by now, but it >>> appears it doesn't >>> work that way. The law of diminishing return still applies, and the >>> changes in between the versions >>> seem almost insignificant. Sometimes at least (recently, I've added a >>> benchmark of 1M small zones to our benchmark [1], which showed how much >>> memory did we need per each zone). >>> We addressed that. And despite the new preallocated packet buffers and >>> other features, we still managed to cut down the resource requirements for >>> TLD use cases for about 20%. >>> My point is, while the 20% does not seem that impressive alone, but the >>> steep release-over-release tendency of smaller memory footprint and faster >>> startup/answer performance just shows the unrelenting attention to the >>> seemingly insignificant stuff, like structure alignment or packet >>> distribution. That's what we're commited to. >>> >>> Now, what's actually new in the 1.5.0? I've touted the major changes under >>> the bonnet earlier this >>> year and boy, we've been busy. One of the major changes is the new query >>> processing, which allowed us to do several cool things. The query processing >>> is broken down to the set of step, >>> that are built like a LEGO, and each of the steps can be altered by the >>> modules. >>> We have two modules now - a module capable of synthesizing forward/reverse >>> records according to the configuration template. This for example solves the >>> IPv6 reverse records problem (SLAAC as well), as we don't have to generate >>> massive zones, but rather create the records on the fly. >>> The second module is a dnstap query/response log. Heard about the dnstap >>> [2]? It's a pretty ingenious solution to the fine-grained capture of the DNS >>> traffic without compromising the performance. >>> >>> By the way, the utilities (kdig) support it too and you can either capture >>> or replay queries now. >>> The good thing about modules is that it allows us to streamline (about 12K >>> LOC less) the core functionality and extend the server at the some time. >>> Think RRL, load balancing, geo-aware answers. >>> >>> What about other things? As for the visible changes, for instance a >>> multi-master failover, improved logs, asynchronously loaded zones, much more >>> accurate "knotc memstats" and "zonestatus" tools, new user manual ... >>> I could probably bore you to death with the nitty gritty stuff, so check >>> out the changelog to know more. That being said, I'd like to ask your help. >>> The new stuff, like the asynchronous zone loading or logging, change the >>> usability a little. Did we break your scripts or use case? Compliment, >>> cheeky remark or angry rant? Please let us know, we'd like to get most of >>> the kinks ironed out till the final release. Thank you. >>> >>> Changelog: >>> https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS >>> >>> Sources: >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz >>> >>> GPG signatures: >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc >>> >>> [1] http://knot-dns.labs.nic.cz/pages/benchmark.html#tab-resource-usage >>> [2] http://dnstap.info/ >>> >>> Kind Regards, >>> >>> Marek >>> >>> -- >>> Marek Vavrusa, Knot DNS >>> CZ.NIC Labs http://www.knot-dns.cz >>> ------------------------------------------- >>> Americká 23, 120 00 Praha 2, Czech Republic >>> WWW: http://labs.nic.cz http://www.nic.cz >> >> >> >> >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >> > > > > -- > Is there any problem Exterminatus cannot solve? I have not found one yet.

11 let

2
1
0 0

Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Anand, I see this could be a problem, is the backoff causing the delays for failed zone transfers? There is a configuration option "background-workers" with which you can limit the number of parallel requests, but if you can email me some statistics about failed/passed transfers and transfers/second we can probably work out some more clever queuing. Cheers, Marek On 4 June 2014 12:11, Marek Vavruša <marek(a)vavrusa.com> wrote: > Hi Anand, > > I see this could be a problem, is the backoff causing the delays for > failed zone transfers? > There is a configuration option "background-workers" with which you > can limit the number of parallel requests, > but if you can email me some statistics about failed/passed transfers > and transfers/second we can probably work out > some more clever queuing. > > Cheers, > Marek > > On 4 June 2014 12:06, Anand Buddhdev <anandb(a)ripe.net> wrote: >> On 03/06/2014 20:10, Marek Vavruša wrote: >> >>> Hi Everyone, >>> >>> with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs >>> thought >>> that the time has come to share it with you in form of a first release >>> candidate. >> >> Great stuff Marek! >> >> I've started an instance of 1.5.0-rc1 with a few thousand slave zones >> configured. The bootstrap takes quite a while as Knot has to XFR all the >> zones in. >> >> It looks like Knot is hitting our master very hard, because it seems to >> want to make too many parallel connections. I see this in the logs: >> >> 2014-06-04T09:58:51 [error] AXFR of 'zone' with 'master': Requested >> resource is busy. >> >> Each such error will cause Knot to retry the zone later, and waste time >> and cycles. Is there any way to get Knot to limit the number of parallel >> XFRs it does? Or re-use TCP connections? >> >> The Knot server has been running for over 15 minutes now, and has still >> not finished boot-strapping all the zones. >> >> Regards, >> >> Anand >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

11 let

1
0
0 0

Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Everyone, with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs thought that the time has come to share it with you in form of a first release candidate. I'd like to tell you a story first - I was browsing through the NEWS file, looking back at the things we've done since the 1.0.0 two years ago. Oddly enough, one of the new features was an "optimized memory consumption", and I've seen this repeat a few times. I would have thought that the Knot DNS consumes zero memory by now, but it appears it doesn't work that way. The law of diminishing return still applies, and the changes in between the versions seem almost insignificant. Sometimes at least (recently, I've added a benchmark of 1M small zones to our benchmark [1], which showed how much memory did we need per each zone). We addressed that. And despite the new preallocated packet buffers and other features, we still managed to cut down the resource requirements for TLD use cases for about 20%. My point is, while the 20% does not seem that impressive alone, but the steep release-over-release tendency of smaller memory footprint and faster startup/answer performance just shows the unrelenting attention to the seemingly insignificant stuff, like structure alignment or packet distribution. That's what we're commited to. Now, what's actually new in the 1.5.0? I've touted the major changes under the bonnet earlier this year and boy, we've been busy. One of the major changes is the new query processing, which allowed us to do several cool things. The query processing is broken down to the set of step, that are built like a LEGO, and each of the steps can be altered by the modules. We have two modules now - a module capable of synthesizing forward/reverse records according to the configuration template. This for example solves the IPv6 reverse records problem (SLAAC as well), as we don't have to generate massive zones, but rather create the records on the fly. The second module is a dnstap query/response log. Heard about the dnstap [2]? It's a pretty ingenious solution to the fine-grained capture of the DNS traffic without compromising the performance. By the way, the utilities (kdig) support it too and you can either capture or replay queries now. The good thing about modules is that it allows us to streamline (about 12K LOC less) the core functionality and extend the server at the some time. Think RRL, load balancing, geo-aware answers. What about other things? As for the visible changes, for instance a multi-master failover, improved logs, asynchronously loaded zones, much more accurate "knotc memstats" and "zonestatus" tools, new user manual ... I could probably bore you to death with the nitty gritty stuff, so check out the changelog to know more. That being said, I'd like to ask your help. The new stuff, like the asynchronous zone loading or logging, change the usability a little. Did we break your scripts or use case? Compliment, cheeky remark or angry rant? Please let us know, we'd like to get most of the kinks ironed out till the final release. Thank you. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS> Sources: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.xz.asc [1] http://knot-dns.labs.nic.cz/pages/benchmark.html#tab-resource-usage [2] http://dnstap.info/ Kind Regards, Marek -- Marek Vavrusa, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let

4
8
0 0

Re: [knot-dns-users] knot-dns-users post from fay-mutluluk-hikayeleri@fotoalem.com requires approval

by Jan Včelák

Dne St 28. května 2014 16:19:49, knot-dns-users-owner(a)lists.nic.cz napsal(a): > As list administrator, your authorization is requested for the > following mailing list posting: > > List: knot-dns-users(a)lists.nic.cz > From: fay-mutluluk-hikayeleri(a)fotoalem.com > Subject: You are in the financial matrix. Choose the red pill! > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://lists.nic.cz/cgi-bin/mailman/admindb/knot-dns-users > > to approve or deny the request.

11 let

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users