match-recursive-only vs configured zones

Chris Buxton cbuxton at menandmice.com
Tue May 19 18:55:19 UTC 2009


On May 19, 2009, at 10:50 AM, Matus UHLAR - fantomas wrote:
>> On May 19, 2009, at 9:45 AM, Matus UHLAR - fantomas wrote:
>>> I'd like to know how does match-recurtsive-only view interact with
>>> configured zones.
>
> On 19.05.09 10:25, Chris Buxton wrote:
>> 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; };
>
> wouldn't "recursion yes;" have the same effect here?

Yes.

>> };
>> 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.
>
> That's the desired effect.
>
>> - 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.
>
> So it will just use zones configured in "auth" as they were in  
> "resolver" -
> if I hadn't views at all?

Not exactly. The "resolver" view will perform recursion, and should  
end up querying itself (and get the "auth" view).

>> (If the server is behind a NAT server, you may need to configure  
>> something
>> specially to make this work.)
>
> It's not, but can you at least hint me so I could understand?

If NAT is involved, then when the "resolver" view tries to query the  
"auth" view, it will actually query the public address. This won't  
work without two-way NAT.

>> - 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.
>
> I think this won't confuse me. This is a server some people use for
> recursion and there are also some domains there, I want to move all  
> services
> away and shut the server down.
>
> Now if I configured
>
> view "external" {
> 	match-clients { any; };
> 	match-recursive-only yes;
> 	recursion no;
> }
>
> between "resolver" and "auth", that view would be used for all  
> recursive
> queries from unauthorised sources, while iterative queries would  
> still go to
> "auth", so I could provide special (no) service to unauthorised  
> recursive
> clients, correct?

That is correct.

Chris Buxton
Professional Services
Men & Mice




More information about the bind-users mailing list