Boswell's Q&A

Rooted in DNS

Many AD problems stem from DNS. Here's a quick DNS configuration best practices checklist.

• By Bill Boswell
• 03/15/2005

Bill: We are planning on building a root domain from scratch at our HQ called "root.com" and then having separate child domains for Europe and North America. Can you provide some "best practice" steps and information on configuring DNS prior to installing AD for an environment such as this? I'd be very appreciative.

On a side note, our new 2003 AD structure will eventually include Exchange Server, but it will not start out that way. Will it cause any problems if we go ahead and extend the schema for the forest and domain ahead of time? If extending the schema will not be a problem, is it best to do it before or after the service packs are applied to the OS?
—Steve

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Steve: It's a great idea to get your DNS infrastructure configured and tested prior to deploying Active Directory. Nearly all AD problems have a root cause in DNS.

In your example, you specified a DNS domain name of Root.com. I'm assuming that you're actually going to use another name that you've registered to assure uniqueness. I'll use root.com in all the examples.

Start with a Standalone DNS Server
Start by installing a standalone DNS server running Windows Server 2003. You'll eventually integrate DNS into Active Directory and use the domain controllers as DNS servers, but installing a separate DNS server at first gives you more control over the process in case something goes wrong.

You don't need server-class hardware for this machine. You'll only be using it temporarily. I often use a virtual machine (using either VMware or Microsoft Virtual Server) to act as the initial DNS server in a new forest.

Before you install DNS on the server, change the Server Properties to include a DNS suffix. Access the Server Properties window by holding down the Window key and tapping the Pause key. Select the Computer Name tab then click Change then click More.

Assign a DNS suffix of Root.com to the server. This creates a Registry entry called NVDomain that Windows concatenates to the host name (NVHost) to get a Fully Qualified DNS Name (FQDN), such as RootDC.Root.com.

Important: A Windows DNS server will not accept dynamic updates unless it has an FQDN, which means you must make the NVDomain entry on the standalone server.

You'll be required to restart the server after making the NVDomain entry.

Install DNS on the Standalone Server
Following the restart, install the DNS service on the server. Create a new zone called Root.com. Configure the zone to accept dynamic updates. You can't use secure updates until you have integrated DNS into Active Directory, so don't point any clients at this DNS server.

You can create a reverse lookup zone, if you like, but that isn't absolutely required at this point.

By default, the DNS service will be able to resolve out-of-zone queries (such as queries for Internet hosts) using Root Hints. You may prefer to configure the server to use a forwarder.

Configure DNS Settings at the Domain Controller
You’re now ready to install the first domain controller in the root domain. Install the operating system and configure the TCP/IP settings to use the standalone DNS server for DNS lookups. Don't make any changes in the DNS tab of the TCP/IP settings or to the DNS suffix in System Properties. DCPromo will automatically configure these settings based on the domain name you supply during the promotion.

To make sure that the DNS settings are correct, run DCDiag with the following syntax:

dcdiag /test:dcpromo /dnsdomain:root.com /newforest

You should get the following response:

Starting test: DcPromo
Messages logged below this line indicate whether this domain controller will be able to dynamically register DNS records required for the location of this DC by other devices on the network. If any misconfiguration is detected, it might prevent dynamic DNS registration of some records, but does not prevent successful completion of the Active Directory Installation Wizard. However, we recommend fixing the reported problems now, unless you plan to manually update the DNS database. DNS configuration is sufficient to allow this domain controller to dynamically register the domain controller Locator records in DNS. The DNS configuration is sufficient to allow this computer to dynamically register the A record corresponding to its DNS name.

......................... RootDC passed test DcPromo

If you get a failure, the error message will give you a hint as to the cause. The most common causes are typos in the DNS IP address or in the DCDiag strings.

Run DCPromo and create the new forest. During DCPromo, you will get a DNS Registration Diagnostics window that hopefully contains no errors. Here's an example:

Diagnostic Results
The registration diagnostic has been run 1 times.
DNS registration support for this domain controller has been verified. To continue, click Next.

Details
The primary DNS server tested was: DNS1.Root.com (10.10.0.1)
The zone was: Root.com
The test for dynamic DNS update support returned:
"The operation completed successfully."

If the window says you have an error, you can continue with the promotion then troubleshoot later. That's the advantage of having a separate DNS server.

