publication: Christian ALT

Security NEWs Service: TLAnews

 

TLAalert    Security Service

Save Time and Money

updated 23.4.2000 Networking: Troubleshooting DNS for Windows 2000 original post  13.3.2000   With the increase of DNS attacks we publish a small guide on troubleshooting Windows 2000 DNS. It includes DNS and DHCP Useful commands for troubleshooting windows 2000 DNS

• DNS and DHCP Useful commands for troubleshooting windows 2000 DNS
• Troubleshooting DNS for Windows 2000
• Incorrect answer
• Diagnosing Problems with Incorrect Authoritative Data
• Diagnosing Problems with Recursion
• Checking the DNS Server for Problems
• Windows 2000 rearranges list of DNS servers

Cannot Find Name or IP Address
If a query fails because you get the response Non-existent domain from Nslookup or the response  Unknown host from Ping, the DNS server did not find the name or IP address that you are looking  up. Use the following process, shown in Figure 6.36, to help troubleshoot the problem:
1. Check that the client and server computers have a valid IP configuration.
To check IP configuration, type ipconfig /all at the command prompt. In the command-line  output, verify the IP address, subnet mask, and default gateway.
2. Check that the server is working properly. For more information about verifying that the  server is working properly, see “Checking the DNS Server for Problems” later in this chapter.
3. Check whether the DNS server is authoritative for the name that is being looked up. If the DNS server is authoritative for the name that is being looked up, you probably  have a problem with authoritative data. For more information about checking for problems with  authoritative data, see “Checking for Problems with Authoritative Data” later in this chapter.
– Or –
If the DNS server is not authoritative for the name that is being looked up, proceed to  the next step.
4. Query for the name by using Nslookup. At the command prompt, type the following:
Nslookup <query address> <IP address of server>
where IP address of server is the IP address of the server that you queried originally,  and query address is the name or IP address you are attempting to resolve. If you get the message  “Server failed” or “Request to server timed out,” you probably have a problem involving a broken  delegation. For more information about problems with broken delegations, see “Checking for  Recursion Problems” later in this chapter.
– Or –
If you get an incorrect answer or the message “Non-existent domain,” proceed to the next  step.
5. Flush the resolver cache. At the command prompt, type the following:
Nslookup <query address> <IP address of server>
where IP address of server is the IP address of the server that you queried originally,  and query address is the name or IP address you are attempting to resolve. If the answer is  correct, the problem was a stale cache entry, and your problem is solved.
– Or –
If the answer is still not correct, you probably have a problem with authoritative data.  For more information about problems with authoritative data, see “Checking for Problems with  Authoritative Data” later in this chapter.

Incorrect Answer
If you query a DNS server and it responds with incorrect information, use the following process,  shown in Figure 6.37, to solve the problem.
1. Flush the resolver cache.
2. At the command prompt, type the following:
Nslookup <query address> <IP address of server>
where IP address of server is the IP address of the server that you queried originally,  and query address is the name or IP address you are attempting to resolve. If the answer is  correct, the problem was a stale cache entry, and your problem is solved.
– Or –
If the answer is still not correct, you probably have a problem with authoritative data.  For more information about how to diagnose problems with authoritative data, see “Checking for  Problems with Authoritative Data” later in this chapter.

