knot-dns-users Listopad 2015

knot-dns-users@lists.nic.cz

8 participants
7 discussions

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

8 let, 5 měsíců

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

by Florian Maury

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

8 let, 5 měsíců

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

by Daniel Salzman

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

8 let, 5 měsíců

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

by Josef Karliak

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

8 let, 5 měsíců

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

by Florian Maury

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

8 let, 5 měsíců

[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

8 let, 5 měsíců

[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

8 let, 5 měsíců

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users Listopad 2015