DNS Monitoring
DNS is the one part of your store that lives entirely outside it — and when it changes without you, the failure is invisible to an ordinary uptime check. A changed NS or MX record can mean a domain hijack or mail interception; a blocklisted IP silently stops your order confirmations from being delivered.
DNS Monitoring resolves your domain from an independent public resolver, remembers what it saw, and alerts you when it changes.
How It Works
On each run, Pulsar resolves the record types you've selected and compares them against a stored baseline:
- Establishes a baseline on the first run (no alert — it's just recording what "normal" looks like).
- Diffs every later run against that baseline.
- Alerts once per distinct change — it won't re-page every interval while a record stays changed.
Severity depends on which record changed:
| Change | Severity | Why |
|---|---|---|
NS or MX record changed | Compromised (pages immediately) | Nameserver / mail-exchanger changes are how domain hijacks and email interception show up |
A / AAAA / CNAME / TXT changed | Degraded (review) | Could be a legitimate migration or an SPF/DMARC edit — worth a look |
| Resolved IP on a DNS blocklist | Degraded (review) | A listing silently kills transactional email deliverability |
DNS checks are kept separate from your uptime SLA — a DNS change doesn't mean the site is down, so it never affects your uptime percentage.
What It Monitors
Record changes. Any of A, AAAA, CNAME, NS, MX, TXT (you choose the set; the default covers all six). Resolution goes to a public resolver rather than the local one, so you see authoritative records, not a stale cache.
Blocklist listings. Your resolved IPs are checked against public DNS blocklists (Spamhaus, Barracuda by default). Only genuine listing responses count — the sentinel codes some blocklists return for public-resolver queries are ignored, so you don't get false alarms.
Configuration
Open your site in Pulsar and find the DNS Monitoring card, then Enable DNS Monitoring.
| Setting | Description |
|---|---|
| Alert on record changes | Toggle record-change detection on/off |
| Record types | Which records to snapshot and diff. Leave empty for the default set (A, AAAA, CNAME, NS, MX, TXT) |
| Check resolved IPs against DNS blocklists | Toggle DNSBL checks on/off |
| DNSBL zones | Blocklist zones to query. Leave empty for the built-in defaults |
| Check interval | 15 minutes is typical; minimum 5 minutes (DNS TTLs are minutes-to-hours, so there's no benefit to checking faster) |
When a Change Fires
- Confirm it was you. Check whether a teammate or your DNS provider made an intentional change (a migration, a new mail provider, an SPF update).
- If it wasn't — treat an unexpected
NS/MXchange as a security incident: your registrar or DNS account may be compromised. Lock it down and rotate credentials. - For a blocklist listing — identify why the IP was listed (often a shared-host neighbour or a compromised sender) and start the delisting process with the blocklist operator; transactional email is degraded until it clears.
Related
- Health Monitoring — the
transactional_emailcollector catches emails that were generated but never sent, which pairs with blocklist detection - HTTP Checks — uptime and response-time monitoring for the site itself