Many have asked, when do I use a Stub zone, a Conditional Forwarder, or a Forwarder? Or better, what’s the difference?
I thought to put this simple comparison together compiled from past posts in the Technet Forum.
Partner Organization DNS Resolution: What should I use, a Stub, Conditional Forwader or Forwarder?
Secondary zones are read only copies “copied,” or “zone transferred” from a Master zone. This makes the zone data available locally (as read only, of course), instead of querying a DNS server across a WAN link. However, in many cases Secondaries are not used due to many limitations and security concerns, such as exposing all DNS zone data that a partner may not want to divulge.
In addition, Secondaries can’t be AD integrated, and the zone data is stored in a text file. So you would have to manually create a copy on all of your DNS servers.
Organizations own their own AD zones. When business partners need to resolve data at a partner’s organization, there are a few options to support this requirement. Years ago, prior to Stub or Conditional Forwarders, there weren’t many options to handle this other than to use Secondary Zones and keep copies of each others zones via zone transfers. While the solution worked well in regards to name resolution, it was not the best security-wise, due to trust level between partners, because zone data is fully exposed at the partner. This became a security concern because the partner is able to see all of their business partner’s records. When the zone was transferred to partners, who knows what they were doing with the information. If the information was made public, attackers would have a field day with all of the IPs for the networked devices.
When stub zones were made available, it became a solution to overcome this security issue. What is also beneficial about Stubs, is you can AD integrate them instead of manually creating a Stub on each indivdual DC. THis way the zone will be available domain or forest-wide, depending on replication scope.
However, some may say due to the fact that the SOA records are included in the zone file, it may be a concern that the SOA and NS data is exposed. In such high security concerns, the better solution would be to use a Conditional forwarder.
This option is heavily used, and many look at them as the best regarding security concerns with zone data exposure, because no data is exposed. This option has worked very well in many environments.
With Conditional Forwarders, no information is being transerred and shared. The only thing you would need to know is one or more of your business partner’s DNS server IPs to configure it, and they don’t have to be the SOA, rather any DNS server that hosts the zone or that has a reference to the zone.
However, it does require open communication and let each other know when their DNS server IPs may change, because you must manually set them.
Windows 2003 introduced Conditional Forwarders, but it did not have the option to make it AD Integrated. If you have 10 DNS servers, you must create the Conditional Forwarder on each server manually. The AD integrated option was added to Windows 2008 or newer DNS servers, so you don’t have to manually create them on each DNS server. THis way the Conditional Forwarder will be available domain or forest-wide.
Parent-Child DNS Zone Delegation
Delegation can be used in a situation where a child domain host their own DNS zone. Therefore in the forest root domain, you would create a delegation zone with the IPs of the DNS servers in the child domain. This is normally performed when the child zone have their own administrators. It’s also useful they do not have access to “see” all of the forest root DNS records.
Comments, corrections and suggestions are welcomed.