Configuring DNS

The Domain Name System (DNS) is an Internet standard for mapping Internet computer names (called “host names”) to numerical Internet Protocol addresses (called “IP addresses”). The DNS server contains a database of all of the host names for a domain.

Active Directory uses DNS to locate the domain controllers in a domain.

Note: Incorrect configuration of DNS is the number one cause of problems with Active Directory. If DNS is configured incorrectly, domain controllers will not be able to locate each other for replication. Client computers will not find their domain controller(s), and users will not be able to log on.

A domain controller uses DNS to connect back to itself. If DNS is incorrectly configured, the domain controller will not be able 'see' itself, causing loopback errors that will prevent the DC from connecting to its own local AD database.

U-Move moves all DNS settings by default

Because DNS is critical for Active Directory, U-Move is careful to move all DNS settings from the source computer to the destination computer when cloning AD. This includes the following:

Client DNS settings
Server DNS settings
Server DNS zone data files (\Windows\system32\dns\*)
Hosts and lmhosts text files (\Windows\system32\drivers\etc\*)

By moving all DNS settings, U-Move prevents potential DNS errors due to differences in the DNS settings between the old and new computers.

Option: Skip moving the Client DNS Settings

If you choose do not copy the IP addresses, U-Move will skip moving the client DNS settings, the hosts file, and the lmhosts file from the old computer to the new computer This can be useful when moving AD to another network (such as the cloud).

U-Move will display the current client DNS settings and ask you to review and confirm them during the interview.

Types of moves: Clone versus Upgrade

When cloning AD using an emergency move or a planned move, the DNS settings and zones will carry over transparently to the new computer. The only issue is re-registering dynamic DNS records written more than 7 days ago (see below).

When upgrading AD (swing migration), the DNS settings and zones will carry over transparently to the new computer.

When cloning AD to an isolated test lab, you need to consider additional issues (see below).

Troubleshooting DNS Problems

To troubleshoot DNS run Dcdiag to verify DNS connectivity:

dcdiag /v /test:DNS

The following is an example of a successful run of Dcdiag:

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = MyServer
   * Identified AD Forest.
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site-Name\MyServer
      Starting test: Connectivity
         ......................... MyServer passed test Connectivity

Doing primary tests

   Testing server: Default-First-Site-Name\MyServer

      Starting test: DNS

         DNS Tests are running and not hung. Please wait a few minutes...
         ......................... MyServer passed test DNS

   Running partition tests on : ForestDnsZones

   Running partition tests on : DomainDnsZones

   Running partition tests on : Schema

   Running partition tests on : Configuration

   Running partition tests on : MyDomain

   Running enterprise tests on : MyDomain.com
      Starting test: DNS
         Test results for domain controllers:

            DC: MyServer.MyDomain.com
            Domain: MyDomain.com

         Summary of test results for DNS servers used by the above domain
         controllers:

         Summary of DNS test results:

                                            Auth Basc Forw Del  Dyn  RReg Ext
            _________________________________________________________________
            Domain: MyDomain.com
               MyServer                         PASS PASS PASS PASS PASS PASS n/a

         ......................... MyDomain.com passed test DNS

If Dcdiag reports a failed DNS test, you should first check network connectivity with the DNS server. Use the commands ping and nslookup to verify that the DNS server is visible on the network and can resolve the DNS records.

Not all failed DNS tests indicate errors. For example if you are running AD on an isolated network for offline testing in your lab, Dcdiag will fail the DNS test because there are no DNS forwarders that can reach the Internet. This is normal and expected.

Another common failed DNS test is the lack of a reverse PTR record. PTR records are optional; many sites to not configure them. PTR errors are normal and can be ignored.

Troubleshooting: The DNS Client service

The DNS Client service caches results from the DNS service. This includes “negative” results where an address is not found. You should flush the cache of the DNS Client service before troubleshooting any changes to your DNS configuration:

ipconfig /flushdns

netlogon.dns

To assist you in troubleshooting DNS problems, upon each boot the domain controller will write a copy of its desired DNS records to a text file. The text file is named C:\Windows\System32\config\netlogon.dns. You can inspect this file (use NOTEPAD.EXE) in order to verify that your DNS server contains the correct A, PTR, and SRV records for the domain controller.

If your DNS server does not contain the records listed in netlogon.dns, you need to find the cause and correct it. If you are using dynamic DNS updates, you need to investigate why the domain controller failed to update the dynamic records (for example, the NIC has the wrong DNS client IP address). If you are using static DNS, you may need to manually recreate the necessary A, PTR, and SRV records.

The DNSLint Utility

The DNSLint tool can be used to diagnose DNS errors. On the moved domain controller type the command
dnslint /ad 127.0.0.1 /s localhost /v

Immediate re-registration of DNS records

If you see errors in the Event Log due to problems with locating a domain controller in DNS that has failed to dynamically register its DNS address, and you do not want to wait 5-10 minutes for automatic re-registration, you can force the domain controller to immediately register its IP address with the DNS server. Open an administrative console and type the following commands:

ipconfig /flushdns ipconfig /registerdns nltest /dsregdns

