2 Zář
2015
2 Zář
'15
18:28
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.cz https://www.nic.cz
2 Zář
2 Zář
19:17
New subject: minimal responses (was: Re: Knot DNS 2.0.1 patch release)
Jan Včelák wrote:
- 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.
Hi,
It looks like this code has just been deleted. I wonder if it could
instead be made into a tunable, defaulted to off? Maybe even with the
conditional wrapped in unlikely().
I can certainly see how apex NS records in the authority section is not
particularly useful for root or TLD servers, but it's occasionally
useful for "leaf" zones to speed up the propagation of updated NS
records, due to the trust ranking rules in RFC 2181 §5.4.1.
I also know of at least one more DNS server (rbldnsd) that has this
behavior as a tunable run-time option.
--
Robert Edmonds
edmonds(a)debian.org
3 Zář
3 Zář
13:53
New subject: minimal responses
Hello Robert,
Robert Edmonds wrote:
Jan Včelák wrote:
yes, the code was deleted.
- 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.
It looks like this code has just been deleted. I wonder if it could
instead be made into a tunable, defaulted to off? Maybe even with the
conditional wrapped in unlikely(). I can certainly see how apex NS records in the
authority section is not
particularly useful for root or TLD servers, but it's occasionally
useful for "leaf" zones to speed up the propagation of updated NS
records, due to the trust ranking rules in RFC 2181 §5.4.1.
I haven't thought about this. This might be indeed useful. On the other
hand, why NS and not any other RR type? I think this is really single
purposed and I'm not convinced (at the moment) that this is worthy of
adding an option.
My DNS operational experience are quite limited in this area. Can anyone
confirm that this use case is really valid?
Best Regards,
Jan
4 Zář
4 Zář
14:49
New subject: minimal responses
Jan Včelák wrote:
Robert Edmonds wrote:
I've created an issue so that we don't forget about it:
https://gitlab.labs.nic.cz/labs/knot/issues/421
Jan
I can certainly see how apex NS records in the
authority section is not
particularly useful for root or TLD servers, but it's occasionally
useful for "leaf" zones to speed up the propagation of updated NS
records, due to the trust ranking rules in RFC 2181 §5.4.1.
I haven't thought about this. This might be indeed useful. On the other
hand, why NS and not any other RR type? I think this is really single
purposed and I'm not convinced (at the moment) that this is worthy of
adding an option. 
14 Zář
14 Zář
8:50
New subject: minimal responses (was: Re: Knot DNS 2.0.1 patch release)
Hey Robert,
"occasionally" useful, yes. As everything it's a compromise.
RFC2181 ranks data based on trust level, but that doesn't reflect the
correctness of the data as I've seen delegations broken in
authoritative data and vice versa.
A resolver has to deal with both cases unfortunately, and evaluates
all possible options before giving up and be wary of what to accept it
cache at the same time.
NS in the authority section is really extra data and shouldn't be
cached, as it gives the attacker a tool to joust valid NSs out of
cache with spoofed ones much more easily.
The real problem is that people want DNS to be decentralised when it
works and centralised when they make a mistake.
This could be solved by providing feed of "purge requests" indexed by
time, so the resolvers could poll it and automatically flush part of
its cache.
It is a glaringly similar problem to RPZ feeds which were adopted
really quickly, so I trust it's tractable.
Do you know about any efforts going in this direction?
Marek
On 2 September 2015 at 19:17, Robert Edmonds <edmonds(a)debian.org> wrote:
Jan Včelák wrote:
- 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.
Hi,
It looks like this code has just been deleted. I wonder if it could
instead be made into a tunable, defaulted to off? Maybe even with the
conditional wrapped in unlikely().
I can certainly see how apex NS records in the authority section is not
particularly useful for root or TLD servers, but it's occasionally
useful for "leaf" zones to speed up the propagation of updated NS
records, due to the trust ranking rules in RFC 2181 §5.4.1.
I also know of at least one more DNS server (rbldnsd) that has this
behavior as a tunable run-time option.
--
Robert Edmonds
edmonds(a)debian.org
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
15 Zář
15 Zář
0:34
New subject: minimal responses (was: Re: Knot DNS 2.0.1 patch release)
Marek Vavruša wrote:
"occasionally" useful, yes. As everything
it's a compromise.
RFC2181 ranks data based on trust level, but that doesn't reflect the
correctness of the data as I've seen delegations broken in
authoritative data and vice versa.
A resolver has to deal with both cases unfortunately, and evaluates
all possible options before giving up and be wary of what to accept it
cache at the same time.
NS in the authority section is really extra data and shouldn't be
cached, as it gives the attacker a tool to joust valid NSs out of
cache with spoofed ones much more easily.
I agree that resolvers could probably do better than to eagerly
overwrite a cached NS RRset with whatever just came in off the wire.
(In the non-DNSSEC case.)
But, given a Knot 2.0.1 style server that only hands out its apex NS
RRset when explicitly asked for qtype NS, that potentially makes things
even easier for an attacker, since the NS RRset being attacked has the
lowest "trustworthiness" level.
I think it would be nice to keep the pre-2.0.1 behavior as an option
(but have the 2.0.1 behavior be the default). But it's not a must-have
option, I don't think. Certainly not for root or TLD service :-)
The real problem is that people want DNS to be
decentralised when it
works and centralised when they make a mistake.
This could be solved by providing feed of "purge requests" indexed by
time, so the resolvers could poll it and automatically flush part of
its cache.
It is a glaringly similar problem to RPZ feeds which were adopted
really quickly, so I trust it's tractable.
Do you know about any efforts going in this direction?
There are generally calls for such a mechanism to exist, usually on the
dns-operations@ list right after a compromise of some high profile
domain :-) I don't know of any active efforts, though.
--
Robert Edmonds
edmonds(a)debian.org
17 Zář
17 Zář
15:51
New subject: minimal responses (was: Re: Knot DNS 2.0.1 patch release)
On Sep 14, 2015, at 6:34 PM, Robert Edmonds
<edmonds(a)debian.org> wrote:
Marek Vavruša wrote:
Every resolver SHOULD be asking for the NS records from the child zone in parallel with he
query that triggered the
discovery of the delegation. We are not living in the pre-Kaminski world anyone, every
piece of information that is used in
resolution SHOULD be of highest credibility.
I support what Knot is doing i.e. only minimal answers, as paranoid resolvers SHOULD only
follow information from outside Answer section for bootstrapping.
Olafur
"occasionally" useful, yes. As
everything it's a compromise.
RFC2181 ranks data based on trust level, but that doesn't reflect the
correctness of the data as I've seen delegations broken in
authoritative data and vice versa.
A resolver has to deal with both cases unfortunately, and evaluates
all possible options before giving up and be wary of what to accept it
cache at the same time.
NS in the authority section is really extra data and shouldn't be
cached, as it gives the attacker a tool to joust valid NSs out of
cache with spoofed ones much more easily.
I agree that resolvers could probably do better than to eagerly
overwrite a cached NS RRset with whatever just came in off the wire.
(In the non-DNSSEC case.)
But, given a Knot 2.0.1 style server that only hands out its apex NS
RRset when explicitly asked for qtype NS, that potentially makes things
even easier for an attacker, since the NS RRset being attacked has the
lowest "trustworthiness" level.
I think it would be nice to keep the pre-2.0.1 behavior as an option
(but have the 2.0.1 behavior be the default). But it's not a must-have
option, I don't think. Certainly not for root or TLD service :-)
The real problem is that people want DNS to be
decentralised when it
works and centralised when they make a mistake.
This could be solved by providing feed of "purge requests" indexed by
time, so the resolvers could poll it and automatically flush part of
its cache.
It is a glaringly similar problem to RPZ feeds which were adopted
really quickly, so I trust it's tractable.
Do you know about any efforts going in this direction?
There are generally calls for such a mechanism to exist, usually on the
dns-operations@ list right after a compromise of some high profile
domain :-) I don't know of any active efforts, though.
3384
days inactive
3399
days old
6 comments
4 participants
participants (4)
-
Jan Včelák -
Marek Vavruša -
Olafur Gudmundsson -
Robert Edmonds