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.
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
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
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
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
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
-----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-----
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>
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
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.czhttps://www.nic.cz
