DNS External/Internal Shadow Domains?

James Hall-Kenney JHall at sytec.co.nz
Tue Nov 9 19:24:38 UTC 1999


There was quite a bit of discussion on this in the archives a coupla weeks
back.  In summary the answer was that internal roots and forwarding are
mutually exclusive as root servers believe that they have an authoritive
answer for all names.

However if you separate your internal root servers away from the internal
name servers that are actually queried by clients, you can define forwarders
on the non-root servers which work ok.

It's not too hard to run a low end machine in the background running only
the root zone and create a cache hints that points to these for your other
name servers ...

I've tried this in the lab and it worked ok.  There were others that had
this going in production.

Cheers

-----Original Message-----
From: Steve Kelley [mailto:Steve.Kelley at sdrc.com]
Sent: Wednesday, 10 November 1999 07:07
To: Joseph S D Yao
Cc: comp-protocols-dns-bind at news.uu.net
Subject: Re: DNS External/Internal Shadow Domains?


Hi Joe,

Thanks for your response.  The issue is not to standard.
I assume your message below assumes that the Internal name
servers use Internal root name servers.  If so, I agree it
seems pretty standard.  The only problem we are seeing with
this configuration is that we would like to setup our Internal
name servers as both the Internal root name server and Internal
domain name server.  This causes some confusion concerning setting
the "forward" option on the Internal name server.

If you setup an Internal root name server, can it exist on a name
server that is setup as a forwarder?

How critical do you think it is to a corporation that name resolution
relies on the Internet root name server vs. Internal root name servers?

We don't have very many Internet disruptions in a given year, but we don't
want a disruption to bring down hostname resolution internally due to
Internet root name servers not being available.

Maybe this shows you more detail as to what we are trying to accomplish:

     Internet	     Internet	     Internet
	|		|		|
	|	    Ext. View		|
    jelly.com	    toast.com	    butter.com
     1.1.1.0	     1.1.2.0	     1.1.3.0
	|	Uses Internet Roots     |
	|	Resolver points to	|
	|	Internal name server	|
	|	to handle internal name	|
	|	lookups.		|
	|		|		|
     Firewall	     Firewall	     Firewall
	|		|		|
	|	   Internal View	|
	|	    toast.com		|
	|	forwards to Ext. name	|
	|	server for un resolved	|
	|	hosts.  Delegate sub	|
	|	domains to remote sites	|
	|	connected via WAN.	|
	|		|		|
         \             / \             /
          \           /   \           /
           \         /     \         /
            \       /       \       / 
             \     /         \     /
              \   /           \   / 
               \ /             \ /
                |               |
	wheat.toast.com	   rye.toast.com
	
If your "internal" domains use Internet root name servers to allow
the "internal" domain to resolve Internet hostnames, the internal
domains can't resolve other internal subdomains as the Internet root
name servers delegate to your external domain name servers who don't
have a view of the internal domain structure.

So if you want a true split DNS solution with both an internal/external
view of your domain it would appear you would have to make use of a
combination of internal root name servers, and the use of forwarders to
resolve Internet domain names.

Thanks,
Steve...

		 
Joseph S D Yao wrote:
> 
> This is pretty standard.  Internal name servers resolve all internal
> domains.  They forward to the firewall for all unresolved queries.  No
> domains are split in half between internal and external [or if they are,
> you resign yourself to losing the other part of the domain].
> 
> --
> Joe Yao                         jsdy at cospo.osis.gov - Joseph S. D. Yao
> COSPO/OSIS Computer Support                                     EMT-B
> -----------------------------------------------------------------------
> This message is not an official statement of COSPO policies.


More information about the bind-users mailing list