On 29/09/2010 12:09, Niall O'Reilly wrote:
> On 29 Sep 2010, at 09:34, Anand Buddhdev wrote:
>
>> Now, I have been given 2 keys, t1 and t2, to use for transferring z1 and
>> z2 respectively.
>
> [Wandering off topic, perhaps]
>
> That seems to me a back-to-front way to do things.
>
> If the organization running the master is concerned to identify
> responsibility for purported slave access, the key needs to be
> provided by the organization responsible for running the slave,
> and accepted (or not) at the master end.
>
> That's what I expect from my slaves.
> None has revolted yet. 8-)
>
> One way or the other, using multiple keys to express what is
> intrinsically a single trust relationship seems to be both likely
> to increase the risk of compromise and certain to add administrative
> burden. Why do it?
Hi Niall,
You're probably right, and it does increase administrative burden.
However, this design isn't my choice, so I'm stuck with it.
Anyway, I discussed this with my colleague here, and we came up with a
solution that works. We have created 2 views of the master name servers:
masters m-key1 {ip1 key key1; ... };
masters m-key2 {ip1 key key2; ... };
zone z1 {
masters { m-key1; };
...
};
zone z2 {
masters { m-key2; };
...
};
Regards,
Anand Buddhdev
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
