My take on Stub Zones vs Conditional Forwarders

I'm lucky/unfortunate enough (delete depending on the day) to architect and manage a geographically distributed Active Directory environment consisting of multiple domains and forests. The forests are connected using a variety of AD trusts and they all hinge on our DNS infrastructure.

I've typically been a big advocate for AD integrated stub zones rather than Conditional Forwarders due to the ability to centrally manage them by virtue of their AD integration whether it be Domain or Forest wide scope and also their ability to update the name servers belonging to the DNS zone.

To be clear, stub zones contain three record types (SOA, NS and A) which reference the name servers responsible for the source DNS zone. Periodically the SOA, NS and A records are updated from the Master Server list for the particular zone. When a query is performed against the server hosting and matching the Stub Zone, the server references the NS and then A records contained in the zone to direct the query to a suitable name server for an answer. This is perfectly acceptable when the source zone is located on a number of Domain Controllers in a central location such as a data centre but may add complications when the Domain Controllers are geographically distributed, such as in Hub/Spoke topologies where the spokes consist of DCs in remote offices connected to small/slow links. While answers to name queries are cached by the server hosting the stub zone, attempting to perform name lookups across such links may introduce delays or add to the traffic on the links. Microsoft indirectly acknowledge this eventuality by virtue of the behaviour of stub zones in the Technet - Contrasting stub zones and conditional forwarders but in the context of security and not being able to directly influence server to server connections when compared to the static configuration of Conditional Forwarders.

Stub zones do not provide the same server-to-server benefit because a DNS server hosting a stub zone in one network will reply to queries for names in the other network with a list of all authoritative DNS servers for the zone with that name, instead of the specific DNS servers you have designated to handle this traffic.

Based on the above statements, interpretation and my experience, my recommendations are as follows..

Conditional Forwarders - Great for server to server connections for name resolution such as specifically defining server A will always forward to server X,Y,Z for contoso.com when contoso.com is a hosted on a geographically heavy distributed AD infrastructure or where not all sites are routable from server A. The obvious downside with all Conditional Forwarders is maintaining the list of forwarders on a per server basis.

Stub Zones - Ideal when referencing DNS zones hosted on resource forests/infrastructures which are hosted centrally, fully routable/reachable from the server hosting the stub zone. Obvious benefits are that the name server list is maintained as part of the stub and the zone can be AD integrated to ensure that it is available throughout the Domain or Forest. Be careful when creating a stub zone which references a zone which is hosted on geographically distributed infrastructure.