 |
|
| Windows Server Tips: |
|
|
|
ACTIVE DIRECTORY ADMINISTRATION
Best practices for DNS structure design
Gary Olsen, Contributor
03.06.2007
Rating: -4.30- (out of 5)
|
When working with the domain name system (DNS) for Active Directory, there are several key components to be aware of regarding client configuration, server configuration and monitoring. Another aspect that should not be overlooked, however, involves DNS structure and design.
When designing the DNS structure, keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect AD performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
Know the basic principles
Here are the main points to keep in mind when designing the DNS structure:
However, in my experience, the method of having each DNS server pointing to itself causes more problems than just AD replication issues. That is why I agree with the recommendation that has all DNS servers pointing to a single name server for preferred DNS.
I recall one admin who called about a Systems Management Server (SMS) issue. In the process of troubleshooting, I noticed his DNS servers pointed to themselves for DNS. After a long discussion, I finally convinced him to have the DNS servers point to a single primary. He called back the following day and reported that his clients had never had better name resolution performance. I've seen that scenario many times and, even today, as a general rule, I always recommend pointing all DNS servers to a single primary as the "preferred DNS server."
Use Active Directory integrated zones.
This is a great implementation of a domain name system, and it's obviously on Microsoft's best practice list. Its advantages include:
Each domain should have its own DNS delegation.
In a parent/child domain environment, there should be an authoritative name server in each
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
child domain. All clients (workstations, servers, DCs) in that domain should point to this name server for a DNS. To make this work, you must create a delegation for the child domain in the root domain and add the IP address of all DNS servers in the child domain to that delegation. In addition, in the child domain's name servers, they must forward back to the parent's DNS servers.
You can find the principles of forwarding and delegation in any good DNS book or go to Microsoft's DNS white paper.
I often find that this is only partially implemented. For example, the delegation record is created, but the admin forgets to forward back to the root domain. It's amazing how long this situation can exist without raising any flags. In fact, I've seen cases where they start adding secondary zones and other tricks to patch it together, or sometimes they simply live with it.
Here are the benefits of configuring each domain to have its own domain name system delegation:
Delegate the _msdcs zone in a multiple domain environment.
This zone holds important records such as CName (alias) records used for AD replication and global catalog (GC) records. In a multiple domain forest, these two record types only exist in the _msdcs zone that is in the forest root domain. Other domains (even if they are not child domains to the forest root) do not contain these records. This means that DCs for any other domain in the forest must go back to the name servers in the forest root domain to resolve CName records for replication. The same goes for clients looking for a GC for authentication, Outlook Global Address List lookups, etc. If they can't get to those name servers, then it all breaks. Delegating the root zone's _msdcs zone to child domain name servers will put the GC and CName records closer to the requestors and increase the efficiency of name resolution.
Name servers in remote sites.
This is a tricky one. As I noted previously, many environments make each DC a DNS server (for ADI zones) and make sure that there is a name server in each site. In sites that don't have a DC, you can install a DNS on a member server and make a secondary copy of the zone.
That said, there are large AD forests that use very few DNS servers. Hewlett-Packard, for example, has a root domain, HP.com, and three child domains: Americas, EMEA and AsiaPacific. They have delegated zones for the child domains from the root. For each of these geographical zones, there are only about three DNS name servers -- not one per site, not one per DC. Of course this depends very much on your network infrastructure. You don't want to do this if you have poorly connected or unreliable network links. However, you could use three name servers for the general population, and then add name servers in those poorly connected sites as needed.
It is important to review your DNS structure. In times of change and growth, mistakes can be made, often unknowingly. Using the DCDiag tool is a good quick health check, and reviewing event logs for DNS-related errors via MOM or other tools is also helpful. However, I highly recommend a high-level review of the DNS structure by comparing it to best practices to proactively ensure that Active Directory is running smoothly.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.
|
|
|
|
|
|
|
|
|
| TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of . |
|
| |
All Rights Reserved, , TechTarget |
|
|
|
|
|
