The Domain Name System (DNS) translates domain names into the IP addresses systems use to reach each other. DNS monitoring is the practice of regularly querying your domains and resolvers to confirm three things: that DNS answers at all, that it answers quickly, and that it returns the right address. Nagios XI handles all three through the DNS Query Wizard.

DNS failures are unusually frustrating because everything underneath them is often working perfectly. The servers are up, the application is healthy, the certificates are valid, and users still can’t reach anything, because the name never resolved. Worse, DNS problems tend to be diagnosed last: teams check the web server, the load balancer, and the network before anyone thinks to check what the domain is actually resolving to.

Slow resolution is the quieter version of the same problem. A resolver taking two seconds to answer adds two seconds to every request, which reads to users as a slow site rather than a DNS issue.

The DNS Query Wizard (Configure > Configuration Wizards > DNS Query) sets up checks for:

• Resolution. Confirms your domains resolve at all, which is the baseline check.
• Expected address match. Verifies a domain resolves to the address it’s supposed to. This is the check that catches a bad record push, a stale entry after a migration, or a redirect nobody authorized.
• Specific resolvers. Query a particular DNS server rather than whatever the Nagios server would use by default, so you can confirm each resolver in your environment is answering correctly.
• Authoritative answers. Verify a server is authoritative for the lookup when that distinction matters.
• Response time. Set Warning and Critical thresholds so slow lookups surface before users feel them.

Nagios XI 2026R1.5 (May 27, 2026) added round robin DNS support to the wizard, so domains that legitimately return multiple rotating addresses no longer generate false alerts.

DNS monitoring is often marketed as hijacking and spoofing detection, so it’s worth being precise about what Nagios actually does here.

Nagios doesn’t inspect DNS traffic for threats or run anomaly detection. What it does is check whether a domain resolves to the address you told it to expect. If the answer changes to something unexpected, the check goes Critical and someone finds out. That’s a genuinely useful control against hijacking and unauthorized redirection, and for most teams it’s the practical version of the capability. But it works because you defined the expected value, not because Nagios recognized an attack.

If you need traffic-level threat detection, that’s Nagios Network Analyzer, a separate solution with its own license.

• Fewer misdiagnosed outages. When DNS is monitored, “the site is down” gets answered in seconds rather than after the web and network teams have both cleared their systems.
• Change safety. Expected-address checks catch DNS changes that didn’t go as planned, which is when most DNS incidents actually happen.
• Performance visibility. Response-time thresholds turn slow resolution into an alert instead of a vague complaint about site speed.
• One place to look. DNS checks sit alongside your website, server, and network monitoring in the same dashboards and notification chains, rather than in a separate tool.

Setup runs through the DNS Query Wizard: enter the domain, optionally specify which DNS server to query and what address you expect back, set your response-time thresholds, and finish. The new Host and Services appear in your existing views. For step-by-step instructions, watch the video below or see the DNS Query Wizard documentation.