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