Thank you for the opportunity to help you with your question!
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. ATXT 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.
Please let me know if you nea case for torture by michale levined any clarification. I'm always happy to answer your questions.