On 1/10/10 9:15 AM, "Joerg Dorchain" <jo...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Kal Feher 

bind-users mailing list

Reply via email to