Detect DNS problems before guessing at the web server
Your application can be running normally while visitors cannot find it. An accidentally removed address record, an unexpected alias or an incorrect mail record can break a service before an HTTP request reaches the intended server. DNS monitoring checks that layer directly.
MetriBeacon lets you monitor DNS records with an explicit expected condition, inspect results from selected checking locations and connect suitable alarms. This guide shows how to choose a useful first check and read it alongside website monitoring. It focuses on the DNS answers you configure, rather than claiming to test every resolver on the internet.
What does DNS monitoring actually check?
A DNS check asks for a record type at a chosen name and evaluates the response against your configuration. For example, you might require an address record to exist, require a particular set of answers or check that an old record is absent.
The distinction matters: “an answer exists” is weaker than “the answer contains the address we expect.” A valid DNS response can still direct a visitor somewhere you did not intend.
MetriBeacon supports common record types including A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA and PTR. Choose a name and type that represent an actual dependency of your service.
| Record | Useful question | Important limit |
|---|---|---|
| A or AAAA | Does the name return the expected IPv4 or IPv6 address? | An address alone does not prove the application works |
| CNAME | Does the alias point to the expected name? | The target's application still needs its own check |
| MX | Is the expected mail-routing record present? | A record does not prove a message was delivered |
| TXT | Does the expected published text appear? | A DNS check does not interpret every policy's meaning |
| NS | Are the expected nameserver records returned? | One observation does not establish worldwide consistency |
Use a separate HTTP monitor to check the request and response your application needs. For an important interaction, a browser journey can provide another distinct signal.
Choose the expected condition deliberately
MetriBeacon offers conditions for presence, absence, exact answers and inclusion of expected answers. Start with the narrowest condition that matches what you genuinely control.
Presence checks that the selected record type has an answer. It is useful when addresses may legitimately change and existence is the requirement. It will not establish that a returned address is the one you intended.
Exact answers require the returned set to match the configured expected set. Use that for a stable record whose entire answer set you know. Answer order is not the point; membership is.
Including expected answers requires your selected values to be present while allowing additional answers. This can fit a service that intentionally publishes several values, provided the specific required value is stable.
Absence checks that the requested record type has no answers under the configured response-code expectation. Do not assume that an empty answer and a nonexistent name are the same DNS result.
A CDN or other managed service may rotate addresses legitimately. An exact-address expectation chosen without considering that behaviour can create alerts about intended changes. Check your provider's configuration before treating every difference as a fault.
Create a DNS monitor in MetriBeacon
Follow the network-check setup guide. You need permission to edit the workspace and a target allowed by the available checking setup.
- Choose Add monitor → Network & certificates → DNS.
- Give the monitor a recognisable name and enter the DNS name without an HTTP URL path.
- Select the record type and configure the expected condition and values where required.
- Review resolver and transport options if your question requires a specific DNS path.
- Select available locations, the interval, confirmation settings and the measurements you need.
- Review estimated usage, save and inspect the first result before relying on alarms.
For an illustrative web-service check, select your own public hostname and its A record. First confirm its intended addresses from your DNS configuration. Then decide whether requiring presence or a known answer set expresses the requirement. Do not copy another site's addresses into your expected values.
The network monitoring overview explains the related check types. Available locations and capabilities determine what you can configure; a check name cannot enable an unsupported protocol or grant access to a private network.
Understand the resolver, location and TTL
A recursive resolver answers using its lookup process and cache. An explicitly configured authoritative query asks a different question about the server selected for it. Choose that option only when it matches the investigation and target you intend.
MetriBeacon supports DNS transport options including UDP, TCP, DNS over TLS and DNS over HTTPS. The configuration and permitted target determine which path a check uses. Changing transport is not evidence that every user's DNS path is now healthy.
TTL describes how long a DNS answer may be cached. A cached response can show a decreasing remaining TTL, so an observed TTL is not necessarily the original value entered in the zone. Set optional TTL bounds only if that distinction fits your requirement.
After a planned change, inspect fresh observations with their timestamps, chosen resolver and location. One successful result cannot prove that every cache worldwide has adopted the new value. Compare only checks that ask the same question when investigating differences.
Read DNSSEC as its own result
DNSSEC adds validation evidence for signed DNS data. MetriBeacon distinguishes valid, invalid, unsigned and unknown results. It can observe validation or require a valid result when that is the policy you want.
Unsigned and invalid are different states. A domain without signatures is not automatically evidence of a broken signature, although it does not satisfy a requirement for valid signed data. Unknown validation also does not prove validity.
DNSSEC validation and encrypted DNS transport answer different questions. Using DNS over HTTPS does not by itself establish a valid DNSSEC result. Inspect the configured policy and actual validation status when investigating an alert.
Connect an alarm to a useful first action
Review and explicitly enable appropriate alarm suggestions. Connect a confirmed destination and use the alarm setup guide and email and Telegram guide to test delivery.
Name the response you want: check the requested record, compare the intended DNS configuration and inspect recent changes. For a mail record, investigate routing separately from actual delivery. For a web address, compare the DNS observation with the HTTP result and certificate information.
Keep unavailable or stale observations separate from a confirmed answer mismatch. Missing checking evidence does not establish either a healthy domain or a domain outage. The heartbeat and freshness article explains why an older success cannot fill a later gap.
A controlled test on a domain or test record you own helps verify the rule and delivery path. Restore its intended configuration and confirm a fresh recovery result. Monitoring reports what it observes; it does not automatically edit your DNS zone.
Frequently asked questions about DNS monitoring
Is DNS monitoring the same as website monitoring?
No. A DNS check evaluates the selected name, record and conditions. An HTTP monitor checks the configured application request. Use both when both layers matter.
Can MetriBeacon detect an unexpected DNS answer?
Yes, when your expected-answer condition or configured baseline expresses that requirement. A presence-only condition does not confirm the exact intended value.
Does a successful check prove DNS propagation is complete?
No. It is evidence for the selected query, resolver, location and time. Other caches and querying paths may differ.
Is DNS monitoring free with MetriBeacon?
MetriBeacon is free within its documented technical quotas. Review the usage overview, interval and selected measurements when planning checks.
Start with one important DNS dependency
Create a free MetriBeacon account, select DNS under Network & certificates and monitor one important record with a clear expected condition. Verify its first result and test an actionable alarm. The Website/API template below creates a complementary HTTP monitor; create the DNS check through its separate setup entry.
