How do I split the _msdcs section from the root domain DNS zone?

Hi again,

Reading again what I wrote, I'm not sure to have been precise enough :

You just have to create the new zone "_msdcs.rootdomain.com", that's all ! DON'T remove the "_msdcs" subzone !!! DNS service will manage it and it will replace it with a delegated zone automatically.

So DO NOT remove "_msdcs" subzone or you'll lose all the content. Let DNS make its job.


Have a good day

@Chris-Dent:
Yeah I'm aware that this change was brought about with 2003.  I believe I fully understand why too.  It would seem the reason they have done this is to minimize the amount of replication needed for DNS servers in the enterprise.  By only replicating the _msdcs.rootdomain.com zone to all DNS servers in forest vs. the entire rootdomain.com zone it can drastically reduce the amount of replication needed (in a large enterprise that is).  My company is indeed a large enterprise so I am trying to be as efficient as possible.

@PaciB:
I'm not fully sure I believe what you are suggesting.  By simply creating the new zone, I don't see how the system will magically "correct" itself.  For instance:  With the desired setup, the _msdcs folder under the rootdomain.com dns zone would end up being "delegated".  That is this folder should remain, but be grey in color and also only contain the NS records of the authoritative DNS servers.  Your suggestion doesn't seem like it would accomplish this.

As a test I tried to do the reverse of what you suggest in my test environment (it is already sitting at my desired configuration).  I simply deleted the _msdcs.rootdomain.com zone and tried to run the dcdiag /test:dns /fix command and all I got was a bunch of expected DNS errors, e.g. missing SRV records and it even complained that there was a problem with the delegation setup on the _msdcs.rootdomain.com domain.   DCdiag /test:dns /fix did not fix anything.

I then decided to undelegate the _msdcs.rootdomain.com namespace by simply deleting the folder entirely.  I re-ran DCdiag /test:dns /fix and it got rid of my delegation error, but still complained of missing SRV records.  I ran this command a few times and it did not recreate the DNS entries I needed.

I ended up restarting the netlogon service and *this* actually reregistered all my SRV records and now my test environment matches my production environment.  Now I will need to test undoing it, but I'm almost positive your suggestion will not work as you intend.  I would think simply "delegating" this namespace would end up creating the zone for me, no?

@PaciB:
Well, it looks like I stand corrected!  It seems your suggestion did work.  It even caused my _msdcs subfolder of the rootdomain.com zone to grey out as if delegated.  I assumed you had to run the delegation wizard to accomplish that.

On a side note, your suggestion seems to have caused one issue though.  With this backended delegation, the _msdcs.rootdomain.com DNS zone ended up only being delegated to one of my DNS servers.  It was missing the delegation for the second server.  I ended up having to edit the delegation and add the second server and then force replication again.

I'm going to test again to see if I can simply "delegate" the zone using the GUI tools vs. creating the zone manually and see if the same is accomplished, but easier.  I will update!

Thanks again PaciB!

We can export the records from the existing zone and create a new zone including those.

It is possible (quite easy even) to find static records within a zone, so it would be possible to incrementally allow DCs to update their own records again (delete static, from local DNS service, restart NetLogon).

That would be quite a lot of work considering the number of DCs but would allow you to continue working with the zone with very little interruption. I guess it would cause too much bother to simply wait for netlogon to re-register the records even over a weekend?

Chris

Otherwise the NS records could just be added to the delegation. That's all that's missing?

Bear in mind that if you're replicating the zone to the entire Forest the Delegation information (NS Records) will not be used except by DNS servers that do not host a copy of the zone.

Chris

@Chris-Dent
Actually that may be a good idea (static and systematically phase out with dynamic), but you're right that is a lot of work!

I guess it may not be too much of a problem to just let the systems sort themselves out over the weekend.  I might just be too worried for nothing.

Regarding the non-use of the NS records, that confuses me.  The zone is replicated to all DNS servers in the forest (by default).  All of my DNS servers will hold this zone then.  Why would there even be a delegation then if these records aren't used?  When would there be a case that I would have a DNS server that didn't have this zone?  Sorry I mean, should I ever have such a case, how would the delegation records even be used at that point?  I mean if the server knows nothing about this zone, how would it ever find the servers that do host the zone (unless I use forwarding which also negates the need for NS records itself, no?)

Hi,

I did it many times before, for different customers... You should only have created the "_mdcs" zone. If you want to see the result immediatly you just have to restart DNS service.
And yes... it's magic ! the new zone is alreadu populated with records and yes, it's magic also, the DNS service have created the delegation under "rootdomain.com"...

In fact it is not magic... DNS service only categorize records in the matching zone if one exists. If a zone does not exist then DNS service automatically shows a subzone...

Have a good day.

Do you have a preferred scripting language? Generating a zone file from the current structure is rather easy I'll happily show you how if you wish. Otherwise, Exporting the entire parent zone using DNSCmd and hacking at  the file with Notepad would work equally well.

> Why would there even be a delegation then if these records aren't used?

Good DNS structure, but the delegation would only be used by a server that does not host _msdcs (cannot provide an answer from a local source).

Given that you're splitting the zone, I have to assume that "domain.com" is not hosted in the Forest partition. Therefore a "third" DNS server would first ask for the NS records for _msdcs from domain.com, then cache the NS records for _msdcs and use the servers listed in the delegation.

> When would there be a case that I would have a DNS server that didn't have this zone?  

Only if you decided to implement a DNS server on a Windows 2000 DC, or a stand-alone DNS server (not DS-Integrated). Quite unlikely from your descriptions.

Chris

