IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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.
Background on Storing DNS Data in the Active Directory Database
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:
1. To All DNS servers running on domain controllers in the forest: contoso.com:
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.
2. To all DNS servers running on domain controllers in this domain: contoso.com
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.
3. To all domain controllers in this domain (for Windows 2000 compatibility): contoso.com.
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.
4. To all domain controllers in the scope of this directory partition:
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:
“So you THINK you removed DNS from Your Server”
Let’s say I uninstall DNS from a DC: what happens?
Scenario 1: DNS data stored in the Domain Partition:
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.
Scenario 2: DNS Data stored in Application Partitions (ForestDNSzones, DomainDNSzones, and Custom DNS application partitions):
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.
Forcing a DNS Application partition removal, after the removal of DNS:
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.
Forcing the removal of the ForestDNSZones or Domain DNSzones, after the removal of DNS:
1. Uninstall DNS/Remove the DNS role
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)
A Final Note: “Why would I use a custom application partition for DNS Zones?”
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