When designing a DNS architecture it is important to ask a number of questions about the current and future infrastructures. Hopefully the following questions will help you develop a reasonable DNS backbone for your corporation.
This is by far the most important question you will have to answer!
There are two different routes to take when designing a DNS architecture for a company's network. The first option is the easiest—create one DNS domain for the whole company (for example Acme.com). This means that you would have one primary DNS server and one or more secondary DNS servers. There are some downsides to choosing this option. The first being that the Primary DNS may have a problem keeping up with all of the secondaries polling. There are solutions to this problem such as, increase the secondary refresh interval, make some of the secondaries load from other secondaries (that is multiple DNS masters) and/or create some caching servers (allows you to avoid the overhead of a zone transfer—Warning : they are only valuable once they build up their cache). If you choose this approach and you decide in the future that it should be re-designed it can always be broken up.
The second option is more for the larger network installations which span multiple sites (this is the option we will explore in great detail in the rest of the paper). In this design you would have more than one DNS domain. The architecture would consist of one root domain (with a primary DNS server and one or more secondary DNS servers) and with one or more sub-domains (each with a primary DNS server and one or more secondary DNS servers). An example of the subdomains might be Dallas.Acme.Com and Reno.Acme.Com. The reason for such a design is quite obvious. A network architect usually breaks up a corporate DNS domain into multiple DNS domains to distribute the management of parts of the domain to various entities within the organization or to enable multiple zone files since zone files can only be created at the domain level. Another less obvious reason may be to simply allow for organizational affiliation of your systems. If you choose this route then the structure of your domain should mirror the structure of your organization, especially your companies support structure. Either way, you will need to determine how many domains your company will need.
Here is an example of such a configuration showing the DNS servers and the zone database files on each:
|
|
From a futures migration standpoint it's recommended that you create a DNS domain for every Windows NT domain that you currently have in your enterprise. |
It may not be that apparent today, but for a smooth migration to the next major revision of Windows NT this will be important. The next major revision of Windows NT is tightly coupled with the DNS backbone. See the Futures section of this paper for more information.
The following figure tries to show how a name might look in the future, keep in mind that you will still be able to use friendly names such as Scottsu@microsoft.com.
For a general overview of how a Windows NT domain might map to a DNS domain see the following figure. It has a Multiple Master domain with 2 Masters Reno and Dallas, and 6 Resources L100 to L202.
For the previous domain design you might have 9 DNS domains, Acme.com, Reno.Acme.com, Dallas.Acme.com, L100.Reno.com, L101.Reno.com, L102.Reno.com, L201.Dallas.com, L202.Dallas.com and L201.Dallas.com.
