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.|
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.
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
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 can temporarily stop the DNS Client service to avoid confusion while you are troubleshooting DNS.
NET STOP "DNS Client"
Windows Server 2019: The DNS Client service cannot be stopped on Windows Server 2019.
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
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,
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
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:
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. On Windows Server 2003 Nltest is part of the Windows 2003 Support Tools, located on the Windows Server 2003 CD/DVD.
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.)
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
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
- Setting Up the Domain Name System for Active Directory (KB237675)
- Frequently Asked Questions About Windows Server DNS (KB291382)
- How to Verify That SRV DNS Records Have Been Created for a Domain Controller (KB816587)
- How to Clear Bad Information in Active Directory-Integrated DNS (KB305967)
- How to Create a New Zone on a DNS Server in Windows Server (KB323445)
- How to Configure DNS Dynamic Update in Windows Server (KB816592)
- Best Practices for DNS Client Settings in Windows Server (KB825036)
- How to Replace the Current Primary DNS Server with a new Primary DNS Server in Windows Server (KB323383)
|U-Move for Active Directory|