match-recursive-only vs configured zones
Chris Buxton
cbuxton at menandmice.com
Tue May 19 17:25:27 UTC 2009
On May 19, 2009, at 9:45 AM, Matus UHLAR - fantomas wrote:
> Hello,
>
> I'd like to know how does match-recurtsive-only view interact with
> configured zones.
The order of views matters. The first one matched, wins.
Let's suppose you have a config along these lines:
view "resolver" {
match-clients { local-clients-acl; };
match-recursive-only yes;
allow-recursion { local-clients-acl; };
};
view "auth" {
recursion no;
zone "example.com" {
type master;
file "example.com";
};
};
There are three scenarios for queries:
- If a query comes from the outside, it will hit the "auth" view,
regardless of wether it's recursive or iterative. It will always be
answered as an iterative query - that is, your server will not perform
recursion for outside clients, and the ra bit will always be turned
off in the response.
- If a recursive query comes from an authorized user, it will be
answered by the "resolver" view. If it is for one of your local zones,
the "resolver" will end up asking the "auth" view for the answer. (If
the server is behind a NAT server, you may need to configure something
specially to make this work.)
- If an iterative query comes from the internal network, it will be
handled by the "auth" view. This allows you to use other internal
resolving servers without having to special-case anything.
One thing to note, for internal users who use nslookup (or dig, or
host, or whatever) to try to diagnose problems with the "auth" view:
If they send recursive queries, they will get non-authoritative
responses. If they send iterative queries, they will be told that
recursion is not available. This can be confusing.
Chris Buxton
Professional Services
Men & Mice
More information about the bind-users
mailing list