Did anyone try restricting nsupdate by using tcp-wrappers? I heard
that we can restrict nsupdate using tcp-wrapper
Anyone tried this?
cheers
Maani
On Nov 17, 9:06 pm, "Jonathan Petersson"
wrote:
> --===7939338197629145746==
> Content-Type: multipart/alternative;
> boundary="
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
> 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 itsel
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 t
> 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
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
Yeah, kinda makes sense, thanks!
/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
> > 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 c
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
On Nov 16, 2008, at 5:22 PM, Jonathan Petersson 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?
No. It says:
1. Deny anyone who isn't in 10/8.
2. Allow anyone using this key.
The first item in the list
On Sun, Nov 16, 2008 at 1:28 PM, Chris Thompson <[EMAIL PROTECTED]> wrote:
> On Nov 14 2008, blrmaani wrote:
>
> I use BIND 9.2 on Linux.
>>
>
> Horribly old. But I doubt whether anything has changed in the ACL logic
> since then.
>
> I was experimenting with a feature
On Nov 14 2008, blrmaani wrote:
I use BIND 9.2 on Linux.
Horribly old. But I doubt whether anything has changed in the ACL logic
since then.
I was experimenting with a feature to allow
dynamic updates based on
BOTH the following:
1. Secret key ( TSIG )
2. Subnet.
acl address_allow { 10/8; };
acl address_reject { !address_allow; any; };
allow-update { !reject; key ""; };
In message <[EMAIL PROTECTED]>, Chris Buxton
writes:
> On Nov 14, 2008, at 12:40 PM, blrmaani wrote:
> > All,
> > I use BIND 9.2 on Linux. I was expe
On Nov 14 2008, blrmaani wrote:
I use BIND 9.2 on Linux.
Horribly old. But I doubt whether anything has changed in the ACL logic
since then.
I was experimenting with a feature to allow
dynamic updates based on
BOTH the following:
1. Secret key ( TSIG )
2. Subnet.
On Nov 14, 2008, at 12:40 PM, blrmaani wrote:
All,
I use BIND 9.2 on Linux. I was experimenting with a feature to allow
dynamic updates based on
BOTH the following:
1. Secret key ( TSIG )
2. Subnet.
Unfortunately, I realized that we can specify only one of the above in
allow-update {} ACL.
If I
All,
I use BIND 9.2 on Linux. I was experimenting with a feature to allow
dynamic updates based on
BOTH the following:
1. Secret key ( TSIG )
2. Subnet.
Unfortunately, I realized that we can specify only one of the above in
allow-update {} ACL.
If I specify both, it doesn't work as expected.
Qu
16 matches
Mail list logo
