What Do You Mean Find Them?
Some companies think this is absolute madness, everyone should know where their DNS servers are. However, I have seen organizations where DHCP and DNS servers were stood up to service a “special use case” and never cleaned up.
If you work at a large organization with multiple locations across the globe, it is far more likely to have scattered DNS servers. Making it challenging to keep everyone involved aware of what servers are responsible for DNS, especially in crisis mode.
So how do we go about finding them? Many organizations said Configuration Manager.
Let’s Talk About Tiering and ConfigMgr
For many organizations, the answer to finding all of their DNS servers was simple. They just activated CMPivot and used a simple query to find their DNS Servers. The below example and others started circling Twitter immediately:
OptionalFeature | where (Caption == 'DNS Server') | where InstallState == 1
What needs to be discussed is how some organizations don’t have the Configuration Manager agent installed on their DNS servers and for a good reason. First, DNS is considered a Tier0 service even if it’s been moved away from a domain controller. When you control how a device resolves the IP address to name, you can easily own an environment.
In a PROPERLY TIERED ENVIRONMENT, ConfigMgr shouldn’t be installed on your Windows DNS servers. This doesn’t mean you should remove ConfigMgr from all your Windows DNS servers. It is rare to encounter an organization with proper tiering and is the only scenario when you use an alternate management layer. This also enters the risk balancing act of adequately managing and patching your servers, v.s. Hardening and securing your core infrastructure.
PowerShell To the Rescue – (ish)
Fortunately, not all hope is lost. We can still find servers with DNS installed using PowerShell either directly or in roundabout ways. There are several different ways to find out if DNS is installed.
First, we can look to see if the feature itself is installed.
$(Get-WindowsFeature -Name "DNS" | Where-Object {$_.InstallState -eq "Installed"}).InstallState
Second, we can look to see if the DNS service is installed:
Get-Service -Name DNS
Finally, the question of Scope. How do we determine which servers to run this against? In which case, your best bet is to start with all your domain controllers and then hit every other server in your environment.
The challenge will always be knowing that you have access to all servers from your management layer that potentially COULD have DNS installed. This brings us to our final point.
Mitigating Risk at Speed
Whenever a critical patch comes out there is always mass panic. Since 2017 there has been at least one patch a year that posed a significant risk.
- WannCry – 2017
- EternalBlue 2017
- DoubleKill 2018
- Bluekeep 2019
- SIGRed 2020
Learning to mitigate risk at speed starts with removing outdated practices, and ends… well it never really ends. It’s a constant evolution.
To close, we need to address a widespread misconception in IT. The idea we can run a successful, efficient business in a segmented archaic silo structure. This is not fixed in a day or a week. Often this needs to come down as an organizational re-design. Organizations will continue to struggle when mitigating risk at speed when using any structure that does not promote an open and collaborative mindset.
Something I stress during my patching engagements is how there will come a time when you NEED to implement and mitigate risk at speed in a safe, secure manner. The earlier you start to plan out a proper tier model and adequate management of each of those tiers, the better off you will be.