Extraneous _msdcs. forward lookup zone failing replication, how do I check what uses it? and can I delete it?

Question

We run Active directory on windows server 2008 and 2008 R2 in 2008 AD mode.

Our DNS is part of the AD and runs on the same servers as the Global Catalogue.

My predecessor created the environment within domain.local (domain is a substitution, .local is not)

In the forward lookup zones we have a container called domain.local and this contains a working _msdcs container.

However at the top level we have a container called _msdcs.domain.net (note its the same domain but .net tld rather than .local) this container mostly contains the same records as the working _msdcs container inside domain.local but with some minor differences.

Example of layout in DNS manager (Not enough reputation points to post an image)

+ Forward Lookup Zones
    - _msdcs.domain.net
        + dc
        + domains
        + gc
        + pdc
    - domain.local
        - _msdcs
            + dc
            + domains
            + gc
            + pdc

I want to find what is using it? I want to know how it got there? and I want to delete it or fix it.

All the MS documentation I can find on _msdcs describes its use and what it contains but not why there would be a separate one at the top of my forward lookup zone for a domain other than my AD's.

================

Update

Looks like the AD has been renamed using rendom but not cleaned up / completed.

To confirm this use sysinternals Active Directory Explorer (BE CAREFUL THERE BE DRAGONS IN THIS TOOL)

then look in this container (not all containers shown, asuming your domain is domain.local)

-servername [servername.domain.local]
    -CN=Configuration,DC=domain,DC=local
          -CN=Partitions
               CN=DOMAIN

for an attribute called msDS-DnsRootAlias

In my case this showed domain.net

Not certain how to fix but that's for another Question.

Answer 1

If anything thinks your domain is domain.net instead of domain.local (really you shouldn't use .local, but that's another conversation entirely), it will look for your DCs at _msdcs.domain.net.

There is no telling what this might break (kerberos comes to mind, as well as dynamic DNS updates), so I'd imagine little or nothing is using it. However, if you like, do a packet capture (use wireshark, or better yet clone the port and use wireshark on something else so you don't have to run wireshark on a production server) filtering for DNS records, and search the resultant data for queries involving _msdcs.domain.net. If you happen to find one, inspect the device querying to see what it is that is so misconfigured.

Perhaps you also have, or had, an AD domain with that name. If so, and it no longer exists, you can purge those records. This will make your life easier when eventually someday you migrate away from .local.

Answer 2

The _msdcs.domain.local under the domain.local (which is the first domain in the forest) is delegated authority by right-clicking the domain.local and choosing "New Delegation..." wizard. Run the wizard to point to the same PDC as the SOA. It may seem fruitless to do, but it has a definite purpose.

Normally, domain controllers throughout the network contain a replica of the DNS zones and are authoritative only in that domain. The Delegation wizard creates a new _msdcs.domain.local at the same level as domain.local as a new domain. It is a copy of all the zones, and causes the Name Servers throughout the Forest to become authoritative. The purpose is for large networks over WAN connections that have domain controllers at each site. These domain controllers are each a DNS replication server with a replica of the whole AD DNS (all the zones), but performing the Delegation wizard allows them, as authoritative, to be writeable. No longer does dynamic updating of system records have to be done between all PCs in the domains to the PDC, but just to their local DC, which will update the PDC on its regular update cycle.

By default, the replication scope for Name Servers (NS) in _msdcs is set to all DNS servers in the domain, but now the NS's in _msdcs.domain.local are authoritative for the forest. This allows LDAP queries to interface locally in their domain on their local DC as a minor reason. But, even if all the DNS replica's are at headquarters, until this delegation is done, the name servers (NS) are only authoritative about AD details that are in domain.local (or better written as domain1.local) not authoritative to domains (i.e. domain2.local) at the same level as the first domain in the forest.

Some make the mistake to assume that child domains of the first domain in the forest also need this. But Name Servers are authoritative for their domain, even if child.domain.local resides inside domain.local.

As far as the _msdcs.domain.net name being different, from the domain at the same level it came from, domain.local? That was probably a rookie admin who thought that _msdcs.domain.local domain would conflict with _msdcs name (FQDN:_msdcs.domain.local) that was under domain.local, since it would be identically named and possibly cause corruption.