DNS and NetBIOS Name Resolution to Create External, Realm and Forest Trusts
Published: July 23, 2009
Updated: July 24, 2009
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
Before you create a domain or forest trust, there are name resolution requirements that must be met so that you can establish the trust successfully. These requirements ensure that the forest or domain can resolve the address of the domain controllers in the target forest or domain to support the creation and ongoing operation of the trust.
For all trusts except trusts across forests, the New Trust Wizard and its command-line equivalents allow you to refer to domains that participate in a trust by their Domain Name System (DNS) or NetBIOS domain names. For trusts across forests, you must use a DNS name.
Although Windows Internet Name Service (WINS) has been used to support trusts in the past, the focus of this topic is configuring DNS to create and operate a trust.
DNS Name Resolution
You can use DNS to resolve names for a forest or domain for which you are attempting to establish a trust. Most DNS names are fully qualified, which means that there is a dot (.) in the name between the forest root domain and a top-level domain, such as .com, .gov, and .local. There are rare instances in which Active Directory domains are created with a single-label DNS domain name, such as “contoso”. When you type in the name of a remote domain in the New Trust wizard that you are expecting to be resolved by DNS, then you should enter the DNS name of the remote domain (not its NetBIOS or WINS name).
The DNS servers that the domain controllers in one forest use may not be able to resolve the DNS names for domain controllers in another forest, and the other way around. If the DNS names for trusting domains are not registered with an Internet Register, then the DNS Servers used by DCs in the trusted domain cannot use forwarders to resolve the DNS queries needed to support the trust. There are two common DNS configurations that you can choose from when you establish DNS name resolution between domains and forests:
Secondary zones with zone transfers enabled
Note Stub zones can be used to resolve DNS names, but are less commonly used than secondary zones and conditional forwarders; therefore, they are not covered in this document.
Using Conditional Forwarders vs. Using Secondary Zones
There are several conditions you should take into account when choosing between conditional forwarders or secondary zones with zone transfers (to resolve DNS names that your DNS Servers are not authoritative for). When you decide whether to use conditional forwarders or secondary zones with zone transfers enabled, there are several considerations you should take into account before choosing either configuration.
The benefit of using a conditional forwarder is that it is much easier to configure and troubleshoot than a zone transfer. The process of configuring a conditional forwarder is straightforward: all you need to know is the DNS domain name of the domain that houses the DNS server that you are configuring to forward requests and the IP address of the target DNS server.
However, a conditional forwarder is not an efficient way to keep a DNS server that hosts a parent zone aware of the authoritative DNS servers for a child zone. If you use a conditional forwarder, whenever the authoritative DNS servers for the child zone change, the conditional forwarder setting on the DNS server that hosts the parent zone must be configured manually with the IP address for each new authoritative DNS server for the child zone.
Using a secondary zone with zone transfers enabled is beneficial because this configuration maintains a list of all the authoritative DNS servers for the secondary copy of the zone, and the list is updated as DNS servers are added and removed from the target forest or domain. Secondary zones also host a full copy of the DNS zone.
The drawbacks to using secondary zones with zone transfers enabled are that this configuration is much more complicated to configure and maintain and you do not have the direct, point-to-point contact with a DNS server in the target forest or domain as you do with a conditional forwarder. In addition, with secondary zones you expose hosts to IP address mappings for all hosts in the zone. This can expose the domain or forest to security risks due to unauthorized access.
You can use conditional forwarders to route queries between the domains or forests for which you are establishing a forest or domain trust. Conditional forwarders route names to a specified DNS server in the target domain or forest for queries that the conditional forwarders cannot resolve.
For example, if you establish a two-way, forest trust between the fabrikam.com and contoso.com forests, you configure a conditional forwarder in the fabrikam.com forest to route queries that it cannot resolve to a name server in the contoso.com forest. You then configure a conditional forwarder in the contoso.com forest to route names that it cannot resolve to the fabrikam.com forest.
For more information about conditional forwarders, see the following:
Using forwarders (http://go.microsoft.com/fwlink/?LinkId=157391)
How to Configure Conditional Forwarders in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=157393). This post not only explains how to configure a conditional forwarder in Windows Server 2008, it also explains how to configure a conditional forwarder in Windows Server 2003.
The following flowchart explains how to troubleshoot instances in which conditional forwarders are not correctly performing name resolution to the target forest or domain. The flowchart shows a one-way, transitive, outgoing, forest trust between forest A (trusting) and forest B (trusted). Simply put, users in forest B have access to specified resources in forest A. To complete the steps in the following flowchart, use the credentials of a member of the Domain Admins group. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Secondary Zones with Zone Transfers Enabled
Zone transfers replicate DNS databases across a set of DNS servers. If you want to establish a trust between two forests, you can configure the DNS server in the trusting domain or forest to host a secondary zone of the trusted forest, with zone transfers enabled.
For example, if you want to establish a two-way trust between the fabrikam.com and contoso.com forests, you configure the DNS server in the fabrikam.com forest to host a secondary zone of the contoso.com forest’s namespace, and the reverse. After you configure the secondary zones in each forest, you then allow zone transfers between the two forests. For more information about secondary zones or zone transfers, see the following:
Adding a Secondary DNS Server to a Zone (http://go.microsoft.com/fwlink/?LinkId=157397)
Understanding zones and zone transfers (http://go.microsoft.com/fwlink/?LinkId=157398)
Understanding Zone Types (http://go.microsoft.com/fwlink/?LinkId=157399)
DNS Resource Records That Are Required for Secondary Zones
There are two DNS resource records that must be registered properly on the DNS server that hosts the secondary copy of the trusted domain or forest:
Service (SRV) resource record (_ldap._tcp.dc._msdcs.<computer account domain>)
Host (A) resource record
These records must be in place and registered properly before you establish a domain or forest trust.
The following flowchart explains how to troubleshoot instances in which secondary zones with zone transfers enabled are not correctly performing name resolution to the target domain or forest. The flowchart shows a one-way, transitive, outgoing, forest trust between forest A (trusting) and forest B (trusted). Simply put, users in forest B have access to specified resources in forest A. To complete the steps in the following flowchart, use the credentials of a member of the Domain Admins group. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).