Best Practices for Active Directory-Integrated DNS

This is the second article in our series about Active Directory. In this article, we’ll discuss DNS and Active Directory integration and give you some best practices for your DNS server administration.

DNS is an important prerequisite of Active Directory. Without it, Active Directory will not function, or should we say, you can’t install or promote a server to a domain controller without having a DNS server either locally on that server or somewhere else on your network. It is the primary name resolution service for Active Directory.




The DNS service provides domain name services and the DNS database can be integrated with Active Directory or stored in an external database. Each DNS server has at least one DNS zone. A DNS zone is a contiguous part of the DNS domain name space, meaning it is a portion of a namespace and not a domain. In Active Directory there are a number of different zone types. We’ll list them all below:

Primary Zone.

The primary zone is the only zone that can be edited since it is the original data source for all domains in the zone. Typically, a backup of the primary zone is made to a secondary zone.

Secondary Zone

A secondary zone is read-only and cannot be edited. It contains a copy of the DNS data copied from the master DNS server’s primary zone

Active Directory Integrated Zone

The Active Directory Integrated zone stores its data in Active Directory and it does not need DNS zone files. It is in fact an authoritative primary zone and the data gets replicated to other domain controllers as part of Active Directory’s replication process. A benefit if this type of zone is that it uses the security features of Active Directory.

Stub Zone

Stub zones were introduced with Windows Server 2003 and contain only the resource records that are required to identify the authoritative DNS servers for the master zone.

The two main zones that are used in Active Directory (or Windows Server 2003 and up) are the primary and Active Directory-integrated zones. You could say that an Active Directory-integrated zone is an improved version a primary DNS zone because it can use multi-master replication to other DNS servers in the domain and use the security features of Active Directory. We’ll list some of the main advantages Active Directory-integrated zones have over standard primary DNS zones:


  • Active Directory replication is faster, which means that the time needed to transfer zone data between zones is far less.
  • The Active Directory replication topology is used for Active Directory replication, and for Active Directory-integrated zone replication. There is no longer a need for DNS replication when DNS and Active Directory are integrated.
  • Active Directory-integrated zones enjoy the security features of Active Directory.
  • The need to manage your Active Directory domains and DNS namespaces as separate entities is eliminated; reducing in turn reduces administrative overhead.
  • When DNS and Active Directory are integrated; the Active Directory-integrated zones are replicated, and stored on any new domain controllers automatically. Synchronization takes place automatically when new domain controllers are deployed.

DNS Server Best Practices

Let’s look at some best practices for DNS Server Administration that provide the foundation for a good DNS environment. We’ll focus on server administration, but keep in mind that there are specific client settings that you should look into as well.


Use Active Directory integrated DNS zones

Active Directory will automatically replicate DNS information to other DNS servers that are installed on Active Directory Domain Controllers.


Configure all DNS Servers to have either local copies of all DNS Zones or to appropriately forward to other DNS servers.

This makes sure that all DNS Zones are available from all DNS servers simplifies administration and prevents name resolution problems


Configure all DNS Zones to replicate to All DNS servers in the Active Directory forest when possible.

Replicating DNS zones across domains will allow all domains in the forest to share DNS information and make (again) administration easier. You do want to secure each DNS zone if decentralized administration and security is of 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.


Use Active Directory-Integrated DNS Forwarders instead of standalone DNS Forwarders

This makes sure that the information is replicated to all the DNS servers in the domain or the forest. It is recommended you set this to replicate to the Forest. This will save you work in the future.


Use AD Integrated Stub Zones instead of standalone DNS Domain Forwards

Stub Zones can automatically be replicated to all DNS servers when AD integrated Zones are used and work similar to DNS forwards. DNS Stubs will decrease administration when DNS servers are replaced.


Configure Zone Transfers using the Name Servers tab, and configure the Zone Transfers tab to transfer and notify the Name Servers of changes. Do not use Zone Transfers to IP Addresses

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. When you only use the Zone Transfers tab and configure transfer by IP Address can result in loss of information if a DNS server is replaced.


Create a DNS Server Hierarchy for DNS forwarders

Configure all the DNS Servers to forward requests towards 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. This creates a tree-like hierarchy.


Configure all DNS Servers to use the Root Hints to forward external requests directly to the Internet

This is actually 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.


Configure all DNS Servers to be a Caching DNS Server in addition to hosting DNS Zones

This is the default configuration for Windows 2003 DNS servers. Leaving this to the default setting will speed up DNS queries.


Use CNAME records to create an alias in DNS. Avoid using A (host) records for aliasing.

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.


Do not manually create Host (A) records in the same domain with records where dynamic Host records are created via DDNS

Instead create a sub-zone and create the Host records there and create an Alias (CNAME) record in the appropriate zone. The sub-zone can be used to document the device type as server, router, appliance, etc., this provides a well-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.


Set the Aging/Scavenging properties for all Zones to be 7 days

Even though the default number of days is set to 7 to scavenge dynamically registered DNS Host records, it is not applied to any zone. To configure this you must select Scavenge stale resource records to enable this policy on every zone. Enabling this policy allows dynamically created Host records to be automatically removed from the zone.


There are many other things to consider when configuring your DNS server administration to be as optimal as possible. To cover everything here is beyond the scope of this article but we’ve provided you with the most basic best practices for your Active Directory-Integrated DNS structure.

In our next article in this series we’ll talk about Replication Topology in Active Directory.