Windows Server DNS faults

Before discussing how to resolve the DNS issue, we want to know whether you know how to determine whether a problem is caused by DNS rather than by other naming services. On a Windows host, it is difficult to determine whether the cause of the problem lies in DNS. Windows supports many naming services, such as DNS, Wins, HOSTS, and LMHOSTS. However, the commonly used Windows 2000 nslookup ignores all these naming services. You may only run nslookup and query name servers on Windows 2000 computers, but the problematic service may use another Naming Service. First, you need to consider which type of program has a problem. If it is a TCP/IP client, such as telnet or ftp, the problem may occur in the DNS and HOSTS files. If it is a utility that supports NetBIOS naming, such as net (the same as in net use), it is doubtful to include Wins and LMHOSTS files. Other clients that use DNS or NetBIOS names as parameters (such as ping) also use any of these naming services. Next, consider the order in which Windows uses these naming services. Check various services in this order when looking for problems. These prompts will help you identify the crux of the problem, at least to help you eliminate a suspect object.
　　
To check the cache area of a server, click the plus sign to the left of the server name in the left pane of the DNS console. You will see a folder named Cached Lookups. Click the plus sign on the left or double-click the folder icon or tag to expand the next level. This shows the top-level domains that your name server has cached data. Continue to expand until you see the Domain Name of the cached data you want to view. For example, our name server has cached three NS records and one A record for microsoft.com. If you double-click "net" and "hp", we will also see the cache addresses of these name servers. To view the TTL on the cached data, double-click a record in the right pane. If the DNS console is in advanced view mode (select View> advanced), the displayed window displays the TTL of the record. Before TTL check, you must use the operation> refresh or press F5 to refresh the DNS console. Otherwise, the TTL you see may be greater than the current TTL. If you right-click the record, you may notice an option to delete the record.
　　
Common DNS errors
　　
1. Forgot to add the serial number
　　
Some problems may occur when you manually change the region data file instead of using the DNS console. The DNS console will remember to add a serial number to the SOA record every time it changes the region data, so you don't have to worry about this. However, this also means that you may not get into the habit of updating the serial number, so you may forget to add the serial number when making one-time manual modification. The main symptom of this problem is that the slave name server won't get any changes you made to the region on the master server. The slave server does not think that the region data has not changed because the serial number it sees is still the original serial number. How can I check if I remember to add a serial number? Unfortunately, this is not that easy. If you do not remember the original serial number, but the current serial number cannot indicate when it was updated, there is no direct way to determine whether it has been changed. When you start the master server, whether or not you have changed the serial number, it will load the updated regional data file. The best way is to use nslookup to compare the data returned by the master server and the slave server. If they return different data, you may have forgotten to add the serial number. If you think of a recent change, you can view the data. If you cannot remember the last change, you can copy the region from a master server and a slave server, sort the results, and use the File comparison tool to compare them. There is also good news that, although it is difficult to determine whether the region has been copied before, it is very easy to make sure that the region has been copied. You only need to double-click the SOA record on the DNS console and manually edit the serial number field to add the serial number in the copy of this region on the master server. The slave server will obtain the new data within the refresh interval. If they use NOTIFY, it will be faster.
　　
2. Manually change the DNS server
　　
Remember that the Microsoft DNS Server regularly updates data files in its region. Each time you use the DNS console to change the data in a region, a write operation is suspended: Before the DNS server exits, it must overwrite the data file in the region, otherwise, your changes will be lost. This can be compared to an updated page in memory: the operating system must write it to the disk before exiting. If you manually change the data file in a region during a write operation suspension, the changes will be lost inexplicably after the name server exits. For example, when the server is running and a write operation is suspended, you add a delegate to a new subdomain named microsoft.com. After making the changes, you must stop the server and start it again so that it can read the data in the region again. However, when the server exits, it will overwrite the data file in the microsoft.com region, and your delegation will be discarded. If you carefully observe The Event Viewer (which is usually needed), you will see a message like this before The server stops The event: The DNS server wrote version 37 of zone microsoft.com to file microsoft.com. dns. (the DNS server writes version 37 of the region microsoft.com to the file microsoft.com. dns .) If you use operation | update the server data file to force the server to rewrite its regional data file, the server will synchronize with the regional data file instead of rewriting at exit. Therefore, if you want to manually change the region data file, either stop the server first (but this means that the server will not respond to any queries during the change ), you can either use the DNS console to synchronize the server and regional data files and then make changes.
　　
3. The slave server cannot load the region data.
　　
If a slave server cannot obtain the current serial number of a region from its master server, it will not send you a warning message at first. However, if the problem persists and the slave server cannot determine whether its data is up-to-date within the validity period, the region will expire. On a Microsoft DNS Server, you will see a message similar to the following in the Event Viewer: the microsoft.com region times out and has been disabled before successful replication in the region or replication from the primary server in the region as its source. After the region expires, When you query data in the region from the name server, you will receive the SERVFAIL error message:
C:> nslookup robocop wormhole.microsoft.com.
Server: wormhole.microsoft.com
Addresses: 207.46.230.219, 192.253.253.1
Wormhole.microsoft.com can't find robocop.microsoft.com: Server failed
　　
There are three main reasons for this problem: Due to network failure and disconnection from the master server, the IP address configured for the master server is incorrect, A syntax error occurs in the region data file on the master server. First, you should use the DNS console to check the address of the master server that the slave server is trying to load data from. Right-click the Domain Name of the region in the left pane, select properties, and view the General tab to check whether it is the IP address of the Master name server. If yes, check the connection to this IP Address: C:> ping 207.46.230.219
Pinging 207.46.230.219 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
　　
If you cannot connect to the master server, check whether the host is running (for example, powered on) or check for network problems. You may also need to check whether the master server returns an authoritative response to the data query in the region. If the response of the master server is not authoritative for the region, the slave server will not copy the region from the master server. You can use nslookup to check the authoritative response of the master server to the SOA record of the region. The command format is as follows:
C:> nslookup-norec-type = SOA microsoft.com. 207.46.230.219
　　
This command sends a non-recursive query to the name server located at 152.104.1.6 to query the SOA record of microsoft.com. We must send a non-recursive query so that the name server located in 152.104.1.6 will not forward the query to another server. If the master server is correctly configured, the response to this query should be authoritative. (Remember, the response is authoritative unless nslookup returns an "unofficial" response .) An unauthoritative response may indicate that the master server encountered a problem when loading the region, usually due to a syntax error in the region data file. Contact the administrator of the master server to check whether there is a message indicating a syntax error in the event viewer or system log output. We have never seen that the Windows 2000 naming server is not authoritative in this region due to syntax errors in the region data file, but the old BIND naming server does. Therefore, if your name server is a subordinate server in a region and the main name server in this region is a BIND name server, the server is not authoritative in this region, the problem may be a syntax error. If the response to the query is authoritative but the slave server still cannot successfully copy the region, you can use the nslookup ls command to manually copy the region. If you see an error message similar to the following, it is likely that the master server restricts region replication:
C:> nslookup-152.104.1.6
Default Server: terminator.microsoft.com
Address: 152.104.1.6
> Ls microsoft.com
[Terminator.microsoft.com]
* ** Can't list domain microsoft.com: Query refused
　　
Contact the administrator of the master server to check whether regional replication is restricted. Ask him to check the options on the region replication tab of the Properties window of the region you are trying to copy (if he is running Microsoft DNS Server ). If the remote server is running BIND, is it using the xfrnets or allow-transfer Function to restrict region replication. After the problem has been ruled out and your server can successfully copy the region, you will see the following message in the Event Viewer: A more recent version, version 212 of zone microsoft.com was
Found at DNS server at 207.46.230.219. Zone transfer is in progress.
The DNS server wrote version 212 of zone microsoft.com
　　
File microsoft.com. dns. (On the DNS server of 207.46.230.219, find the latest version 212 of region microsoft.com. Copying the region in progress. The DNS server writes version 212 of the region microsoft.com to the file microsoft.com. dns .)
　　
There are several other cases of DNS faults that we will continue to discuss in the next period.
Asp> http://www.netadmin.com.cn/experience/20040609/2888.asp
　　
4. network connection disconnected