The DNS record disappears! What should I do?

The DNS record disappears! Don't be confused. It's not so terrible. The first thing you need to do is to find the invisible DNS records (as described above). Now you have calmed down, let's take a look at how to fix the DNS records that disappear!

Fix "corrupted" or wrong DNS records

If the DNS record is corrupted or is not updated in time, you can use dynamic registration to easily fix the problem. For example, the DNS alias record used to map the GUID from the server to the server FQDN is often used in AD replication. Restoring or reinstalling DC may result in copying the alias records that do not clear old records. If there are multiple alias records or the records are incorrect, delete these problem records and the server will log on to the correct records again. This usually takes 15 minutes, but you can restart the Netlogon service for faster feedback. Remember to refresh the DNS Management Unit to view new records. All record types can use this method to register correct records.

Fix "disappear" DNS zone

An administrator is trying to clear the DNS from the DC. He mistakenly deleted the DNS zone from the unit on the DC. He ignored the warning that this would remove the zone from the AD. Within a few minutes, the entire production DNS zone disappeared... Oh, my God! Gone! He is thinking about looking for the next job, but I assure him that this can be easily fixed thanks to dynamic registration. We simply re-built the DNS zone, restarted Netlogon on each DC, and then re-formed the zone. Some static A records must be manually input, but they own the information. I do not recommend this as a solution, but I do use it when the entire zone is cleaned (the meaningful records and names are resolved differently on different DNS servers. Delete the region and re-register the DC.

Recover damaged ADI Zone

Although the basic DNS function of the Active Directory (which stores files in the Active Directory) is faster and more efficient than the standard DNS, it also has some disadvantages:

The zone file is not a simple text file on the disk, and can only be viewed and operated by the AD tool.

Different replication ranges are stored in different locations in AD, which makes it very difficult to locate DNS records.

The ADI region becomes "corrupt" because the DNS records are not consistent across all DC, and the DNS query results are inconsistent.

Suppose you don't want to destroy the entire zone. If you suspect that the ADI zone is damaged (not behavior during domain name resolution), there is a cool technique that can bring the ADI (Multi-Basic) back on track.

Determine a correct name server to use as a new source (select a PDC simulator or view DNS errors, performance, and so on ).

Go to the DNS Management Unit-partition property. Select the zone type and configure the zone to the standard DNS zone (see here ). You can do this by not selecting the "store in the Active Directory" option. This will dump DNS information from AD to the hosts file on the DC hard disk.

Go to another DC/nameserver-DNS management unit and delete the zone. This will delete it from the Active Directory (a prompt will be displayed ).

Wait for the replication and then check each DC/name server to ensure that the zone disappears from the AD. You can also use LDP and view the three locations in AD (table 1) to ensure that there are no DNS records. If you see them, you have not deleted the region or copied it.

When DNS is removed from the AD, keep the configuration for two or three days. Now you have a single source (control), so there may be no inconsistency. Make sure that all operations are normal. Creating a standard subarea pointing to the name server as a control is a good idea, so you will have better name resolution performance during this transition period.

Change the standard base to the ADI zone. Go to DNS unit-zone-properties-enter and check the "store the Zone in the Active Directory" option.

Select "copy" from "area property" to "Copy range" (see here ).

Change the subarea to the ADI area:

Delete the subarea from the DNS unit on each name server. Restart the DNS and it will automatically log on to the server. You may need to re-create the zone on the name server and it will automatically complete.

Or

Restart DC. Yes, restart the DC hosting the secondary DNS zone, and the ADI Primary will change the secondary DNS zone to the ADI during its backup.

Disappearing zone (intentional)

I once encountered a situation where the Administrator claimed that his DNS zone had only disappeared for a period of time (sometimes one or two days, sometimes one week. Check the DNS unit on each DC/name server, and the zone disappears. This is actually intentional and is based on the above seven steps. In this case, the Administrator has a standard base-Sub-configuration and decides to migrate to an ADI Primary configuration. When the standard base area becomes the ADI base, all the DC must host an ADI base area. They retained the subarea before the restart because the information is stored in the memory. After the instance is restarted, the ADI zone is re-formed on all DC/name servers.

It is allowed to have subareas In the ADI base area, but they must be hosted on the member server rather than on the DC. This allows the DNS server to be placed on a remote site without DC.

Although the multi-control replication and comprehensive activity directory (Multi-Basic) Functions combine advantages and disadvantages, knowing how they work saves AD administrators a lot of time and effort in solving these problems.

TechTarget Chinese original content, original article link: http://www.searchsv.com.cn/showcontent_55206.htm