You're absolutely right, I did have to set the view where the slave match the IP address as the last view in my config. I just didn't want to have a large list of "negatives" in each of my views definition, but you seem to have set a smarter way to do that in your example... Like Niall said before, learning is a two-way process...
2012/7/9 Mark Andrews <[email protected]> > > In message <[email protected]>, Niall O'Reilly > writes > : > > > > On 3 Jul 2012, at 21:21, Rodrigo Renie Braga wrote: > > > > > Just giving a feedback, this method worked great, but in my case, > didn't ha > > ve no negate the keys in the ACL (like the example below), I created one > key > > for each ACL in my configuration and used that ACL for the > "match-clients" di > > rective in the view. > > > > Congratulations! > > You seem to have thought of a better (i.e. simpler) way to do it > > than I did. Learning is a two-way process. > > > > ATB > > Niall > > Running w/o negate keys in the match-clients acl is fragile and > depends on the address of the master/slaves being in the last view > whereas the scheme below works independently of which view the > master/slave ip addresses match. > > key key1 { ... }; > key key2 { ... }; > key key3 { ... }; > acl all-keys { key key1; key key2; key key3; } > view view1 { match-clients { key key1; !all-keys; ... }; ... }; > view view2 { match-clients { key key2; !all-keys; ... }; ... }; > view view3 { match-clients { key key3; !all-keys; ... }; ... }; > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
