29 Čec
2013
29 Čec
'13
16:58
Hi,
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.
There is a new known issue, in which slave zone transfer fails to
reschedule. We haven't been able to reproduce that,
so if you experience this, please let us know.
You can find the full changelog at:
https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc5/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz.asc
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2.asc
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz.asc
Packages available at www.knot-dns.cz will be updated soon as well.
Cheers,
Marek
--
Marek Vavruša Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.cz http://www.nic.cz
1 Srp
1 Srp
13:14
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 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.
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
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
15:33
On 01/08/2013 15:09, 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.
I'm happy with this response. As I said, out-of-zone names shouldn't be
there in the first place, and I can't think of any negative side effects
of discarding them.
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?
If you can make Knot parse the options as either boolean or strings,
that would be great. Then we can have on|off for sane defaults, or
string values for wacky people who want to misreport versions and
identities for any reason :)
You're a star! Thanks!
Regards,
Anand
3 Srp
3 Srp
17:24
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'm happy with this response. As I said, out-of-zone names shouldn't be
there in the first place, and I can't think of any negative side effects
of discarding them. 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?
If you can make Knot parse the options as either boolean or strings,
that would be great. Then we can have on|off for sane defaults, or
string values for wacky people who want to misreport versions and
identities for any reason :)
5 Srp
5 Srp
8:01
Hi Johan,
On 3 August 2013 17:24, Johan Ihrén <johani(a)johani.org> wrote:
What about NSEC/NSEC3 chains?
Yes, it was said that it could disconnect an NSEC3 chain. That being
said, no sane signer
would allow this and there could even be a question of ordering.
There are about a zero reasons to have something like 'something.' in
a 'something.else.' zone.
There are cases where having your own version is more than reasonable. Apart from the
minimum disclosure case (that would be covered by an "off" switch) it may be
that we have our own modifications to the stock releases. Sure, if we're hacking the
source we can of course hack the part that specifies the version string...but we all
forget about such maintenance while we're chasing the real problem, so being able to
just tweak the config to indicate that this is not stock knot-1.3.0 but rather my own
derivative version would be helpful.
Johan
Yup, we kept the whole hexstring/string configuration, so you can
still set it to any arbitrary string
as before. But as an addition, you are also able to set it to boolean
on and it will fill the value automagically.
Here's some extra information https://gitlab.labs.nic.cz/knot/issues/113
Best,
Marek
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'm happy with this response. As I said, out-of-zone names shouldn't be
there in the first place, and I can't think of any negative side effects
of discarding them. 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?
If you can make Knot parse the options as either boolean or strings,
that would be great. Then we can have on|off for sane defaults, or
string values for wacky people who want to misreport versions and
identities for any reason :)
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
10:30
Hi Marek,
On Aug 5, 2013, at 08:01 , Marek Vavruša wrote:
I agree with that logic. However, the interesting case is not that one, but rather having
foo.child.parent. A 1.2.3.4
child.parent. NS whatever.
in the zone "parent.". I.e. the first record will never be seen in response to a
query (because it will be shadowed by the referral to the child.parent nameservers). But
it IS part of the zone, will be seen in a zone transfer and is not out of bailiwick. And
AFAIK it will be part of the NSEC/NSEC3 chain.
But I haven't looked closely enough to know whether this case is part of what
you're taking out. Is it?
What about
NSEC/NSEC3 chains?
Yes, it was said that it could disconnect an NSEC3 chain. That being
said, no sane signer
would allow this and there could even be a question of ordering.
There are about a zero reasons to have something like 'something.' in
a 'something.else.' zone. Yup, we kept the whole hexstring/string configuration,
so you can
still set it to any arbitrary string
as before. But as an addition, you are also able to set it to boolean
on and it will fill the value automagically.
WFM.
A couple of other things that I'm struggling with at the moment (I'm on 1.3.0-rc4
at the moment):
1. If I turn on rate limiting with something like
rate-limit 5;
and reload then rate limiting kicks in, and all is good. However, when I try to later turn
rate limiting OFF, by
rate-limit 0; # 0 is supposed to indicate "unlimited", i.e. off
and again reload then the effect is to make it even more aggressive (i.e. qps drops even
further, although I haven't looked carefully at exactly how low). Only way I manage to
turn rate limiting off is by a full restart, which is not what I want.
2. I'm trying to figure out how to configure dynamic updates and I cannot find any
mechanism for configuring the update policy (in BIND9 terms, i.e. assuming an update is
signed with the key X, what is it allowed to update?). This is what I do:
keys {
updater.key hmac-sha256 "secret";
}
remotes {
...
my-updater { address 0.0.0.0; port 53; key updater.key; }
}
zones {
the.zone { file "/tmp/the.zone"; update-in my-updater; }
}
So I expected this to enable me to authenticate dynamic updates by signing them with the
key "updater.key" but I haven't progressed further than "NOTAUTH"
(i.e. I have not yet managed to get any updates accepted).
What am I missing?
Johan
11:26
On Mon, 5 Aug 2013 10:30:53 +0200
Johan Ihrén <johani(a)johani.org> wrote:
Hi Marek,
On Aug 5, 2013, at 08:01 , Marek Vavruša wrote:
I agree with that logic. However, the interesting case is not that one, but rather having
foo.child.parent. A 1.2.3.4
child.parent. NS whatever.
in the zone "parent.". I.e. the first record will never be seen in response to
a query (because it will be shadowed by the referral to the child.parent nameservers). But
it IS part of the zone, will be seen in a zone transfer and is not out of bailiwick. And
AFAIK it will be part of the NSEC/NSEC3 chain.
Right, well this record is technically part of the zone
so it isn't affected and processed by AXFR happily.
What
about NSEC/NSEC3 chains?
Yes, it was said that it could disconnect an NSEC3 chain. That being
said, no sane signer
would allow this and there could even be a question of ordering.
There are about a zero reasons to have something like 'something.' in
a 'something.else.' zone.
But I haven't looked closely enough to know whether this case is part of what
you're taking out. Is it?
This should work as you describe it, but there was a bug
that prevented you from disabling it completely.
To circumvent it, set it to very high value or wait for
the today's 1.3 where I fixed this.
So to disable it, there are two ways:
#rate-limit 5; (comment out or remove the statement)
rate-limit 0; (zero is special)
Yup, we kept the whole hexstring/string
configuration, so you can
still set it to any arbitrary string
as before. But as an addition, you are also able to set it to boolean
on and it will fill the value automagically.
WFM.
A couple of other things that I'm struggling with at the moment (I'm on 1.3.0-rc4
at the moment):
1. If I turn on rate limiting with something like
rate-limit 5;
and reload then rate limiting kicks in, and all is good. However, when I try to later
turn rate limiting OFF, by
rate-limit 0; # 0 is supposed to indicate "unlimited", i.e. off
and again reload then the effect is to make it even more aggressive (i.e. qps drops even
further, although I haven't looked carefully at exactly how low). Only way I manage to
turn rate limiting off is by a full restart, which is not what I want.
2. I'm trying to figure out how to configure dynamic updates and I cannot find any
mechanism for configuring the update policy (in BIND9 terms, i.e. assuming an update is
signed with the key X, what is it allowed to update?). This is what I do:
keys {
updater.key hmac-sha256 "secret";
}
remotes {
...
my-updater { address 0.0.0.0; port 53; key updater.key; }
}
I think you need "0.0.0.0/0" for any address.
Also port is unneccesary as the updater will be connecting from random port probably, but
this is
ommited in ACLs.
zones {
the.zone { file "/tmp/the.zone"; update-in my-updater; }
}
So I expected this to enable me to authenticate dynamic updates by signing them with the
key "updater.key" but I haven't progressed further than "NOTAUTH"
(i.e. I have not yet managed to get any updates accepted).
What am I missing?
Johan
Cheers,
Marek
--
Marek Vavrusa <marek.vavrusa(a)nic.cz>
13:28
Hi,
Ok, great, in that case everything seems fine.
Ok, fine.
You're right, "0.0.0.0/0" works while "0.0.0.0" doesn't. I
should have thought of that myself. Thanks.
It would perhaps be nice, though, with *something* in the logs when the update is
rejected. As it was I could see the "NOTAUTH" in the response on the client
sending the update, but nothing on the actual nameserver (except for looking at the update
packet on the wire with tcpdump).
So now I manage to get the update accepted and applied to the zone, which is a great
start. But it is clearly a rather large hammer in the sense that any key can be used to
make any change, i.e. this isn't much of a "policy" but rather a binary
on/off thing.
Do you have any plans or thoughts on how to design more granular update policies?
Regards,
Johan
foo.child.parent. A 1.2.3.4
child.parent. NS whatever.
in the zone "parent.". I.e. the first record will never be seen in response to
a query (because it will be shadowed by the referral to the child.parent nameservers). But
it IS part of the zone, will be seen in a zone transfer and is not out of bailiwick. And
AFAIK it will be part of the NSEC/NSEC3 chain.
Right, well this record is technically part of the zone
so it isn't affected and processed by AXFR happily. 1. If I turn
on rate limiting with something like
rate-limit 5;
and reload then rate limiting kicks in, and all is good. However, when I try to later
turn rate limiting OFF, by
rate-limit 0; # 0 is supposed to indicate "unlimited", i.e. off
and again reload then the effect is to make it even more aggressive (i.e. qps drops even
further, although I haven't looked carefully at exactly how low). Only way I manage to
turn rate limiting off is by a full restart, which is not what I want.
This should work as you describe it, but there was a bug
that prevented you from disabling it completely.
To circumvent it, set it to very high value or wait for
the today's 1.3 where I fixed this.
So to disable it, there are two ways:
#rate-limit 5; (comment out or remove the statement)
rate-limit 0; (zero is special) remotes {
...
my-updater { address 0.0.0.0; port 53; key updater.key; }
}
I think you need "0.0.0.0/0" for any address.
Also port is unneccesary as the updater will be connecting from random port probably, but
this is ommited in ACLs.
3926
days inactive
3933
days old
8 comments
3 participants
participants (3)
-
Anand Buddhdev -
Johan Ihrén -
Marek Vavruša