Hi Everyone,
I think the time is ripe for a small status update, preview of things
to come and a new patch release. Sounds good? So, at the moment, our
team at the CZ.NIC Labs is working towards the next major thing, but
I'd like to reiterate that we didn't forget about the 1.4 and as of
today we have a new release with several important backported
bugfixes, here's the brief version:
* Two bugs related to authenticated denial of existence proof with a
certain combination of wildcard expansions triggering an assertion
failure
* Comparison of $ORIGIN and zone file in configuration is case insensitive
* Corrupted journal data caused a cleanup failure during the zone loading
In addition to the bugfixes, we have also slipped in a small
enhancement - "include" statement in the configuration can include
whole directory, this is useful if you have really a lot of includes
in one place.
Now a brief status update on what are we working on and what can you
expect in the next few weeks/months. The next major release is going
to happen later this spring and it's going to be focused on three
things mostly - covering the code by tests, cleaning up and polishing
existing features. There's going to be a feature or two, but that is
not the main focus. The reason is the functionality we have piled up
over the time has taken it's toll and now is the right time to sit
back and make the features leaner and meaner (that includes usability
as well), as that was always an integral idea behind Knot DNS. Plus
less things means less things to break, right?
I'd like to thank namely Petr Stastny and Olafur Gudmundsson (among
others) for bugreports, ideas and thoughts.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.3/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz.asc
Kind Regards,
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hi Knot developers,
I have a feature request: I'd like a knotc command that will force Knot
to transfer a zone that is configured as a slave. The only command I can
issue at the moment is "refresh", but this will not transfer a zone if
Knot has a higher serial than the master.
Such a forced transfer command is useful to help recover from situations
where due to some operational error on the master server, the serial
number has gone back, and we deliberately need our Knot server to sync
to that old serial number. Without this command, the only way to make
Knot recover is to stop it, delete the zone file from disk and start it
again. But this is not ideal on a running server with lots of zones,
because the stop and start times can be quite high (in our case, 37s to
stop, and 1m30s to start).
Both BIND and NSD provide such commands to ignore the serial number
check and force zone transfers. I'd love to see such a command for Knot too.
Regards,
Anand
I started to play with the dnssec signing features in Knot.
I had this in my .conf file
B-100.tld { file "B-100.zone"; …. }
In the B-100.zone file I had
$ORIGIN B-100.tld.
I get
Jan 31 16:27:32 bigredone knot[31315]: [error] Zone 'B-100.tld.': mismatching origin in the zone file.
Jan 31 16:27:32 bigredone knot[31315]: [error] Failed to load zone 'B-100.tld.'.
When I changed to
$ORIGIN b-100.tld.
Same error
When I changed the conf line for B-100 to b-100
zone got loaded,
I when I changed Origin to upper case but kept the lower case in conf file then zone was loaded.
Summary: conf file requires zone name to be lower case, origin can be either case.
(not documented)
I do not think this what users expect.
Either respect the case that users present or downcase both zone name and name on $ORIGIN line
Also I would be great to have knot-checkzone command that one can use to verify the syntax of zone
with output to standard output.
Olafur
Hello,
I'm using Knot DNSSEC automatic signing and all is well and working.
How would one go about obtaining proper DS records for registrar glue
with least amount of trouble?
Thanks for Knot DNS, by far the most pleasant experience in comparison
with all other DNS servers. I've had zero issues with it, flawless
operation from the start!
Hello List!
We really appreciate your feedback on the previous release - both positive and
negative. Thank you for that, it motivates us to make Knot DNS even better.
Today, CZ.NIC Labs proudly announce the Knot DNS 1.4.2.
There are quite a lot of changes:
* The new release includes a compatibility fix for the AXFR/IXFR issues, which
occurred when accepting transfers from tinydns/axfrdns.
* In some cases, a TSIG did not fit into the outgoing transfer causing the
transfer to be terminated. This problem was addressed as well.
* Also, journal files are newly created only when necessary. It means
that some disk space is spared when IXFR, DDNS, and DNSSEC signing are
disabled. Feel free to delete the existing journal files if the zones fits
into this category.
* In addition, problems with incorrect logging categories regarding zones were
reported. The logging was reviewed and should be appropriate with the new
release.
* We also fixed several problems in DNSSEC. Firstly, the 'knotc signzone'
command was broken and caused a deadlock of the main server thread. It does
not happen with the new version.
Secondly, prior to this release, the signatures were refreshed two hours
before their expiration, which was found to be extremely insufficient. With
the new release, signatures are refreshed one tenth of the signature
lifetime before their expiration. With the default configuration, the
signature lifetime is 30 days, which implies that the signatures are
refreshed three days before the expiration.
* Moreover, RRSIGs in the additional records not-fitting into the DNS message
do not cause packet truncation, but are simply skipped.
We are looking forward to your reactions and comments.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.2/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz.asc
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hello.
I configured "max-udp-payload 1464" and noticed that Knot 1.4 sets tc if
it can't fit RRSIGs for records in the additional section while 1.3.4
didn't.
I was wondering what the reasoning is behind this behaviour. Shouldn't
validating resolvers ignore unsigned record sets in the additional
section anyway?
In my tests, Knot 1.4 almost always sets tc unless it can fit all
DNSKEYs, nameserver addresses and their signatures in the additional
section. That seems a bit excessive. There are only a few narrow buffer
sizes ranges that don't result in a truncated response, depending on the
reply content:
> $ l=""; i=1800; j=$i; while [ "$i" -lt "4097" ]; do n="`dig +bufsize=$i +ignore +norec +dnssec openchaos.org soa @nsig17.openchaos.org |grep ";; flags:"`"; [ "$l" != "$n" ] && { echo "$j - $(($i-1)): $l"; l=$n; j=$i; }; i=$(($i+1)); done; echo "$j - $(($i-1)): $n"
> 1883 - 1898: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 4
> 2102 - 2129: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 6
> 2333 - 2348: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8
> 2552 - 2567: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 10
> 2771 - 2798: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 12
> 3002 - 3017: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14
> 3221 - 3236: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 16
> 3440 - 3455: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 18
> 3659 - 3686: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 20
> 3890 - 4096: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 22
FWIW, the attached patch works for me. It should remove the last
additional record if its RRSIG doesn't fit.
Hauke
Hi,
the majority of warning messages does not contain particular domain name
(zone name), so it is impossible to figure which zone file is wrong.
For example:
> 2014-01-23T20:13:07 [warning] encountered identical extra SOA record
> 2014-01-23T20:13:07 [warning] encountered identical extra SOA record
> 2014-01-23T20:13:07 [warning] TTL does not match TTL of its
> RRSet.Changing to 19200
Can you please add zone names into all error and warning messages
related to one zone?
Thanks
Petr Šťastný
Hello,
I want to use Knot for master zones only without any DNS updates, so
journal files are not needed. But they are created for every zone and it
seems impossible to disable them.
But this is bad in my situation when I want to serve 200000+ zones,
because it creates 200000+ journal files in one directory (but they are
never used).
Should be possible to disable journal files or create them only in case
of need or at lease divide them into more subdirectories?
It would be also nice to be able to choose another directory for journal
files in configuration. "storage" option is for both (zone files and
journal files). Or explicitly state journal file path and filename in
"zone" section.
Thanks
Petr Šťastný
Hoj vespolek.
trosku jsem se uz ztratil s dnssecem s knotem. Vygeneroval jsem si
klice, rekl knotu, kde ma klice hledat, knot je podepsal, zadna
stiznost od nej. Klic jsem zadal i do keysetu na web4u, to proslo
taky. Ale pokud si udelam drill my zony, drill oznami, ze mi chybi DS
zaznam nebo trusted key:
drill -TD ajetaci.cz
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: . 172800 IN DNSKEY 256 3 8
AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED ;{id = 33655 (zsk), size =
1024b}
[S] cz. 86400 IN DS 54576 10 2
397e50c85ede9cde33f363a9e66fd1b216d788f8dd438a57a423a386869c8f06
;; Domain: cz.
;; Signature ok but no chain to a trusted key or ds record
[S] cz. 18000 IN DNSKEY 256 3 10 ;{id = 40877 (zsk), size = 1024b}
cz. 18000 IN DNSKEY 257 3 10 ;{id = 54576 (ksk), size = 2048b}
cz. 18000 IN DNSKEY 256 3 10 ;{id = 54602 (zsk), size = 1024b}
[S] Existence denied: ajetaci.cz. DS
;; No ds record for delegation
;; Domain: ajetaci.cz.
;; Signature ok but no chain to a trusted key or ds record
[S] ajetaci.cz. 3600 IN DNSKEY 257 3 5 ;{id = 36256 (ksk), size = 2048b}
ajetaci.cz. 3600 IN DNSKEY 256 3 5 ;{id = 11937 (zsk), size = 1024b}
[S] ajetaci.cz. 3600 IN A 77.48.63.10
;;[S] self sig OK; [B] bogus; [T] trusted
--
Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a
DomainKeys/DKIM (with ADSP) . 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 check. If you've problem with sending emails to me, start
using email origin methods mentioned above. Thank you.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hi,
I think there is something wrong with logging categories.
Documentation says:
> server - Messages related to general operation of the server.
> zone - Messages related to zones, zone parsing and loading.
I use Knot 1.4.1 with the following configuration:
> log {
> file "/var/log/knot/knot-server.log" {
> server error, warning, notice, info;
> }
>
> file "/var/log/knot/knot-zone.log" {
> zone error, warning, notice, info;
> }
>
> stderr {
> any error, warning;
> }
> }
Everything is logged only into knot-server.log and knot-zone.log is
always empty.
knot-server.log file contains:
> 2014-01-20T21:45:12 Knot DNS 1.4.1 starting.
> 2014-01-20T21:45:12 Rate limiting set to 20 responses/sec.
> 2014-01-20T21:45:12 Binding to interface 0.0.0.0 port 53.
> 2014-01-20T21:45:12 Binding to interface :: port 53.
> 2014-01-20T21:45:12 Configured 2 interfaces and 1 zones.
> 2014-01-20T21:45:12 Changing group id to '1001'.
> 2014-01-20T21:45:12 Changing user id to '1001'.
> 2014-01-20T21:45:12 Server started as a daemon, PID = 25371
> 2014-01-20T21:45:12 PID stored in
> '/usr/local/knot/1.4.1/var/run/knot/knot.pid'
> 2014-01-20T21:45:12 Server changed directory to /.
> 2014-01-20T21:45:12 Zone 'xxxx.eu.' loaded (serial 2013042301)
> 2014-01-20T21:45:12 Loaded 1 out of 1 zones.
> 2014-01-20T21:45:12 Starting server...
> 2014-01-20T21:45:12 Binding remote control interface to
> /usr/local/knot/1.4.1/var/run/knot/knot.sock
> 2014-01-20T21:45:25 Reloading configuration...
> 2014-01-20T21:45:25 Zone 'xxx.eu.' is up-to-date (serial 2013042301)
> 2014-01-20T21:45:25 Loaded 1 out of 1 zones.
> 2014-01-20T21:45:25 Configuration reloaded.
And the question is: why are messages related to zone loading logged in
"server" category and not in "zone" category (which is said in
documentation)?
Thanks
Petr Šťastný