Checking the DNS Server for Problems
1. Check Event Viewer for error messages. For information about Event Viewer, see 
“Troubleshooting Tools” earlier in this chapter.
2. Check for basic connectivity between the client computer and the DNS server that you used  for your original query by pinging the DNS server by its IP address.
If the DNS server does not respond to a direct ping of its IP address, you probably have  a network connectivity problem between the client and the DNS server.
3. At the command prompt on the client computer, type the following:
nslookup 127.0.0.1 <IP address of server>
If the resolver returns the name of the local host, the server does not have any  problems.
– Or –
If the resolver returns the response “Server failure,” proceed to step 4.
– Or –
If the resolver returns the response “Request to server timed out” or “No response from  server,” proceed to step 5.
4. If the resolver returns the response “Server failure,” the zone 1.0.0.127.in-addr.arpa is  probably paused, or the server is possibly overloaded. You can find out whether it is paused by  checking the General tab of the zone properties, from within the DNS console.
5. If the resolver returns the response “Request to server timed out” or “No response from  server,” the DNS server probably is not running. Try to restart the server by typing the  following at the command prompt on the server:
net start DNS
– Or –
If it is running, the server might not be listening on the IP address that you used in  your Nslookup query. From the Interfaces tab of the server properties page in the DNS console,  administrators can restrict a DNS server to listen only on selected addresses. If the DNS server  has been configured to limit service to a specific list of its configured IP addresses, it is  possible that the IP address used to contact the DNS server is not in the list. You can try a 
different IP address in the list or add the IP address to the list. For more information about  restricting a DNS server to listen only on selected addresses, see Windows 2000 Help.
– Or –
In rare cases, the DNS server might be configured to disable the use of its automatically  created default zones. By default, the DNS service automatically creates the following standard  reverse lookup zones based on RFC recommendations:
· 0.in-addr.arpa
· 127.in-addr.arpa
· 255.in-addr.arpa

The automatic creation of these zones can only be disabled through the registry, so it is  unlikely that this has happened. However, if you think automatic creation has been disabled, you  can use the DNS console to make sure that the zones exist.
– Or –
In rare cases, the DNS server might have an advanced security or firewall configuration. 
If the server is located on another network that is reachable only through an intermediate host 
(such as a packet filtering router or proxy server), the DNS server might use a non-standard port 
to listen for and receive client requests. By default, Nslookup sends queries to DNS servers on 
UDP port 53, so if the DNS server uses any other port, Nslookup queries fail. If you think this 
might be the problem, check whether an intermediate filter is intentionally used to block traffic 
on well-known DNS ports. If not, try to modify the packet filters or port rules on the firewall 
to allow traffic on UDP/TCP port 53.

Diagnosing Problems with Incorrect Authoritative Data
If you have determined that the server contains incorrect authoritative (non-cached) data, use 
the following process to help troubleshoot the problem:
1. Determine whether the server that is returning the incorrect response is either a primary 
or secondary server for the zone.
If the server is a primary server for the zone — either the standard primary server for 
the zone or a server that uses Active Directory integration to load the zone — the data is 
incorrect on the primary zone. Go to step 5.
– Or –
If the server is hosting a secondary copy of the zone, proceed to the next step.
2. Examine the zone on the master server (the server from which this server pulls zone 
transfers). You can determine which server is the master server by examining the properties of 
the secondary zone in the DNS console. Is the name correct on the master server?
If the name is not correct on the master server, go to step 1. When prompted to examine a 
server, examine the server from which this server pulls zone transfers.
– Or –
If the name was correct on the master server, proceed to the next step.
3. Check whether the serial number on the master server is lower than or equal to the serial 
number on the secondary server. If not, proceed to the next step.
– Or –
If the serial number on the master server is lower than or equal to the serial number on 
the secondary server, modify either the master server or the secondary server so that the serial 
number on the master server is higher than the serial number on the secondary server. Then, 
proceed to the next step.
4. Force a zone transfer from within the DNS console. (For information about how to force a 
zone transfer, see Windows 2000 Server Help.) Next, examine the secondary server again to see 
whether the zone was transferred correctly. If not, you probably have a zone transfer problem; 
see “Zone Transfer Problems” later in this chapter.
– Or –
If the zone was transferred correctly, check whether the data is now correct. If not, the 
data is incorrect on the primary zone. Proceed to the next step.
5. If the data is incorrect on the primary zone, the problem might be caused by user error 
when entering data into the zone, a problem with Active Directory replication, a problem with 
dynamic update, or a WINS lookup problem. 
If you are responsible for maintaining the zone, you can solve the problem. Otherwise, 
ask the person who is responsible for maintaining the zone to solve the problem.

