Active Directory Integrated DNS Zones: Explained

4.3K

Windows Server hosts that have been promoted to domain controller can store DNS zone data in the Active Directory Domain Services (ADDS) rather than in a zone text file. This is known as an AD-integrated DNS zone. Integrated DNS zones can only be created on an AD domain controller that has the DNS server role installed.

In most AD environments, DNS is a critical dependency for authentication, service location, and domain operations. AD-integrated DNS zones simplify DNS management by storing zone data directly in AD and leveraging its replication and security model.

Advantages of Active Directory integrated DNS zones

• DNS zone data is transferred to other DNS servers in the domain and forest using the standard Active Directory replication mechanism rather than classic zone transfer method. Multi-master replication mode used for AD-integrated zones, meaning that any domain controller can write updates to the zone. When a DNS zone is replicated, only the changes between the domain controllers are transferred, not the entire zone.
• Secure update mode is supported for integrated zones. In this mode, only authorized clients can update their records in the DNS zone.
• In order to restrict the access to the records in the DNS zone, Access Control Lists are used.
• The DNS zone and the DNS records are stored in the Application Directory Partition in the AD database.

When not to use AD-integrated DNS Zones

While AD-integrated DNS zones provide many benefits, keep in mind that there are cases where they may not be the best choice:

• Non-Windows DNS environments. In case your infrastructure includes non-Microsoft DNS servers (such as BIND or Infoblox), AD-integrated zones are not suitable because they rely on AD replication instead of standard DNS zone transfers.
• DMZ or perimeter networks. In isolated or security-sensitive environments (DMZ), we don’t recommend you to use AD-integrated zones. It requires DCs and AD connectivity, which may violate security boundaries.
• Need for standard DNS zone transfers (AXFR/IXFR). In case you need to replicate DNS data to external DNS servers using standard zone transfer mechanisms, it’s better to use traditional primary/secondary zones.
• Public DNS zones. AD-integrated zones are designed for internal use within AD. Note that public-facing DNS zones should typically be hosted on external/dedicated DNS infrastructure.

In such cases, you should consider using standard primary/secondary DNS zones instead of AD-integrated zones.

Key decision rules

• You should use AD-integrated zones for internal AD DNS
• You should use standard primary/secondary zones for external/cross-platform scenarios

Replication Scope Differences

When creating an AD-integrated DNS zone, you must choose how the zone will be replicated across DCs. This setting defines where the DNS data is stored in AD and which DCs will receive it.

• DomainDNSZones (Domain-wide replication). The DNS zone is replicated only to DCs within the current domain. You should use this option in most cases to limit replication traffic and keep DNS data scoped to a single domain.
• ForestDNSZones (Forest-wide replication). The DNS zone is replicated to all DCs across the entire forest. You should use this option only if the zone must be available across multiple domains.

The replication scope determines which AD partition stores the zone:

• `DC=DomainDNSZones,DC=domain,DC=com`
• `DC=ForestDNSZones,DC=domain,DC=com`

Best practice

• You should use DomainDNSZones in most environments to reduce replication traffic
• You should use ForestDNSZones only when multiple domains need to resolve the same zone

Keep in mind that Forest-wide replication increases replication traffic across all domains (so you should use it only when necessary).

Create a new integrated DNS zone in your AD domain

1. Open the DNS Manager snap-in (dnsmgmt.msc);
2. Connect to a domain controller, right-click Forward Lookup Zones, and select New Zone;
   

   

3. Select the Primary zone type and enable the option Store this zone in Active Directory (available only if DNS server is a writable domain controller).
   
   

   Note. Secondary and Stub DNS zones cannot be AD-integrated (because they rely on standard zone transfers (AXFR/IXFR), not AD replication). However, they can coexist with AD-integrated zones and are usually used for delegation, integration with external/non-Windows DNS, and cross-environment name resolution.

   

   
   
4. Here you need to specify the replication scope for the zone (Domain/Forest). See the replication scope explanation above before making your decision;
   

   

5. Type the zone name: ad.example.com;
   

   

6. Choose whether you want to allow only dynamic updates. For Active Directory, it is recommended that you always use the Allow only security dynamic updates option;

   

7. Click Next > Finish and a new primary AD-integrated zone will appear in the DNS console;

   

   
   This zone will be automatically replicated to all of the other domain controllers in the AD.

Note. DNS changes in AD-integrated zones are replicated using AD replication and don’t happen instantly. Keep in mind that in multi-site environments, replication latency may cause temporary inconsistencies between DCs. This means that newly created/updated records may not be immediately available in all locations.

AD-integrated zones are stored in one of the following ADDS LDAP partitions: DC=DomainDNSZones,DC=contoso,DC=com or DC=ForestDNSZones,DC=contoso,DC=com. This depends on the replication scope you have selected for the zone. The selected replication scope directly determines which of these partitions is used.

Hint. In the same way, you can create an AD-integrated reverse lookup DNS zone.

Connect to and manage the AD directory partition that stores integrated zones using ADSIEdit

You can connect to and manage the AD directory partition that stores integrated zones using the ADSIEdit console.

1. Open the adsiedit.msc MMC snap-in;
2. Select Connect to > Connection Point > type a Distinguished name: DC=DomainDNSZones,DC=contoso,DC=com

   

3. Expand your domain DN > CN=MicrosoftDNS. An object of the dnsZone class must be created in this section for each DNS-integrated zone.
   

   

4. When you expand the dnsZone object, you will see a list of records for that DNS zone in the form of separate dnsNode objects;
5. You can use the built-in attribute editor for AD objects to manually change the parameters of any DNS zone record;
   Warning. In production environments, you should avoid editing DNS records directly with ADSIEdit unless absolutely necessary. Keep in mind that incorrect changes can corrupt DNS data stored in AD (you should use standard DNS management tools whenever possible).
   

   

Create an integrated primary DNS zone with PowerShell

You can also create and manage AD-integrated DNS zones using PowerShell console (which is useful for automation and scripting scenarios):

Add-DnsServerPrimaryZone `
    -Name "ad.example.com" `
    -ReplicationScope "Domain" `
    -DynamicUpdate Secure `
    -PassThru

You can remove an AD-integrated DNS zone with the following command:

Remove-DnsServerZone -Name "ad.example.com" -Force

Add the reverse lookup zone AD-integraded zones

Add-DnsServerPrimaryZone -NetworkID "10.24.0.0/24" -ReplicationScope "Forest"

List integrated DNS zones

Get-DnsServerZone|where IsDsIntegrated -eq True

Wrapping up

AD-integrated DNS is the recommended choice for AD because it automatically syncs changes across all servers, offers better security, and is managed easily as part of the directory itself.

However, they are not suitable for all cases. You should avoid using them in mixed DNS environments, DMZ networks, or when standard DNS zone transfers are required.

The important thing is to always carefully choose the replication scope and use secure dynamic updates to ensure a reliable and secure DNS infrastructure.