Do not ignore DNS settings when network combat domain controllers are built

The domain controller is the core of corporate network management, and its failure often causes the logon failure of the whole network user's computer. However, when you set up a domain controller, you often ignore the DNS settings, causing the DNS in the domain to cause frequent failures. Do you know the importance of DNS? What would happen if DNS settings went wrong? The author is responsible for the maintenance of the company's servers, recently in the actual work encountered a sudden DNS-related server failure.

Failure phenomenon

Company size is not very large, there are about 50 computers, purchased two IBM servers. 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, recently there has been a failure of the primary domain controller DC server to log on to the system desktop. Each time the domain controller is started to stay in the login interface (that is, the interface before the Administrator account and password operation is required), the login information below shows "connecting to the network", and there is still no progress pending for nearly one hours. Restarting the server presses the F8 key to enter Safe mode normally, however, as soon as one enters the normal mode, the above problem occurs.

Troubleshooting

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. The author tries to enter Safe mode to disable the NIC so that the system will not search the network and will not attempt 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 you log on without a NIC? The author once again the idea of troubleshooting to focus on 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. When the network cable on the backup domain controller is plugged in, the NIC on the primary domain controller can enter the system normally and the fault is eliminated.

Advanced Thinking

This failure seems to be due to the loose network cable on the backup domain controller, which is actually the result of a problem with our configuration when we set up the domain, because we are ignoring the configuration of DNS. When you establish a domain, it is a good idea to configure DNS according to the following rules.

1.DC The DNS service is installed on the BDC and not only on one server, preventing DNS parsing errors and providing redundancy for DNS resolution.

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

The 3.DC secondary DNS server address is set to the address of the BDC, 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 go wrong when we do DNS parsing. Because logging on to the primary domain controller for DNS resolution and connection to the network automatically queries the DNS settings for this computer, even if the BDC network cable is loose or shutdown does not affect the DC login.

Summary: Configuring a domain controller in a Windows system is a hassle, and failure occurs without regularity, so it is important to follow the rules when upgrading a network as a domain, so that the probability of failure can be minimized.