This post discuses the design and placement of DNS for Active Directory. These design imperatives are my own and not Microsoft’s although they are derived from my experiences for twenty years as an Engineer with Active Directory design starting with the NT5 Server Beta in 1998.
These imperatives do not reflect the use of third-party DNS which by definition separates DNS from Domain Controller placement. They also do not consider AD implementations where there is only a single forest. Active Directory 2003’s addition of the forest DNS partition makes these implementations simple. So, here we discuss multi-forest Microsoft DNS design imperatives and their interpretation.
Design imperatives:
DNS should be available at all sites containing clients (servers or workstations).DNS should be in a Highly Available (HA) configuration if possible.Domain Controllers should not be deployed at sites solely for the support of DNS.Secure updates should be possible if required.The DNS Infrastructure should have as few Secondary\Stub zones as possible and as little conditional forwarding as possible.The DNS infrastructure should be a simple as possible without violating the other design imperatives.
Lets consider two multi-forest designs.
Design one: Three Forests: northamerica.mydomain.com, europe.mydomain.com, asia.mydomain.com. All are single domain. mydomain.com is a virtual root. There are trusts between the forests. There are at least 3 sites, one in each geographic location.
The optimal solution here is that each forest contains it’s own DNS. There are either stub zones, secondaries, or conditional forwarding for the other two forests in each forests DNS. Stub zones, secondaries, and conditional forwarding are different. None is better than the other. Which one you utilize would depend on how you weigh those differences.
So why not put DNS in only one forest – say northamerica.mydomain.com perhaps because that is the corporate headquarters? That satisfies imperatives 4, 5 and 6. But it violates imperative 3 which is higher (lower numbered imperatives have a higher priority) because it forces the deployment of northamerica.mydomain.com DCs in Asia and Europe.
Design two: Three Forests: students.mydomain.com, resources.mydomain.com, facultystaff.mydomain.com. All are single domain. mydomain.com is a virtual root. There are trusts between the forests. There are three school sites, in different geographic locations: Chicago, Phoenix, Boston. All forests are required at each site for the school to function autonomously.
The optimal solution here is completely different. DNS can be placed in the resources.my domain forest. It can host the zones for facultystaff.mydomain.com and students.mydomain.com forests. Trusts allow secure updates.
So why not put DNS in each forest like design one? Because that violates imperative 4 and 6. It is more complex requiring secondary\stub zones or potentially conditional forwarding. Unlike design 1 imperative 3 is NOT violated because each school location already requires Domain Controllers from all forests to function. So, imperative 6 – make it a simple as possible can be accomplished because it does not violate imperatives 1-5.
Conclusion: Although design 2 is seldom used, it fits many multi-forest situations single or multiple site. In these situations the design 1 approaches requirements for stub zones, secondary zones, and conditional forwarding means that more effort is required to manage and debug DNS.
I have been involved it two centralized Microsoft DNS (design 2) scenarios. Both happened to be single site. Interesting, one of the Microsoft DNS clients has evolved away from the initial design over the years adding an additional forest with DNS effectively giving them two DNS infrastructures to manage with forwarders secondaries, etc. IMO that has not gone well.
I was also involved with a client using a third-party DNS infrastructure. One of their justifications for the third-party DNS scenario was that is produced a simplified DNS infrastructure which is the goal of these design imperatives.