Observe the following suggestions to prevent common configuration errors:

• 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, this field can be used to report query errors, incorrect data returned in a query, and security problems. Although most Internet e-mail addresses contain the at sign (@) when used in e-mail applications, you must replace this symbol with a period (.) when typing an e-mail address for this field. For example, instead of [email protected], you would use administrator.reskit.com.
• When designing your DNS network, use standard guidelines and wherever possible, follow preferred practices for managing your DNS infrastructure.
• Make sure that you have at least two servers hosting each zone. They can host either primary and secondary copies of the zone, or two directory-integrated copies of each zone.
• If you are using Active Directory, use directory-integrated storage for your zones.
  In an integrated zone, domain controllers for each of your Active Directory domains correspond in a direct one-to-one mapping to DNS servers. When you troubleshoot DNS and Active Directory replication problems, the same server computers are used in both topologies, which simplifies planning, deployment, and troubleshooting.
  Using directory-integrated storage also simplifies dynamic updates for DNS clients that are running Windows 2000. When you configure a list of preferred and alternate DNS servers for each client, you can specify servers corresponding to domain controllers located near each client. If a client fails to update with its preferred server because the server is unavailable, the client can try an alternate server. When the preferred server becomes available, it loads the updated, directory-integrated zone that includes the updates that the client made.
• If you are not using Active Directory integration, correctly configure your clients and understand that a standard primary zone becomes a single point of failure for dynamic updates and for zone replication.
  Standard primary zones are required to create and manage zones in your DNS namespace if you are not using Active Directory. In this case, a single-master update model applies, with one DNS server designated as the primary server for a zone. Only the primary server, as determined in the SOA record properties for the zone, can process an update to the zone.
  For this reason, make sure that this DNS server is reliable and available. Otherwise, clients cannot update their A or PTR resource records.
• Consider using secondary or caching-only servers for your zones to offload DNS query traffic.
  Secondary servers can be used as backups for DNS clients, but they can also be used as the preferred DNS servers for legacy DNS clients. For mixed-mode environments, this enables you to balance the load of DNS query traffic on your network and, thus, reserve your DNS-enabled primary servers for Windows 2000–based clients that need primary servers to perform dynamic registration and updates of their A and PTR resource records.

The IETF has published several Requests for Comment (RFCs) that cover best practices for DNS, as recommended by DNS architects and planners for the Internet. You might find the following RFCs useful, especially if you are planning a large DNS design:

• RFC 1912, “Common DNS Operational and Configuration Errors”
• RFC 2182, “Selection and Operation of Secondary DNS Servers”
• RFC 2219, “Use of DNS Aliases for Network Services”