@PaciB:
Gotcha. Thanks!

@Chris-Dent
VBScript is my language of choice, but that's not really necessary.  I can already export dns records VBscript and/or dig/nslookup.  Thanks for the offer though!

Also my rootdomain.com zone is indeed replicated throughout the entire forest (because it currently *contains* the _msdcs subdomain which is required globally).  This is what I'm trying to clean up.  At some point I also intend to split out all of my subdomains as well.  With my subdomains however, I fear I will have a major issue as I have both static and dynamic records that I cannot afford to lose.  Using your suggestion to keep all records static and then delete/let dynamic recreate is not going to be possible for me with thousands of systems that have registered themselves.  I guess I'm going to have to do some serious thinking.  I thought this would end up being super simple but it seems it's not.

PaciB's method doesn't work for the other sub-domains? I wasn't aware it did that at all, becoming too cynical I think :)

Chris

@Chris-Dent
Actually after thinking about it, I think PaciB's solution will work (without loss of any records).  If what he hinted at was true (the DNS admin just displays the existing records under the newly created zone) then I should be completely fine.  I have another test I'll be doing shortly to verify this information!

Might just be mine (2008 server), but it works perfectly for copying over dynamic records. However, if the sub-domain contains static records it leaves it as is and doesn't create the delegation (that is, it does create the zone can copies the dynamic records).

That need not be a problem though, finding static records in a zone is also easy / trivial to script. So adding a few static records to the newly created zone wouldn't be hard. Once done, deleting the existing sub-domain and re-creating it as a delegation is also very simple. Neither of those actions will break the newly generated copy of the zone.

Just in case :)

Chris

I think I need some further clarification though.  While this process seems like it will work, I think my desired configuration changes things a little bit breaking this process...

Server1 is a DC in the forest/root domain.  I created the new zone in the forest root for _msdcs.rootdom.com and all is great.  What happens with sub1.rootdom.com?  I intend to have sub1.rootdom.com be hosted only within the sub1 domain (and only on the dc/dns servers in sub1 domain).

I just did a test run and it doesn't seem to have worked as intended.  I created the zone sub1.rootdom.com on the DC for this domain.  The zone created, but none of my records from the subdomain of the rootdom.com zone came over.

*note* Before doing this, I did convert my rootdom.com zone to replicate only within the rootdom.com domain (vs. forest) so this zone was missing entirely from sub1DC1.  I'm assuming since sub1DC1 didn't see these records to begin with, it couldn't pull them over successfully?

Should I have done this first on the rootDC1 while the zone had forest level scope and then later converted this zone to replicate only on DC in sub1 domain?

I apologize I keep asking questions but posting more information before I get a response.  I should probably just continue to do my own testing and then just post results.

At any rate, it seems no matter what I do, PaciB's method *only* works with the _msdcs.rootdom.com zone.  If I manually create a sub.rootdom.com zone, the records never move over to it.  They remain under the sub folder of the rootdom.com zone.  Also depending on where I create this new sub.rootdom.com zone, I get different results.

For instance:
(rootdom.com configured on rootDC1 with forest wide scope and containing sub folder for sub domain/with a few RRs)
If I create a new sub.rootdom.com zone on rootDC1 with forest scope, the new zone ends up with just one NS and SOA record in it.  Overtime some stuff starts to show up in the zone from this domain as machines routinely update their records.  *note* when this process was done with the _msdcs.rootdom.com zone, all the SRV records showed up immediately *akin to magic!*.

If I create a new sub.rootdom.com zone on subDC1, the new zone ends up with a bunch of records right off the bat, including the sub _msdcs, _sites, _tcp, etc. folders.  The only records created though reference subDC1 (not subDC2 which also exists).

In both cases, the subfolder for sub.rootdom.com underneath the rootdom.com zone does *not* get delegated (e.g. turn grey) like the _msdcs zone does.

It would seem the idea that when creating a new zone for an already existing subfolder/domain of the parent zone the existing records will not simply *display* under the new zone.  New records are created.  I think with the _msdcs zone the records are just added so fast by AD that it almost seems like they just moved over.  It's either that or AD is doing things differently between the _msdcs zone and the other subdomain zones.

I wish there was some clear information as to what I can expect to happen but I'm sure that I'm out of luck there.

I think I am going to close this request as well since the original scope of the question was for delegating the _msdcs zone and it seems PaciB's suggestion works fine for that particular case.

I will move my subdomains question to another thread.

Thanks again PaciB and Chris-Dent!

If I were to do it I'd make all of the initial changes on a single DC in the root domain as follows:

1. Create each child domain as a separate zone, leaving it in the Forest scope
2. Verify that records copy over (either in the directory or in the console)
3. Deal with any issues arising (static records if it follows the results of my brief tests). It would be well worth checking a few of the record security descriptors to see if the client / DHCP server still owns or has write access.
4. Connect to a DC on the child domain and switch the zone replication scope to DomainDnsZones. Check again (of course)

It's always difficult to know what's going on with MS DNS, there's very little documentation on its inner workings (most of what exists is created by reverse engineering by the community at large) and no published API allowing us to control it. It's clear that it's creating a copy of the dnsNode objects in AD, but it isn't clear how that is driven or how it is started.

Chris

@Chris-Dent

> 2. Verify that records copy over (either in the directory or in the console)

All of my tests show none of the records copy over.  When I did it with your suggestion, the only records that immediately show up in the zone is the SOA and NS record for rootDC1 as it is authoritative for that zone.   None of my member server records, etc show up until they auto-refresh their records.

Did you see different results with your 2008 DNS server?