Some of the materials I have read on Active Directory and DNS I feel have not done a clear job explaining exactly what the _msdcs subdomain is and how it is used in an Active Directory forest.
The following is my explanation which I hope makes some sense out of the issue.
_msdcs and Domain Controller Location
First, all domains in an Active Directory forest have a subdomain beneath them called _msdcs. To illustrate, if I create a domain called parent.local and a child domain called child.parent.local, those domains will each contain a subdomain: _msdcs.parent.local and _msdcs.child.parent.local respectively. You can see the _msdcs subdomain of a domain in my Active Directory forest below:
This subdomain is reserved for the registration of DNS records for Microsoft specific services. For example, when looking for a domain controller, a client will need to query a LDAP service record. Microsoft is not the only software company who makes directory services software using the LDAP protocol. As such, there needs to be a way for a client to specifically request a Microsoft LDAP server (in other words a domain controller). Because the _msdcs domain is reserved specifically for Microsoft, clients can safely query this domain for LDAP service records and know they will be receiving the record for a Microsoft domain controller.
Take a closer look at the _msdcs subdomain. You’ll see it actually has several subdomains of its own.
One of these subdomains is the “dc” domain. The dc._msdcs domain contains two other subdomains called “_sites” and “_tcp.”
When a client is querying DNS for a domain controller, if the client does not know what site it belongs to, it will request a _ldap service record from the _tcp.dc._msdcs.domain.tld zone.
If the client does know what site it belongs to, it can query for a _ldap record in the subdomain for that site. For example, _tcp.Default-First-Site-Name._sites.dc._msdcs.child.parent.local using the example pictured above.
_msdcs Subdomain of the Forest Root Domain
The _msdcs subdomain of the forest’s root domain is a little special.
First, if you look at the records registered in the root of the zone, you may see several CNAME (or alias) records. There is a CNAME record for each domain controller in the forest and this record maps the GUID of the domain controller to the fully-qualified domain name of the domain controller. These records are used by Active Directory for replication purposes. All writable domain controllers must register a record in this zone for proper replication.
Now, take a look at the _msdcs domain under the forest root domain in the DNS Server Manager. Notice how it is depicted as a gray icon.
This signifies _msdcs is a delegated domain. Recall that delegations are used to specify the IP address of another DNS server that will host the zone. In the case of the _msdcs domain, the delegation does not actually specify a different DNS server, but instead points to the local server as you can see from the properties of the delegation in the screen shot below:
So, what is the point of delegating this subdomain to the same server? Well, essentially by specifying the _msdcs domain as a delegation, you remove it from the parent zone on the DNS server allowing you to create an independent _msdcs zone. The screen shot below highlights this _msdcs zone:
Because this is now a separate zone, it is possible to change it’s replication scope. By default, the replication scope is set to all DNS servers in the forest.
In contrast, the parent domain’s replication scope is set to only the DNS servers in the domain by default.
Now, the _msdcs subdomain of the forest root has its own subdomain underneath it called “dc,” like we looked at earlier, where DCs for the domain register their service records. But, because the _msdcs subdomain of the forest root domain is replicated to all DNS servers in the forest, it also make the perfect place for services that are needed throughout the forest to register their DNS records as well. For example, say the global catalog.
Looking at the subdomains in the _msdcs domain, you’ll see in addition to the “dc” domain, there is a subdomain called “domains” and another subdomain called “gc.”
The domains._msdcs domain contains subdomains corresponding to all domains in the forest (labeled by the domain’s GUID). In these subdomains are service records for the DCs in those domains.
The gc._msdcs domain contains two subdomains of its own called “_sites” and “_tcp.” These function the same way as the “_sites” and “_tcp” subdomains in the dc._msdcs domain function. When a client needs to find a global catalog in the forest, it can query for an _ldap record in the _tcp.gc._msdcs.forestroot.tld zone if it does not know what site it is in or it can query for a global catalog in a specific site by requesting an _ldap record in the _tcp.SiteName._sites.gc._msdcs.forestroot.tld zone.
I also want to make it clear, that because the _msdcs subdomain of the forest root is replicated to all DNS servers in the forest, this means every DNS server is authoritative for the _msdcs.forestroot.tld zone.
That concludes this look at the _msdcs domain. I hope this description was helpful.
I think this works slightly different in a all 2008r2 domain. The subdomain _msdcs is removed automatically as soon as a forest copy is setup at the root. Let me know if I am incorrect but I can find nothing that explains this behaivor, but I have seen the delegation deleted as soon as the _msdcs.domain.com is created.
Hi there! Thanks for the comment. I am not quite sure I am following. Can you explain what you mean by “The subdomain _msdcs is removed automatically as soon as a forest copy is setup at the root?”
I just installed a copy of 2008R2 and created a new forest and I see that _msdcs is still showing as a delegation. I’d be interested in seeing this behavior you described. Thanks.
In our environment you see:
_msdcs.legislature.x.x.us (forest zone)
legislature.x.x.us (domain zone)
_msdcs was deleted automatically when the forest zone _msdcs.legislature.x.x.us was created and is only visible as tombstoned entries in ADSI edit.
I can find nothing that would indicate that this is a problem (actually the microsoft article that applies to 2003 says it is no longer needed at the domain zone when moved to the forest zone). Our environment is one that started life as NT4, was migrated to 2003 AD, an now freshly migrated to 2008r2 with all remenents of 2003 gone. Domain functional level is still 2003.
Well, I tried to replicate what you were seeing by creating a new forest with 2008R2 from scratch, but I could not get the delegation in the domain zone to be deleted automatically. I don’t know why it would do that to be honest. Maybe something related to how you migrated over?
But, you are right that it shouldn’t be a problem as long as the _msdcs.legislature.x.x.us is replicated throughout the forest to all DNS servers.
Thanks for this article! I have a little bit more understanding of the reason for your _msdcs.forestname.local residing outside your main forward lookup zone. You mentioned it had to do with being able to change the replication apart from your domain.local FLZ (Forward Lookup Zone).
If i’m not mistaken, i believe Windows 2000 domains used to, by default, keep the _msdcs records as a subfolder, under your domain FLZ (that or it was recommended by microsoft to keep it this way). I see now that it is recommended or best practice to have the _msdcs under the forest root instead of the domain.local FLZ. You mentioned 1 advantage to this:
“But, because the _msdcs subdomain of the forest root domain is replicated to all DNS servers in the forest, it also make the perfect place for services that are needed throughout the forest to register their DNS records as well. For example, say the global catalog.”
The questions i have regarding this is…
Are there any other benefits to keeping the _msdcs in the forest root?
Do any of these benefits apply to single domains? Is this best practice for all domains/forests (keeping the _msdcs in the forest root instead of a subfolder under the domain FLZ)?
I’m curious about this because i have been taught by some engineers to remove the root level _msdcs.forestname.local and let the _msdcs subfolder under the domain FLZ become active with the DC locator, SRV records. Now a lot of what i’m hearing it the opposite.