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)
>
> 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
signature.asc
Description: Digital signature
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
