1 Srp
2013
1 Srp
'13
15:09
Anand,
thanks for the extensive write up, very informative!
On 1 August 2013 13:14, Anand Buddhdev <anandb(a)ripe.net> wrote:
On 29/07/2013 16:58, Marek Vavruša wrote:
Hi Marek,
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.
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 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
RIPE NCC
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)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.
Marek