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