Overview
The DNS Name Resolution monitoring test appears under the Operating System section for all monitored server types.
Monitoring Benefit
The DNS Name Resolution test performs a real name lookup from the monitored server and times how long it takes. It answers a question the server-side DNS tests cannot: can this server, from where it sits, actually resolve the names it depends on — and how quickly?
The test is deliberately strict. It resolves using the DNS protocol only, and it ignores the local hosts file. That means a name that resolves on the server because someone added a hosts entry will still fail this test, which is the intended behaviour — the test reports what DNS can do, not what the server has been worked around into doing.
Each test is identified by the host name and record type being resolved, so a server can carry several DNS Name Resolution tests covering different names and record types, each reported separately.
Latency thresholds
Unlike a simple pass or fail check, this test measures resolution time with a stopwatch and compares it against configurable warning and critical thresholds. Slow resolution is a real fault in its own right — it shows up to users as long logons, applications that hang on startup and intermittent connection failures, long before name resolution stops working altogether.
Both thresholds are configured alongside the test. Because reasonable resolution time varies with environment and with what is being resolved, confirm the values in force in your own console before treating a warning as unexpected.
How do we verify the monitoring test results?
1. Run the same lookup on the monitored server. ENow uses PowerShell, and the switches matter — they are what make this a pure DNS test:
Resolve-DnsName -Name <host name> -DnsOnly -NoHostsFile-DnsOnly restricts the lookup to the DNS protocol, excluding NetBIOS and LLMNR. -NoHostsFile ignores the local hosts file. Run it exactly as written; dropping either switch can make a failing name appear to resolve.
2. Time it. If the test is reporting a latency warning rather than a failure, measure it:
Measure-Command { Resolve-DnsName -Name <host name> -DnsOnly -NoHostsFile }3. Check which resolvers the server is using. This test reflects the server's own resolver configuration, so a failure on one server and not another usually starts here:
Get-DnsClientServerAddress4. Test each configured resolver individually. Where a server lists more than one, a failing primary can produce intermittent slowness as lookups fall through to the secondary:
Resolve-DnsName -Name <host name> -Server <resolver IP>Configure the test from Universal Policy > All Servers, in the DNS section.
Common warning or error results, and potential solutions
| Result | Potential solution |
| Resolution fails | Confirm the server's configured DNS resolvers are reachable and answering. Check Get-DnsClientServerAddress, then query each resolver directly. |
| Resolution exceeds the warning threshold | Slow but working. Common causes are a failing primary resolver with lookups falling through to a secondary, an overloaded DNS server, or a slow forwarder path for external names. |
| Resolution exceeds the critical threshold | Treat as an outage in progress. At this level users will already be reporting long logons and applications hanging on startup. |
| The name resolves manually but the test fails | Check whether your manual test included the -DnsOnly and -NoHostsFile switches. A hosts file entry or a NetBIOS/LLMNR fallback will resolve the name outside DNS, which the test deliberately excludes. |
| One server fails while others resolve the same name | The difference is local to that server. Compare its configured resolvers, and check for a local firewall rule or VPN split-tunnel configuration affecting outbound DNS. |
| Failure only for a particular record type | Each test is identified by host name and record type. Confirm the record type being requested actually exists for that name — an AAAA lookup against a name with only an A record will not resolve. |
| Intermittent failures with no pattern | Check whether more than one resolver is configured and whether one of them is unhealthy. Alternating success and failure across runs is the usual signature. |
Related monitoring tests
- DNS IP Connectivity — reachability of the configured DNS servers, as distinct from whether names resolve through them.
- On domain controllers, the DNS Server family of tests covers the server side of DNS rather than the client side measured here.
Comments
0 comments
Please sign in to leave a comment.