Hi,
I did a "apt-get upgrade" on my Knot node.
The package update fails with "Failed to initialize default key store
(unknown error -13)."
Can anyone tell me what that means?
root@localhost:~# knotd --version
knotd (Knot DNS), version 2.1.0
root@localhost:~# ps aux | grep knot
knot 30048 0.0 0.6 1245236 6400 ? Ssl 16:08 0:00
/usr/sbin/knotd -d -c /etc/knot/knot.conf
root@localhost:~# /etc/init.d/knot restart
* Restarting Knot DNS server knotd
[ OK ]
root@localhost:~# ps aux | grep knot
knot 30115 0.0 0.6 1245224 6200 ? Ssl 16:09 0:00
/usr/sbin/knotd -d -c /etc/knot/knot.conf
root@localhost:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up knot (2.1.0-2+trusty+2) ...
* Starting Knot DNS server knotd
[ OK ]
Failed to initialize default key store (unknown error -13).
dpkg: error processing package knot (--configure):
subprocess installed post-installation script returned error exit
status 1
Errors were encountered while processing:
knot
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@localhost:~# ps aux | grep knot
knot 30115 0.0 0.6 1245236 6360 ? Ssl 16:09 0:00
/usr/sbin/knotd -d -c /etc/knot/knot.conf
Kind regards,
Volker
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
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.czhttps://www.nic.cz
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.
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
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
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.czhttps://www.nic.cz
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/NEWShttps://gitlab.labs.nic.cz/labs/knot/raw/v2.0.2/NEWS
Tarballs:
https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xzhttps://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.aschttps://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.czhttps://www.nic.cz
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
