Hi, my name is Doug Gabbard and also a Premier Field Engineer (PFE) with Microsoft for about the past 8 years. I hope to add to the Ask PFE Platform blog with the others already here. I get the opportunity to see challenges our customers face and how they resolve them. I hope to share what I learn that is technically interesting.
This blog post is a lesson on DNS storage and behavior. Read on to learn more.
Joining in a conversation……
“….I used server manager to remove the DNS role.” Or
“….I uninstalled DNS from my domain controller. “
“....This means, DNS data is now removed from my domain controller, right?”
Well, probably not.
Let’s hit some basics first to make sure we are all on the same page. If you follow the history of Active Directory integrated DNS from Windows 2000 to 2008 R2 you will find some changes along the way. The one change I want to focus on here is “Where in the database” is the DNS stored and how do you remove DNS.
Those of you that have met me during ADRAPs have found that I encourage understanding where things are located in the database. Knowing this helps when it comes to troubleshooting or understanding this post. So let’s start with a diagram of the database and where DNS can be stored. Fellow PFE wrote a great blog on DNS zones, which summarizes where DNS data is stored in Active Directory. Let’s borrow his diagrams. You’ll note that DNS data can be stored in the non-shaded partitions.
Let’s map these partitions back to the configuration options in the DNS Management console. To see this: open the DNS Management console; connect to a DNS server; Left click on your DNS zone (forward or reverse zones), right click on that zone and choose properties. In the properties dialog box select Change (next to the “Replication:…)” to display the radio buttons showing the options for replication scope. The four choices of radio buttons should now make more sense to you:
This is the forestDNSzones application partition. Meaning any DC in the forest with DNS installed will participate in the replication of the DNS information for that zone.
This is the DomainDNSzones application partition. Meaning any DC in the this domain with DNS installed will participate in the replication of the DNS information for that zone.
Notice the subtle change in wording on this one. There is no mention of DNS. Just that it is replicated to all domain controllers in the domain. Meaning, even if you do not install DNS on all DCs, ALL DCs in that domain will participate in replication of the zone.
This is the custom partition if you are using the custom partition. Only those domain controllers with DNS that YOU choose will participate in the replication of the zone. (Read below for examples why you would want a custom partition). This option is grayed out if there are no custom DNS application partitions.
So, “Class for DNS storage for AD integrated zones 101” is dismissed. On to the topic of the title:
Let’s say I uninstall DNS from a DC: what happens?
Not much other than the DNS service is uninstalled. You can still see all the DNS records in the AD database using your favorite LDAP browser on port 389. Be careful, though. If you delete data, the deletions will replicate and disappear from “real” DNS servers.
You would think – maybe – that the records would no longer reside on a DC after removing DNS from that DC. Sorry, if you thought that. They do exist and are replicating just fine as before. It turns out the DC still replicates the application partition; it just no longer exposes the data through the DNS service.
There is a little cleanup if you decide to completely remove a domain controller from the replication of the DNS information. You can leave the remnants of the DNS if you like because nothing is broken. However, there is risk from accidental deletion of records or the zone if an engineer discovers the partition and does not understand why it is there and attempts clean-up. Also, if the intent was to not expose the DNS records on a domain controller or minimize its replication footprint, you have additional steps after removing a DNS Role. I will start with the custom application partition first because it is easier and the assumption is that you want to Remove the DNS role from the domain controller.
1. Uninstall DNS/Remove the DNS role
2. From a command prompt run:
Dnscmd <DCNAME> /unenlistdirectorypartition <foo.com>
Where <DCNAME> is the name of the DC and <foo.com> is the name of the application partition.
2. Use Ntdsutil to remove the partition to remove it from the replication group.
a. Remove NC replica dc=forestDNSzones,dc=contoso,dc=com dc2.contoso.com
(Note: I am purposefully not giving you all the syntax here, because I want you to practice this in a lab before you try this in production. Also, there is a Delete NC command. Do NOT use this unless you want to delete the partition globally)
Although there are many reasons, here are some that I have observed:
1. 100% control of exactly which domain controllers participate in replication of the DNS information.
2. Custom Application partitions can replicate to domain controllers across domains (in the same forest).
3. Easier to smoothly retire a DNS server
I was on site when a customer using custom application partitions gave me a great example. In most large environments, when you want to retire a server of any role there is always a concern of: Is anyone still using that server or service? Think of the impact of removing DNS if an application is depending on that server for DNS. With a custom application partition, we can “unenlist” from the replication (leaving the DNS service running – and if that was the only zone it becomes a caching DNS server). Then forward requests from this caching only DNS server to a DNS server that still hosts the zone. Finally, with monitoring, discover who is still using the DNS server you wish to retire.
4. If you have a DNS zone that is only needed in a few locations. If you have many domain controllers in your environment and you need the zone in just a couple of locations, this is a great option so that not all DNS servers need to replicate the data
This was interesting to me and I hop you learned some new things about DNS.
Doug Gabbard, Senior PFE