[knot-dns-users] Knot DNS 1.3.0-rc5
anandb at ripe.net
Thu Aug 1 13:14:21 CEST 2013
On 29/07/2013 16:58, Marek Vavruša wrote:
> as the 1.3.0 final release is coming out next monday, we would like
> you to check if everything works for you.
> There are three major fixed bugs - interrupts during AXFR bootstrap,
> which is now miles faster
> for a large number of zones. Also support for obsolete record types in
> zone transfers.
> And finally, out of zone records are now discarded during zone
> transfer, but the transfer as a whole is accepted.
Thanks for all these fixes. This last fix works for me, but I see a
difference in behaviour between Knot and BIND. I don't have an opinion
either way, and in fact I asked about it on the dns-operations list for
more general opinion from DNS experts. Here's the thread for reference:
Essentially, BIND preserves the zone, including out-of-zone records. It
won't serve them, but it will pass them along in an AXFR. Knot strips
out-of-zone records during the AXFR, so when providing an AXFR out to a
client, Knot will provide it an altered copy of the zone. I'm not too
bothered by this, because the out-of-zone records shouldn't have been
there to start with, but it is an implementation difference, and the
AXFR RFC isn't clear about it.
I have other comments, and they are about the values of the settings
"identity", "version", "hostname" and "nsid". By default they are off,
and that is okay. The operator can enable them if he wishes. However,
letting them all be strings isn't the best choice, in my opinion. For
example, if I set "version" to "1.2.0" and then later upgrade to 1.3.0,
and forget to change this setting, it will report the incorrect version
In my opinion, "version" should just be a boolean, defaulting to "no".
If set to "yes", it will report the current version number.
Additionally, if Knot could respond with "Knot 1.3.0" instead of just
"1.3.0" it would be better, and this would make the "identity" option
unnecessary. However, if you must maintain "identity", then it should
also be a boolean, so that when set to "yes" it reports "Knot".
Next up, the hostname. It makes sense for this to be a string, so the
operator can choose what to report. But there should be some way of
setting it to some magic value, so that it just defaults to the FQDN of
the host. How about the following: if not set, the response is REFUSED.
If set but empty, then return the FQDN of the host. If set, and not
empty, then return that string verbatim.
Finally, NSID. Again this is fine as a quoted string or hex string. It
is meant to be arbitrary. However, if there were a way to set it to some
magic value, which could mean "return the FQDN of the host" it would be
great, since this tends to be the most common use for these options. So
again, if not set, then NSID is not returned. If set to a string, but
empty, return the hex-encoded hostname. If set and not empty, then
return it verbatim.
More information about the knot-dns-users