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