using acls in also-notify doesn't work -- alternative?

[Barry Margolin]

In article <cmgjns$8d1$1 at sf1.isc.org>, Phil Dibowitz <phil at usc.edu> 
wrote:

> On Fri, Nov 05, 2004 at 08:10:05AM -0500, Barry Margolin wrote:
> > 
> > What if the ACL contained 1.2.3.0/24?  That's a wildcard that matches 
> > all 1.2.3.x addresses.  The server can easily match incoming addresses 
> > against that, but it's not as sensible to send notifications to all 
> > those addresses.
> So because the user can make a mistake you don't allow it?

No, it's disallowed because it's conceptually wrong.  An ACL is an 
Access Control List, not an Address List, so it's only appropriate to 
use it in places where it's used as a filter.  In some special cases it 
may contain a list of specific addresses, but that's not the general 
expectation, and it's not intended to be used for such purposes.

> 
> It would make sense to have an ACL with a network, but it also makes sense to
> have one with just a set of IPs.
> 
> It makes sense to use the former for an allow-query line, and it makes sense
> to use the later for an also-notify line.

The right solution is for BIND to provide named address lists, to be 
used in places like also-notify and masters.  Since address lists are a 
subtype of access control lists, it would be reasonable to allow them to 
be used where ACLs are expected, but not the other way around.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***