Diagnosing Problems with Recursion
For recursion to work successfully, all DNS servers that are used in the path of a recursive 
query must be able to respond and forward correct data. If they cannot, a recursive query can 
fail for any of the following reasons:
· The query times out before it can be completed.
· A server used during the query fails to respond.
· A server used during the query provides incorrect data.

If you have determined that you have a problem with recursion, use the following process, , to help troubleshoot the problem. Start with the server used in your original query:

1. Check whether this server forwards queries to another server by examining the Forwarders 
tab in the server properties in the DNS console. If the check box Enable forwarders is selected 
and one or more servers are listed, this server forwards queries.
If this server does forward queries to another server, check for problems with the server 
to which this server forwards queries. To check for problems, follow the troubleshooting steps in 
“Checking the DNS Server for Problems.” When that section instructs you to perform a task on the 
client, perform it on the server instead.
If the server is healthy and can forward queries, repeat this step, examining the server 
to which this server forwards queries.
– Or –
If this server does not forward queries to another server, proceed to the next step.
2. Test whether this server can query a root server by typing the following:
nslookup server <IP address of the server you are examining>
set querytype=NS
.
If the resolver returns the IP address of a root server, you probably have a broken 
delegation between the root server and the name or IP address that you are attempting to resolve. 
Follow the procedure “To test for a broken delegation” to determine where you have a broken 
delegation.
–Or –
If the resolver returns the response “Request to server timed out,” check whether the 
root hints points to functioning root servers by following the procedure “To view the current 
root hints.” If the root hints does point to functioning root servers, you might have a network 
problem, or the server might use an advanced firewall configuration that prevents the resolver 
from querying the server, as described in “Checking the Server for Problems,” earlier in this 
chapter. It is also possible that the recursive time-out default (15 seconds) is too short. For 
information about how to change this time-out, see the Windows 2000 Server Help. Search for 
“tuning advanced parameters.”

Note Begin the tests in the following procedure by querying a valid root server. The test takes 
you through a process of querying all the DNS servers from the root down to the server that you 
are testing for a broken delegation.

To test for a broken delegation
1. At the command prompt on the server that you are testing, type the following:
nslookup 
server <server IP address>
set norecursion
set querytype=<resource record type> <FQDN >

where resource record type is the type of resource record that you were querying for in 
your original query, and FQDN is the FQDN for which you were querying (terminated by a period).

2. If the response includes a list of NS and A resource records for delegated servers, 
repeat step 1 for each server and use the IP address from the A resource records as the server IP 
address.
– Or –
If the response does not contain an NS resource record, you have a broken delegation.
–Or –
If the response contains NS resource records, but no A resource records, type set 
recursion and query individually for A resource records of servers listed in the NS records. If 
for each NS resource record in a zone, you do not find at least one valid IP address of an A 
resource record for each NS resource record, you have a broken delegation.

If you determine that you have a broken delegation, fix it by adding or updating an A resource 
record in the parent zone with a valid IP address for a correct DNS server for the delegated 
zone.
To view the current root hints
1. Start the DNS console.
2. Add or connect to the DNS server that failed a recursive query.
3. Right-click the server and select Properties.
4. Click Root Hints.
5. Check for basic connectivity to the root servers.
6. If root hints appear to be configured correctly, verify that the DNS server used in a 
failed name resolution can ping the root servers by IP address.
If the root servers do not respond to pinging by IP address, the IP addresses for the 
root servers might have changed. However, reconfiguration of root servers, is uncommon.

Diagnosing Zone Transfer Problems
If you have determined that a secondary server cannot pull a zone transfer from a master server, 
use the following process,  to diagnose and solve your zone transfer problems.

