stub versus forward

[Kevin Darcy]

With a stub zone, you hardcode the masters in named.conf and it replicates the NS records for the zone (well, it also replicates the SOA record, but that's just for serial-number tracking). It can use those replicated NS records to find out anything it needs to about the zone, using *non-recursive* queries, assuming that the answer is not already in the cache.

With a zone of type "forward", any query in the relevant domain, which does not have an answer already cached, is sent, via a recursive query, to a (hardcoded-in-named.conf) list of forwarders for resolution.

So the major differences are:

1) stubs replicate NS records, so they are a little more resilient to nameserver reassignment (as long as at least one of the nameservers is still valid, the replicated NS records should be up to date); forwarding tends to degrade as the hardcoded forwarders list becomes invalid.

2) stub zones cause non-recursive queries; forwarding causes recursive querying. Non-recursive querying generally spreads processing load more evenly, but if you're dealing with a connectivity issue (e.g. you're behind a firewall), forwarding via recursive queries may be your only choice.

Note that in some versions of BIND (including all versions of BIND 9, I think), forwarders are used _sequentially_, which results in a severe performance penalty when the first forwarder in the list (or the first "n" forwarders in the list) is down or unavailable. Stubs, in contrast, always use the RTT calculation to pick nameservers to contact, which is more resilient to failures or congestion.

                                                                                                                    - Kevin

Armin Safarians wrote:

> Can someone please tell me what is the difference. I know basically how
> they work. I just don't really know why one versus another.
>
> Thanks,
> AMS :-)
>
> --
> *******
> It is by acts and not by ideas that people live.
> - Anatole
> *******
>
> "WorldSecure Server <safeway.com>" made the following
>  annotations on 05/02/02 10:53:39
> ------------------------------------------------------------------------------
> Warning:
> All e-mail sent to this address will be received by the Safeway corporate e-mail system, and is subject to archival and review by someone other than the recipient.  This e-mail may contain information proprietary to Safeway and is intended only for the use of the intended recipient(s).  If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited.  If you have received this message in error, please notify the sender immediately.
>
>
> ==============================================================================
>
> -- Binary/unsupported file stripped by Ecartis --
> -- Type: text/x-vcard
> -- File: armin.safarians.vcf
> -- Desc: Card for Armin Safarians