Runbooks' DNS Monitor template compares A, CNAME, MX, TXT, and NS answers with a previous snapshot every six hours. That is a useful starting observation, not evidence that someone hijacked a domain. The answer may come from a recursive cache, an old nameserver delegation, or an approved change. An alert should say which record and source changed, what was expected, and whether a human needs to act.
Compare the right record with the right source
- Keep an approved inventory by fully qualified hostname and record type, including expected values, responsible owner, and planned change window. A single snapshot of yesterday's answer is not an approval record.
- Query the currently delegated authoritative nameservers for the record. Record each nameserver, query time, answer, response status, and TTL. Check the domain's actual delegation if your configured DNS zone and the live answer disagree.
- Query a recursive resolver separately. If its answer differs, record the TTL and retest after the previously cached value could expire. Changing a TTL now cannot flush an answer already cached under the old TTL.
- Compare both observations with the approved inventory and change log. Escalate an unexplained authoritative change to the domain owner; investigate a resolver-only mismatch as a caching or delegation problem first.
Cloudflare documents TTL as a cache duration and notes that a local cache may retain an older answer longer. AWS Route 53 also documents wrong hosted zones and old nameserver delegations as reasons a DNS update appears ineffective. Neither source gives one safe wait time for every DNS provider or network.
An operator decision table
| Observation | Next step | What not to claim |
|---|---|---|
| Authoritative answer differs from the approved record; no known change | Notify the domain owner with record type, old and new values, nameserver and timestamp; verify provider audit history | A DNS difference alone does not prove compromise |
| Authoritative answer matches the approved change; resolver still returns the old value | Check delegation and prior TTL; sample again after the relevant cache window | Do not call an old cache an attacker |
| Nameservers disagree or delegation points to another zone | Check registrar delegation and the intended provider zone before changing records | Do not assume the zone you edited serves the public answer |
| Queries fail or time out after a retry | Report an observation failure and investigate resolver or network reachability | A failed query cannot establish the current DNS value |
Rehearse the alert before relying on it
In a test zone you control, record the approved baseline, make a planned change, and check whether the monitor includes its source and the change window rather than sounding a security alarm. Next, intentionally query an unreachable resolver: the result should say 'unable to observe', not 'records unchanged'. Finally, verify the recipient actually receives an alert and can open the evidence. The test is a proposed acceptance procedure, not a claim that the gallery template has passed it.
The gallery item lists web_fetch and message and describes its cadence inside HEARTBEAT.md text; it does not install a DNS-query integration or an OpenClaw Automation. Use a DNS-capable source for record types and create an actual schedule with run history if this must run independently. Keep urgent availability or security paging in the system your team already operates; use the agent to assemble a bounded, reviewable change report. OpenClaw's run result and delivered message are separate checks.
Inspect the DNS Monitor template