1. Check Event Viewer for both the primary and secondary DNS server. For information about 
Event Viewer, see “Troubleshooting Tools” earlier in this chapter.
2. Check the master server to see whether it is refusing to send the transfer for security 
reasons. Check the Zone Transfers tab of the zone properties in the DNS console. If the server 
restricts zone transfers to a list of servers, such as those listed on the Name Servers tab of 
the zone properties, make sure that the secondary server is on that list. Make sure that the 
server is configured to send zone transfers.
3. Check the master server for problems by following the steps in “Checking the DNS Server 
for Problems” earlier in this chapter. When prompted to perform a task on the client, perform the 
task on the secondary server instead.
4. Check whether the secondary server is running another DNS server implementation, such as 
BIND. If so, the problem might have one of several causes:

· The Windows 2000 master server might be configured to send fast zone transfers, but the 
third-party secondary server might not support fast zone transfers. If so, disable fast zone 
transfers on the master server by selecting the check box Bind secondaries on the Advanced tab of 
the properties for your server, from within the DNS console.
· If a forward lookup zone on the Windows 2000 server contains a WINS lookup record or the 
reverse lookup zone contains a WINS-R record, the BIND server might not be able to transfer the 
zone. For information about diagnosing problems in which a BIND server cannot transfer a zone, 
see “Solving Common DNS Problems” later in this chapter.
· If a forward lookup zone on the Windows 2000 server contains a record type (for example, 
an SRV record) the secondary server does not support, the secondary server might have problems 
pulling the zone.

5. Check whether the master server is running another DNS server implementation, such as 
BIND.
If so, it is possible that the zone on the master server includes incompatible resource 
records that Windows 2000 does not recognize. For a complete list of all RFC-compliant resource 
record types that are supported by DNS servers that are running under Windows 2000 Server, see 
Windows 2000 Server Help.
6. If either the master or secondary server is running another DNS server implementation, 
check both servers to make sure that they support the same features. You can check the Windows 
2000 server from the Advanced tab of the properties page for the server from within the DNS 
console. In addition to the Bind secondaries box, this page includes the Name checking drop down 
list, which enables you to select enforcement of strict RFC compliance for characters in DNS 
names.

Solving Other Common DNS Problems
This section lists several common DNS problems and explains how to solve them.
Event ID 7062 appears in the event log.
If you see event ID 7062 in the event log, the DNS server has sent a packet to itself. This is 
usually caused by a configuration error. Check the following:
· Make sure that there is no lame delegation for this server. A lame delegation occurs when 
one server delegates a zone to a server that is not authoritative for the zone.
· Check the forwarders list to make sure that it does not list itself as a forwarder.
· If this server includes secondary zones, make sure that it does not list itself as a 
master server for those zones.
· If this server includes primary zones, make sure that it does not list itself in the 
notify list.

Zone transfers to secondary servers that are running BIND are slow.
By default, the Windows 2000 DNS server always uses a fast method of zone transfer. This method 
uses compression and includes multiple resource records in each message, substantially increasing 
the speed of zone transfers. Most DNS servers support fast zone transfer. However, BIND 4.9.4 and 
earlier does not support fast zone transfer. This is unlikely to be a problem, because when the 
Windows 2000 DNS Server service is installed, fast zone transfer is disabled by default. However, 
if you are using BIND 4.9.4 or earlier, and you have enabled fast zone transfer, you need to 
disable fast zone transfer.
To disable fast zone transfer
1. In the DNS console, right-click the DNS server, and then click Properties.
2. Click the Advanced tab.
3. In the Server options list, select the Bind secondaries check box, and then click OK.

