Shulou(Shulou.com)05/31 Report--

How to solve the strange DNS fault, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

DNS naming looks up computers and services through the user's friendly name. When a user enters a DNS name in the application, the DNS service can resolve the name to other information related to the name, such as the IP address, and so on.

As a very important role in the enterprise, DNS service undertakes the important task of the enterprise. More and more enterprises begin to deploy internal DNS servers in their own enterprises. However, with the growth of network size and network traffic, DNS has also appeared a variety of strange failures. The author has encountered a strange DNS malfunction before. In order to solve this problem, after many twists and turns, we finally "subdued" this disobedient DNS server.

In order to express conveniently and from the point of view of confidentiality and security, the author hides the real name of the enterprise, which is called a certain group.

Let's first take a look at the network situation of the group.

Network status quo

Server status:

1. Two DC servers integrate DNS services, and one DNS server with an IP of 10.10.1.5 serves as the main DNS server with a relatively large load. The other 10.10.1.9 has a smaller load.

2. An OA server, on which an OA system developed by a third party company is installed on the OA server. The operating system is Windows Server 2003, which uses the release function of IIS6 to release the system of OA into WEB mode.

3. An Exchange Server server, which mainly provides mail service of OA office system.

4. A Web server, which mainly provides WWW access within the company

5. An OA SQL server, which mainly provides background database support for the office system OA.

6. A Web SQL server, which is mainly used as a background server for WEB Server

7, ERP server, etc., which has nothing to do with the case and will not be considered.

Network access equipment

1. Cisco switch is used in the access layer.

2. Cisco core router is used in core layer.

3. More than five types of unshielded twisted pair are used between each equipment.

4. The flying tower firewall is used to convert NET between the enterprise network and the public network.

Network topology diagram

Network Topology Diagram (part)

Network fault description

The local DNS server DNS01.contoso.net, which is a DC (active Directory Integration DNS). In the past, the Internet was accessed from China Mobile, but later, due to a problem with the mobile DNS server, the local DNS server could not resolve the external address. Later, it was changed to the DNS analysis of China Telecom, but it is still unable to analyze the external website very well. The specific problems are as follows:

