DNS Change Evidence: How to Track DNS Changes Across a Domain Portfolio

Most teams can eventually notice a DNS change. The harder problem across a portfolio of domains is evidence: a record of what the DNS looked like before, what it looks like now, exactly which records changed, and when. That record is what lets you confirm a change was intentional, hand a clear answer to a manager, and reconstruct what happened after an email or SSL renewal quietly breaks weeks later.

This guide explains what DNS change evidence is, what to capture, and the important boundary between having evidence of a change and being able to undo it. CertPilot captures public DNS snapshots and shows a previous/current comparison per domain. It is not a DNS restore tool — it does not edit, roll back, or manage DNS records.

Use the single-domain health check to see the current public DNS records for a domain, the External Footprint Monitoring page for how DNS evidence fits with SSL and domain checks, and the sample reports to see how DNS changes appear in the Domain Health Report. For the detection-and-troubleshooting side of DNS changes, see the DNS drift agency guide and how to monitor DNS changes across client websites.

What "DNS change evidence" means

DNS change evidence is the durable answer to four questions, captured automatically rather than reconstructed from memory:

• What did the records look like before? A baseline snapshot of the public records.
• What do they look like now? The current snapshot.
• What specifically changed? A field-level comparison — which record group, old value, new value.
• When? The check timestamps that bracket the change.

A simple alert that says "DNS changed" is detection. Evidence is the snapshot pair plus the diff. The difference matters most weeks after the fact, when a certificate fails to renew or email starts bouncing and you need to know whether a DNS edit was the cause.

Why evidence beats a bare alert

DNS sits under the website, email, and certificate renewal at the same time, and several parties can touch it — IT, a hosting platform, a CDN, an email vendor, a previous supplier. Across a portfolio, that produces three recurring problems that evidence solves:

• Delayed blast radius. A removed validation record or changed MX does not break anything immediately. Days or weeks later it does. Evidence lets you connect the outage back to the change.
• Crossed boundaries. The person who sees the change often is not the person who made it. A before/after record turns "did someone change this?" into a checkable fact.
• Accountability and proof. "We review DNS across all domains" is a claim. A monthly report showing which records changed — and which were confirmed expected — is proof.

What to capture across a portfolio

For DNS change evidence to be useful, capture the records that actually carry operational risk, and capture them the same way for every domain:

| Record group | Why it matters as evidence | |---|---| | A / AAAA | Where the site resolves; a change can move traffic to the wrong host | | MX | Email delivery; a change can interrupt or reroute mail | | NS | DNS authority; a change can move the whole zone | | TXT (SPF, DMARC, verification) | Email authentication and vendor proofs | | CAA | Which certificate authorities may issue — relevant as SSL lifetimes shorten |

CertPilot's checks capture these public records per domain and compare snapshots between runs, so the latest snapshot and the previous/current comparison are both available on the domain's detail view. The evidence is read-only: it shows what the public DNS looked like, not a control panel for changing it.

Evidence is not restore — an important boundary

This is the line that keeps DNS change evidence honest:

• Evidence answers what changed and when. It is a read-only record of public DNS state over time.
• Restore / rollback would mean changing the DNS back. That requires write access to the DNS provider — credentials, an API, and the authority to make changes.

CertPilot deliberately stays on the evidence side. It reads public DNS signals and records them; it does not edit DNS, roll back records, restore a previous state, or hold DNS provider credentials. When a change needs to be reverted, that happens in the DNS provider's own control panel by whoever owns it — using CertPilot's evidence to know exactly what to set back.

If you want a true "undo," the right tooling is your DNS provider's change history (for example, an audit log at your registrar or DNS host). Evidence monitoring complements that; it does not replace the provider's own controls.

A lightweight DNS evidence workflow

1. Baseline every domain. Add each domain so the current public records become the reference snapshot.
2. Let checks run on a schedule. Daily is a sensible cadence for most portfolios; it caps the detection window at about a day without creating noise.
3. Review the comparison when records change. Look at which group changed and the old/new values, then decide: expected or not?
4. Confirm and annotate. Record whether the change was planned (a migration, a new email vendor, a CDN setup) so the next person is not re-investigating it.
5. Report it. Roll the month's DNS changes into the Domain Health Report so the review is visible, not just a closed ticket.

Reading a DNS change the right way

Not every change is an incident. Treat the comparison as a prompt, not a verdict:

• A/AAAA changed → did the site move hosts on purpose?
• MX changed → was email migrated (Google Workspace, Microsoft 365, a hosted provider)? MX changes are normal during migrations.
• NS changed → nameserver moves change DNS authority; confirm the new provider is expected.
• TXT changed → check SPF/DMARC and vendor verification records; a well-meaning edit can overwrite an existing record.
• CAA changed → confirm the active certificate issuer is still permitted, especially with shorter SSL lifetimes meaning more frequent renewals.

The question is always "was this expected?" — and the evidence is what lets you answer it confidently.

What CertPilot can help with

• Public DNS snapshots — A/AAAA, MX, NS, TXT, and CAA records captured per domain on each check.
• Previous/current comparison — a read-only view of what changed between checks, on the domain detail page.
• DNS change history alongside SSL and expiry — so compounding problems (a DNS change that later breaks a renewal) are visible in one place.
• Domain Health evidence — DNS changes feed the Domain Health Report; see the sample reports.
• Quick single-domain view — the health check shows current public DNS records for one domain on demand.

What CertPilot does not do

• CertPilot is not a DNS restore tool. It does not edit, roll back, or restore DNS records, and it does not roll back a zone to a previous state.
• It does not hold DNS provider credentials or integrate with provider APIs to make changes.
• The DNS evidence is public-signal, read-only — it shows what an outside resolver sees, not private zone configuration.
• No vulnerability scanning, uptime monitoring, employee monitoring, or compliance certification.

Frequently Asked Questions

What is DNS change evidence?

DNS change evidence is a recorded before-and-after of a domain's public DNS records: a baseline snapshot, the current snapshot, a field-level comparison of what changed, and the timestamps around it. It is the difference between knowing that DNS changed and being able to show what changed and when.

Can CertPilot undo or restore a DNS change?

No. CertPilot records public DNS state and shows what changed; it does not edit, roll back, or restore DNS records, and it does not hold DNS provider credentials. To revert a change you use your DNS provider's control panel — CertPilot's evidence tells you exactly what the previous values were.

How is this different from DNS drift monitoring?

DNS drift articles focus on detecting unexpected changes and troubleshooting the resulting outages. DNS change evidence focuses on the durable record — the snapshot pair and diff you can review later and put in a report. They overlap; this is the evidence-and-reporting angle. See the DNS drift agency guide for the detection side.

Which DNS records should I capture as evidence?

Prioritise the record groups that carry operational risk: A/AAAA (website routing), MX (email), NS (DNS authority), TXT (SPF, DMARC, vendor verification), and CAA (certificate issuance). These cover the changes most likely to break a site, email, or an SSL renewal.

Is every DNS change a problem?

No. Many changes are intentional — a host migration, a new email provider, a CDN setup. Evidence exists so you can confirm whether a change was expected, not to treat every edit as an incident.

Does the DNS evidence include private DNS configuration?

No. CertPilot reads public DNS records — what an external resolver can see. It does not access private internal zones or your DNS provider's account.

Related resources

• DNS drift agency guide — what DNS drift is and how it breaks sites.
• How to monitor DNS changes across client websites — the monitoring workflow.
• DNS record inventory for agencies — building the baseline.
• External Footprint Monitoring — DNS evidence alongside SSL and domain checks.
• Sample reports — how DNS changes appear in the Domain Health Report.