Stub zone vs forward zone

[Marc Haber]

Hi,

On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote:
> Stub zones: only available as a single level beyond one's "authoritative  
> core", i.e. the stub server must be able to talk directly to one or more  
> authoritative servers for the zone.
> Forward zones: can be daisy-chained an arbitrary number of levels from  
> the authoritative core (but this is not recommended due to  
> manageability, performance and reliability concerns).
>
> Stub zones: will use whatever is in the NS records of the zone (or  
> descendants of the zone, if not otherwise defined) to resolve queries  
> which are below a zone cut.
> Forward zones: will always use the configured forwarders, which must  
> support recursion, even for names which are known to be deeper in the  
> delegation hierarchy and whose delegated/authoritative nameservers might  
> respond more quickly than the forwarders, if asked.

Thanks for the clarification, I appreciate that.

> As a general rule, use "type forward" zones only if you have some  
> connectivity issue you need to work around, e.g. trying to resolve  
> Internet names from behind a restrictive firewall.

So, a "type forward" zone is the right thing to do for the reverse DNS
zones of RFC1918 networks that are reachable via a VPN link. However,
my setup using a "type forward" zone doesn't work, and bind does not
even try querying the forwarders listed in the type forward zone
statement when I try to obtain a PTR record for an IP on these nets.

>  Use slave zones if you want a full copy of the zone available at all
>  times (unless it expires of course), thus maximizing fault-tolerance
>  and client-to-resolver performance, but subject to the replication
>  overhead, storage space and willingness of the zone owner to allow
>  zone transfers.  And use stub zones if you want a more lightweight
>  alternative to slaving, at the expense of some fault-tolerance and
>  client-to-resolver performance.

In my case, my slave could only intermittendly reach the master
servers for the zones, so I'd need to reload these zones quite
frequently to "catch" a time when the VPN tunnel is built. Does a stub
zone use the same mechanism, or will it immediately query for the
stub's NS records when a query comes in and the NS records are no
longer cached?

> To answer your specific question, the non-intuitive[1] "forwarders { };"  
> is needed to inhibit forwarding which has presumably been defined at a  
> higher level (semantically) in your config, either at the  
> 1.10.in-addr.arpa level, or somewhere above that, explicitly, or  
> so-called "global forwarding" defined in the "options" clause.

Global forwarders. So they would take precedence over the locally
available delegations for the stub zone?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190