Re: nsupdate ACL based on a key AND ip-subnet
On Fri, 2008-11-14 at 17:35 -0800, Chris Buxton wrote: Use a firewall (with deep packet inspection) to restrict by subnet. Then use the TSIG key in the allow-update statement. Unfortunately, to my knowledge, that's the only way to do this. Wouldn't using a BIND view to restrict by subnet work instead of a firewall? /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate ACL based on a key AND ip-subnet
Actually, to take this a step further, is there any remote possibility to
combine this with update-policy as well?
I know both questions has been mentioned on the list before with varied
answers but I wanted to raise it again since this was finally figured out.
/Jonathan
On Mon, Nov 17, 2008 at 11:28 AM, Evan Hunt [EMAIL PROTECTED] wrote:
allow-update { !{!10/8;any;}; key update-key; };
Wouldn't this still permit any client on the 10/8 subnet to update the
zones?
It's very confusing syntax, but no.
You're probably thinking in boolean algebra (I did too, when I first
encountered this). If it were boolean algebra, you could redistribute
the negatives: !{!10/8; any;} becomes {!!10/8; !any;} and then
simplifies to {10/8; none;}.
But ACLs aren't boolean, so you can't do that. Each element has three
possible results not two: match and accept, match and reject, or no
match, which means continue processing.
When an ordinary ACL element matches and is negated (for example, the
element is !10/8; and the address is 10.0.0.1) that means match and
reject. But if the match is inside of a *nested* ACL, then it's treated
differently: A negative result means the nested ACL didn't match--and
so you continue processing.
So if you're checking address A against an ACL of one of the following
forms, these will be the results:
{ A;B; } == A is allowed, accept immediately
{ { A; }; B; } == A is allowed, accept immediately
{!A;B; } == A is forbidden, reject immediately
{ !{ A; }; B; } == A is forbidden, reject immediately
{ { !A; }; B; } == A matched but was negated, try element B
{ !{ !A; }; B; } == A matched but was negated, try element B
Those last two lines there are confusingly similar (and, as written,
useless). The difference is what happens if you're checking an address
*other* than A, and something else in the nested ACL matches it.
{ { !A; any; }; B; } == any address other than A is accepted at once,
but A is only accepted if B matches too.
boolean translation: ((not A) or (A and B))
{ !{ !A; any; }; B; } == any address other than A is *rejected* at
once,
but A is accepted as long as B matches too.
boolean translation: (A and B)
Hope that's helpful. (*I* find it hard to keep this syntax straight, and I
wrote a big chunk of the code that implements it in BIND 9.5...)
--
Evan Hunt -- [EMAIL PROTECTED]
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate ACL based on a key AND ip-subnet
Yeah it would most likely be a feature request/change.
IIRC update-policy cannot be used in congestion with the allow-update
statement. Personally I prefer the usage of update-policy as I can assign
different business units within my organization to take responsibility for
certain records/record types.
As I'm using a multi-view server (public and private IP) I'm concerned that
the update keys used might get compromised (computer stolen or whatever)
thus it would be useful to be able to limit the capability for updates for
specified IP-ranges.
This is achieved with the allow-update policy given throughout this
conversation but as you cannot use them in congestion with update-policy I'm
not able to limit certain records/record types to keys.
To put this in a conf example I'm thinking something like:
allow-update {
! { !10/8; any; };
update-policy { grant key subdomain dummy.com ALL; };
};
I hope this makes sense.
/Jonathan
On Mon, Nov 17, 2008 at 4:43 PM, Evan Hunt [EMAIL PROTECTED] wrote:
Actually, to take this a step further, is there any remote possibility to
combine this with update-policy as well?
I'm not sure what you mean.
I believe you can use allow-updates to filter according to IP address
and then update-policy to filter according to key; that might be an
easier way to accomplish the same thing. I've never done so, but I'd
expect it to work. But it sounds like you're asking for a feature
change... clarify please?
--
Evan Hunt -- [EMAIL PROTECTED]
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate ACL based on a key AND ip-subnet
IIRC update-policy cannot be used in congestion with the allow-update statement. My bad--you're right. There's code I'd never noticed before that says allow-update will be ignored if update-policy is set. Whoops. (Oddly, the check only applies when both of them are defined in the zone itself. You can put allow-updates in the view options and update-policy in the zone, and named won't complain about it... but it also won't work the way you want it to.) I don't know why it was implemented this way--there's no protocol reason I can see. (There may be other reasons I don't know about.) It's probably not a high enough priority for ISC to devote engineering resources to it at this time, but if someone submitted a patch that added an ACL check to the update-policy syntax, I'm sure we'd consider it. -- Evan Hunt -- [EMAIL PROTECTED] Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate ACL based on a key AND ip-subnet
Guess I should start digging in the code then :) On Mon, Nov 17, 2008 at 5:59 PM, Evan Hunt [EMAIL PROTECTED] wrote: IIRC update-policy cannot be used in congestion with the allow-update statement. My bad--you're right. There's code I'd never noticed before that says allow-update will be ignored if update-policy is set. Whoops. (Oddly, the check only applies when both of them are defined in the zone itself. You can put allow-updates in the view options and update-policy in the zone, and named won't complain about it... but it also won't work the way you want it to.) I don't know why it was implemented this way--there's no protocol reason I can see. (There may be other reasons I don't know about.) It's probably not a high enough priority for ISC to devote engineering resources to it at this time, but if someone submitted a patch that added an ACL check to the update-policy syntax, I'm sure we'd consider it. -- Evan Hunt -- [EMAIL PROTECTED] Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
