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

[Herb Martin]

> Kludge alert! You're basically exploiting a *failover* mechanism to get
what
> you want. That's really bad news.

Of course it's a kludge but it works.  And know, it's now
"bad news", it just works and there's not another way that
I know to accomplish it.

It's also documented and only a kludge in the sense that
it takes advantage of the features in unexpected ways.

> 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).

No, the sky might fall too but if this fails then there are a lot
of people out their who's normal use of ACLs will fail too.
I will have an outage, they will have an unexpected and perhaps
unnoticed security problem.

> 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.

No, there is no overload, or sacrifice.  In fact it is very
efficient if you trace the message paths.

Are there better designs? Yes -- but not with current
popular DNS servers (BIND and MS -- and I am stuck
with MS.)

All you BIND lovers and MS haters this is actually something
that MS DNS cannot do.

> 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 no more difficult than anything else in BIND and I documented
it right there in the config file -- it works just fine, thank you.

So unless you can find a "Real Problem" over have a BETTER
solution, it does exactly what I want it to do.  Thank you.

> 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

Ah, but they don't.  An empty zone file (SOA and one NS) is just
find to prevent the SERVERFAIL and I just point all the zones
(however many) to the same 'stubby' zone file so the only issue
is duping ONE LINE in the config, changing the zone name and
VOILA!

> "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...

Stub zones don't work either unless I do it basically the same
way, but if you ever need the solution and prefer Stub zones
then I have no reason to talk you out of that.

In addition, 'true stub' zones require that I maintain connections between
this
server and (all those) real DNS servers.  This method requires
only that I define the zone.