DNS Design Options in a Multi-Domain Forest – How to create a Parent-Child DNS Delegation, and How to Configure DNS to create a new Tree in the Forest
Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer
Original Publication: 10/1/2010
10/4/2010 – Added a variation of the decentralized option. Even though it’s not really used in the industry as far as I know, yet it;s another option.
10/14/2010 – Changed Title to reflect the content of the material
9/22/2011 – Added info on configuring DNS to create a new tree in an existing forest
In an Active Directory forest with more than one domain, there are a number of choices on how to design the DNS resolving infrastructure.
This is basically a summary of how to design a DNS infrastructure to handle parent and child domains. Keep in mind, with any DNS design, you must insure that everything in the forest can resolve any name and resource everywhere in the forest.
There are a number of ways to do this, but it comes down to two basic designs: Centralized and Decentralized.
In a centralized mode, simply setting the parent zone to forest wide replication, install DNS on any DC, whether in the parent or in the child, and the zone will be available everywhere. When a child resource (DC, member server, client, etc), registers, a child folder for the child domain name will be created under the parent zone name in DNS. All records for the child will be populated into this folder. In this design, child resources can simply use their own local DNS servers and the zone is availablle, as well as all other child domains.
Decentralized with a Parent-Child Delegation
Other designs involving decentralization, such as with global infrastructure where there may be local legal regulations involved, you may want to allow them to handle their own DNS servers and their own zones. In such a decentralized model, the parent zone is set to domain-wide replication, and the child zones are delgated to the DC/DNS servers in the child domains.
Decentralized but all Child Domain Resources only use the Forest Root DNS Servers
I haven’t seen this design scenario in the field as of yet, rather see it more in a classroom or lab setup, but it’s another option, yet not recommended. Basically the same as the above but without a delegation. All child domain resources will only use the root’s DNS servers. However in such a design, if the child domains are across WAN links, if the WAN link goes down, the whole child domain will be useless until it’s up again.
How to create a DNS Parent-Child Delegation
By default, the parent.com zone’s Replication scope is set to domain-wide. This is the middle button in the zone’s replication scope properties that says “All DNS Servers in the Domain”. This means it is only available to the parent.com’s DC/DNS servers, and not to any of the child domain’s DC/DNS servers. So if you were to set the child domain DCs to use themselves as DNS, they will not find their own zone.
To overcome that, as mentioned above, you have two basic parent-child design choices:
1. Centralized – No delegation
If you want to use themselves for DNS in the parent and child domains, and to simplify it, you can change the parent.com zone’s Replication scope to Forest DNS Servers.
This way the zone will be available to all DC/DNS servers in the whole forest. The following link shows how to check and/or change replication scopes, that is if this is the desired design based on your company’s requirements.
How to change replication scopes:
2. Decentralized – Parent-Child DNS Delegation
If you want the child domain’s admins to have control of their own resources, including DNS for their own domain, you can delegate the child zone to the child domain’s DC/DNS servers. To do this, you would first create a child zone under the child zone’s DC/DNS servers called child.parent.com. Then in the parent domain’s DNS server, right click parent.com, choose New Delegation, type in ‘child’ (without the quotes), and provide the child domain’s DC/DNS servers names and IP addresses. Do not change the parent zone’s Replication scope, assuming it’s still set to the default domain-wide replication scope.
Then in the child domain’s DC/DNS servers, configure a forwarder to the parent domain’s DC/DNS servers. The following link has info for you to read up on concerning these steps.
How To Create a Child Domain in Active Directory and Delegate the DNS Namespace to the Child Domain:
Specific information regarding how to configure Child domain delegation and DNS configuration
Assuming you have the parent AD domain (the forest root) and zone already created and functional, and you’ve already ran dcpromo on a machine to make it a child domain DC.
- When you first run dcpromo to create the first child domain DC, you’ll want it to use the forest root domain’s DNS server to simplify things and get the ball rolling. This will allow it to register into a subfolder (the child zone) under the parent zone.
- Make sure the parent DCs are only using their own DNS servers in their IP properties. If they show the local loopback, 127.0.0.1, which is what dcpromo puts in there, change it to the actual IP addresses. Do the same with the child DCs for now, meaning they are using the forest root domain DCs for DNS for the time being.
- Make sure the replication scope on the parent domain’s zone, we’ll call domain.com, is set to Domain wide (the middle button). This puts it in the DomainDnsZones application partition for the parent domain. If set to Forest wide (the top button), it will cause a major issue with delegation. This is because of the delegation design. You don’t want the zone forest wide in a parent-child delegation.
- Create a zone on the child domain DC/DNS server. For this example, we’ll call it child.domain.com. The replication scope should be set to the domain-wide in the child domain, which of course once again, is the middle button which puts it into the DomainDnsZones app partition.
- Reverse zone – This is optional, but recommended. Create a reverse zones on the parent for each subnet in the parent domain’s location, and set the replication scope to DomainWide (the middle button). DO NOT create a delegation for this zone.
- Create a reverse zone on the parent for the child domain’s location, and set the replication scope to DomainWide (the middle button). Create a delegation for this zone to the child.
- Make sure the zones all allow updates, whether Secure Only, or Secure and Unsecure.
Follow the steps in the following article to create the delegation:
How To Create a Child Domain in Active Directory and Delegate the DNS Namespace to the Child Domain:
Make sure you configure a forwarder from the child DNS servers to the parent DNS, and then optionally, but recommend, a forwarder from the parent to your ISP’s DNS.
Change the DNS IPs on the child DCs to use their own DC’s as their DNS servers.
Since there is more than one domain, it is HIGHLY recommended to have a minimum two DCs in for each domain. The reason is two-fold, one because of redundancy, the other is because of the IM role conflict on a GC in a multidomain forest. If you are going to have a GC at the child domain, especially if it is in a remote location, just keep in mind of this required rule. On one of the DCs in each domain you will make one of the DCs a GC, and move the Infrastructure Master role from the GC to the non-GC. This is functional basics of domain design and FSMO role placement and the way this specific role works, or rather doesn’t work it is a GC.
Then again, it’s now recommended to just make all DCs in a forest a GC, no matter how the DNS resolving infrastructure is designed. This way it alleviates issues with the IM/GC conflict. Many large installations have been using this design successfully without issues. Matter of fact, Exchange likes it.
Global Catalog vs. Infrastructure Master:
“If a single domain forest, you can have all DCs a GC. If multiple domains, it is recommended for a GC to not be on the FSMO IM Role, unless you make all DCs GCs”
Simple Step by Step to create a Parent-Child DNS Delegation:
If not sure about the above section, or you’ve found it too complicated to follow, try the following steps:
- Open DNS on one of the DCs in the forest root domain.
- Expand your domain.com zone
- Right click the domain name, choose New Delegation
- Type in the child domain name, such as “child1” and not the FQDN (such as child1.domain.com)
- You will notice the bottom part of the window will now show the FQDN based on the child name you typed.
- Click Next
- Now type in two of the DNS servers IP addresses for the Nameservers of the child domain.
- Click through until done.
- Make sure the child domain DCs and all machines in the child domain, are only using the DC/DNS servers in that child domain and no other domains.
Video tutorial to create a Parent-Child Delegation:
How to create a zone delegation in a Windows 2008 DNS server:
Now create a Condition Forwarder on the child domain DNS to the Forest Root domain’s DNS servers.
Windows 2008: Create a Conditional Forwarder video:
Windows 2003: Create Conditional Forwarder vide (scroll upto timeline 3:00, where he shows how to create a conditional forwarder)
Creating Search Suffixes
Keep in mind, with additional child domains or trees, you may need to configure Search Suffixes for each child to resolve names in other child domains. This can be set using a GPO, location can be found in:
Using GPOs to configure DNS Search Suffixes
At this time Win2k3 DHCP cannot assign a DNS suffix search list. That said,
you can assign a connection specific DNS suffix (option 015), which is added
to the search list. But, you can assign only one DNS suffix per client.
There is a GPO that assigns a custom DNS suffix search list to XP and Win2k3 clients which can be assigned by Win2k DCs if you upgrade the GPOs using a Win2k3 or XP client.
If you have Windows 2000, this option does not exist in a GPO. You must upgrade to at least Windows 2003 to have this option.
Upgrading Windows 2000 Group Policy for Windows XP:
After the GPOs have been upgraded, expand the Group policy to here to apply
the custom search list.
Manually adding suffixes
If you have one Suffix to add:
- Go into NIC properties,
- IP4 Properties
- DNS tab
- In the box that says “DNS SUffix for this connection:” type in the suffix
- Click ok
No restart required
If you have more than one Suffix to add:
- Go into NIC properties,
- IP4 Properties
- DNS tab
- Click on the Radio Button that says, “Append theses DNS Suffixes (in order):”
- Click Add, and type in the suffix
- Click Add for each one, and type it in
- Click ok
- No restart required
In some designs and scenarios, you may want to kill the devolution tickbox, have a look at this article:
It refers to the registry key controlled by GPO – this will over-ride the standard internal registry setting at:
You could also use populate the regkey by script if you didn’t want to pull in the extra ADMX GPO template… and this will force your client to JUST resolve hosts on internal.domain.com or whichever zone you want. For example:
Windows Registry Editor Version 5.00
Or use the command:
reg add HKLM\system\currentcontrolset\services\tcpip\parameters /v “SearchList” /d “domain1.com,domain2.com” /f
The key thing to observe with manually creating a suffix lists, (from KB275553, link provided below), is that if you distribute a suffix list then it blocks devolution and use of primary or connection-specific suffixes… so write that list carefully!
How to configure a domain suffix search list on the Domain Name System clients
Using DHCP Option 015 To Populate the Connection Specific Suffix (just for the interface that’s getting a DHCP IP address)
I would like to point out that DHCP 015 Option is the “Connection Specific Suffix.” This means that the connection that receives a DHCP config from DHCP, will get this suffix as the Search Suffix.
Just to illustrate what I mean, you can test it by setting a suffix in Option 015 that’s different than the domain’s zone name. First, if the AD domain’s zone name is ‘domain.com,’ then the Primary DNS Suffix become ‘domain.com’ when you join the machine to the domain. The default Search Suffix becomes the default Search Suffix. Now in DHCP Option 015, configure ‘domain1.com’ as the connection specific suffix. Now go to the workstation and run a /release and /renew. You will now see the suffix you configured in 015 in addition to the machine’s default.
So if you are trying to simply add one additional suffix, this will work for your DHCP clients. However, if you’re trying to add more than one additional suffix, and/or if you have numerous statically configured machines (such as servers), then a GPO will be the better alternative, which Tiger and JM already suggested.
More info on Search Suffixes:
How to configure a domain suffix search list on the Domain Name System clients (Windows 2000)
New group policies for DNS in Windows Server 2003 (and newer)
Manage DNS suffix configuration through Group Policy
Manually Configuring Query Settings in NIC properties (Search Suffixes)
Configuring DNS to Create a New Tree in an Existing Forest
1. Create the zone for the new tree, on the forest root’s DNS server. Configure the zone’s replication scope Forest Wide.
2. Point DNS on the new machine prior to promoting it, to the existing forest root DNS server that you just created the zone on in step# 1.
3. Promote the machine introducting a new tree.
4. After the machine has been promoted, and the necessary records have been created, install DNS on the new server.
5. Walk away for about 30 minutes and allow the zone to auto-populate through replication. DO NOT MANUALLY CREATE the zone or any other zone. It will do so automatically through AD replication.
Your next steps depends on your DNS Design choice whether you want to keep the zone replicated forest wide to all DCs in all domains, or just in the new tree’s domain. The choice comes down to whether you ahve centralized administration or decentralized administration. See the above to help make your decision.
If you’ve chosen to keep the zone in the DomainDnsZones (“All DNS servers in the Domain <New Tree’s Domain.local> zone (the middle button), follow these steps:
6. Once it’s replicated, open DNS console on the new domain controller in the new tree. Right click the zone name, properties, then change the Replication Scope in the tree’s domain name zone’s properties to the “All DNS servers in the domain <newtreeName.local> zone. This is the middle button. This puts it in the DomainDnsZones replication scope in the new tree’s Domain. This will also remove it from the ForestDnsZones partition.
7. Once again, wait for about 30 mintues and allow replication to occur. You can test to see if replication has completed by going back to the forest root’s DNS server, refresh the console. If you see the new tree’s domain name zone disappear, then it has completed. Go back to the new tree’s DC’s DNS server console and hit the refresh button.
8. Go back to the forest root DNS server. You can now create the stub zone on the original forest root DNS pointing to it. Set the stub zone to DomainDnsZones.
9. Create a Conditional forwarder from the new tree DNS server to the forest root DNS server. You can also opt to create a Stub zone (preferrable) to the forest root DNS server and AD integrate the stub zone in DomainDnsZones so it will be available on the new tree domain.
10. Make sure you add Search suffixes on each machine in the original forest root for the new tree, and vice-versa.
If you’ve chosen to keep the zone in the ForestDnsZones Partition choosing “All DNS servers in the Forest” (the top button), do the following:
Make sure you add Search suffixes on each machine in the original forest root for the new tree, and vice-versa.
There are a number of ways to design DNS in an infrastructure. Which is the best one? It all depends on your design specs, requirements, local legal regulations, or simply if you want a centralized or decentralized design.
All comments or corrections are welcomed.