Overview
The DNS Server Functionality monitoring test appears under the DNS Server indicator for a domain controller.
The DNS Server indicator is only shown for domain controllers where the DNS Server role is installed. Where the role is present the indicator appears at the top level, to the right of AD Core; where it is absent, no DNS Server indicator is shown for that server.
Monitoring Benefit
The DNS Server Functionality test validates that the DNS server on the domain controller is available and answering. It runs on the domain controller itself, which removes the variables that make DNS problems hard to attribute — resolver caches, WAN latency, client firewalls, VPN split tunnelling, conditional forwarders and secondary servers all sit outside the measurement.
This matters because DNS is usually the first thing to break when a domain controller becomes unhealthy, and because a DNS failure on a domain controller presents to users as something else entirely: logons failing with "the domain is not available", Group Policy not applying, mapped drives disappearing, Kerberos falling back to NTLM, Outlook sitting on "Trying to connect".
There is one test for each listening IP address detected on the server. A domain controller listening on several addresses produces several results, and they can differ — one address answering while another does not is a real and reportable condition.
How do we verify the monitoring test results?
1. Run the same test on the domain controller. ENow uses PowerShell, so the same call reproduces the result. Substitute the listening address the failing test reports:
Test-DnsServer -IPAddress <listening IP> -Context DnsServer
2. Check every listening address, not just one. List what the server is actually listening on and test each in turn, because the indicator reflects them individually:
Get-DnsServerSetting -All | Select-Object ListeningIPAddress
3. Confirm the DNS Server service is healthy. Check the service and the DNS server event log on the domain controller. Service degradation, RPC failures and WMI provider problems on root\MicrosoftDNS can all present as a functionality failure while the server still appears to be running.
4. Rule out zone loading. AD-integrated zones load from AD DS. If AD replication is unhealthy, zone data can be stale or partial on one domain controller while others are fine.
Common warning or error results, and potential solutions
| Result | Potential solution |
| Test fails on all listening addresses | The DNS Server service is not answering. Check the service state and the DNS server event log on that domain controller. |
| Test fails on one listening address only | Check the binding configuration for that address. A server can answer correctly on one interface and not another, and this is exactly the condition the per-address testing exists to surface. |
| Test passes but Active Directory problems persist | The DNS server is answering, so look at the record-level tests under the same indicator — Domain Records, Forest Records and Host Name Records — rather than at the server itself. |
| Intermittent failures | Check resource pressure on the domain controller. CPU spikes and RPC failures produce intermittent DNS non-response, and DNS is often the first symptom of a wider problem on the server. |
| New listening address appears and fails | An address added to the server is picked up automatically as a new test. Confirm the DNS server is intended to listen on it and is configured to do so. |
Enable or disable this test from the Active Directory section of Alert Intelligence. Alerts are delivered under the DNS Server workload for domain controllers.
Related monitoring tests
- DNS Server Settings — the DNS server configuration collected from the domain controller.
- Forwarders Functionality — tests the configured forwarders.
- Root Hints Functionality — tests the root hints.
Comments
0 comments
Please sign in to leave a comment.