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; };


Anand Buddhdev
bind-users mailing list

Reply via email to