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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