Following the restart of the domain controller, check the DNS zone to ensure that it contains a set of SRV records for the root.com zone. If these records do not appear, run netdiag /fix at the newly promoted domain controller. This takes the SRV records from a flat file called Netlogon.dns and uses them to perform the DNS dynamic registration. If the SRV records still do not appear, check the Event Log for errors.

Change Default Site Name
Assuming that everything looks good at this point, use Active Directory Sites and Services to change the name of the first site from Default-First-Site-Name to the name of your headquarters site. Let's call it HQ. Verify that this change is reflected in DNS. Drill down through the SRV records and make sure that the site name now reads HQ in any place it appears. If this does not happen, refresh the display then run netdiag /fix at the domain controller.

Initial Exchange 2003 Configuration
Since you're going to be running Exchange 2003, now would be a good time to run Forestprep and Domainprep for Exchange. This will make the required Schema changes, install a placeholder Exchange organization in the Configuration naming context, and create the necessary Exchange groups in the root domain of the forest. By doing this work now, all the forest changes will automatically get replicated to any new domain controllers you install.

Create DNS Child Domains
You're now ready to create DNS zones for the child domains (let's call them NA.Root.com and EU.Root.com) and install domain controllers for these domains. I'm assuming that you're going to want a server from each child domain in the company headquarters, so you don't need to create additional sites at this time.

Create the zones for the child domains on the same DNS server where you created the root zone. Eventually you'll integrate these zones into Active Directory. Be sure to enable dynamic updates on these zones.

Note: You don't have to create separate zones. The dynamic update process will create child DNS domains in the root zone file. But I like keeping the resource records in their own zones because it makes the transition to Active Directory a little easier to follow.

So, you now have three zones on the standalone DNS server. Install a domain controller in the two child domains using the same steps that I outlined for the root domain. Configure the TCP/IP settings on both DCs to point at the standalone DNS server as their sole DNS server. Use DCDiag to confirm that the zone information is correct. The DCDiag syntax for the child domains would be:

dcdiag /test:dcpromo /dnsdomain:NA.Root.com /childdomain

Following the restart after DCPromo, be absolutely sure that all SRV records are present in each zone. The critical records, at least from the perspective of Active Directory replication, are the CNAME records in the _msdcs.root.com zone. The replication agent on each domain controller queries DNS for this record based on the Globally Unique Identifier (GUID) of its replication partner. The GUID information is stored in Active Directory.

Wait 15 to 30 minutes for the KCC on each DC to grok (that is, to fully understand) the new topology and to create the necessary connection objects between the DCs. Then use Active Directory Sites and Services to force replication between the three domain controllers. If you get a "Naming Context in the process of being moved..." error, then wait a while longer for the KCC to do its thing. If you get an "RPC Server not found..." error, then you have a DNS configuration problem.

Additional Exchange 2003 Configuration
Exchange requires you to run Exchange Domainprep in every domain that hosts Exchange servers. Take a few minutes right here to run Domainprep in the two child domains.

AD-Integrate the DNS Zones
Okay, with everything working fine up to this point, you're ready to integrate the zones into Active Directory. Once a zone file has been integrated into Active Directory, any domain controller running DNS automatically becomes a primary master for that zone.

It's essential to integrate DNS into Active Directory if you're going to use dynamic updates. If you configure your DNS servers to accept dynamic update requests from unvalidated sources, it's just a matter of time before someone inadvertently or purposefully poisons your zone file with invalid resource records.

Windows only accepts one form of secure dynamic updates, a proprietary method that relies on the underlying object-based security in Active Directory. For this reason, secure updates require that you integrate the zone records into Active Directory.

Here's where DNS can get a little complicated. Under most circumstances, you don't want to replicate resource records for the NA.Root.com zone to the domain controllers in Europe, and vice versa. Windows Server 2003 has a feature where you can place DNS records in separate naming contexts then target replication for those naming contexts.

In LDAP, a naming context forms a replication boundary. It's often called a "partition" although that's not formally correct as per the LDAP RFCs.

Resource records for a domain are placed in a naming context called DomainDNSZones under the same domain. For example, resource records for the NA.Root.com zone would be placed in a naming context with the following Distinguished Name:

DC=DomainDNSZones,DC=NA,DC=Root,DC=com

