DNS External/Internal Shadow Domains?

[Kevin Darcy]

Cricket Liu wrote:

> > As I understood it, Kevin wanted internal roots, but to forward to the
> > firewalls to resolve all non-internal domains.  My understanding of your
> > objection to forwarding to firewalls was that they would use external
> > roots.  I may be wrong.
>
> First of all, Kevin didn't want anything.  He wasn't the original poster,
> and was just proposing a solution that he'd come up with.
>
> You've got my objection basically right, if I interpret the antecedent of
> "they" as "arbitrary internal name servers."  Yes, my objection is that,
> in this setup, arbitrary internal name servers never end up with the list
> of internal root name servers, so they don't use the internal roots.  So
> what good does setting up internal roots do?
>
> > Why doesn't it give iterative resolution of internal domain names?
> > Perhaps I assumed a different common base from you.  My assumption was a
> > "hints" zone that contained internal roots, the option to forward only
> > to the firewall, which was turned OFF for internal zones.  I know that
> > you have mentioned that different versions of 8.2 have handled this
> > differently ... but with this model, ISTM that the resolution of
> > internal zones would be handled by a miniature version of the same
> > process that happens on the Internet.  All other zones would be
> > forwarded to the next-up name server or handled without forwarding.
>
> Resolving internal domain names iteratively *can* work, but it's not as
> simple as you might think.  Since you're not using the internal root name
> servers, you don't have a list of name servers to work from, so you can't
> just say:
>
> zone "internal.zone" {
>     type forward;
>     forwarders {};
> };
>
> on an arbitrary internal name server.  If you did, and your name server
> received a query in internal.zone, it'd have nowhere to start (it wouldn't
> know which name server to query).
>
> > I have not tried this with an internal "." root, but with an internal
> > "master" name server that forwarded all unresolved queries to the
> > firewall.  To make sure it worked, though, I had two ways of doing
> > everything, which made this more work but less sensitive to changes
> > between versions.
>
> It works without internal roots.  It doesn't work with them.

The fly in the ointment here is root NS queries. I have discovered that
whenever a nameserver configured in this "hybrid" way gets a root NS query,
it'll overlay it's existing root NS data with the answer to that query.
Moreover, if the upstream forwarder has the "rfc2308-type1" option turned on,
then a query for *any* non-existent TLD would theoretically send back
Internet root NS'es which would "poison" the internal roots. When internal
queries are made prior to the first root NS query, the internal NS data gets
cached and everything *seems* to work, which is what fooled me at first, but
then when the first root NS query rolls in, it all falls apart.

Frankly, I think this is a BIND bug. The whole point of configuring a hints
file is to take advantage of iteration, so root NS data obtained via a hints
file shouldn't be overwritten by the answer to a non-iterative query. In the
presence of a hints file, BIND should either not cache the results of a
forwarded root NS query at all, or it should cache those entries separately
from the ones it uses for referrals.

And the really annoying part is that you can't even get around this by making
the server a slave to the internal root zone; that seems to cancel global
forwarding, even though technically it shouldn't.

By the way, while I was researching this, I also discovered that BIND only
seems to use the *first* cached root NS for referrals when global forwarding
is enabled. This should also be fixed.


- Kevin