Follow the complete DNS resolution path from root nameservers through TLD and authoritative nameservers to the final resolved IP. Identify exactly which delegation level is introducing a failure or latency, rather than seeing only a final pass or fail result.
DNS Trace monitoring in Cloudmon follows the full iterative DNS resolution path for a domain, starting from the root nameservers and following each delegation through TLD nameservers to the authoritative nameserver that holds the final record. At each hop, Cloudmon records the query time and whether the delegation succeeded. This provides a detailed picture of where in the resolution chain a failure or delay is occurring.
Unlike DNS Server monitoring which verifies a single server's response, DNS Trace tests the entire resolution infrastructure for a domain end to end. It is the right tool when users report intermittent DNS failures and you need to identify which level of the hierarchy is responsible, or when you want to verify that a new domain delegation is correctly propagating through all nameserver levels. Navigate to Synthetic → DNS → DNS Trace to view all configured monitors.
Navigate to Synthetic → DNS → DNS Trace and click the + Add button. Fill in the fields as follows:
| Field | Description |
| Probe | The probe that will perform the DNS trace. For external domain traces, choose a probe with internet access to reach root nameservers. |
| Name | A display name for this trace monitor, such as "example.com Full Trace". |
| Domain | The domain whose DNS resolution path will be traced, for example example.com or your business application domain. |
| Port | Port used for DNS communication. Default is 53. |
| Record Type | The DNS record type to query during the trace. Default is A (Address Record). |
| Protocol | Transport protocol for the trace queries. UDP is the default. TCP is used when responses are too large for a single UDP packet. |
| Interval | How frequently the DNS trace runs, for example every 5 minutes. |
| Alert Rule | A pre-configured alert rule to notify on trace failures. |
| Groups | Assign to logical groups for organised filtering and management. |
| Tags | Custom labels for grouping and filtering monitors. |
| User Groups | The user groups that should be notified when an alarm is raised for this monitor. |
| Third Party Services | Third-party integrations (such as Slack, Teams, or ITSM tools) to notify when an alarm is raised for this monitor. |
| Depends On | Link to another monitor. Alerts are suppressed if the dependency is already down, preventing cascading alarm noise. |
User Groups and Third Party Services set here at the monitor level are automatically inherited by any alarm rule applied to the monitor, so notification routing does not need to be repeated on every rule.
Click Save to add the monitor. Navigate to Synthetic → DNS → DNS Trace to view all configured trace monitors.
Clicking into any DNS Trace monitor opens its detail page. The Metrics Panel shows Availability as the percentage of successful trace completions over the selected time range, Downtime as the total duration the monitor was in a Down state, Query Performance as the final query response time in milliseconds, and Queries as the total number of trace queries performed including a count of failed queries. Three time-series charts are available: Final Query Time (ms) showing trends and anomalies in resolution time, Total Queries showing the number of queries performed per interval, and Failed Queries highlighting recurring failure patterns.
The Log Report tab provides a per-poll breakdown of each trace showing the full resolution path, the final server reached, final query time, and whether each hop in the delegation chain succeeded or failed. This is the key view for pinpointing at which nameserver level a resolution failure is occurring. The Outages tab lists recorded downtime periods including timestamps and durations.
Cloudmon can alert your team when a DNS trace fails to complete or query performance exceeds a defined threshold. Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Learn more.
| Issue | What to check |
| Trace fails immediately at the first hop | The probe cannot reach the root nameservers. Confirm the probe has outbound internet access on UDP port 53. If the probe is in a restricted network, firewall rules may be blocking DNS queries to external IP ranges. Switch to TCP protocol if UDP is filtered. |
| Trace fails at a specific delegation level consistently | Review the Log Report tab to identify which nameserver hop is failing. A failure at the TLD level (e.g., .com or .net) indicates a problem with the domain's NS record delegation at the registrar. A failure at the authoritative level indicates the nameserver itself is unresponsive or misconfigured. |
| Final query time is much higher than expected | Review the Log Report to see per-hop query times and identify which delegation level is slow. High latency at the root or TLD level is typically a probe-to-root connectivity issue. High latency only at the authoritative level points to a slow or overloaded authoritative nameserver for that domain. |
| Failed queries count increasing but availability stays high | This pattern indicates intermittent failures that are resolving before the full consecutive interval threshold is reached. Check the Failed Queries time-series chart for patterns tied to specific times of day. Correlate with DNS server load, TTL expirations, or scheduled maintenance windows on nameservers. |