match-clients and TSIG keys

[Adam Clark]

=20

> -----Original Message-----
> From: jim at gromit.rfc1035.com [mailto:jim at gromit.rfc1035.com]=20
> On Behalf Of Jim Reid
> Sent: Friday, 10 September 2004 5:47 PM
> To: Adam Clark
> Cc: bind-users at isc.org
> Subject: Re: match-clients and TSIG keys=20
>=20
> >>>>> "Adam" =3D=3D Adam Clark <Adam.Clark at ngv.vic.gov.au> writes:
>=20
>     Adam> To me, this seems that when the view for the client is
>     Adam> determined, it only Looks at the originating IP and does not
>     Adam> take into account any TSIG key In the request.  This would
>     Adam> make the statement in the ARM incomplete.
>=20
> View matching with TSIG keys will be implemented in 9.3.
cool
>=20
> Using this for zone transfers will be messy because the view=20
> qualifier applies to all clients, not just the ones that do a=20
> zone transfer. It might not be possible for stub resolvers or=20
> whatever to send TSIG-signed queries so they can see the=20
> relevant view. Or else the view ACLs are a combination of IP=20
> addresses and TSIG keys, which is ugly. And a potential=20
> maintenance headache. You may be better off having the slaves=20
> for each view on discrete sets of name servers rather than=20
> have them serve both views.
I was planning on using something like this
Internal:
Match-clients{ key axfr-int; trusted-clients; }
External:
Match-clients{ key axfr-ext; any; }

But on more thinking, the acl trusted-clients will
Contain the DMZ where the secondary is placed it will
Match the trusted-clients acl before it hits the=20
External view.

It isnt feasible to have two sets of name servers, so
Is the prefered method for this a second ip address
For the secondary and sending axfr's from that address?

>=20
> BTW, using an any ACL for view matching isn't wise. If the=20
> view{} statements get moved around in name.conf, this could=20
> have unwanted results. Like exposing a private name space to=20
> the public. In other words the semantics of a view should not=20
> depend on its relative placing in the configuration file.=20
> It's safest and wisest to make sure the match-client ACLs are=20
> mutually exclusive and completely complement each other. ie
>=20
> view "inside" {
> 	match-clients { a; b; };
> 	...
> };
>=20
> view "outside" {
> 	match-clients { !a; !b; any; };
> 	...
> };
>=20
Gotcha, makes sense