In message <639ab8f7-0ae1-44f7-828f-f3b87aef2...@tcbug.org>, Josh Paetzel write
s:
> On Aug 19, 2009, at 6:30 PM, Mark Andrews wrote:
> >>
> >> Thanks. That worked, and I was quickly able to see what I was doing
> >> wrong. My primary nameserver was matching an IP in one of the
> >> views. So all the notifies were seen by slave as being in that one
> >> view. IPs override keys.
> >
> > Acl matches are order sensitive. The !key is in the examples to
> > prevent
> > the signed message matching the view and moving onto the next one.
>
>
> Ok, that makes even more sense. I was getting what appeared to be
> very non-deterministic behavior, but well, of course, once you know
> the rules it makes a lot of sense.
>
>
> In my case with multiple views and multiple keys..
>
> { subnet A; key A;};
> { subnet B; key B;};
> {subnet C; key C;};
> {subnet D; key D}:
The general and robust solution is:
acl allviewkeys { key A; key B; key C; key D; };
match-clients { key A; !allviewkeys; subnet A; }
match-clients { key B; !allviewkeys; subnet B; }
match-clients { key C; !allviewkeys; subnet C; }
match-clients { key D; !allviewkeys; subnet D; }
This is easily expandable to many views without having to touch
each view when a new view is added. The order of the match-clients
acl is important.
> If the server was in subnet C, and used key A or B it would work fine,
> but just by coincidence. Key C would work too, once again, by
> coincidence...but key D...boom.
>
> Anyways, it's working great now. Thanks to everyone who helped.
>
> Thanks,
>
> Josh Paetzel
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
