per-zone-recursion?

Joerg Dorchain joerg at dorchain.net
Fri Oct 1 07:15:43 UTC 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101001/199dc25f/attachment.bin>


More information about the bind-users mailing list