Stub zone vs forward zone

[Kevin Darcy]

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.

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. 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.

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. By 
default, named does not forward, so if those were the only 2 zone 
definitions in named.conf, and there was nothing about forwarding in 
your "options" clause, then you wouldn't need "forwarders { };" in any 
of your zone definitions. You only see that directive in "hybrid" 
configs, where forwarding is used at one level of the namespace 
hierarchy, and then overridden with regular iterative forwarding at a 
lower level.

                                                                         
                                                               - Kevin

  [1] Personally, I would have preferred a syntax like "forward none" or 
something of that nature, but I guess it's water under the bridge at 
this point...
On 3/14/2011 6:43 AM, Marc Haber wrote:
> Hi,
>
> I am running a local instance of bind on my notebook to spare myself
> some rather annoying reconfiguration orgies that are bound to happen
> when changing networks.
>
> On my biggest customer's network, I am trying to be able to access
> their reverse DNS, which is (don't ask) not loaded on the servers that
> my notebook is assigned via DHCP as forwarders.
>
> I have thus configured these zones locally, experimenting with
> differnt configuration types:
>
> zone "2.1.10.in-addr.arpa" {
>          type stub;
>          masters { 10.1.2.11; 10.1.2.45; };
>          file "stub/2.1.10.in-addr.arpa";
>          forwarders { };
> };
>
> zone "101.1.10.in-addr.arpa" {
>          type forward;
>          forwarders { 10.1.101.6; };
>          forward only;
> };
>
> The stub zone works; the forward zone doesn't. When I ask my local
> bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
> without bind even trying to talk to the actual name server.
>
> I can ping 10.1.101.6 just fine.
>
> I must admit that I haven't yet full understood the difference between
> a stub zone and a forward zone, any why i need the forwarders { } on
> the stub zone.
>
> Any hints will be appreciated.
>
> Greetings
> Marc
>