knot-dns-users

knot-dns-users@lists.nic.cz

734 discussions

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

by Josef Karliak

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

9 let, 7 měsíců

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

by Florian Maury

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

9 let, 7 měsíců

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

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

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ů

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ů

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ů

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ů

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ů

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ů

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users