You see the error message “Default servers are not available.”
When you start Nslookup, you might see the following error message:
*** Can’t find server name for address <address>: Non-existent domain
*** Default servers are not available
Default Server: Unknown
Address: 127.0.0.1
If you see this message, your DNS server is still able to answer queries and host Active 
Directory. The resolver cannot locate the PTR resource record for the name server that it is 
configured to use. The properties for your network connection must specify the IP address of at 
least one name server, and when you start Nslookup, the resolver uses that IP address to look up 
the name of the server. If the resolver cannot find the name of the server, it displays that 
error message. However, you can still use Nslookup to query the server.
To solve this problem, check the following:
· Make sure that a reverse lookup zone that is authoritative for the PTR resource record 
exists. For more information about adding a reverse lookup zone, see “Adding a Reverse Lookup 
Zone” earlier in this chapter.
· Make sure that the reverse lookup zone includes a PTR resource record for the name 
server.
· Make sure that the name server you are using for your lookup can query the server that 
contains the PTR resource record and the reverse lookup zone either iteratively or recursively.

User entered incorrect data in zone.
For information about how to add or update records by using the DNS console, see Windows 2000 
Server Help. For more information about using resource records in zones, search for the keywords 
“managing” and “resource records” in Windows 2000 Server Help.
Active Directory-integrated zones contain inconsistent data.
For Active Directory–integrated zones, it is also possible that the affected records for the 
query have been updated in Active Directory but not replicated to all DNS servers that are 
loading the zone. By default, all DNS servers that load zones from Active Directory poll Active 
Directory at a set interval — typically, every 15 minutes — and update the zone for any 
incremental changes to the zone. In most cases, a DNS update takes no more than 20 minutes to 
replicate to all DNS servers that are used in an Active Directory domain environment that uses 
default replication settings and reliable high-speed links.
User cannot resolve name that exists on a correctly configured DNS server.
First, confirm that the name was not entered in error by the user. Confirm the exact set of 
characters entered by the user when the original DNS query was made. Also, if the name used in 
the initial query was unqualified and was not the FQDN, try the FQDN instead in the client 
application and repeat the query. Be sure to include the period at the end of the name to 
indicate the name entered is an exact FQDN.
If the FQDN query succeeds and returns correct data in the response, the most likely cause of the 
problem is a misconfigured domain suffix search list that is used in the client resolver 
settings.

Name resolution to Internet is slow, intermittent, or fails.
If queries destined for the Internet are slow or intermittent, or you cannot resolve names on the 
Internet, but local Intranet name resolution operates successfully, the cache file on your 
Windows 2000–based server might be corrupt, missing, or out of date. You can either replace the 
cache file with an original version of the cache file or manually enter the correct root hints 
into the cache file from the DNS console. If the DNS server is configured to load data on startup 
from Active Directory and the registry, you must use the DNS console to enter the root hints.
To enter root hints in the DNS console
1. In the DNS console, double-click the server to expand it.
2. Right-click the server, and then click Properties.
3. Click the Root Hints tab.
4. Enter your root hints, and then click OK.

To replace your cache file
1. Stop the DNS service by typing the following at the command prompt:
net stop dns
2. Type the following:
cd %Systemroot%\System32\DNS
3. Rename your cache file by typing the following:
ren cache.dns cache.old
4. Copy the original version of the cache file, which might be found in one of two places, 
by typing either of the following:
copy backup\cache.dns
– Or –
copy samples\cache.dns
5. Start the DNS service by typing the following:
net start dns

If name resolution to the Internet still fails, repeat the procedure, copying the cache file from 
your Windows 2000 source media.
To copy the cache file from your Windows 2000 source media
· At the command prompt, type the following:
expand <drive>:\i386\cache.dn_ %Systemroot%\system32\dns\cache.dns
where drive is the drive that contains your Windows 2000 source media.

