[bind10-dev] ACL Syntax proposal

Evan Hunt each at isc.org
Sat May 28 16:00:39 UTC 2011

> Well, not accept is the same as reject, so there's no problem in it.


   - Do not accept anyone from 132.147/16
   - Accept everyone who is not from 132.147/16

... aren't the same thing.  The ambiguity is in where the "not" is
being applied:  "not-accept X", or "accept not-X".

> The ACL either allows user to perform that action or doesn't.

True, but consider a "doughnut hole" ACL:

   reject 132.147.67/24
   accept 132.147/16
   reject everyone

I.e., allow *almost* everyone within 132.147 to perform an action, *except*
for the losers in 132.147.67, *except* for that nice fella on
You can express this in the boolean syntax you've described:

   allow or {and {132.147, not 132.147.67},}

...and it's not too bad (though the "not" ambiguity is already going to
cause problems for a human reader).  But for an organization with many
such doughnut holes and exceptions I'm concerned that the expression
would get cumbersome quickly, grow even more ambiguious, and just
generally be easy to get wrong, and that's before you even throw
TSIG keys into the mix.  (We have support customers with tens
of thousands of lines in their ACLs.)

The BIND 9 ACL expressing the rule above is:

   allow-query {;

...which isn't pretty but you can easily see how to resolve conflicting

All that said, in one sense I *really like* the idea of allowing boolean
expressions, because sometimes you do need to get the concepts of "and" and
"or" into an ACL, and the BIND 9 way is horrible.  Suppose you only want
to allow address A *and* only allow it if it has key K.  In your syntax
this is:

    allow and {ip A, key K}

...which is simple and elegant.  In BIND 9, it's:

    allow-query { !{ !A; any; }; key K; }

...and we can *definitely* do better than that.

Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.

More information about the bind10-dev mailing list