5 Srp
2013
5 Srp
'13
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>