How to check and troubleshoot network faults through DNS technology

The server is not only the backbone of enterprise network equipment, but also the main body of enterprise software and database application. In the actual operation of the server will often occur such or such a fault, software or hardware. Many failures are not regular, we can only through experience to solve.

　　
The server is not only the backbone of enterprise network equipment, but also the main body of enterprise software and database application. In the actual operation of the server will often occur such or such a fault, software or hardware. Many failures are not regular, we can only through experience to solve. The author is responsible for the maintenance of the company's servers, in a practical work encountered a server can not log on the fault, the investigation is more peculiar, write out and share with you readers.

First, the phenomenon of failure:

The author of the company is not very large, there are about 50 computers, purchased two IBM servers, the model is x SERVICE 200. Because one of the applications used internally requires Windows domain support, the domain for Windows Server is enabled on both IBM servers. One as a domain controller DC and the other set as the backup domain controller BDC.

Since the backup domain controller is primarily a secondary role in the admin domain, no modifications and operations are made after the configuration is complete. However, in the previous paragraph, there was a failure of the primary domain controller DC that server could not log on to the system desktop, each time the domain controller was started to stay in the 2000 login interface, that is, in the request to enter the administrator account and password operation before the interface, below the login information is "Connected network Wait for nearly one hours still without any progress, always stay in the "Connecting network" prompt. Restarting the server presses F8 to enter Safe mode normally, but the problem mentioned above occurs as soon as the normal mode is entered.

Because the system login always stays in "Connecting network", I suspect that there is a problem with the network, for example, the primary domain controller cannot resolve itself through DNS. Try to enter Safe mode to disable the NIC so the system will not search the network and try to connect to the network. Sure enough, the system can get to the desktop normally by disabling the NIC.

However, disabling the NIC is not a permanent solution, although the server can log on to the desktop but the services provided are not available to other clients. Why can I log in without a network card? The author again will relieve the fault of the idea of centralized domain name resolution. It is well known that in a domain-enabled network, DNS-resolved domain names correspond to computers one by one, and any computer that does not retain the correct DNS counterpart name on the primary domain controller will not be able to use the network.

The author looks at the configuration of the DNS service on the primary domain controller and discovers that the primary domain controller's DNS address is set to back up the IP address of the domain controller. There appears to be a problem with DNS resolution on the backup domain controller. The author immediately to the backup domain controller to check, the original backup domain controller on the network cable and Nic interface is loose, that is, backup domain controller actually out of the entire network. After the network cable in the backup domain controller is plugged in, the network card on the primary domain controller is started and the system is properly entered, and the fault is eliminated.

This failure appears to be due to the loosening of the network cable on the backup domain controller, which is actually the result of a problem with the configuration of the domain that we are building, why do you say so? Because we'd better configure DNS according to the following rules when building a domain.

(1) The DNS service is installed on both the DC and the BDC, not just on a single server, preventing DNS parsing errors and providing redundancy for DNS resolution.

(2) The DC native DNS server is set to its own IP address, and the BDC native DNS server is also set to its own IP address.

(3) The secondary DNS server address is also set to the BDC address on the DC, and the secondary DNS server address on the corresponding BDC is set to the IP address of the DC.

In this way we do not easily have problems with DNS parsing, such as this failure will not happen. The DNS settings for your computer are automatically queried when you log on to the primary domain controller when DNS is resolved and connected to the network, even if the BDC network cable is loose or shutdown does not affect the DC login.

Summarize:

Configuring a domain controller in a Windows system is cumbersome, and failure occurs more irregularly, so it is important to follow the rules described above when upgrading a network as a domain, so that the probability of failure can be minimized.