Hello list,
CZ.NIC Labs just released Knot DNS 1.6.3. This patch release contains a few
rather serious bug fixes and some minor improvements. Update is highly
recommended.
When performing our internal benchmarking, we discovered a serious performance
drop for large NSEC-signed zones (not NSEC3). In construction of NSEC proofs
for NXDOMAIN responses, the server got into a loop possibly causing iteration
over all domain names in the zone. The problem was present in Knot DNS since
the beginning of the project. We are sorry for not noticing this earlier.
The new version also handles TCP short-writes properly. Prior to this fix,
sending a response over TCP could fail if the socket send buffer was small
(e.g., in default configuration on FreeBSD). In addition, if the buffers are
too small, we increase their size on server initialization to make fast-path
processing more likely.
We also fixed possible out-of-bound memory accesses revealed by American Fuzzy
Lop fuzzer. One such an access was in the zone parser (long domain names in
zone origin) and two in the packet parser (TSIG with empty RDATA and malformed
NAPTR).
As for the improvements: The zone parser now supports CDS and CDNSKEY RR
types, the documentation now includes default values for TCP config options,
and more detailed message is emitted when a zone reload fails.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.3/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz.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
Hello everyone!
Today, CZ.NIC Labs releases Knot DNS 2.0.0-beta.
We finally managed to complete, stabilize, and document all new features of
the upcoming Knot DNS version. We are aware of some glitches in this release,
however we think that it is ready to be tested by a wider audience.
There are two key features of Knot DNS 2.0:
# New DNSSEC implementation
I wrote quite a lot about the new DNSSEC in the 1.99.1 release announcement.
Since then, only a few things changed. There was a bug in the ZSK rotation
algorithm. The old DNSKEY was removed too soon possibly breaking the
validation. This problem is resolved now. The keymgr utility has a new manual
page. And the documentation was updated to reflect all changes.
# New configuration format
This change is quite significant for the future development of Knot DNS. And
it will affect everyone using the software.
We decided to switch from a custom configuration format to YAML. Internally,
the configuration is stored in a binary database (LMDB). At the moment, you
won't probably notice anything about the database. However we are working on a
new interface, which will allow making changes into the configuration without
a full server reload. If you have Knot DNS with thousands of zones, you will
benefit this for sure.
We don't support full YAML specification, but there is a certain level of
compatibility. We plan to extend the support so you can generate the config
from your favorite scripting language.
Some configuration options (and configuration sections) were renamed.
We changed the concept how the incoming and outgoing connections are
configured. We split 'remotes' to 'remote' and 'acl'. 'remote' defines target
for outgoing connection (zone transfer source, notification target). And 'acl'
defines rules for accepting connections initiated by a remote client (outgoing
transfer, incoming notification, and incoming update).
At the moment, only one address can be specified for each 'remote' or 'acl'.
In addition, we removed 'groups' as it was complicating the implementation. We
are aware that the current state is not ideal. And we are looking for feedback
and suggestions from the community.
We are not just removing and changing things - we added support for zone
templates, which is something a lot of our users asked for. A template allows
you to configure options shared among multiple zones. A change in the template
affects all zones, which use the template.
To convert the configuration from the 1.6 to the 2.0 format, the knot1to2 tool
is provided. The tool doesn't support conversion for answering modules (e.g.
synth_record), but should handle anything else. Please, review the
configuration after performing the automatic conversion.
That's all, folks! Please, give it a try. Experiment with the new DNSSEC and
play around with the new configuration. And most importantly, let us know what
do you think.
Thank you for using Knot DNS!
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz.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
I'm generating my Knot's config from a Jinja2 template, and I'm having a
problem with one thing. For example, if I have a list of elements,
[e1,e2,e3,e4], and I want to generate a "groups" config for these based
on a condition, and I do:
groups {
mygroup {
{% for x in list %}
{% if condition %}
{{ x }},
{% endif %}
{% endfor %}
}
However, this results in a syntax error, because the last element ends
with a comma, and then there's a closing bracket.
I tried to insert the comma conditionally, by checking to see if it was
the last element, but this can also fail if the last element didn't
match the condition.
So I thought about this ugly hack:
groups {
mygroup {
{% for x in list %}
{% if condition %}
,{{ x }}
{% endif %}
{% endfor %}
}
Notice that I have the comma *before* each element. This results in an
opening brace, a comma, and then the other elements. My supposition is
that Knot's syntax parser is okay with this, because it just sees a null
first element. If I check this with knotc's "checkconf", it says the
syntax is okay.
Can I safely use such a config?
Regards,
Anand
Dear Knot developers,
In Knot 1.6.3, is it safe to leave out the "interfaces" section of the
config on a multi-homed server? Will Knot enumerate all the addresses on
the host and bind to them, or will it bind to 0.0.0.0 and ::?
Secondly, if bound to 0.0.0.0 and ::, will Knot use recvmmsg correctly
and set the source address in UDP reply packets to the address the query
was sent to?
Regards,
Anand
