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.
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
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.
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
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.
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
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 followingNslookup 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
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
-
Start Nslookup by typing
Nslookup
at the command prompt and then pressing ENTER.
-
Switch to the server you want to query by typing the following:
server < Server IP Address >
-
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.
-
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.
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
-
At the command prompt, type
nslookup
and then press ENTER.
-
To set the DNS query type to filter for SRV records only, type
set type=SRV
and then press ENTER.
-
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.
-
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.
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
No comments:
Post a Comment