Internal / External resolver question

Kevin Darcy kcd at daimlerchrysler.com
Tue Nov 14 01:04:59 UTC 2000


No, you can't use an "internal root" if these nameservers are expected to
use the Internet roots to resolve external names. If you try to mix
internal and Internet roots, then you'll get non-deterministic answers to
external queries, depending on which root server your nameserver happened
to ask about the name. And no, you can't really tell your internal roots
to forward queries for unknown names to the Internet roots, because a root
server thinks it already knows everything there is to know about "the"
root zone and won't query further. Internal roots are really only
appropriate where you have *no* requirement for internal clients to
resolve Internet names, e.g. a totally isolated network, or one which is
behind proxy firewalls.

Instead, use any combination of slave/stub/per-domain-forwarding for the
apex zone of each of your internal domains in order to selectively
"override" what they see from the Internet. When you do this for the apex
zone of each domain, it'll also work for any subzones you have within
those domains, since then the nameserver will either a) see the internal
delegations and use them, in the case of slave and stub, or b) in the case
of per-domain forwarding, it won't be an issue because *every* query
ending in the specified domain will be forwarded if the answer doesn't
happen to be in the cache.

Which zone type to choose, slave stub or forward? Each one has advantages
and disadvantages...

Slaving requires zone-transfer authority and can incur a significant
amount of zone-transfer overhead, depending on the sizes of the zones,
your refresh settings, how often the zones change, etc., but is the best
thing for reducing query latency to your clients since the answers come
directly from authoritative data. It also offers the best redundancy,
since you have a copy of the whole zone. A slave can still answer any
query in the zone, even if it is completely cut off from the authoritative
servers for the zone (although once the configurable "expiration" interval
has elapsed, it will stop answering authoritatively).

Forwarding is at the other end of the spectrum: no zone-transfers, and
thus no zone-transfer overhead or requirement to be authorized for zone
transfer, but on the other hand, no redundancy and relatively bad latency
for non-cached entries. Depending on your query patterns, the typical
TTL's of what your clients are querying, etc. forwarding can actually
consume *more* resources than you save in zone-transfer overhead, thus
negating that benefit. Moreover, forwarding requires that the forwarders
honor recursion, and if they do, all of the onus is put on them to resolve
the forwarded queries, thus not distributing the load very evenly,
creating more points of failure, scalability problems, etc. On the plus
side, if you have a fast internal backbone with lots of little (in terms
of query volume) nameservers on it, forwarding to a central server or set
of servers which can build up a rich cache, might offer adequate latency,
without all of the zone-transfer overhead of being a full-blown slave. In
fact, if you find that to be the case, you might also want to consider
*global* forwarding (i.e. in the "options" clause as opposed to
per-domain-forwarding) on your less-busy servers in order to improve the
latency of your external queries as well.

Note that, if you decide to go with global forwarding, that forwarding
should be set to "forward first", so that the nameservers can still
resolve Internet names using iterative resolution if the forwarders are
down or unreachable, but, regardless of whether you use global forwarding
or not, any per-domain-forwarding you define for the apex zones should be
set to "forward only", to prevent wasted effort trying to resolve internal
names on the Internet if and when your forwarders are not available.

Stubbing is kind of a middle ground between the two extremes of slaving
and forwarding. Like forwarding, it offers no redundancy and worse query
latency than being a slave, but does not require zone-transfer authority.
On the other hand, unlike forwarding, it has a *small* zone-transfer
overhead (only SOA and NS records need to be transferred), doesn't require
recursion from its "upstream" servers, and (therefore) generally
distributes query-resolution load better. Also, in versions prior to
BIND 8.2.3, stubbing is more *adaptive* than forwarding, since nameservers
are chosen according the normal RTT-based algorithm, which offers more
performance and robustness than a fixed order with timeout-failover. In
BIND 8.2.3, supposedly the same RTT-based algorithm is also used for
forwarder-selection.

There's nothing to say, of course, that you couldn't mix-and-match zone
types for different zones, depending on your needs/requirements. They
don't have to all be the same type. Even if you implement global
forwarding, as suggested above, then you still have the option of
cancelling forwarding in specific domains -- and thus falling back to the
normal, iterative query-resolution mechanisms -- by using the "forwarders
{ }" syntax in a slave or stub zone.


- Kevin

sicr_j at my-deja.com wrote:

> Hello all,
>
> Setting up 2 name spaces, I'll call them inside and outside.  Inside is
> large enough that it not only has authoritative name servers but also
> caching-only resolvers.  Of course, I want to set internal clients to
> resolve off the caching-only resolvers.  However, these resolvers will
> have connectivity to the Internet and will thus be able to query the
> root servers.
>
> How do I get the resolving name servers to query the internal
> authoritative servers for internal addresses without first going to the
> roots?
>
> Will an "internal root" config work here where I configure the hints
> file on the resolving servers to query the internal authoritative
> servers for inside addresses?
>
> I appreciate any assistance from past experience on this one.  I will
> likely not be able to test anything out for a couple of weeks, but
> input is welcome.






More information about the bind-users mailing list