DNS Monitoring Setup
DNS monitoring in Merlonix works by recording a baseline snapshot of all DNS records for an asset the first time it checks successfully. Every subsequent check diffs against that baseline. If anything has changed, the check is classified as drift.
This approach catches unexpected changes — a CDN migration that went wrong, a TXT record removed by mistake, a nameserver change you were not told about — while staying silent when nothing has changed.
How the baseline is set
When you add an asset and the first check completes, Merlonix records all DNS records it can resolve for that hostname:
AandAAAA(IPv4 and IPv6 addresses)MX(mail exchange)TXT(SPF, DKIM, DMARC, verification tokens)CNAME(canonical name)NS(nameservers)SOA(start of authority)
The baseline is visible in the asset detail page under DNS → Baseline. You can inspect each record type and the value captured at baseline time.
Tip: Add client domains right after onboarding them, while their DNS is in a known-good state. A baseline captured mid-migration will flag everything that was already changing.
Drift classifications
When a check finds a difference from the baseline, it returns a drift classification. Each classification maps to a specific record type and change kind.
| Classification | Record | What changed |
|---|---|---|
A_record_changed | A | IPv4 address changed |
AAAA_record_changed | AAAA | IPv6 address changed |
MX_record_changed | MX | Mail routing changed |
TXT_record_changed | TXT | SPF, DKIM, or other TXT record changed or removed |
CNAME_changed | CNAME | CNAME target changed |
NS_changed | NS | Nameservers changed |
record_removed | Any | One or more records in the baseline are now absent |
record_added | Any | New records present that were not in the baseline |
Risk levels by classification
Not all drift is equally urgent. Use this as a starting point:
| Classification | Typical cause | Risk level |
|---|---|---|
A_record_changed | CDN swap, IP change | Medium — check intentionality |
TXT_record_changed | SPF update, new verification token | Low–medium |
MX_record_changed | Email provider migration | High — can break deliverability |
NS_changed | Registrar migration, domain transfer | Critical — can indicate domain takeover |
record_removed (MX or NS) | Accidental deletion | Critical |
CNAME_changed | Service repoint | Low–medium |
NS_changed and record removal affecting MX or NS records are classified as critical regardless of context. All other drift is warning.
Updating the baseline after intentional changes
When a client migrates to a new CDN, adds a new MX record, or changes any DNS configuration intentionally, Merlonix will continue to flag drift until you update the baseline.
To update the baseline:
- Open the asset detail page
- Scroll to the DNS section
- Click Update baseline
- Confirm the current record values look correct
The baseline is immediately replaced with the current DNS state. Future checks diff against the updated baseline.
When to update vs. investigate:
- You were told about the change in advance → update the baseline
- The change appeared without notice → investigate before updating
- The change affects MX or NS records and you were not informed → treat as critical until confirmed
Do not update the baseline just to silence an alert without verifying the change was intentional. The baseline is your reference for "this is what the DNS should look like."
Handling false positives
Some environments produce recurring drift that is not actionable:
TTL-based record rotation (CDN health balancing, anycast) can cause A_record_changed on every check. If the client is on a CDN that rotates IPs and you have confirmed this is expected, update the baseline to the most stable value — or note in the asset that A-record drift is expected.
TXT record churn from Google Search Console, HubSpot, or similar tools that periodically regenerate verification tokens will produce TXT_record_changed alerts. After confirming the change is from a known tool, update the baseline.
Pending DNS propagation after an intentional change may cause different resolvers to return different values during the propagation window (up to 48 hours). If a drift alert fires immediately after a change you made, wait for propagation to complete, confirm the record is consistent, then update the baseline.
DNS monitoring and check intervals
DNS checks run on the same interval as SSL checks for each asset. The default interval is 60 minutes for Starter plan assets.
If a client has active DNS changes in progress (migration, new service onboarding), you can temporarily increase the check interval to 5 minutes from the asset detail page under Settings → Check interval. Reset it after the migration stabilises.
What DNS monitoring does not cover
DNS monitoring detects record drift. It does not:
- Verify that DNS changes are intentional (that requires communication with clients)
- Monitor DNS propagation speed or TTL values
- Check DNSSEC signing
- Monitor DNS response time or resolver availability
For zone security (DNSSEC, registrar lock), check your client's registrar settings directly.
Next: read Alert Channels to configure where DNS drift alerts are sent, or return to Monitoring Concepts for the full classification reference.