The ipconfig command will tell the computer to send ("register") its DNS A and PTR records to the DNS server. The nltest command will register the SRV records. The SRV records are used to locate domain controllers.

Ipconfig and Nltest are built-in utilities.

Restoring DNS from a backup more than 7 days old

Many DNS zones use dynamic updates. When a computer boots that is a member of a dynamic DNS zone it will write its IP address and host name to the DNS server. (This is called “registering with DNS”.) The computer will send an update when it boots, and again periodically - typically once per day. Domain controllers will send dynamic updates to the DNS server just like other computers.

If you restore the DNS server database from a backup that is more than 7 days old there may be a delay of up to 30 minutes during the first reboot. This is normal behavior. It happens because the DNS server will erase stale records if they are not updated after (typically) 7 days.

Background information: If you restore the DNS server database from a backup that is more than 7 days old, and if the DNS server on that computer has dynamic DNS zones, upon booting the DNS server will immediately erase all the dynamic records. This is because the DNS server checks the timestamp of each dynamic DNS record when it boots (and periodically thereafter). If the timestamp is older than the aging interval (default 7 days), the DNS record is erased.

During the initial boot with a newly loaded Active Directory you may see some spurious errors in the Event Log regarding the inability to locate a domain controller or the Global Catalog. These error messages are temporary and can be ignored. Each domain controller will attempt to dynamically re-register its IP address every 5-10 minutes until it succeeds.

The first registration attempt may fail because the DNS server has not yet fetched the DNS zone records from AD. This can happen if you use integrated DNS zones. (see below). This is normal, and the next registration attempt should succeed.

Loading AD in a test lab: Always choose 'Test'

If you are loading AD into an isolated DC in your test lab, for the reload method always choose Test (not Planned or Emergency). By choosing Test, U-Move will notify the DC that it does not need to pause for a successful initial replication during the first boot. The purpose of the delay is to make sure that the restored copy AD is indeed the most recent one. If you select Planned or Emergency, the DC might stall for up to an hour while it waits to replicate with a 'good' DC (one that was not itself also re-loaded). DNS will remain inoperable during this time. Several error messages might appear in the Event Log regarding DNS. This is normal behavior and the error messages can be safely ignored.

Error: The DNS Service cannot load integrated DNS Zones from AD

By default each DNS zone database is stored in C:\Windows\System32\DNS\* as a simple text file. When creating a DNS zone you have the option to instead store the DNS zone inside of Active Directory as an AD object. A DNS zone stored in AD is called an “integrated” DNS zone.

If you use integrated DNS zones, and you are using dynamic DNS registration, there is a circular dependency between DNS and AD that can cause a delay of up to 30 minutes during the initial boot. The reason for the delay is that DNS needs to contact AD to fetch its zone records, but AD will refuse to accept requests until it can register its IP address with DNS. But DNS will refuse to honor AD's registration request because DNS has not loaded the zone records yet from AD. The result is a circular deadlock. The DNS service will report (via the DNS Event Log) that it is unable to load the integrated DNS zones from Active Directory.

Within 30 minutes AD will recognize the problem and start without DNS, breaking the deadlock. If you do not want to wait for 30 minutes, you can manually stop and restart the DNS service. This will break the deadlock. (The deadlock will not happen on subsequent boots. This is because DNS will cache the AD-integrated zone records and use them on subsequent boots.)

You can avoid the delay by selecting Test when loading AD (not Planned or Emergency).

Test move: Not moving all DNS servers

If you are not moving all the DNS servers to your test lab, you must reconfigure DNS so that the test domain controller(s) can continue to locate each other and so that test client computers can locate the domain controllers.

Test move: Creating a dummy root DNS zone

Your test lab will be isolated from the rest of the network. This means that DNS queries for external zones outside of the test lab will time out. Some Microsoft components will attempt to access external DNS zones, such as microsoft.com. Because the DNS server cannot forward these requests, they will time out, causing irritating delays.

To avoid delays due to timeouts for external DNS zones, you can create a dummy root DNS zone on the DNS server in your test lab. This will cause the DNS server to immediately fail external lookup requests instead of trying to forward them (and timing out).

To create a dummy root DNS zone use the following procedure:

Start the DNS MMC snap-in: Click on Administrative Tools -> DNS.
Right-click Forward lookup zones, then click New Zone.
When the New Zone Wizard starts, click Next.
Click Primary, clear the checkbox Store the zone in Active Directory so that it is not checked, and then click Next.
In the Zone Name box, type a single dot (.), and then click Next.
Click Create a new file with this file name and type root.dns (default), and click Next.
Click Do not allow dynamic updates (default) and click Next. Then click Finish.

Do this procedure on the “topmost” DNS server in your test lab.

For more information

For more information on how to troubleshoot the DNS configuration for Active Directory see Dcdiag and Troubleshooting Dcpromo Errors, or see the following Microsoft articles:

U-Move for Active Directory
Backing Up Active Directory
Restoring Active Directory
Cloning Active Directory
	Concepts
		Networking
			Copying Internet Addresses
			Configuring DHCP
			Configuring DNS
			Reviewing Client DNS Settings
Upgrading Active Directory
Remote Use and Scripting
AD Consulting and Repair Service
AD Recovery Service
Error Messages