Yeah, kinda makes sense, thanks!<br><br>/Jonathan<br><br><div class="gmail_quote">On Mon, Nov 17, 2008 at 11:28 AM, Evan Hunt <span dir="ltr"><<a href="mailto:Evan_Hunt@isc.org">Evan_Hunt@isc.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> >  allow-update { !{!10/8;any;}; key update-key; };<br>
><br>
> Wouldn't this still permit any client on the 10/8 subnet to update the<br>
> zones?<br>
<br>
</div>It's very confusing syntax, but no.<br>
<br>
You're probably thinking in boolean algebra (I did too, when I first<br>
encountered this).  If it were boolean algebra, you could redistribute<br>
the negatives: "!{!10/8; any;}" becomes "{!!10/8; !any;}" and then<br>
simplifies to "{10/8; none;}".<br>
<br>
But ACLs aren't boolean, so you can't do that.  Each element has three<br>
possible results not two: match and accept, match and reject, or "no<br>
match", which means continue processing.<br>
<br>
When an ordinary ACL element matches and is negated (for example, the<br>
element is "!10/8;" and the address is <a href="http://10.0.0.1" target="_blank">10.0.0.1</a>) that means "match and<br>
reject".  But if the match is inside of a *nested* ACL, then it's treated<br>
differently:  A negative result means "the nested ACL didn't match"--and<br>
so you continue processing.<br>
<br>
So if you're checking address A against an ACL of one of the following<br>
forms, these will be the results:<br>
<br>
    {     A;    B; }   == A is allowed, accept immediately<br>
    {  {  A; }; B; }   == A is allowed, accept immediately<br>
    {    !A;    B; }   == A is forbidden, reject immediately<br>
    { !{  A; }; B; }   == A is forbidden, reject immediately<br>
    {  { !A; }; B; }   == A matched but was negated, try element B<br>
    { !{ !A; }; B; }   == A matched but was negated, try element B<br>
<br>
Those last two lines there are confusingly similar (and, as written,<br>
useless).  The difference is what happens if you're checking an address<br>
*other* than A, and something else in the nested ACL matches it.<br>
<br>
    {  { !A; any; }; B; }  == any address other than A is accepted at once,<br>
                              but A is only accepted if B matches too.<br>
                              boolean translation: ((not A) or (A and B))<br>
<br>
    { !{ !A; any; }; B; }  == any address other than A is *rejected* at once,<br>
                              but A is accepted as long as B matches too.<br>
                              boolean translation: (A and B)<br>
<br>
Hope that's helpful.  (*I* find it hard to keep this syntax straight, and I<br>
wrote a big chunk of the code that implements it in BIND 9.5...)<br>
<font color="#888888"><br>
--<br>
Evan Hunt -- <a href="mailto:evan_hunt@isc.org">evan_hunt@isc.org</a><br>
Internet Systems Consortium, Inc.<br>
</font></blockquote></div><br>