internal + external DNS integration

Kevin Darcy kcd at daimlerchrysler.com
Fri Mar 30 20:58:43 UTC 2001


What you're proposing is somewhat similar to what we have. Except we have
multiple SLD's (chrysler.com, daimlerchrysler.com, daimler-benz.com, cfc.com,
etc.) and an internal-root architecture.

I'm not sure what you mean by "common multihomed DNS server". Are you talking
about a firewall? We run split DNS on the firewalls which serve external DNS,
although most of our clients won't be asking the firewalls about internal
names, since that's handled by a whole infrastructure of internal-only
DNS servers. With BIND 8, split DNS requires running multiple nameservers, or
at the very least, multiple nameserver instances on the same machine listening
on different interfaces. With BIND 9, you can use "view"s to differentiate
between clients, so that you could run split DNS on a non-firewall or even
non-multihomed box. Be aware, however, that if you want your internal clients
(including potentially your firewalls) to see both the internal *and* external
entries in your domains, you'll have to maintain the external entries in both
versions of your zones. This is true for both the multiple-instance
(BIND 8) case and for "view"s (BIND 9), although if the same machine is master
for both the internal and external versions of zones, you might be able to play
$INCLUDE-file games to make maintenance a little easier.


- Kevin


Leonid S. Knyshov wrote:

> Dear comp.protocols.dns.bind readers,
>
> I am in the middle of drafting up a proposal for DNS changes across our
> company and need some help to validate my logic. I will face an uphill
> battle to solve this problem, so it would be nice to be sure it'll all work
> as described before engaging in the endeavor. I believe that it is
> technically feasible, but I keep an open mind when it comes to my own errors
> :-)
>
> I know the syntax necessary to set all this up thanks to the good old DNS &
> BIND.
>
> Further suggestions on how to improve the solution would be highly
> appreciated.
>
> Thank you very much,
>
> Leonid S. Knyshov
>
> === The problem
>
> Here is the current state of things:
>
> - We have purchased several companies and the DNS systems are not
> integrated.
> - Each company still runs its own DNS on its own domain and has no
> connection at DNS level to other parts of the company forcing the usage of
> phased out WINS.
> - The acquired companies are becoming increasingly integrated and are
> requiring access to hosts in other parts of the company
> - We have a need to limit internal DNS lookups for other domains in our
> company.
> - We have a need to not resolve external addresses of hosts inside the
> network and rather retrieve their internal addresses instead.
> - We require to retain local management of DNS at company sites as to avoid
> delays
>
> === The solution
>
> Changes required:
>
> In tradition with geographically dispersed DNS structure, I would like to
> propose to change the way we address the hosts at the very least here in my
> office as follows:
>
> HostName.SiteName.StateName.Company.Net - external access
> HostName.Company.Net - special case if production server
> HostName.SiteName.StateName.Company.Net - internal access
>
> StateName is to become CountryName in our overseas operations
>
> Benefits netted by these changes:
>
> - Unified naming convention eliminates confusion as to where the systems are
> located
> - Common multihomed DNS server can serve both internal and external queries
> based on where the query came from (True?)
> - We eliminate internal versus external address headaches
> - Subdomains on SiteName level can be delegated to the various offices
> willing to manage them or retained at the core Company.net level.
> - Host name lookups within Company.net domain will be completed without
> leaving the network
> - High latency ceases to be an issue due to the availability  of local
> copies of the HQ zone
> - Users can retain the ease of use of single host name internally with
> certain DHCP scope changes to reflect default DNS
> - Internal DNS becomes a highly available service
>
> Items involved:
>
> - Core DNS server in HQ becomes a top of the tree for all company.net
> subdomains
> - Regional DNS servers will require management of delegation at core level
> - Zone files changes at the SiteName level will be minimal
> - Legacy domains will be dropped and some systems dependent on DNS would
> require configuration changes
>
> Risks:
>
> - Possibility of Oracle-related problems
> - Possibly other applications dependent on DNS breaking temporarily
> --
> Leonid S. Knyshov
> http://www.pctips.com





More information about the bind-users mailing list