DNS best practices
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Best practices
Enter the correct e-mail address of the responsible person for each zone you add to or manage on a DNS server.
This field is used by applications to notify DNS administrators for a variety of reasons. For example, query errors, incorrect data returned in a query, and security problems are a few ways in which this field can be used. While most Internet e-mail addresses contain the at sign (@) when used in e-mail applications, this symbol must be replaced with a period (.) when entering an e-mail address for this field. For example, instead of "administrator@microsoft.com", you would use "administrator.microsoft.com".
For more information on configuring the responsible person for a zone, see Modify the start of authority (SOA) record for a zone.
Be conservative in adding alias records to zones.
Avoid using CNAME resource records (RRs) where they are not needed to alias a host name used in a host (A) resource record. Also, ensure that any alias names you use are not used in other RRs.
DNS allows an owner name of a CNAME resource record to be used as the owner name of the other types of resource records, such as NS, MX, and TXT resource records.
For more information, see Managing resource records.
When designing your DNS network use standard guidelines and, wherever possible, follow preferred practices for managing your DNS infrastructure.
DNS was designed to provide a level of fault tolerance for resolving names. If possible, you should have at least two name servers hosting each zone.
If you are using Active Directory, use directory-integrated storage for your DNS zones for increased security, fault tolerance, simplified deployment and management.
By integrating zones, you can simplify network planning. For example, domain controllers for each of your Active Directory domains correspond in a direct one-to-one mapping to DNS servers. This can simplify planning and troubleshooting DNS and Active Directory replication problems because the same server computers are used in both topologies.
If you are using directory-integrated storage for your zones, you may select from the different replication scopes that replicate your DNS zone data throughout the directory. If your DNS infrastructure must support Windows 2000 DNS servers, you will use the directory-integrated storage method that replicates DNS zone data to all domain controllers in a domain. If your DNS infrastructure is composed of DNS servers running Windows Server 2003 only, you may also select from replication scopes that replicate your DNS zone data to all DNS servers in the Active Directory forest, all DNS servers in a specified Active Directory domain, or all domain controllers specified in a custom replication scope.
For more information on directory-integrated DNS zone storage and replication options, see DNS zone replication in Active Directory.
Any DNS server hosting a directory-integrated zone is a primary DNS server for that zone. This enables a multimaster model where multiple DNS servers may update the same zone data. A multimaster model eliminates a single point of failure associated with a conventional single-master DNS topology, where updates may only be done to a single DNS server for a given zone.
One of the important benefits of directory integration is the support for secure dynamic update of the names within a zone. For more information, see Dynamic update.
Consider the use of secondary zones to assist in off-loading DNS query traffic wherever it makes sense.
Secondary servers can be used as backups for DNS clients. This allows you to use secondary servers as a means to load balance DNS query traffic on your network and reserve your DNS-enabled primary servers for use only by those clients that need them to perform dynamic registration and updates of their A and PTR RRs.
For more information about the use of secondary or caching-only servers, see Using secondary servers and Using caching-only servers.
If you are planning a large DNS design, such as for a large Internet service provider (ISP) that supports the use of DNS, review the following Request for Comments (RFC) documents published by the Internet Engineering Task Force (IETF).
RFC Title 1912
Common DNS Operational and Configuration Errors
2182
Selection and Operation of Secondary DNS Servers
2219
Use of DNS Aliases for Network Services
You can obtain these RFCs from the RFC Editor Web site. This Web site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.
To see the most current RFCs related to actively defining the DNS standard, see DNS Extension (dsnext) at the Internet Engineering Task Force Web site, which discusses dynamic update, notify, zone transfers, security, and adjustments to address the requirements of IPv6 addressing. Also, see DNS operations (dnsop) at the Internet Engineering Task Force Web site, which provides guidelines for the implementation of DNS by administrators of DNS domains.
Note