Multiple roots?

[Kevin Darcy]

Dave Wreski wrote:

> Hi all,
>
> I'm trying to configure an internal name server that is to become
> authoritative for a top-level domain that is different than the
> top-level of the company to which it belongs.
>
> In other words, I have something like this:
>
> [Internet]-----[DMZ]----[ns.inside.companyA.com]
>                  |              |
>         [ns.companyA.com]  [internal network]
>                                 |
>                                 |
>                            [ns.bigcompany.com]
>
> ns.inside.companyA.com is also a proxy server. Hosts on the internal
> network need to be able to resolve hosts within the bigcompany.com
> domain using the bigcompany.com internal domain servers, not the one's
> authoritative for the top-level domain.
>
> ns.bigcompany.com has no knowledge of ns.inside.companyA.com.
>
> The problem is that when clients on the internal network try to resolve
> www.internal.bigcompany.com using ns.inside.companyA.com, the nameserver
>   seeks its answer from the public DNS servers on the Internet.
>
> If I use forwarders on ns.inside.companyA.com with name servers capable
> of resolving hosts in the private.bigcompany.com domain and a root cache
> file containing the correct bigcompany-root.net servers, it works
> correctly but then of course it's unable to resolve public Internet hosts.
>
> If I use forwarders on ns.inside.companyA.com with a name server defined
> in the public DMZ and public root servers, I'm of course able to resolve
> hosts on the Internet but not the bigcompany.com internal hosts.
>
> If I use the name server in the public DMZ as a forwarder combined with
> the internal root servers, I receive the following for each of the 6
> defined root servers:
>
> 08-Jul-2002 22:26:26.084 default: check_hints: no A records for
> c.bigcompany-root.net class 1 in hints
>
> What am I doing wrong? Is this even possible? Is it possible to somehow
> define multiple roots or configure forwarders correctly?

You need to define bigcompany.com *selectively* as a zone of type slave, stub
or forward. "Stub" is probably the most lightweight of the 3 alternatives,
but depending on the frequency of changes to the zone, query mix,
REFRESH settings for the zone, etc., etc., one of the other alternatives
might be a better choice overall for performance, redundancy, efficiency etc.
depending on what your requirements and preferences are. "Slave" gives the
most redundancy, of course, but is out of the question if the master
restricts zone transfers and you can't get your nameservers included on their
Access Control List. Forwarding is your only reasonable alternative if you
need to resolve names in subzones of bigcompany.com, where the nameservers
for the subzones are unreachable from your nameservers (although you could
opt to define only the problematic subzones -- instead of bigcompany.com
itself -- as "type forward" in that case). Note that when using forwarding
for this purpose, the forwarding mode should be set to "forward only" (which
is *not* the default mode), and it won't work at all if the intended
forwarder doesn't support recursion.


- Kevin