[knot-dns-users] Knot DNS 1.3.0-rc5

Marek Vavruša marek.vavrusa at nic.cz
Thu Aug 1 15:09:09 CEST 2013


thanks for the extensive write up, very informative!

On 1 August 2013 13:14, Anand Buddhdev <anandb at ripe.net> wrote:
> On 29/07/2013 16:58, Marek Vavruša wrote:
> Hi Marek,
>> 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:
> https://lists.dns-oarc.net/pipermail/dns-operations/2013-July/010438.html
> 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 see, well we've been thinking about this. But the cost of keeping
out-of-zone records
in place for transfers is just too high, as it would need to bypass
various checks.
Besides, I think it conforms to the standard listed in the thread as
we "identify and handle occluded names"
and also include occluded names in the AXFR response. Except, we don't
but since we don't accept
such names into a zonefile in the first place, it is irrelevant to
consider whether we would include them
or not in the AXFR response. And I believe discarding them falls into
the "identify and handle" category.

> 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
> number.
> 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.

I see the point, but I also see a few good cases where it's a good idea to fake
the server version/id. Nevertheless, we could accept two (3 for NSID)
different types:
* boolean on|off - on would fill a default string, off would turn it
off (just a convenience)
* text "something" - arbitrary string, just like now, even empty text
* hexstring - just for the NSID

This would make it convenient to serve both automatic or arbitrary data.
Does this sound okay?

> 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.
> Regards,
> Anand Buddhdev
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users at lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

I agree, as noted in the previous paragraph.
Anand, yet again many thanks for the valuable input and ideas.


More information about the knot-dns-users mailing list