After you have installed DNS service on a Windows 2000/.NET Server, or if you already have a functioning Microsoft DNS server (or a third party DNS server), you may wish (or rather, need) to verify the DNS configuration. This is especially important if you use an "outside" DNS server (a server running on a remote computer or even in another organization). It is not enough that you yourself think that all DNS parameters are properly set; rather, it is the system and program tests that should confirm that everything is working fine.
You must check that the DNS server holds the correct forward and reverse zones and that these zones allow dynamic record updates. For testing Microsoft DNS Servers, it is helpful to use a general-purpose command-line DnsCmd.exe utility (that is standard in Windows .NET, or has been included in the Windows 2000 Support Tools pack). You can start it from any computer that has access to the inspected DNS server. This utility can perform all operations necessary for remote maintenance of a Microsoft DNS server.
In Chapter 5, "Installing Active Directory", we will discuss how to use specialized utilities that also help to verify DNS configuration, such as DCdiag.exe and NetDiag.exe.
To verify a zone, use the /enumzones command. You will get an output similar to the following (which is the output for the simplest configuration):
C:\>dnscmd netdcl.net.dom /EnumZones Enumerated zone list: Zone count = 8 Zone name Type Storage Properties . Cache AD-Domain _msdcs.net.dom Primary AD-Forest Update 1.168.192.in-addr.arpa Primary AD-Forest Update Rev net.dom Primary AD-Domain Update Comand completed successfully.
In this case, netdcl.net.dom is the Microsoft DNS Server name, "." corresponds to the cached lookups, net.dom is an authoritative zone name and the DNS name of the future domain, and 1.168.192.in-addr.arpa is a manually created reverse zone for the private network 192.168.1.0 (255.255.255.0 mask; the address and mask depend on your network configuration).
The Update parameter indicates whether or not the zone is dynamically updatable. You can also check this property of zones (e.g., the net.dom zone) using the following command. (Be careful; in the Windows 2000 version of DnsCmd, the AllowUpdate and other zone properties are case-sensitive!):
C:\>dnscmd netdcl.net.dom /ZoneInfo net.dom AllowUpdate Zone query result: Dword: 1 (00000001) Command completed successfully.
The value 1 indicates that this zone can be dynamically updated.
You must also verify DNS server responsiveness. It is recommended that you do this before any DC creation in a Windows 2000 environment (in Windows .NET, similar tests are built-in), in order to avoid serious domain problems in the future. Enter the following command on the inspected computer (a client, or a server to be promoted):
192.168.1.2 is the DNS server's IP address, specified in the TCP/IP properties of that computer. The result will be similar to the following output:
Server: netdcl.net.dom Address: 192.168.1.2 Name: netdcl.net.dom Address: 192.168.1.2
Here, the Server reply contains the DNS server name, and Name is the name resolved from the specified IP address. In this case, the names are the same (because we have asked the DNS server for its own name), but you may want to resolve any other IP addresses if their corresponding host names are registered on the DNS server. You may also verify resolving DNS computer names into IP addresses, for example: nslookup net.dom.
In contrast to DnsCmd.exe, the Nslookup command can be used with any type of DNS servers.
If you receive any different outputs or error messages, like "Can't find server name for address" or "Default servers are not available," you need to check all TCP/IP properties, the connectivity and the existence of forward and reverse zones. The DNS server may reply with the aforementioned messages, if, for example, the server is operational but the reverse zone is absent or corrupted.
After a domain controller is created (and especially when the first DC in the forest is created), it is strongly recommended that you verify the registration of all necessary SRV records (see Chapter 3, "Domain Name System (DNS) as Main Naming Service"). You can check an SRV record with the DNSCmd.exe utility by entering, for example, the command (asking the SRV record registered by the PDC operations master):
C:\>dnscmd netdcl.net.dom /EnumRecords _msdcs.net.dom _tcp.pdc /Type SRV Returned records: _Idap [Aging:3519689] 600 SRV 0 100 389 netdcl.net.dom. Command completed successfully.
(Here, _msdcs.net.dom is the authoritative zone name.)
In conclusion, it is worth repeating that the best command for testing domain controllers is the DcDiag.exe utility that reliably verifies DNS issues for a specified computer. For example, if the following command returns no information, you may be sure that the selected DC is "healthy":
C:\>dcdiag /s:netdc4.net.dom /q
All described procedures will help you to avoid some pitfalls of domain functioning. Do not forget to set aside at least a half an hour for DNS testing. Take your time and be thorough, or you could spend days trying to resolve potential problems, such as "why is network reaction so slow?" or "why doesn't the new domain controller replicate data?"