Resolver does not take advantage of round robin feature.
Windows 2000 includes subnet prioritization, a new feature, which reduces network traffic across 
subnets. However, it prevents the resolver from using the round robin feature as defined in RFC 
1794. By using the round robin feature, the server rotates the order of A resource record data 
returned in a query answer in which multiple resource records of the same type exist for a 
queried DNS domain name. However, if the resolver is configured for subnet prioritization, the 
resolver reorders the list to favor IP addresses from networks to which they are directly 
connected.
If you would prefer to use the round robin feature rather than the subnet prioritization feature, 
you can do so by changing the value of a registry entry. For more information about configuring 
the subnet prioritization feature, see “Configuring Subnet Prioritization” earlier in this 
chapter.
WINS Lookup record causes zone transfer to a third-party DNS server to fail.
If a zone transfer from a Windows 2000 server to a third-party DNS server fails, check whether 
the zone includes any WINS or WINS-R records. If it does, you can prevent these records from 
being propagated to a secondary DNS server.
To prevent propagation of WINS lookup records to a secondary DNS server
1. In the DNS console, double-click your DNS server, right-click the zone name that contains 
the WINS record, and then click Properties.
2. In the Properties dialog box for the zone, click the WINS tab and select the check box Do 
not replicate this record.

To prevent propagation of WINS-R records to a secondary DNS server
1. In the DNS console, double-click your DNS server, right-click the reverse lookup zone 
that contains the WINS-R record, and then click Properties.
2. In the properties page for the zone, click the WINS-R tab and select the check box Do not 
replicate this record.

WINS lookup record causes a problem with authoritative data.
If you have a problem with incorrect authoritative data in a zone for which WINS lookup 
integration is enabled, the erroneous data might be caused by WINS returning incorrect data. You 
can tell whether WINS is the source of the incorrect data by checking the TTL of the data in an 
Nslookup query. Normally, the DNS service answers with names stored in authoritative zone data by 
using the set zone or resource record TTL value. It generally answers only with decreased TTLs 
when providing answers based on non-authoritative, cached data obtained from other DNS servers 
during recursive lookups.
However, WINS lookups are an exception. The DNS server represents data from a WINS server as 
authoritative but stores the data in the server cache only, rather than in zones, and decreases 
the TTL of the data.

To determine whether data comes from a WINS server
1. At the command prompt, type the following:
nslookup -d2
server <server>
where <server> is a server that is authoritative for the name that you want to test.
This starts nslookup in user-interactive, debug mode and makes sure that you are querying 
the correct server. If you query a server that is not authoritative for the name that you test, 
you are not able to tell whether the data comes from a WINS server.
2. To test for a WINS forward lookup, type the following:
set querytype=a
– Or –
To test for a WINS reverse lookup, type the following:
set querytype=ptr
3. Enter the forward or reverse DNS domain name that you want to test.
4. In the response, note whether the server answered authoritatively or non-authoritatively, 
and note the TTL value.
5. If the server does not answer authoritatively, the source of the data is not a WINS 
server. However, if the server answered authoritatively, repeat a second query for the name. 
6. In the response, note whether the TTL value decreased. If it did, the source of the data 
is a WINS server.

If you have determined that the data comes from a WINS server, check the WINS server for 
problems. 

A zone reappears after you delete it.
In some cases, when you delete a secondary copy of the zone, it might reappear. If you delete a 
secondary copy of the zone when an Active Directory-integrated copy of the zone exists in Active 
Directory, and the DNS server from which you delete the secondary copy is configured to load data 
on startup from Active Directory and the registry, the zone reappears.
If you want to delete a secondary copy of a zone that exists in Active Directory, configure the 
DNS server to load data on startup from the registry, and then delete the zone from the DNS 
server that is hosting the secondary copy of the zone. Alternatively, you can completely delete 
the zone from Active Directory when you are logged into a domain controller that has a copy of 
the zone. 

You see error messages stating that PTR records could not be registered
When the DNS server that is authoritative for the reverse lookup zone cannot or is configured not 
to perform dynamic updates, the system records errors in the event log stating that PTR records 
could not be registered. You can eliminate the event log errors by disabling dynamic update 
registration of PTR records on the DNS client. To disable dynamic update registration, add the 
DisableReverseAddressRegistrations entry, with a value of 1 and a data type of REG_DWORD, to the 
following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<name of the 
interface>
where name of the interface is the GUID of a network adapter.

Solving Dynamic Update and Secure Dynamic Update Problems

If you have problems with dynamic update, use the following steps to diagnose and solve your 
problem.

