Author: NetworkAdminKB.com
Created: 2007-07-18
Modified: 2009-02-15
This is a collection of real world DNS best practices for mid to large size companies. Small companies that are growing should also follow these practices to save them growth pains in the future. The basic idea behind most of the best practices provided is to limit server and client side DNS administration. As an added benefit following these practices will reduce the amount of documentation required on your DNS environment by making DNS self documenting. You may also notice that these practices build upon each other. By doing one it makes the next one possible or easier to do.
Server Administration Best Practices Part I
These are the foundations and building blocks for all the DNS best practices.
1) Use Active Directory integrated DNS zones
a. Why? Active Directory will automatically replicate DNS information to other DNS servers that are installed on Active Directory Domain Controllers.
2) Configure all DNS Servers to have either local copies of all DNS Zones or to appropriately forward to other DNS servers.
a. Why? Making sure that all DNS Zones are available from all DNS servers simplifies DNS administration and prevents DNS name resolution problems. As a company changes over time what was once an isolated DNS zone can suddenly become used in many locations. Simply being proactive and appropriately configuring DNS will reduce your administration over time.
b. Options for configuring all DNS servers to find all DNS zones. Ordered in preference from the top down.
i. Configure all DNS Zones to replicate to All DNS servers in the Active Directory forest when possible.
1. Why? Replicating DNS zones across domain lines will allow all domains in the forest to share DNS information easier and ultimately make DNS administration easier. Simply secure each DNS zone as needed if decentralized administration and security is a concern. Replicate to “all Domains in the Forest” even if you have only one domain, this will save you time in the future should a second domain be added.
ii. Use Active Directory (AD) Integrated DNS Forwarders instead of normal standalone DNS Forwarders when possible.
1. Example: dnscmd /ZoneAdd domain.com /DsForwarder 10.10.10.10 [/DP /forest]
2. Why? Using AD integrated forwarders will replicate the information to all the DNS servers in the domain or the forest (/DP /Forest). This will simplify DNS administration. Replicating to the forest (/DP /Forest) is preferred.
iii. Use AD Integrated Stub Zones instead of standalone DNS Domain Forwards.
1. Why? Stub Zones can automatically be replicated to all DNS servers when AD integrated Zones are used and they work similar to DNS forwards. Using DNS Stubs will decrease administration as DNS servers are replaced overtime. Using standalone server based DNS Domain Forwards can require configuration of every DNS server, increasing DNS administration.
iv. Configure Zone Transfers by using the Name Servers tab, and configuring the Zone Transfers tab to transfer to and notify the Name Servers of changes. Do not use Zone Transfers to IP Addresses.
1. Why? Using the Name Servers tab to configure the Zone Transfer creates a better documented DNS server. An Active Directory integrated DNS Server will replicate the Name Server information to each DNS server. As DNS servers are added or replaced this information is kept, using only the Zone Transfers tab and transferring by IP Address can result in lost information when a server is replaced.
v. Create a DNS Server Hierarchy for DNS forwarders.
1. How? Configure all the DNS Servers to forward requests toward a centralized location if a query for any DNS Zone is not found on the local DNS server. Each new DNS server will have some new zones that can be searched. If you drew a picture of this solution the end result should be diagram that looks like a tree showing the location of every DNS Zone and how it would be resolved from every location.
2. This is an older way of doing DNS forwarding that still works, but is cumbersome to manage in large environments. Proper planning of every DNS zone is required. This is not a recommended way of doing DNS forwarding, but is provided as an historical option.
3) Integration with other DNS servers at other companies.
a. Many of the techniques above (DNS Hierarchy excluded) lend themselves to sharing one or more DNS zones with other companies.
b. Best Practice Suggestions: Use AD Integrated DNS forwarders to resolve DNS Zones across independent companies/forests, or replicate DNS Zones onto all DNS servers if the companies are owned by the same parent company and in the same forest.
4) Configure all DNS Servers to use the Root Hints to forward external requests directly to the Internet.
a. Why? This is the default configuration for Windows 2003 DNS servers. Leaving this enabled simplifies DNS administration and speeds DNS queries to the internet. This is also the recommended practice from Microsoft and many Internet Service Providers (ISP). The older practice was to have internal DNS servers forward requests to external DNS servers provided by the local ISP. While this worked there were several problems with it.
i. Some ISPs could not guarantee proper performance, fault tolerance, or availability of their DNS servers.
ii. This requires that every DNS server be manually configured to forward All other DNS domain requests to external IP addresses. This increases your DNS Administration.
1. Some people may argue that a DNS Hierarchy for forwarding external DNS requests to one (or more) internal DNS servers that can then access to the Root Hints (or even forward to the ISP DNS servers) is the recommended solution because of firewall concerns or other internal issues. However, this simply leads to more DNS administration. From a security perspective there is little difference between letting one DNS server talk externally and more than one. Also, our focus here is on simplified administration and best practices regarding DNS not the firewall.
5) Configure all DNS Servers to be a Caching DNS Server in addition to hosting DNS Zones.
a. Why? This is the default configuration for Windows 2003 DNS servers. Leaving this enabled simplifies DNS administration and speeds DNS queries.
6) Do NOT manually create a Host (A) record as an alias to an existing IP address that has a Host record. Instead use an Alias (CNAME) record.
a. Bad Practice Example: 10.10.10.10 A server1.domain.com already exists, and you want to create 10.10.10.10 A www.domain.com to be more user friendly.
b. Best Practice Example: Create www.domain.com CNAME server1.domain.com
c. Why? For easier administration only one Host record needs to be updated to update all Alias records associated with it. This practice also provides a better documented DNS system over time, and keeps PTR records from getting improperly configured with Alias names.
7) Do NOT manually create Host (A) records in the same domain with records where dynamic Host records are created via DDNS. Instead create a SubZone (or new Zone) and create the Host records there, then create an Alias (CNAME) record in the appropriate zone for user friendly DNS searches.
a. Bad Practice Example: domain.com is used for DDNS registration, do not manually create a Host (A) record in this Zone.
b. Best Practice Example: domain.com is used for DDNS registration, serv.domain.com is used for manual Host records, then place an Alias record in domain.com to allow easy client configuration.
c. Why? The SubZone (or new Zone) can be used to document the device type as server, router, appliance, etc., this provides a better documented DNS environment. This also allows manual DNS host records to be easily monitored and maintained. As equipment is replace over time easier DNS maintenance is achieved.
8) When first installing a Windows 2003 forest create _msdcs.domain.com as a separate DNS zone.
a. Why? This zone can then have its own settings different from other zones. This zone is the primary zone needed to maintain Active Directory and as such may have special needs or considerations in your company.
9) Set the Aging/Scavenging properties for all Zones to be 7 days (default).
a. By default the number of days is set to 7 to scavenge dynamically registered DNS Host records, but it is not applied to any zone. You must manually select Scavenge stale resource records and click OK to enable this policy on every zone.
b. Why? Enabling this policy allows old dynamically created (not manually created) Host (A) records to be automatically removed from the zone. This eases DNS administration as workstations and servers are removed from the domain.
Client Administration Best Practices
10) Configure every client (workstation and server) with a primary and secondary DNS server (via DHCP is preferred).
a. Why? This allows DNS server replacement, patching, problems, etc. to be addresses without affecting the clients.
b. Location of primary vs. secondary DNS Servers?
i. While this is important to many variables need to be addresses at each company independently. Review the Microsoft standard practices for more information on this concern.
11) Use the Default DNS Client configuration, do not manually set DNS search orders, or special DNS registrations, etc.
a. Why? Using the default DNS client configuration reduces client side administration; in large environments this is very useful. Use zone consolidation and DNS zone migration techniques to reduce the number of DNS zones needed to be searched to achieve this. See the Server Best Practice for 3 tier domain names for more information.
12) Use DHCP to add a DNS domain name to the DNS search order list (if needed).
a. Why? Instead of using a group policy or manually setting the DNS each order you can use DHCP to assign one extra DNS search domain. By default the DNS search order on any client will be the following:
i. Primary Computer DNS Suffix (Set in the Computer Name Change dialog)
ii. Local DNS Suffix for this connection (Manually set or set via the DHCP domain name option)
iii. Parent domains of the primary DNS Suffix are then appended.
b. By using the default DNS configuration and proper DHCP administration you can simplify DNS client administration over time.
13) Have one default DNS search order list per domain, and keep a centralize list of all DNS search orders for comparison.
a. Why? Using the default DNS client settings will automatically result in one DNS search order per domain, but it could be done with a manually controlled DNS search order list as well. By keeping a list of the DNS search order for each domain you can see what the “common” searched domains are, allowing easier sharing of DNS information between domains. For each domain identify the “common” DNS zone that will be used to share information with all domains, and the “local” DNS zone(s) that can be used to share information within the local domain.
14) Only one or two DNS Zones are required for good client side DNS search order lists. One “common” (parent) DNS zone that is searched by all DNS clients across all domains and one “local” DNS zone that is searched by the local domain clients only.
a. Why? All other internally owned and managed DNS domains that are searched are not really needed, and can be consolidated into existing domains. This is because ultimately all searched DNS domains are equal. This means it doesn’t matter in what DNS zone the record is “found” because we a performing a search and not using FQDNs. The goal of having “common” vs “local” DNS zone searches is to logically manage DNS records and simplify access to the resource by name. Having one DNS search zone would also be appropriate if managing access by FQDN name is not important.
Server Administration Best Practices Part II
These are easier to comprehend after the Client Side Administrative Practices are read and understood.
15) When starting a new forest consider using a 3 tier Domain Name (third.second.com) using the second level domain name to indicated location, region, hemisphere, or simply windows OS, etc.
a. Best Practice Examples: company.northamerica.com, company.windows-northamerica.com, sistercompany1.easternregion.com, sistercompany2.easternregion.com, etc.
b. Why? By default the clients are configured to Append parent suffixes of the primary DNS suffix. Using a third level domain name adds one more zone to search, the second “higher” logical level. Having sister companies in the same forest that are not in a parent-child relationship but have a common unified DNS relationship makes using the default DNS client configuration easier, because they now both automatically search the “common” second level domain.
c. Example: company1.northamerica.com and company2.northamerica.com are sister companies with corresponding domains. There is not a northamerica.com domain, but since both companies include that DNS parent in their DNS name they have created a unified DNS implementation.
16) Configure only one DNS zone to query WINS servers (per client search order). Preferably this should be the “common” DNS zone available to all DNS clients in any domain when possible.
a. Why? Having DNS query WINS for computer names is a nice feature to have. However, sometimes you want to know that WINS was used to resolve the name via DNS. The following two administration options for using WINS with DNS are available.
i. By using a separate DNS zone we can more easily determine that WINS resolve the name for us. This involves a little more client side configuration.
ii. However, using the “common” DNS zone available to all domains can help reduce DNS administration by reducing the creation of Alias records in the “common” DNS zone for shared servers….WINS will simply resolve it for us.
b. Option 1 Example: If you manually control the DNS search order or if you use DHCP to assign a DNS domain name you could add wins.domain.com to each DNS search order and then configure the wins.domain.com zone to query WINS.
c. Option 2 Example: Assuming default DNS search order of “append parent” and all domains share domain.com in the DNS search order. By configuring domain.com to search WINS, all domains can resolve server names like server1, server2, server3, regardless of which DNS domain they are registered in.