per-zone-recursion?
Kalman Feher
kalman.feher at melbourneit.com.au
Fri Oct 1 09:25:31 UTC 2010
On 1/10/10 9:15 AM, "Joerg Dorchain" <joerg at dorchain.net> wrote:
> On Thu, Sep 30, 2010 at 07:13:11PM -0400, Kevin Darcy wrote:
>> Per-zone recursion control doesn't exist in BIND, because frankly it
>> doesn't make sense.
>
> I used to think that, too, until I came to my specific problem.
>>
>> Either a zone type is meaningless *without* recursion (type forward,
>> type stub), or recursion is *unnecessary* because the nameserver
>> answers from authoritative data (type master, type slave).
>
> Exactly. Up to here I completely agree.
>>
>> Put another way, have you thought through exactly what you want to
>> happen if a client queries something not specifically carved out for
>> recursion, e.g. isc.org?
>
> Yes. To explain my setup further, there is a view based on
> src-IPs for some clients, where recursion is turned on.
> The rest of the world gets non-recursive answers, e.g. with
> authoritative data, or refused.
>
> In case of that specfic forward zone, bind answers in the
> non-recursive case with a referal to itself (there is only one
> public IP), which is causing a loop, as there is no way to
> specify a different port in the DNS protocol (AFAIK)
This is the problem and the reason I agree with Kevin. The referral is
correct behaviour. Your DNS set up is wrong. You have 2 choices and a third
less palatable option:
1. Make the other DNS software available on another IP. So normal DNS
behaviour works.
2. Add the zone as a slave within your authoritative view. (this option may
be the easiest for your situation).
3. recursive view with forwards to both your authoritative view and the
dynamic subdomain. I think this solution is silly and will be problematic to
maintain, but its likely to suite your needs exactly.
>>
>> The response from a BIND instance, when recursion is denied or not
>> requested, is always either (as per Section 4.3.1 of RFC 1034):
>> a) an answer from authoritative data,
>> b) an answer from cache
>> c) a negative-caching response,
>> d) a (0 answers) referral, or
>> e) some sort of "non-response", like an error (SERVFAIL) or an
>> administrative rejection of the query (REFUSED)
>>
>> If (a) doesn't apply (because not authoritative) and neither does
>> (b) (because how can answers be cached in the first place if
>> recursion is being denied?), that leaves (c) through (e), none of
>> which are particularly useful to the client. So you might as well
>> REFUSE queries outside of zones for which recursion is not
>> explicitly enabled. Configure "allow-query { none; };" as the
>> default followed by specific exceptions for the zones you want to
>> "open up", e.g., dynsup.example.net.
>
> You have summarized my thoughts very well. At this point I found
> out that the current grammar for bind does not allow to combine
> "type forward;" with an "allow-query" (or "allow-recursion").
>
> A quick look at the sources also showed that forward zones are
> implemented differently than "real" zones like master or slave.
>
> This way I came to the point where I am wondering if it is
> possible to configure bind either
> - do recursion on a per-zone base for forward zones, as the
> currently implemented criteria (src-ip, dst-ip, recursion flag)
> do not cover my case in an obvious way
> - forward queries to a specific destination and the answers back,
> acting as a reverse-proxy without too much intelligence.
>
> Bye,
>
> Joerg
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Kal Feher
More information about the bind-users
mailing list