Hi,
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.
Ok, great, in that case everything seems fine.
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)
Ok, fine.
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.
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