View selection via TSIG

[Mark Andrews]

In message <639AB8F7-0AE1-44F7-828F-F3B87AEF2CA2 at 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: marka at isc.org