Verifying Your Basic DNS Configuration

If you use a third-party DNS server to support Active Directory, you must perform configuration tasks manually, and doing so, you might cause common configuration errors that prevent DNS and Active Directory from working properly. The following sections describe tests that you can perform to verify that your DNS server is working properly, that the forward and reverse lookup zones are properly configured, and that DNS can support Active Directory.

If you use either the Configure DNS Server wizard or the Active Directory Installation wizard to install your Windows 2000 DNS server, most configuration tasks are performed automatically and you can avoid many common configuration errors, but you might still want to perform the tests in this section.

Before checking anything else, check the event log for errors. For more information about Event Viewer, see "Troubleshooting Tools" earlier in this chapter.

Verifying That Your DNS Server Can Answer Queries

Use the following process to verify that your DNS server is started and can answer queries.

• Make sure that your server has basic network connectivity. For more information about verifying basic network connectivity, see "Checking the DNS Server for Problems" later in this chapter.
• Make sure that the server can answer both simple and recursive queries from the Monitoring tab in the DNS console. For more information about the Monitoring tab, see "Troubleshooting Tools" earlier in this chapter.
• From a client, use Nslookup to look up a domain name and the name of a host in the domain. For more information about using Nslookup, see "Troubleshooting Tools" earlier in this chapter.
• On the server, run netdiag to make sure the server is working properly and that the resource records Netlogon needs are registered on a DNS server. For more information about Netdiag, see "Troubleshooting Tools" earlier in this chapter.
• Make sure that the server can reach a root server by typing the following:

  nslookup

  server <IP address of server>

  set querytype=NS

  .

• Make sure that there is an A and PTR resource record configured for the server. For information about PTR resource records, see "Testing for Reverse Lookup Zones and PTR Records" later in this chapter.

Verifying That the Forward Lookup Zone Is Properly Configured

After you create a forward lookup zone, you can use Nslookup to make sure it is properly configured and to test its integrity to host Active Directory. To start Nslookup, type the following

Nslookup
server <IP address of server on which you created zone>
set querytype=any

Nslookup starts. If the resolver cannot locate a PTR resource record for the server, you see an error message, but you are still able to perform the tests in this section.

To verify the zone is responding correctly, simulate a zone transfer by typing the following:

ls -d <domain name>

If the server is configured to restrict zone transfers, you might see an error message in Event Viewer. (For more information about Event Viewer, see "Troubleshooting Tools" earlier in this chapter.) Otherwise, you see a list of all the records in the domain.

Next, query for the SOA record by typing the following and pressing ENTER:

<domain name>

If your server is configured correctly, you see an SOA record. The SOA record includes a "primary name server" field. To verify that the primary name server has registered an NS record, type the following:

set type=ns
<domain name>

If your server is configured correctly, you see an NS record for the name server.

Make sure that the authoritative name server listed in the NS record can be contacted to request queries by typing the following:

server <server name or IP address>

Next, query the server for any name for which it is authoritative.

If these tests are successful, the NS record points to the correct hostname, and the hostname has the correct IP address associated with it.

Testing for Reverse Lookup Zones and PTR Resource Records

You do not need reverse lookup zones and PTR resource records for Active Directory to function. However, you need them if you want clients to be able to resolve FQDNs from IP addresses. Also, PTR resource records are commonly used by some applications for security purposes, to verify the identity of the client.

You do not need to have the reverse lookup zones and PTR resource records on your own servers; instead, another DNS server can contain these zones.

After you have configured your reverse lookup zones and PTR resource records, manually examine them in the DNS console. A reverse lookup zone must exist for each subnet, and the parent reverse lookup zone must have a delegation to your reverse lookup zone. For example, if you have a private root and the subnets 172.32.16.x and 172.32.17.x, the private root can host all reverse lookup zones, or it can contain the reverse lookup zone 172.32.x and delegate the reverse lookup zones 172.32.16.x and 172.32.17.x to other servers. Also, PTR resource records must exist for all the computers in your network. For more information about adding a reverse lookup zone, see "Adding a Reverse Lookup Zone" earlier in this chapter.

You can also use Nslookup to verify that the reverse lookup zones and PTR resource records are configured correctly.

To make sure your reverse lookup zones and PTR resource records are configured correctly

1. Start Nslookup by typing Nslookup at the command prompt and then pressing ENTER.
2. Switch to the server you want to query by typing the following:

   server <Server IP Address>

3. Enter the IP address of the computer whose PTR resource record you want to verify, and then press ENTER.

   If the reverse lookup zone and PTR resource record are configured correctly, Nslookup returns the name of the computer.

4. To quit Nslookup, type exit and then press ENTER.

Verifying Your DNS Configuration After Installing Active Directory

When you use third-party DNS servers to support Active Directory, you can verify the registration of domain controller locator resource records. If the server does not support dynamic update, you need to add these records manually.

The Netlogon service creates a log file that contains all the locator resource records and places the log file in the following location:

%SystemRoot%\System32\Config\Netlogon.dns

You can check this file to find out which locator resource records are created for the domain controller.

The locator resource records are stored in a text file, compliant with RFC specifications. If your server is configured correctly, you see the LDAP SRV record for the domain controller:

_ldap._tcp.<Active Directory domain name> IN SRV <priority> <weight> 389 <domain controller name>

For example:

_ldap._tcp.reskit.com. IN SRV 0 0 389 dc1.reskit.com

Next, use the Nslookup command-line tool to verify that the domain controller registered the SRV resource records that were listed in Netlogon.dns.

Note

During the following test, if you have not configured a reverse lookup zone and PTR resource record for the DNS server you are querying, you might see several time-outs. This is not a problem.

To verify that SRV resource records are registered for the domain controller

1. At the command prompt, type nslookup and then press ENTER.
2. To set the DNS query type to filter for SRV records only, type set type=SRV and then press ENTER.
3. To send a query for the registered SRV record for a domain controller in your Active Directory domain, type _ldap._tcp.<Active Directory domain name> and then press ENTER.
4. You should see the SRV records listed in Netlogon.dns. If you do not, SRV resource records might not be registered for the domain controller.

The following example shows a full Nslookup session, used to verify SRV resource records that are registered for locating two domain controllers on a network. In this example, the two domain controllers (DC1 and DC2) are registered for the domain noam.reskit.com.

C:\>nslookup

Default Server:  dc1.noam.reskit.com

Address:  10.0.0.14

> set type=SRV

> _ldap._tcp.noam.reskit.com

Server:  dc1.noam.reskit.com

Address:  10.0.0.14

_ldap._tcp.noam.reskit.com   SRV service location:

          priority       = 0

          weight         = 0

          port           = 389

          svr hostname   = dc1.noam.reskit.com

_ldap._tcp.noam.reskit.com   SRV service location:

          priority       = 0

          weight         = 0

          port           = 389

          svr hostname   = dc2.noam.reskit.com

dc1.noam.reskit.com     internet address = 10.0.0.14

dc2.noam.reskit.com     internet address = 10.0.0.15

© 1985-2000 Microsoft Corporation. All rights reserved.