DNS External/Internal Shadow Domains?

[Kevin Darcy]

Cricket Liu wrote:

> > Thanks to the new "de-forwarding" feature of BIND, the internal
> nameservers
> > could selectively use the internal roots for internal domains and forward
> for
> > everything else, thus reaping the rewards of both architectures, i.e. the
> > ability to resolve Internet names via forwarding, while at the same time
> > exploiting the robustness, adaptability and scalability of an
> internal-root
> > architecture for everything internal.
>
> Yeah, I thought of that some time ago, back when the new forwarding
> features were spec'd, but it doesn't work.  When you try to set this up,
> you'll notice that in a configuration like this:
>
> options {
>     forwarders { external.forwarder; };
> };
>
> zone "internal.zone" {
>     type stub;
>     file "stub.internal.zone";
>     forwarders {};
> };
>
> zone "." {
>     type hint;
>     file "internal.root.hints";
> };
>
> ...your system query gets sent to your forwarder.  Since the forwarder
> sees the Internet name space, you get the Internet's root name servers
> in the response, and you ignore the contents of your root hints file.
> Consequently, you don't use your internal roots.
>
> If you've found a way around this, I'd love to hear it.

Seems to work fine for me if I define my internal top-level as a
"forward" zone instead of a stub (it doesn't need to be a stub since it can
get the NS info from the internal roots). I bring up the nameserver, query
something external, query something internal, both resolve, the only root
NS'es in my cache are internal roots. This is true even if I query something
in a non-existent TLD before I query anything internal, but in that case
there's a relatively-harmless root SOA record in the cache (and, of course, a
negative cache entry). What am I overlooking?


- Kevin