DNS, which is responsible for resolving domain names to IP addresses, isn’t just the name resolution system that underpins the global Internet—it’s also a critical component in Windows Active Directory (AD) for locating network resources. But despite the ubiquitous nature of DNS in Windows networking over the past decade as a replacement for Microsoft’s proprietary WINS, DNS is a complex hierarchical system that many junior administrators find difficult to grasp.
In this article, we’ll look beyond a single-forest/single-domain AD structure, where DNS configuration is relatively straightforward, and investigate how DNS works in a more complex AD design. Along the way, we’ll introduce some of the new DNS concepts in Windows Server 2008 R2.
Active Directory and DNS Integration
To help us understand how DNS integrates with AD, let’s configure an AD structure that’s commonly deployed in midsized and large organizations. We’ll create a single forest with two domains, as Figure 1 shows. The first domain will be what’s often referred to as an empty root, or just root, domain. An empty root domain sits at the top of the AD hierarchy and, as its name suggests, doesn’t contain any resources. This type of domain gives organizations more flexibility and better separation of security roles than a single forest/single domain. The second domain will sit below our empty root and is therefore a child domain; it will function as the main domain for our organization, where resources (e.g., groups, user and computer accounts) are located.
Figure 1: Single forest with two domains
We start by running Dcpromo on the first server to create the forest and empty root domain. Log on to Server 2008 R2 as an administrator. Make sure that you’ve given the server an appropriate name, such as DC1, and set an IP address, subnet mask, and default gateway on the server’s NIC. You can leave the NIC’s DNS settings empty and let Windows add a local address.
Run Dcpromo from the Start menu and create a new forest and domain called ADcompany.com. Note that I appended AD as a prefix to the company name to keep the internal and external DNS namespaces separate. ADCOMPANY will become the NETBIOS name for the domain. Even though the domain is intended for internal use only, it’s important to register the ADcompany.com domain on the Internet to ensure that clients can’t be accidentally redirected to a device that’s outside the organization’s control. It’s also common to use the AD.company.com namespace hierarchy, where AD becomes the NETBIOS name for the domain. In this case, assuming company.com is already registered by the company on the Internet, no additional action is required.
On the Additional Domain Controller Options screen, make sure the DNS server option is selected. After you click Next and Dcpromo begins to validate the selected options, you’ll receive a warning stating that a delegation can’t be created because the authoritative parent zone can’t be found. In other words, Dcpromo can’t find an authoritative DNS server (i.e., a server that holds a primary or secondary copy of zone data for the .com domain), where it can create a delegation zone for the ADcompany.com domain.
A DNS zone holds all resource records for one part of the namespace, such as ADCOMPANY or COM. Because this is our internal root AD domain, a delegation record in the public COM zone isn’t necessary and you can safely ignore this warning. We’ll understand more clearly what delegation means when we create our child domain.
Testing with Dcdiag
After Dcpromo finishes, reboot the server as prompted. To make sure that everything is working as expected with our new domain, open a command prompt and run Dcdiag. A series of tests will be carried out that should pass with success if DNS and other critical AD components are configured correctly.
Before running Dcdiag, you might want to clear the System and DFS Replication event logs to prevent the tool from reporting various failures because of error warnings logged during the domain setup process. For example, DFS replication errors are typically shown when Dcdiag is run for the first time on a new domain controller (DC)—however, they don’t necessarily indicate a problem with DNS, which is often the source of replication failures. After the event logs are cleared, run
dcdiag /test:dfsrevent
This command should pass the test successfully.
Until you configure an appropriate time source, you’ll get W32tm (Windows Time service) errors in the Dcdiag tests for the root domain’s DC. For information about configuring the Windows Time service, see the Microsoft article “How to configure an authoritative time server in Windows Server”.
Root Hints
Now that AD DNS is in working order, if the DC has a connection to the Internet, the installed DNS server should let us resolve Internet domain names even though we haven’t configured any forwarders or added an IP address for an ISP’s DNS server on the DC’s NIC settings. The DNS server includes root hints that point to the top-level DNS servers on the Internet so that it can resolve queries for names that it isn’t authoritative for and doesn’t already have in its cache.
To see the root hints that are loaded from the cache.dns file, open DNS from Administrative Tools on the Start menu. In the DNS console, right-click the DNS server in the left pane and select Properties from the menu. In the server properties dialog box, select the Root Hints tab, as Figure 2 shows.
Figure 2: Viewing root hints
You might also encounter situations, such as the requirement to use a service like OpenDNS for web content filtering, in which you set up a forwarder for Internet name resolution instead of relying on root hints. When designing your DNS infrastructure, remember that if forwarders are configured on a DNS server, they’re used for name resolution before root hints.
Iterative and Recursive Queries
Requests made by the DNS server to resolve names using root hints are iterative, meaning that a best answer will be accepted—which might be a referral to a name server lower down the hierarchy that can resolve the query definitively. This is in contrast to the Windows DNS client, which sends recursive queries to a DNS server, requiring a definitive answer or an error stating that the resource doesn’t exist. Recursive queries are typically sent by DNS clients or forwarders.
Configuring a Child Domain
Now that internal and Internet name resolution have been tested and are working in our root domain, it’s time to add a child domain, called HR (HR.ADcompany.com), where all our resources will be located. Log on to the second Server 2008 R2 machine as a local administrator and make sure it has an appropriate name, such as DC2. Assign an IP address and subnet mask, then set the primary DNS server for the server’s NIC with the IP address of your DC in the root domain. When we run Dcpromo, the tool needs to locate the root DNS domain and DC, so a DNS server that can answer those queries must be configured.
Before starting, we can run
dcdiag /test:dcpromo /dnsdomain:HR.ADcompany.com /ChildDomain
to ensure that everything is configured properly for Dcpromo to promote this server to a DC for the domain specified using the /dnsdomain switch.
Figure 3: Creating a new domain in an existing forest
Now run Dcpromo from the Start menu, this time opting to create a new domain in an existing forest. On the Network Credentials screen, enter the forest domain (ADcompany.com) and an account that’s a member of the Enterprise Administrators group in the root domain, as Figure 3 shows. In the Name the New Domain dialog box, enter the Fully Qualified Domain Name (FQDN) for the root domain (ADcompany.com) and single-label name for the new child domain (HR), as Figure 4 shows. In the Additional Domain Controller Options dialog box, select DNS server. For the rest of the wizard, accept the default settings.
Figure 4: Naming the new domain
Reboot the server when prompted, and run Dcdiag on the HR DC to ensure that everything’s working as expected, following my earlier advice for running Dcdiag. Open a command prompt and run
ipconfig /all
Note that the server’s NIC primary DNS is set to the local server address, and the root domain’s DNS server IP address is shifted to act as a secondary DNS server.
Delegation and Forwarding
Still working from the command prompt, make sure that you can ping the DC in the root domain, using either the DC’s single-label name (DC1) or FQDN (DC1.ADcompany.com). You should also be able to ping an Internet domain name from the child domain’s DC, assuming it has Internet connectivity. From the root domain’s DC, make sure that you can ping the DC in the child domain. The DNS server in the child domain refers queries for resources in ADcompany.com to a forwarder, which is automatically configured when Dcpromo runs. To see this configuration, open the DNS server console on the child domain’s DC from Administrative Tools on the Start menu. In the DNS console, right-click the server in the left pane and select Properties from the menu. In the properties dialog box, select the Forwarders tab; you’ll see that the server is configured to send all queries that it can’t resolve to the root domain’s DNS server. Both internal and Internet queries are forwarded; this is different from a conditional forwarder, which is configured to forward queries that can’t be resolved locally only for a specific namespace.
Conversely, on the root domain’s DNS server you’ll find a delegation record (sometimes referred to as a delegation zone) for the HR domain. Again, this record was configured as part of the Dcpromo process for the child domain’s DC and lets the root domain’s DC locate resources in the child domain. Open the DNS console on the root domain’s DC; in the left pane, expand DNS Server, Forward Lookup Zones, ADCompany.com. Click the HR delegation zone at the bottom of the tree. In the right pane you’ll see a host (A) record for the child domain’s DNS server. Delegation and forwarding are the default mechanisms in Windows Server for enabling resolution up and down a branch of a contiguous DNS namespace, as Figure 5 shows.
Figure 5: Delegation and forwarding
DNS Devolution
DNS devolution is a feature of the Windows DNS client. It isn’t new to Server 2008 R2 or Windows 7, but it includes some changes to improve security. From the child domain’s DC, we can ping resources in the root domain without specifying the FQDN (i.e., we can ping DC1 without having to enter DC1.ADcompany.com). The same is true from the root domain’s DC; we can ping DC2 successfully without the FQDN.
By default, devolution attempts to resolve a single-label name by appending domains from the client’s Primary DNS Suffix (PDS). So a machine that belongs to the AD.contoso.com domain will first try to resolve a machine name as DC1.AD.contoso.com and then DC1.contoso.com. It won’t try to resolve DC1.com because the default devolution level is 2, which is the default setting in Windows prior to Server 2008 R2 and Windows 7. In some situations, a default level of 2 can create a security concern if DNS clients try to resolve FQDNs that are outside the control of the organization. For example, consider the following set of queries when the devolution level is set to 2: DC1.HR.company.co.us, DC1.company.co.us, DC1.co.us. The final query, DC1.co.us, is outside the organization’s control and could result in a client accidently connecting to a malicious machine on the Internet.
In Server 2008 R2 and Windows 7, the default behavior is to set the devolution level to the number of labels in the Forest Root Domain (FRD) if the PDS ends with the FRD. Our PDS is HR.ADcompany.com and our FRD is ADcompany.com—so according to the default behavior in Server 2008 R2 and Windows 7, devolution is enabled and the level is set to 2 for our DNS clients. Microsoft issued an update to change the DNS devolution behavior in Windows Vista, Windows XP, and Windows 2000. For more information about the update, see the Microsoft article “Post-installation behavior on client computers after you install the DNS update”.
DNS Suffix Search List
If we add a third domain to our forest, finance.ADcompany.com, DNS devolution might not be enough to resolve single-label names of resources in HR.ADcompany.com from clients in the FINANCE domain. Single-label name resolution works from the FINANCE domain if you try to ping resources in the HR domain when all devices are located on the same physical subnet. This is because Windows will broadcast for the IP address if it can’t successfully resolve the name from the machine’s local cache or configured DNS server.
If you use Nslookup to test DNS resolution, you’ll see that without a DNS suffix search list, you must enter the FQDN of the resource located in the HR domain, because as a tool for testing DNS name resolution, Nslookup uses DNS exclusively. To test DNS with Nslookup, open a command prompt from the Start menu, type
nslookup
and press Enter. At the new prompt, enter the FQDN or single-label name that you want to resolve and press Enter. Nslookup will either return the IP address or report a lookup failure.
If resolving single-label names across all AD domains is important for your environment, you can configure the DNS suffix search list on all devices with a list of primary DNS suffixes that you want to resolve (in our case, finance.ADcompany.com, HR.ADcompany.com, and ADcompany.com). If a DNS suffix search list is configured for a DNS client, DNS devolution is automatically disabled. A search list can be configured manually (select Change adapter settings in Windows 7’s Network and Sharing Center) for each NIC on the DNS tab in the Advanced TCP/IP Settings dialog box for the IPv6 and IPv4 properties. Alternatively, a search list can be configured using a comma-delimited list in the DNS Suffix Search List setting under Computer Configuration, Policies, Administrative Templates, Network, DNS Client in Group Policy (for Windows Server 2003 and XP or later).
Similarly, if we add a new DNS zone, secure.HR.ADcompany.com, on the HR DNS server for the purposes of creating a separate zone for important server resource records that should be secured with DNS Security Extensions (DNSSEC), we need to deploy a DNS suffix search list so that DNS clients can locate resources in the new zone by single-label name. A new DNS zone is required in this case, because DNSSEC doesn’t support dynamic updates—the ability of client host records to automatically update on a DNS server—which is the default and desired setting for DNS zones where host records are stored for client computers. Under normal circumstances, IP addresses of server computers don’t change, so secured zones can be manually administered.
Conditional Forwarding
We can help our two child domains, finance.ADcompany.com and HR.ADcompany.com, resolve cross-domain queries more efficiently, without the need to send a recursive query to the DNS server in the forest root, by configuring a conditional forwarder on the DNS servers in both child domains. Conditional forwarders take priority over server-level forwarders and are more efficient in that we can set queries for specific domain suffix(es) to be sent to a predefined DNS server, as Figure 6 shows.
Figure 6: Conditional forwarding
The DNS server in HR.ADcompany.com will contain a forwarder that sends all queries for finance.ADcompany.com to the primary DNS server for the FINANCE domain, and vice versa. To configure a conditional forwarder, open the DNS console on the DC in the HR domain from Administrative Tools on the Start menu. In the left pane of the DNS console, expand the DNS server, right-click Conditional Forwarders, and select New Conditional Forwarder from the menu. In the New Conditional Forwarder dialog box, enter finance.adcompany.com in the DNS Domain box. Under IP addresses of the master servers, enter the IP address or server name of the DNS server in the FINANCE domain, as Figure 7 shows, and press Enter. Click OK to complete the procedure. Repeat the process on the DNS server in the FINANCE domain, but enter HR.ADcompany.com in the DNS Domain box and the IP address of the DNS server in the HR domain.
Figure 7: Creating a new conditional forwarder
DNS Complexities
It’s impossible to cover all bases in one article—for example, there are two additional zone types, secondary and stub zones, that you can use to improve performance in complex DNS deployments, as well as new Server 2008 R2 features, such as DNSSEC. But having a basic understanding of how DNS and AD work together as an integrated solution will help you design new AD deployments and troubleshoot any problems that occur. Most importantly, when testing a new or existing AD infrastructure, make sure that for each domain you can ping resources in all other trusted domains. In addition, deploy delegation and conditional forwarding to enable resolution between namespaces. These basics will help you use DNS more effectively in complex AD environments.
