match-clients and TSIG keys

Jim Reid jim at rfc1035.com
Fri Sep 10 07:47:24 UTC 2004


>>>>> "Adam" == Adam Clark <Adam.Clark at ngv.vic.gov.au> writes:

    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.

View matching with TSIG keys will be implemented in 9.3.

Using this for zone transfers will be messy because the view qualifier
applies to all clients, not just the ones that do a zone transfer. It
might not be possible for stub resolvers or whatever to send
TSIG-signed queries so they can see the relevant view. Or else the
view ACLs are a combination of IP addresses and TSIG keys, which is
ugly. And a potential maintenance headache. You may be better off
having the slaves for each view on discrete sets of name servers
rather than have them serve both views.

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

view "inside" {
	match-clients { a; b; };
	...
};

view "outside" {
	match-clients { !a; !b; any; };
	...
};


More information about the bind-users mailing list