Troubleshooting Dynamic Update
If dynamic update does not register a name or IP address properly, use the following process to 
diagnose and solve your problem.
· Force the client to renew its registration by typing ipconfig /registerdns.
· Check whether dynamic update is enabled for the zone that is authoritative for the name 
that the client is trying to update.

· To rule out other problems, check whether the dynamic update client lists the primary DNS 
server for the zone as its preferred DNS server.
This is not necessary for dynamic update to work; however, if the client lists a 
preferred server other than the primary DNS server for the zone, many other problems might cause 
the failure, such as a network connectivity problem between the two servers or a prolonged 
recursive lookup for the primary server of the zone. To ascertain the preferred DNS server for 
the client, check the IP address configured in the TCP/IP properties of the network connection 
for the client, or at the command prompt type ipconfig /all.
If the zone is Active Directory-integrated, any DNS server that hosts an Active 
Directory-integrated copy of the zone can process the updates.
· Check whether the zone is configured for secure dynamic update.
If the zone is configured for secure dynamic update, the update can fail if zone or 
record security does not permit this client to make changes to the zone or record, or the update 
can fail if this client does not have ownership of the name that it is trying to update. To see 
whether the update failed for one of these reasons, check Event Viewer on the client. For more 
information about Event Viewer, see “Troubleshooting Tools” earlier in this chapter.
For information about what to do if the update failed because the zone is configured for 
secure dynamic update, see “Troubleshooting Secure Dynamic Update” later in this chapter.

Troubleshooting Secure Dynamic Update
Secure dynamic update can prevent a client from creating, modifying, or deleting records, 
depending on the ACL for the zone and the name. By default, secure dynamic update prevents a 
client from creating, deleting, or modifying a record if the client is not the original creator 
of the record. For example, if two computers have the same name and both try to register their 
names in DNS, dynamic update fails for the client that registers second. 
If a client failed to update a name in a zone that is configured for secure dynamic update, the 
failure could be caused by one of the following conditions:
· The system time on the client and the system time on the DNS server are not in sync.
· You have modified the UpdateSecurityLevel registry entry to disallow the use of secure 
dynamic update on the client. For more information about dynamic update and secure dynamic 
update, see “Dynamic Update and Secure Dynamic Update” earlier in this chapter.
· The client does not have the appropriate rights to update the resource record. You can 
confirm this by checking the ACL associated with the name to be updated.
If the client does not have the appropriate rights to update the resource record, check 
whether the DHCP server registered the name of the client and that the DHCP server is the owner 
of the corresponding dnsNode object. If so, you might consider placing the DHCP server in the 
DNSUpdateProxy security group. Any object created by a member of the DNSUpdateProxy security 
group has no security.

DNS and DHCP Useful commands for troubleshooting windows 2000 DNS

Useful commands for troubleshooting windows 2000 DNS

Windows 2000 rearranges list of DNS servers

Q. We have a situation in which we have several DNS server defined on our server. I configured the W2K server on a machine to be used as a proxy server. It was supposed to use 3 DNS servers for name solving, 2 on the Internet and the last one on the internal LAN (as a last resort). As you know, you can configure the order in which the DNS servers are accessed.

The DNS in the internal LAN is not having any real names, and is not communicating with the Internet in any way (the LAN is behind the firewall). I have noticed that the proxy W2K server was acting strange. After restarting it, it would server few clients OK and after that it will stop resolving names.

A. Windows 2000 clients will avoid slow and unresponsive DNS servers. The following is a brief description from the Windows 2000 Help:

<snip>
Avoidance of unresponsive DNS servers
The DNS Client service uses a server search list, ordered by preference. This list includes all preferred and alternate DNS servers configured for each of the active network connections on the system.

Windows 2000 rearranges these lists based on the following criteria:

Preferred DNS servers are given first priority.
If no preferred DNS servers are available, then alternate DNS servers are used.
Unresponsive servers are removed temporarily from these lists.