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

Johan Ihrén johani at johani.org
Mon Aug 5 13:28:01 CEST 2013


>> foo.child.parent. A
>> 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; port 53; key updater.key; }
>> }
> I think you need "" 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, "" works while "" 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?



More information about the knot-dns-users mailing list