Dear Knot DNS users,
CZ.NIC has released Knot DNS 2.5.1 that fixes issues that some users might
experience when upgrading existing DNSSEC enabled installations of Knot DNS.
Knot DNS 2.5.1 (2017-06-07)
===========================
Bugfixes:
---------
- pykeymgr no longer crash on empty json files in the KASP DB directory
- pykeymgr no longer imports keys in the "removed" state
- Imported keys in the "removed" state no longer makes knotd to crash
- Including an empty configuration directory no longer makes knotd to crash
- pykeymgr is distributed and installed to the distribution tarball
Thank you for using Knot DNS. Feel free to write us, fill an issue or
just say thank you if you are happy with Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.x/html/
Cheers,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
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/
--------------------------------------------
Hello Knot DNS users,
CZ.NIC has just released the 2.5.0 version of Knot DNS with the
following features:
- New LMDB-based KASP database, which no longer uses JSON files and
provides
better performance and robustness. With this change, the keymgr syntax
has been
redesigned and new pykeymgr utility was introduced for migration from
the previous version.
- Automatic DNSSEC signing newly supports KSK rollover and optional
shared KSK keys.
During the key submission, CDS and CDNSKEY records are generated. A
periodical checking
for new DS at the masters or a maximum time interval can be configured
for automatic
finalization of the rollover or by manual calling the
zone-ksk-submitted knotc command.
- Completely new query module API with dynamic loading functionality.
So, for example, the dnstap module can be a separate package in a
repository.
- Zone events freeze and thaw knotc operations, which allow reliable
manual zone
modification along with possible automatic modifications.
- Zone journal can be used to store full zone contents beside the
subsequent zone
differences if the zone file synchronization is disabled. This
configuration is especially
interesting on slave servers. Manual zone flush is still possible with
an optional
destination directory parameter.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.0/NEWS
Source code:
https://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.5/html/
In addition to that, Knot DNS 2.4.4 patch release has been released,
including some
event timing and journal fixes.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.4/NEWS
Source code:
https://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xz.asc
Regards,
Daniel
Hi,
I have the following configuration working for unbound, how can I get
the same behavior working in knot-resolver?
server:
do-not-query-localhost: no
domain-insecure: "stubzone"
local-zone: "stubzone" nodefault
stub-zone:
name: "stubzone"
stub-addr: 127.0.0.2
I run this for various testing and what I want is to redirect a zone to
a local DNS server and I also what the resolver to follow any
delegations it receives.
Cheers,
Jerry
Dear all,
I setup knot to do an automatic rollover of the zsk after 180 days
policy:
- id: policy
keystore: keystore
manual: off
single-type-signing: off
algorithm: rsasha256
ksk-size: 4096
zsk-size: 2048
zsk-lifetime: 180d
propagation-delay: 1d
However I can not see on which date this will be.
root@vserver:~# keymgr zone key list yyy.ch
- 28f58xx 6862
- 79fb61b77xx 63816
root@vserver:~# keymgr zone key list yyy.ch
- 28f58xx 6862
- 79fb61b77xx 63816
root@vserver:~# keymgr zone key show yyy.ch
Name of zone and key have to be specified.
root@vserver:~# keymgr zone key show yyy.ch 28f58xx
id 28f58xx
keytag 6862
algorithm 8
size 4096
flags 257
publish 1491505038
active 1491505038
retire 0
remove 0
root@vserver:~# keymgr zone key show yyy.ch 79fb61b77xx
id 79fb61b77xx
keytag 63816
algorithm 8
size 2048
flags 256
publish 1491504999
active 1491504999
retire 0
remove 0
How do I know it is activated and when it will be ?
I imported the keys - can this be the reason ?
Thank you and
best regards
Dirk
Hi all,
I'm currently looking for alternatives which do automatic DNSSEC signing
as a master DNS server. I run a Knot secondary instance and added a
manual and auto signing zone, because I want to understand the
differences and which is better for my needs.
I added this to my knot.conf
policy:
- id: rsa
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
- id: manual
manual: on
zone:
- domain: "auto.test."
file: "/etc/knot/master/auto.test.zone"
dnssec-signing: on
dnssec-policy: default
- domain: "manual.test."
file: "/etc/knot/master/manual.test.zone"
dnssec-signing: on
dnssec-policy: manual
I'm not sure about how some things work, perhaps someone can answer my
questions.
When auto signing is used, the ZSKs are rolled automated? And the KSK
rollover is not possible at all? Even not manual?
For manual mode, I followed these steps to generate the keys:
$ keymgr zone key generate manual.test algorithm RSASHA256 size 1024
$ keymgr zone key generate manual.test algorithm ECDSAP256SHA256 size
256
This results in
dig @localhost DNSKEY manual.test +short
256 3 8 AwEAAbGES3TH8jPCIhcdc93dbDNoUkDn5YmviG2/lkCESDcIvzpRFjsC
ATAZEIEo1LosM6cALS8AVkxKK/BSOpuvLHvhX7O+ny7eX5X/C2PHnGs+
WMieIhbjLJWdIsNCMhSqQ7vTlguFmHbUdyzV+8dnrMl1GSpdSc1P0Fyp vjxDM5+H
256 3 13 H+qtCYv9A0RlqQCOtDyGGEMhVgn92wPdZ+WrqRAqb/MJ3RzdDSyhaX2p
B/TU5F8mQccrVIdiJriT+zmWpoW9sA==
I don't understand why there is no DNSKEY with SEP set. Shouldn't it be
there?
Regards,
Volker
Dear Knot Resolver users,
a bugfix release of Knot Resolver 1.2.6 has been released.
We have fixed a nasty bug that caused some names to stop
resolving if there was a packet lost. We apologize for any
inconvenience this might have caused. And thank to all
Turris Omnia users and Stéphane Bortzmeyer who provided
valuable debugging information.
In this release, we have also fixed a handling of AD flag
for NODATA answers not covered due opt-out NSEC3 and several
other small bugs.
The update from 1.2.5 to 1.2.6 is recommended. The update from 1.1.x
to 1.2.x branch is strongly recommended, the 1.1.x branch is no longer
supported.
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.6/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.6.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.6.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/latest/
Cheers,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
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/
--------------------------------------------
Hello,
I set it up as below and forward it to kometch.local of the internal domain which is the stub zone, but when reverse lookup it will be output as block.
kometch@dns02:~$ drill 192.168.122.1 -x
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 43732
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.122.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
blocked. 900 IN SOA blocked. . 0 3600 900 604800 900
;; ADDITIONAL SECTION:
;; Query time: 1 msec
;; SERVER: 192.168.122.223
;; WHEN: Fri Apr 14 22:13:57 2017
;; MSG SIZE rcvd: 86
# kresd.conf
modules = {
'hints > iterate', -- Hints AFTER iterate
'policy > hints', -- Policy AFTER hints
'view < rrcache', -- View BEFORE rrcache
predict = {
window = 30, -- 15 minutes sampling window
period = 24*(60/15) -- track last 6 hours
},
'daf',
'stats'
}
modules.list() -- Check module call order
--stub forward
policy.add(policy.pattern(policy.FORWARD('192.168.122.223@10053', '192.168.122.224@10053'), '\7kometch\5local'))
In this case, how should it be set?
Best regards.
Hello,
For the second time after an upgrade, one of my knot instance did not
restart. (actually, it restarts but does not respond to queries)
I got theses messages in log :
2017-03-27T17:11:16 warning: [durel.eu.] discontinuity in chages history
(2017032310 -> 2017032309), dropping older changesets
2017-03-27T17:11:16 error: [durel.org.] zone event 'load' failed
(invalid parameter)
2017-03-27T17:11:16 error: [durel.eu.] failed to store changes into
journal (invalid parameter)
2017-03-27T17:11:16 error: [durel.eu.] zone event 'load' failed (invalid
parameter)
2017-03-27T17:11:27 warning: [durel.eu.] discontinuity in chages history
(2017032310 -> 2017032309), dropping older changesets
2017-03-27T17:11:27 error: [durel.eu.] failed to store changes into
journal (invalid parameter)
2017-03-27T17:11:27 error: [durel.eu.] zone event 'load' failed (invalid
parameter)
2017-03-27T17:11:27 warning: [durel.org.] discontinuity in chages
history (2017032310 -> 2017032309), dropping older changesets
2017-03-27T17:11:27 error: [durel.org.] failed to store changes into
journal (invalid parameter)
2017-03-27T17:11:27 error: [durel.org.] zone event 'load' failed
(invalid parameter)
removing all files in journal/ directory and restarting it leads to
normal behaviour.
Do you have hints about these error ?
Thanks,
--
Bastien Durel
Hullo,
Thanks for a new version of Knot DNS!
Knot DNS 2.4.3 is now available in the GNU Guix[1] package manager &
operating system. Perhaps this might warrant an entry under
‘Distribution packages’ on https://www.knot-dns.cz/download/?
I also noticed that the ‘Full Knot DNS 2.4.3 changelog’ link at
https://www.knot-dns.cz/2017-04-11-version-243.html still points to the
change log for 2.4.2.
Kind regards,
T G-R (not subscribed to this list)
[1]: https://gnu.org/s/guix