Resource records intended for replication throughout the forest are placed in a naming context called ForestDNSZones under the root domain namespace as follows:

DC=ForestDNSZones,DC=Root,DC=com

Create the DNS Naming Contexts
When you install DNS on the Infrastructure Master in each domain, it will automatically create the DomainDNSZones naming context in its domain. When you install DNS on the Infrastructure Master in the forest root domain, it will also create the ForestDNSZones naming context.

Also, Windows Server 2003 allows you to target replication of these naming contexts to Active Directory domain controllers that are actually running the DNS service. After all, why waste time replicating DNS resource records to a domain controller that can't reply to DNS queries?

The next step, then, is to install DNS on the three domain controllers. Since each of these DCs is also the Infrastructure Master for its domain, this will result in the creation of the special DNS naming contexts.

Since you now have multiple DNS servers, it makes sense to use a forwarder to handle Internet host lookups. Most organizations either contract with their ISP to use a DNS server at the ISP or they put a caching-only DNS server in their DMZ.

Starting with the domain controller in Root.com, change the TCP/IP settings on each DC to point the server at itself for DNS lookups. In other words, the IP address in the Primary DNS setting should match the IP address of the server. (Don't do this in a Windows 2000 forest root domain. There's a flaw in the way Windows 2000 obtains the CNAME records for domain controllers and this flaw can cause replication failures if you point a root DC at itself for DNS. This flaw is fixed in Windows Server 2003.)

Now, install the DNS service on each of the DCs. On the root DC, create a zone for the Root.com domain. Configure the zone as Active Directory integrated and set the security to accept only secure updates. In the Active Directory Zone Replication Scope window, select the radio button labeled "To All DNS Servers in the Active Directory domain root.com."

On the other two domain controllers, configure a zone for each server's domain: NA.Root.com and EU.Root.com. Configure the zones as Active Directory integrated with secure updates only. Select the option to replicate the zone only to DNS servers in the respective domain. Populate the zones with resource records by running netdiag /fix at each DC. Verify that the SRV records appear in the three zones.

One more zone to go. At the root DC, create a new Forward Lookup Zone called _msdcs.root.com. Make this an Active Directory integrated zone and configure the scope option to replicate to every DNS server in the forest. When you do this, the zone will automatically populate with SRV records and a dimmed folder will be left behind in the root.com zone. This zone contains the records required to support forest-wide replication, so that's why you want a copy of it on every domain controller. The number of records is small, so the intercontinental replication load is trivial.

Configure Stub Zones
At this point, the domain controllers face a dilemma. They point at themselves for DNS lookups and there are no resource records in their copy of Active Directory to tell them where to find domain controllers in the other domains. This will cause replication failures.

The classic DNS way to handle this situation would be to configure the child domain controllers to forward their out-of-zone lookups to the DNS server in the root domain and to create delegation records in the root domain that point at the name servers in the child domains.

However, it's simpler to use another new Windows Server 2003 feature called "stub zones."

A stub zone is a special copy of a zone that contains only the Name Server (NS) records and their associated A (Host) records, often called glue records. If the DNS server receives a query for a host in the stub zone, it refers to the NS records in the stub zone to find the DNS servers in that domain. It then uses the IP addresses in the glue records to send the query to one of the DNS servers in the target zone. When it gets a resource record as a reply, it returns a copy of the record to the client who originated the query.

Stub zones do not require special replication permissions. The zone only contains NS and glue records, which are freely available via a standard DNS query. To repeat, stub zones do not require zone transfers.

Stub zones, then, take the place of traditional DNS delegation. They are especially handy in a Windows Server 2003 forest because you can integrate the stub zone into Active Directory so that every DNS server in a domain can find the NS and glue records.

The final step, then, is to create an Active Directory integrated stub zone in each domain representing the other domains. For example, the Root.com domain would need stub zones for NA.Root.com and EU.Root.com, while the NA.Root.com would need stub zones for Root.com and EU.Root.com.

With the stub zones in place, you should be able to get error-free replication between the domain controllers. You can now join a few clients to the domains and make sure that they can authenticate and get access to resources in the other domains and resolve Internet host addresses.

Go Forth and Configure DNS
Configuring DNS in a multiple-domain forest can get fairly complex, but this quick checklist should help you anticipate most of the problems.