Split roots (was: Can someone explain forwarders and why I don't need them?)

Kevin Darcy kcd at daimlerchrysler.com
Thu Jul 31 23:09:42 UTC 2003


Herb Martin wrote:

> "Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
> news:bgbuds$s9p$1 at sf1.isc.org...
> > I guess I'm missing something here: what exactly is the purpose of
> defining
> > zones that return nothing but REFUSED or SERVFAIL? Either you have valid
>
> You have to look at the (typical) behavior of an internal
> server -- and how we can "fiddle" that to solve the "two
> separate (disjoint) namespaces" problem.
>
> An internal server forwards, our forwarder returns the NXDOMAIN
> because it cannot find the answer, and the internal server STOPS
> looking, considering the NXDOMAIN to be definitive.
>
> If we want our internal server to FORWARD and recurse and internal
> namespace from the root down on it's own, we need to prevent the
> NXDOMAIN.
>
> REFUSE and SERVERFAIL are two ways to accomplish that.

Ah, so if I read you correctly, you're set up with "forward first", a private
internal root, and you're deliberately scotching certain parts of the
namespace in order to trigger named to go to iterative resolution...

Kludge alert! You're basically exploiting a *failover* mechanism to get what
you want. That's really bad news. What if your forwarders hiccup some
day? Then your great failover mechanism might kick in accidentally, and
suddenly your nameservers are giving *incorrect* responses (e.g. NXDOMAIN for
www.msn.com/A instead of SERVFAIL or timeout). You're overloading something
that was never intended to be used the way you are using it, and potentially
sacrificing proper behavior as a result.

> > "private" data for those zones, or you don't: if you have valid data, why
> not
> > return it? and if you don't, why not just fetch (via forwarding) whatever
> is
> > available on the Internet in that domain? Is a REFUSED or SERVFAIL
> response
> > somehow *better* than a response which yields addresses, albeit
> unreachable
> > ones? The point of the configuration you described apparently eludes me.
>
> In this case above it is better because the typical behavior of
> OTHER (internal) DNS servers is to continue the search
> recursively.
>
> Since the forwarder and the internal server have different
> root hints, we have tricked them into efficiently searching
> two namespaces.

I usually prefer to configure things using well-understood -- or at least
well-understandable -- methodologies instead of "trickery". Do you really
expect your successor to understand or support this Rube Goldberg contraption
you've created?

> It's only an advantage if you have multiple zones internally
> that require you to establish a private root and thereby a
> private, disjoint namespace -- but you still want to resolve
> Internet (or some other) namespace names.

Okay, so how is it really a win to have to maintain all of those delegations
in a private root zone (remembering of course that all delegations from a root
zone require glue A records, so anytime the name or address of a delegated
nameserver changes, so must your root zone),plus all of those so-called
"synthetic" zone definitions, than it is to just maintain the equivalent
number of stub-zone definitions and be done with it? I'm still not seeing the
point of the configuration, other than as a Proof of Concept to show how
egregiously you can abuse BIND's failover algorithms...


- Kevin




More information about the bind-users mailing list