Rooted in DNS
Many AD problems stem from DNS. Here's a quick DNS configuration best practices checklist.
- By Bill Boswell
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?
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:firstname.lastname@example.org;
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
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
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
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
......................... 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
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:
The registration diagnostic has been run 1 times.
DNS registration support for this domain controller has been verified.
To continue, click Next.
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
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
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
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
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
Resource records intended for replication throughout the forest are placed
in a naming context called ForestDNSZones under the root domain namespace
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.