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

Marek Vavrusa marek.vavrusa at nic.cz
Mon Aug 5 11:26:32 CEST 2013


On Mon, 5 Aug 2013 10:30:53 +0200
Johan Ihrén <johani at johani.org> wrote:

> Hi Marek,
> 
> On Aug 5, 2013, at 08:01 , Marek Vavruša 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.
> 
> 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.

> 
> But I haven't looked closely enough to know whether this case is part of what you're taking out. Is it?
> 
> > 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.

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)

> 
> 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 at nic.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.nic.cz/pipermail/knot-dns-users/attachments/20130805/11528a75/attachment.pgp>


More information about the knot-dns-users mailing list