match-clients and TSIG keys

[Adam Clark]

Please validate my train of thought.

I am trying to implement a Master-Slave configuration in
A DMZ with internal and external views. The Master is setup
And working well, now it is time for the slave to tranfer
The zones down. But as you know, the same IP cannot see the
Two views to tranfer them both. So after a bit of thinking
I thought it would work by using TSIG keys to identify the=20
Appropriate zone to transfer.

According to the bind9arm:
The addition of the key clause made the name of this syntactic element
something of a misnomer, since
security keys can be used to validate access without regard to a host
or network address. Nonetheless, the
term "address match list" is still used throughout the documentation.

I take that as meaning:
If I use no ip based acl's to identify views, but only a valid TSIG key,
I should
Be able to see what the TSIG key is entitled to.

The below configuration should work ok given used with the appropriate
key with dig
I should be able to query and transfer the appropriate zone dependant on
the
Key I use.

key axfr-int {
..
..
};

key axfr-ext {
..
..
};

view "internal-in" in {
match-clients { key axfr-int; };

zone domain.com {
allow-query { any; };
};
};

view "external-in" in {
match-clients { key axfr-ext; };
zone domain.com {
allow-query { any; };
};
};

But if I run dig, I get an entry in the log:
dig @localhost -k Kaxfr-int.+157+50739.private domain.com
Sep 10 15:55:18.810 client 127.0.0.1#32901: no matching view in class
'IN'

Whereas if I change the config to this:

view "internal-in" in {
match-clients { 127.0.0.1; };

zone domain.com {
allow-query { key axfr-int; };
};
};

view "external-in" in {
match-clients { any; };
zone domain.com {
allow-query { key axfr-ext; };
};
};

I can only query when I use the TSIG keys, which is what I expected.
So my keys are valid and my methodology seems sound, but match-clients
Seems to be the missing part of the puzzle.


To me, this seems that when the view for the client is determined, it
only
Looks at the originating IP and does not take into account any TSIG key
In the request. This would make the statement in the ARM incomplete.

Adam

[Jim Reid]

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; };
...
};

[Adam Clark]

=20

-----Original Message-----
On Behalf Of Jim Reid
Sent: Friday, 10 September 2004 5:47 PM
To: Adam Clark
Subject: Re: match-clients and TSIG keys=20
=20
=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

[Jim Reid]

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

BIND 9.3 isn't out yet. That means the only current way of deciding
which views clients see is based on IP address. Unless of course
you're willing to run 9.3 release candidates and/or betas on
production servers.

[Adam Clark]

-----Original Message-----
On Behalf Of Jim Reid
Sent: Monday, 13 September 2004 10:21 PM
To: Adam Clark
Subject: Re: match-clients and TSIG keys=20
=20
=20
Adam> It isnt feasible to have two sets of name servers, so Is the
Adam> prefered method for this a second ip address For the
Adam> secondary and sending axfr's from that address?
=20
BIND 9.3 isn't out yet. That means the only current way of=20
deciding which views clients see is based on IP address.=20
Unless of course you're willing to run 9.3 release candidates=20
and/or betas on production servers.
=20

Not at all, I have aliased another IP onto the slave server
And set the axfr's for the second view to originate from there
And that works fine.=20

Once 9.3 does come out, would using TSIG keys to identify which
Of the views you want to transer become the prefered=20
method or will the current method remain best practice?

Also, thanks for the tip on acl's making the mutually exclusive.
This also helped make my configuration deal with bogon
Lists more clear and concise.

Thanks for all your help

Adam