How to check and troubleshoot network problems through DNS technology?

Servers are not only the backbone of enterprise network equipment, but also the mainstay of enterprise software and database applications. In actual operation, the server often has one or the other faults, software or hardware. Many faults are irregular, and we can only solve them through experience. The author is responsible for the maintenance of the company's servers. In a practical work, I encountered a failure that the server could not log in. The troubleshooting was more peculiar, and I wrote it out to share with readers.

First, the failure phenomenon:

The author company is not very large, there are about 50 computers, bought two IBM servers, the model is X SERVICE 200. Since an application software used internally requires Windows domain support, the Windows 2000 server domain is enabled on both IBM servers. One is the domain controller DC and the other is the backup domain controller BDC.

Since the backup domain controller plays a primary role in the management domain, basically no modifications and operations are performed after the configuration is completed. However, in the previous paragraph, there was a failure that the server of the primary domain controller DC could not log in to the system desktop. Each time the domain controller was started, it stayed in the login interface of 2000, that is, the interface before the administrator account and password operation were required. The login information below shows "Connecting to the network", waiting for nearly an hour and still no progress, always staying at the "Connecting to the network" prompt. Restart the server and press F8 to enter safe mode normally. However, as soon as you enter normal mode, the above mentioned problems occur.

Troubleshooting

Since the system login always stays at the "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 network card, so the system will not search the network, try to connect to the network. Sure enough, the system can enter the desktop normally after disabling the network card.

However, disabling the NIC does not cure the problem, although the server can log in to the desktop but the services provided are not available to other clients. Why can I log in without a network card? The author once again concentrated the idea of ​​resolving the fault on domain name resolution. It is well known that in a domain-enabled network, the DNS-resolved domain name has a one-to-one correspondence with the computer. Any computer that does not retain the correct DNS corresponding name on the primary domain controller will not be able to use the network.

The author checks the configuration of the DNS service on the primary domain controller and finds that the DNS address of the primary domain controller is set to the IP address of the backup domain controller. It seems that there is a problem with DNS resolution on the backup domain controller. The author immediately went to the backup domain controller to check that the connection between the network cable and the network card interface on the backup domain controller was loose, that is, the backup domain controller was actually disconnected from the entire network. After the network cable on the backup domain controller is plugged in and the network card on the primary domain controller is started, the system can enter the system normally, and the fault is eliminated.

Advanced thinking

This failure seems to be caused by the looseness of the network cable on the backup domain controller. Actually, it is the result of the configuration problem when we set up the domain. Why is this? Say? Because when building a domain, we'd better configure DNS according to the following rules.

(1) The DNS service is installed on both DC and BDC, instead of being enabled on only one server, preventing DNS resolution errors and providing redundancy for DNS resolution.

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

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

So we will not have a problem when doing DNS resolution, and this kind of failure will not happen. Because DNS authentication is performed when logging in to the primary domain controller and connecting to the network, the DNS settings of the local machine are automatically queried. Even if the BDC network cable is loose or shut down, the DC login will not be affected.

Summary:

Configuring a domain controller in a Windows system is a very cumbersome task, and the occurrence of a fault is even more irregular, so this initialization operation is also done when upgrading the network to a domain. Be sure to follow the rules outlined above to minimize the chance of failure.