match-recursive-only vs configured zones

[Chris Buxton]

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