1. Use nslookup to resolve internal addresses on the server, both positive and negative, no problem. (DNS's own simple query and recursive query tests also passed)

2, (on the server) to resolve external website addresses, some addresses can be resolved, some addresses can not be resolved, unresolvable addresses can be tried many times (up to 14 times) to resolve successfully. This is the crux of the problem: sometimes it can be parsed, sometimes it can't be resolved.

3, (on the client) can not resolve the external address, IE opens those websites that can not be resolved will not be opened (the server can not resolve, of course, can not open). The client needs to refresh the page multiple times.

Wrong row one:

First of all, check the configuration of the server: ip address, mask, gateway, DNS (refers to yourself), do a forwarding on the DNS transponder, forward to Telecom's DNS server 61.134.1.4. These are all correctly configured.

Second: suspect that there is a cache problem, so use the ipconfig / flushdns command to clear the cache of the server's identity as a client. Then use the DNSCMD / clearcache command to clear the cache of the DNS server itself. If the command does not work, use the methods in the DNS console to clear the cache, reload, or even restart the server. As a result, the problem remains the same. No record related to external server parsing was found in the DNS log. At the same time, I thought about whether the DNS cache was poisoned, so I checked the cache records in the cache one by one through the command. It is found that the cache records are normal and are signs of a virus, so the problem of cache virus is eliminated.

Third, it is found that the server network card is a gigabit adaptive network card, the switch is also a gigabit adaptive port, and the network cable uses more than five types of wires. It is suspected that when two gigabit adaptive ports pass through 100m super five unshielded lines, the super five lines are always used as 1000m, thus causing both parties to overclock this section of super five unshielded network lines through the network card (because there are no Category 6 lines on hand). Reduce the speed of the network card to 100m both on the server and on the switch. I found that the problem remained.

Fourth, it is suspected that it is caused by network delay. So using set timeout=5 in the nslookup command increases the response time of the nslookup query. It turns out that the query result is another 5-second timeout (the default for the nslookup program is 2-second timeout). So I increased the time to 10 seconds, and there was another 10-second timeout. That is to say, the fundamental use of the question to increase the query time is a timeout.

Conclusion: it may be that there are factors in the network that lead to the timeout of DNS query. Could be caused by network hardware.

Error number two:

Judging from the symptoms of DNS query, it may be caused by network delay, considering that there are three reasons for delay:

One is that the interfaces between the server and the core switch in the network are 1000m interfaces, and the connecting cable uses more than Category 5 unshielded twisted pair, so a Category 6 twisted pair of 7 meters is specially purchased to replace the original Category 5 unshielded wire. after the replacement, it was found that it had not changed much. As a result, the problem of DNS query delay caused by network cable overclocking is eliminated.

The second is that there are a large number of broadcast packets in the network, which increases the probability of data collision. A large number of broadcast packets in the network are generally caused by problems with switches or routers. Then check the configuration of the switch or router and find that the hot backup method is used on the router to connect the two Cisco routers. And the position of the network cable does not correspond to the hot backup position. It was suspected that it was caused by the location of the network cable. Later, after work, the position of the network cable was reset to the original initialized position, and it was found that the DNS query had been slightly improved. But the parsing failure still exists. This eliminates the problem caused by the configuration of the network cable and switch.

Third, consider whether the ports on the firewall open the UDP53 and TCP53 ports required by the DNS service, because only one TCP or UDP port is opened, there will also be DNS query delay failure. So check the firewall configuration and find that the corresponding port is opened correctly on the firewall. Then troubleshoot the setting of the firewall.

Conclusion: troubleshoot the hardware and settings of routers, switches and firewalls.

Thinking: analyze the failure of query failure through the flow direction of the query of the packet

Wrong number three

First of all, the MPS report of the configuration status of the server (MPSRPT_NETWORK, MPS report download address http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en) is collected from the server, and all kinds of log files in the MPS report are checked. DCDIAG does not report any errors. Check the DNS server log again. I did find a lot of warnings and error logs in the DNS server log, but after careful study, I found them to be irrelevant to the problem (similar error warnings have been rarely reported since 2010). In addition, considering that this is an external URL resolution problem, there is no internal problem, so you can ignore these errors and warning logs. From other logs, there are no errors that may be related to this problem.

In view of the fact that the above schemes are not effective, we grab the packet 4 times from the server and client, and analyze the cause of the failure by grabbing the packet.

From the point of view of the client grabbing the packet, using the telecom server 61.134.1.4 to resolve the address directly, and found that the resolution was all successful, including www.sina.com,www.sohu.com,www.google.com,www.tudou.com,www.xiaoli.cc,www.hao123.com,www.chinaren.com, and did not find any errors.

However, when you specify the client's DNS as internal server 10.10.1.5, you find that a timeout occurs when you parse sites such as www.tudou.com,www.chinaren.com,www.sohu.com. Try to compare which link causes the delay through the following steps:

Step 1:

In the client 10.20.2.5 grab packet, find a DNS request, for example, parsing the www.sohu.com is not successful. The request was sent at Jan 13, 2010 12 Jan 23 Jan 52.823093000

Then we see in the same grab packet from DNS server 10.10.1.5, the result is parsing failure, the error code is Server failure (2), the receiving time of this reply is Jan 13, 2010 12-12-24-Jan-03.790867000 with an interval of about 10 seconds.

Step 2:

In the grab package of DNS server 10.10.1.5, I try to find the corresponding DNS request from 10.20.2.5 to see how the DNS server forwards this DNS request to the telecom server 61.134.1.4. But I did not see a DNS request containing www.sohu.com from the client 10.20.2.5 during the 2010 period of time between 52.823093000 and 03.790867000. Such a DNS request that is close to this time period occurs at Jan 13, 2010 12 23 47.056713000. I found it strange that I re-examined other failed requests and found similar problems. So I suspect that the system time of the DNS server and this client is not synchronized.

In addition, I found that the server was heavily loaded per unit time, or it was possible that the DNS server was too busy to respond to some address resolution requests from the client in a timely manner.

Then I checked the debug log of the packet grab and nslookup that I just captured. I found that it can be parsed normally when I directly use the telecom DNS server. But when you change the DNS server to internal server 10.10.1.5, you find a lot of timeouts. Then I checked the grab package, and also compared the client grab packet with the server grab package, and found that there is a relatively obvious time difference between the two. In addition, there are the following findings:

Step 1:

In the client grab package, I found a DNS request that failed to parse www.sina.com. The client sent it at the time of Jan 13, 2010 14R 34R 16.876351000.

Then check the same grab packet, and the reply from the DNS server is Jan 13, 2010 14 Server failure 34 21.175179000, the result is parsing failure, the error code is still Server failure (2). Here the interval between request and reply is 5 seconds, which is the default timeout interval for DNS servers.

Step 2

In the server grab packet, the same DNS request packet containing www.sina.com from the client 10.20.2.5 arrives at the internal DNS server 10.10.1.5 at Jan 13, 2010 14frex34 15.041088000, which is still about 1 second behind the client side. The time when the internal DNS server redirects this DNS request to the telecom server 61.134.1.4 is Jan 13, 2010 14 Jan 15.041088000. However, since then, the internal server has not received a reply packet about the request from the telecom server.

Therefore, from the results here, the failure of the telecom server to respond in time is also one of the reasons why the parsing is not successful.

From the above analysis, I have the following doubts:

1. Ensure that the timeline of the client and DNS server in the domain is synchronized

two。 Check that the telecom DNS server 61.134.1.4 sometimes fails to respond in time, or it may be because it is too busy. Check the link from the telecom to the corporate network.

3. Add additional DNS servers to carry out DNS load balancing to make load balancing.

Solution 1:

The time configuration of the clients in the network is checked and it is found that the timelines of all clients are synchronized and there is no time lag problem. So as soon as the suspicion is ruled out.

Invite the telecom engineers and us to go to the telecom company to check the telecom DNS server. It is found that there is no problem with the DNS service of China Telecom. And the optical cable communication between the telecom and the group is also normal, and there is no delay and point of failure, and the telecom DNS problem is eliminated step by step.

At this time, it is found that there is only one situation, that is, the excessive load becomes the cause of the fault. So the DNS server within the group was adjusted to direct all the traffic from the sub-airport (a sub-unit of the group) to the normal DNS server (192.168.1.9), and the problem was solved.

But just as we were about to raise our glasses to celebrate, the problem arose again. The normal DNS server (192.168.1.9) experienced the same failure behavior as the previous DNS after a week of normal operation. As a result, we grabbed the once-normal DNS server (192.168.1.9) and found that this DNS server had the same problem as the previous DNS server. That is, the DNS server receives a large number of query packets per unit time, and some packets can not be forwarded successfully in time. Considering that both DNS servers have the same problem when there is a large increase in traffic, consider immediately whether it is server performance and traffic. Then check the two DNS servers, found that the two DNS servers are early IBM servers, the performance is not high, the memory is also small, coupled with the installation of Windows Server2003 network operating system, but the Windows Server2003 operating system DNS processing and forwarding capacity is not as good as Windows Server2008, especially the Windows Server2008 system DNS function in the background area loading and DNS forwarding performance improvement, will greatly increase the forwarding efficiency of DNS. And considering that the group also has Wins servers, through the GlobalNames region function in Windows Server2008DNS, the original Wins and DNS servers can be merged to solve the problem of single label access. So I came up with the following solutions.

Solution 2:

Because considering the debugging and modification directly on the real network server, it may affect the normal operation of the network. Therefore, through the P2V technology of Microsoft's SCVM2007 (virtualization technology), all the real physical servers are virtualized into a virtual server, with a total of 8 virtual servers. Then do a stress test in a virtual network. After passing the virtual network stress test, it is found that the above problems do exist. So proceed with method three.

Solution 3:

1. Purchase 2 new high-performance IBM servers and upgrade the original Windows Server 2003DNS integrated active directory to Windows Server 2008 in the group.

two。 Two AD servers integrated with DNS services are set up through the load balancing function of Windows Server. Instead of manually specifying the client's DNS server to a server as before, the two DNS will simply let the server load itself.

Method 2 has been implemented for two months, and both DNS servers are working properly. It was only then that the problem was completely solved.

Summary:

1. The DNS server is becoming more and more important and the load is increasing, but we often ignore the load problem of the DNS server because we consider that DNS is only for name resolution and the work pressure is not great.

two。 Try to use the latest Windows Server network operating system, performance and processing power have been improved.

3. In the case of network failure, try to simulate the network environment first, and do not modify it directly on the real server to avoid further expansion of the server failure. Use virtual environments whenever possible.

4. When you encounter problems, you should analyze them carefully and verify them carefully. In line with the principle of "soft before hard". The problem will be solved satisfactorily.

The solution to the strange DNS fault

Microsoft Advanced Technology training Center of Northwestern Polytechnic University

Lecturer: Zhang Chi MCP ID:3098942

DNS is the abbreviation of Domain name system (Domain Name System). It was first invented by Paul Moca Paijos (Paul Mockapetris) in 1983. The Domain name system (DNS) is a system for naming computers and network services in a TCP/IP network, which organizes these computers and network services into a domain hierarchy. DNS naming looks up computers and services through the user's friendly name. When a user enters a DNS name in the application, the DNS service can resolve the name to other information related to the name, such as the IP address, and so on.

As a very important role in the enterprise, DNS service undertakes the important task of the enterprise. More and more enterprises begin to deploy internal DNS servers in their own enterprises. However, with the growth of network size and network traffic, DNS has also appeared a variety of strange failures. The author has encountered a strange DNS malfunction before. In order to solve this problem, after many twists and turns, * finally "subdued" this disobedient DNS server.

In order to express conveniently and from the point of view of confidentiality and security, the author hides the real name of the enterprise, which is called a certain group.

Let's first take a look at the network situation of the group.

Network status quo

Server status:

1. Two DC servers integrate DNS services, and one DNS server with an IP of 10.10.1.5 serves as the main DNS server with a relatively large load. The other 10.10.1.9 has a smaller load.

2. An OA server, on which an OA system developed by a third party company is installed on the OA server. The operating system is Windows Server 2003, which uses the release function of IIS6 to release the system of OA into WEB mode.

3. An Exchange Server server, which mainly provides mail service of OA office system.

4. A Web server, which mainly provides WWW access within the company

5. An OA SQL server, which mainly provides background database support for the office system OA.

6. A Web SQL server, which is mainly used as a background server for WEB Server

7, ERP server, etc., which has nothing to do with the case and will not be considered.

Network access equipment

1. Cisco switch is used in the access layer.

2. Cisco core router is used in core layer.

3. More than five types of unshielded twisted pair are used between each equipment.

4. The flying tower firewall is used to convert NET between the enterprise network and the public network.

Network topology diagram

Network Topology Diagram (part)

Network fault description

The local DNS server DNS01.contoso.net, which is a DC (active Directory Integration DNS). In the past, the Internet was accessed from China Mobile, but later, due to a problem with the mobile DNS server, the local DNS server could not resolve the external address. Later, it was changed to the DNS analysis of China Telecom, but it is still unable to analyze the external website very well. The specific problems are as follows:

1. Use nslookup to resolve internal addresses on the server, both positive and negative, no problem. (DNS's own simple query and recursive query tests also passed)

2, (on the server) to resolve external website addresses, some addresses can be resolved, some addresses can not be resolved, unresolvable addresses can be tried many times (up to 14 times) to resolve successfully. This is the crux of the problem: sometimes it can be parsed, sometimes it can't be resolved.

3, (on the client) can not resolve the external address, IE opens those websites that can not be resolved will not be opened (the server can not resolve, of course, can not open). The client needs to refresh the page multiple times.

Wrong row one:

First of all, check the configuration of the server: ip address, mask, gateway, DNS (refers to yourself), do a forwarding on the DNS transponder, forward to Telecom's DNS server 61.134.1.4. These are all correctly configured.

Second: suspect that there is a cache problem, so use the ipconfig / flushdns command to clear the cache of the server's identity as a client. Then use the DNSCMD / clearcache command to clear the cache of the DNS server itself. If the command does not work, use the methods in the DNS console to clear the cache, reload, or even restart the server. As a result, the problem remains the same. No record related to external server parsing was found in the DNS log. At the same time, I thought about whether the DNS cache was poisoned, so I checked the cache records in the cache one by one through the command. It is found that the cache records are normal and are signs of a virus, so the problem of cache virus is eliminated.

Third, it is found that the server network card is a gigabit adaptive network card, the switch is also a gigabit adaptive port, and the network cable uses more than five types of wires. It is suspected that when two gigabit adaptive ports pass through 100m super five unshielded lines, the super five lines are always used as 1000m, thus causing both parties to overclock this section of super five unshielded network lines through the network card (because there are no Category 6 lines on hand). Reduce the speed of the network card to 100m both on the server and on the switch. I found that the problem remained.

Fourth, it is suspected that it is caused by network delay. So using set timeout=5 in the nslookup command increases the response time of the nslookup query. It turns out that the query result is another 5-second timeout (the default for the nslookup program is 2-second timeout). So I increased the time to 10 seconds, and there was another 10-second timeout. That is to say, the fundamental use of the question to increase the query time is a timeout.

Conclusion: it may be that there are factors in the network that lead to the timeout of DNS query. Could be caused by network hardware.

Error number two:

Judging from the symptoms of DNS query, it may be caused by network delay, considering that there are three reasons for delay:

One is that the interfaces between the server and the core switch in the network are 1000m interfaces, and the connecting cable uses more than Category 5 unshielded twisted pair, so a Category 6 twisted pair of 7 meters is specially purchased to replace the original Category 5 unshielded wire. after the replacement, it was found that it had not changed much. As a result, the problem of DNS query delay caused by network cable overclocking is eliminated.

The second is that there are a large number of broadcast packets in the network, which increases the probability of data collision. A large number of broadcast packets in the network are generally caused by problems with switches or routers. Then check the configuration of the switch or router and find that the hot backup method is used on the router to connect the two Cisco routers. And the position of the network cable does not correspond to the hot backup position. It was suspected that it was caused by the location of the network cable. Later, after work, the position of the network cable was reset to the original initialized position, and it was found that the DNS query had been slightly improved. But the parsing failure still exists. This eliminates the problem caused by the configuration of the network cable and switch.

Third, consider whether the ports on the firewall open the UDP53 and TCP53 ports required by the DNS service, because only one TCP or UDP port is opened, there will also be DNS query delay failure. So check the firewall configuration and find that the corresponding port is opened correctly on the firewall. Then troubleshoot the setting of the firewall.

Conclusion: troubleshoot the hardware and settings of routers, switches and firewalls.

Thinking: analyze the failure of query failure through the flow direction of the query of the packet

Wrong number three

First of all, the MPS report of the configuration status of the server (MPSRPT_NETWORK, MPS report download address http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en) is collected from the server, and all kinds of log files in the MPS report are checked. DCDIAG does not report any errors. Check the DNS server log again. I did find a lot of warnings and error logs in the DNS server log, but after careful study, I found them to be irrelevant to the problem (similar error warnings have been rarely reported since 2010). In addition, considering that this is an external URL resolution problem, there is no internal problem, so you can ignore these errors and warning logs. From other logs, there are no errors that may be related to this problem.

In view of the fact that the above schemes are not effective, we grab the packet 4 times from the server and client, and analyze the cause of the failure by grabbing the packet.

From the point of view of the client grabbing the packet, using the telecom server 61.134.1.4 to resolve the address directly, and found that the resolution was all successful, including www.sina.com,www.sohu.com,www.google.com,www.tudou.com,www.xiaoli.cc,www.hao123.com,www.chinaren.com, and did not find any errors.

However, when you specify the client's DNS as internal server 10.10.1.5, you find that a timeout occurs when you parse sites such as www.tudou.com,www.chinaren.com,www.sohu.com. Try to compare which link causes the delay through the following steps:

Step 1:

In the client 10.20.2.5 grab packet, find a DNS request, for example, parsing the www.sohu.com is not successful. The request was sent at Jan 13, 2010 12 Jan 23 Jan 52.823093000

Then we see in the same grab packet from DNS server 10.10.1.5, the result is parsing failure, the error code is Server failure (2), the receiving time of this reply is Jan 13, 2010 12-12-24-Jan-03.790867000 with an interval of about 10 seconds.

Step 2:

In the grab package of DNS server 10.10.1.5, I try to find the corresponding DNS request from 10.20.2.5 to see how the DNS server forwards this DNS request to the telecom server 61.134.1.4. But I did not see a DNS request containing www.sohu.com from the client 10.20.2.5 during the 2010 period of time between 52.823093000 and 03.790867000. Such a DNS request that is close to this time period occurs at Jan 13, 2010 12 23 47.056713000. I found it strange that I re-examined other failed requests and found similar problems. So I suspect that the system time of the DNS server and this client is not synchronized.

In addition, I found that the server was heavily loaded per unit time, or it was possible that the DNS server was too busy to respond to some address resolution requests from the client in a timely manner.

Then I checked the debug log of the packet grab and nslookup that I just captured. I found that it can be parsed normally when I directly use the telecom DNS server. But when you change the DNS server to internal server 10.10.1.5, you find a lot of timeouts. Then I checked the grab package, and also compared the client grab packet with the server grab package, and found that there is a relatively obvious time difference between the two. In addition, there are the following findings:

Step 1:

In the client grab package, I found a DNS request that failed to parse www.sina.com. The client sent it at the time of Jan 13, 2010 14R 34R 16.876351000.

Then check the same grab packet, and the reply from the DNS server is Jan 13, 2010 14 Server failure 34 21.175179000, the result is parsing failure, the error code is still Server failure (2). Here the interval between request and reply is 5 seconds, which is the default timeout interval for DNS servers.

Step 2

In the server grab packet, the same DNS request packet containing www.sina.com from the client 10.20.2.5 arrives at the internal DNS server 10.10.1.5 at Jan 13, 2010 14frex34 15.041088000, which is still about 1 second behind the client side. The time when the internal DNS server redirects this DNS request to the telecom server 61.134.1.4 is Jan 13, 2010 14 Jan 15.041088000. However, since then, the internal server has not received a reply packet about the request from the telecom server.

Therefore, from the results here, the failure of the telecom server to respond in time is also one of the reasons why the parsing is not successful.

From the above analysis, I have the following doubts:

1. Ensure that the timeline of the client and DNS server in the domain is synchronized

two。 Check that the telecom DNS server 61.134.1.4 sometimes fails to respond in time, or it may be because it is too busy. Check the link from the telecom to the corporate network.

3. Add additional DNS servers to carry out DNS load balancing to make load balancing.

Solution 1:

The time configuration of the clients in the network is checked and it is found that the timelines of all clients are synchronized and there is no time lag problem. So as soon as the suspicion is ruled out.

Invite the telecom engineers and us to go to the telecom company to check the telecom DNS server. It is found that there is no problem with the DNS service of China Telecom. And the optical cable communication between the telecom and the group is also normal, and there is no delay and point of failure, and the telecom DNS problem is eliminated step by step.

At this time, it is found that there is only one situation, that is, the excessive load becomes the cause of the fault. So the DNS server within the group was adjusted to direct all the traffic from the sub-airport (a sub-unit of the group) to the normal DNS server (192.168.1.9), and the problem was solved.

But just as we were about to raise our glasses to celebrate, the problem arose again. The normal DNS server (192.168.1.9) experienced the same failure behavior as the previous DNS after a week of normal operation. As a result, we grabbed the once-normal DNS server (192.168.1.9) and found that this DNS server had the same problem as the previous DNS server. That is, the DNS server receives a large number of query packets per unit time, and some packets can not be forwarded successfully in time. Considering that both DNS servers have the same problem when there is a large increase in traffic, consider immediately whether it is server performance and traffic. Then check the two DNS servers, found that the two DNS servers are early IBM servers, the performance is not high, the memory is also small, coupled with the installation of Windows Server2003 network operating system, but the Windows Server2003 operating system DNS processing and forwarding capacity is not as good as Windows Server2008, especially the Windows Server2008 system DNS function in the background area loading and DNS forwarding performance improvement, will greatly increase the forwarding efficiency of DNS. And considering that the group also has Wins servers, through the GlobalNames region function in Windows Server2008DNS, the original Wins and DNS servers can be merged to solve the problem of single label access. So I came up with the following solutions.

Solution 2:

Because considering the debugging and modification directly on the real network server, it may affect the normal operation of the network. Therefore, through the P2V technology of Microsoft's SCVM2007 (virtualization technology), all the real physical servers are virtualized into a virtual server, with a total of 8 virtual servers. Then do a stress test in a virtual network. After passing the virtual network stress test, it is found that the above problems do exist. So proceed with method three.

Solution 3:

1. Purchase 2 new high-performance IBM servers and upgrade the original Windows Server 2003DNS integrated active directory to Windows Server 2008 in the group.

two。 Two AD servers integrated with DNS services are set up through the load balancing function of Windows Server. Instead of manually specifying the client's DNS server to a server as before, the two DNS will simply let the server load itself.

Method 2 has been implemented for two months, and both DNS servers are working properly. It was only then that the problem was completely solved.

Summary:

1. The DNS server is becoming more and more important and the load is increasing, but we often ignore the load problem of the DNS server because we consider that DNS is only for name resolution and the work pressure is not great.

two。 Try to use the latest Windows Server network operating system, performance and processing power have been improved.

3. In the case of network failure, try to simulate the network environment first, and do not modify it directly on the real server to avoid further expansion of the server failure. Use virtual environments whenever possible.

4. When you encounter problems, you should analyze them carefully and verify them carefully. In line with the principle of "soft before hard". The problem will be solved satisfactorily.

This is the answer to the question about how to solve the strange DNS fault. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.