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.
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) Configure DNS Zones that are used by Active Directory domains to accept Dynamic Updates.
a. Why? Allowing Dynamic DNS (DDNS) updates on DNS zone used by the Active Directory domain is the default/recommended configuration. This configuration is fundamental to having good communication between all devices in the AD domain.
b. It is recommended that only Secure updates be allowed to DNS Zones that are used by AD Domains.
7) 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: server1.domain.com A 10.10.10.10 already exists, and you want to create www.domain.com A 10.10.10.10 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.
8) 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.
9) Configure DNS Zones that are NOT used by an Active Directory domain NOT to accept Dynamic Updates
a. Why? Typically DNS Zones that are not tied to Active Directory Domains are external zones that are used internally as well, and configured with internal IP Addresses. This configuration is typically called a Split DNS Implementation. Dynamic updates to these DNS Zones is not recommended, but if implemented would normally require Non-Secure DDNS updates. This will allow any device to update and overwrite records. This can lead to issues if important records like MX and SMTP hosts are accidently over written. Because of the Non-Secure nature it is easier to accidently (or maliciously) overwrite important records.
i. You should manually control these zones. The records in them tend to be non-server name specific (i.e. www, smtp1, mail1, etc), and lend themselves to using CNAME records to manage rather than Host (A) records and IP Addresses.
10) Use the Text (TXT) Record to document specific records.
a. You can create a TXT record with the same name as any A record. A TXT record can be used to record important information regarding the purpose of the record, its history, contact information, etc. This makes for a well maintained DNS environment without maintaining external documentation.
server1.domain.com A 10.10.10.10
server1.domain.com TXT “IIS Server used by several applications, owner John Doe”
b. While you cannot create a TXT record with the same name as a CNAME record, you can create a standard so these records are documented and the documentation is easy to find. For example add “-txt” the end of the record name so the records sort together.
finanicials.domain.com CNAME server1.domain.com
finanicials-txt.domain.com TXT “finanicials.domain.com is used by peoplsoft”
11) 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.
12) 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
13) 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.
14) 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.
15) Use Dynamic DNS (DDNS) registrations to update the Primary DNS Zone when the OS supports it.
a. Why? By default all Windows 2000 and higher clients support dynamic registration, and leveraging this reduces client and server side administration. If DDNS is not working on the client work to resolve the issue on the client (or server), do NOT use a “workaround” by configuring manual Host records in DNS.
i. The Primary DNS Zone on the client is usually the AD Domain the client is a member of. This is the only DNS Zone that should be updated using DDNS.
16) Configure DHCP to register DDNS records (to the AD DNS Zone) for clients that do not support DDNS
a. Why? By default DHCP for clients that do not support DDNS, DHCP will attempt to register Host and PTR records for the client’s Primary DNS zone. Usually the Primary DNS zone is the Active Directory domain the computer is a member of. This practice allows for good communication between all devices in the AD domain.
b. Make sure to add all the DHCP servers to the DNSUpdateProxy group.
17) 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.
18) 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.
19) 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 DNS zones. 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.
20) 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.
21) 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.
Article ID: 4, Created On: 9/15/2011, Modified: 9/15/2011