Who changed this DNS record? How to find out

The site went down at 14:05. By 14:20 someone has found that www now points at an address nobody recognises. The next question in the incident channel is always the same: who changed it, and when? On many DNS setups that question has no answer, and the reason is worth understanding before the next incident.

1 Why DNS cannot tell you who changed a record

The DNS protocol answers questions about the current state of a zone. An authoritative server returns the records it holds right now, and a resolver returns whatever it has cached. Nothing in a DNS answer carries an author, a timestamp of the change or the previous value.

The closest thing to a change marker is the serial number in the zone's SOA record. RFC 1035 describes it as the version number of the zone, used by secondary servers to notice that something changed. It tells you that the zone changed, not which record changed or who did it. Some setups encode the date in the serial (for example 2026100201), but that is a convention, not a rule, and many managed providers use other schemes.

So the author of a change can only be found outside DNS: in the system that accepted the change, which is your provider's panel and API, or your own tooling if you deploy zones from code.

2 Reconstruct the incident step by step

2.1 Confirm what is being served now

Ask each authoritative nameserver directly, without recursion, so caches are out of the picture. If the servers disagree, the change may still be propagating between them, or one of them is serving stale data.

dig +short NS example.com
dig @ns1.example.net example.com SOA +norecurse +noall +answer
dig @ns1.example.net www.example.com A +norecurse +noall +answer
dig @ns2.example.net www.example.com A +norecurse +noall +answer

Write down the SOA serial from every server. If you check again later and it has moved, someone has changed the zone again while you were investigating.

2.2 Work out when it changed

The first failed health check is not the moment of the change. Resolvers that had the old answer cached keep serving it until its TTL runs out, so the change happened up to one TTL before the first users noticed, and different users notice at different times.

Use the earliest reliable signal you have (monitoring, deploy logs, the SOA serial if your provider uses dates) and search the change logs in a window that starts at least one TTL before it.

2.3 Ask the system that accepted the change

This is where the author is, if anywhere. Two common cases:

Cloudflare. Cloudflare's documentation states that audit logs are available on all plan types and are retained for 18 months, and that entries include the actor's email and IP address. The dashboard shows the most recent 90 days; older entries are reachable through the API.

Route 53. Route 53 is integrated with AWS CloudTrail, and record changes appear as ChangeResourceRecordSets events with the caller's identity and source IP. CloudTrail event history keeps the past 90 days of management events at no charge; for anything older you need a trail you created in advance. AWS notes that Route 53 events are found in the US East (N. Virginia) region:

aws cloudtrail lookup-events --region us-east-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ChangeResourceRecordSets \
  --start-time 2026-10-01T12:00:00Z --end-time 2026-10-01T15:00:00Z

A CloudTrail entry records the change request. For an UPSERT that is the new record set only, so the previous value has to come from somewhere else, such as a zone export or your infrastructure code.

For DNS that came bundled with a domain or hosting plan, check the control panel for an activity or history page, and if there is none, ask support. Some providers keep internal logs they do not expose.

2.4 When there is no log at all

You can still establish what changed. Compare the live answers with the last zone file you have: a backup, an export, or the zone as defined in Terraform, OctoDNS or DNSControl. Passive DNS services, which record answers observed on the internet over time, can show when an answer first appeared. Neither tells you who made the change. That gap is the argument for fixing the setup before the next incident, not during it.

3 What a useful DNS audit log records

An audit log helps in an incident only if each entry answers the questions you will actually ask. Use this as a checklist when you evaluate a provider or your own tooling:

Whether you get a log like this depends on who hosts your DNS. Where DNS is an extra that comes with a domain registration, there is often no change log at all; where one exists, the details differ a lot. Checked against public documentation on 2 October 2026:

4 Which regulations and standards expect a change log

A DNS change log is not only useful during an outage. Most security frameworks ask you to show who changed critical configuration, when, and with whose approval, and DNS is critical configuration: whoever controls a record controls where your users, email and API traffic go.

• NIS2 (EU Directive 2022/2555): Article 21 requires risk-management measures including access control, incident handling and security in maintenance of systems. DNS service providers are in scope themselves, and for them Implementing Regulation (EU) 2024/2690 spells out logging, monitoring and privileged access requirements.
• DORA (EU Regulation 2022/2554): banks, insurers and other financial entities must manage ICT risk, log and monitor access, and oversee their third-party ICT providers, which includes the DNS provider.
• ISO/IEC 27001:2022: Annex A controls 8.15 (Logging), 8.32 (Change management), 5.15 and 5.18 (Access control and access rights) and 8.2 (Privileged access rights).
• SOC 2: Trust Services Criteria CC6 (logical access), CC7 (system monitoring) and CC8.1 (change management).
• NIST SP 800-53, the basis of FedRAMP: AU-2 and AU-3 (which events to log and what each record contains), AU-11 (retention), CM-3 (configuration change control) and AC-6 (least privilege).
• PCI DSS v4.0: Requirement 10 (log and monitor access, with at least 12 months of history and the last 3 months immediately available) and Requirement 7 (restrict access by need to know), when DNS can redirect traffic to payment pages.
• HIPAA Security Rule: 45 CFR 164.312(b) audit controls for systems handling health data.
• GDPR Article 32: appropriate technical measures for the security of processing.

None of these frameworks names a DNS product, but in an audit the questions are concrete: show the changes to this zone in the last year, show who can edit it, show that access is reviewed. An exportable log with old and new values and per-zone roles answers them with a file instead of a meeting.

5 Limit who can change what

An audit log tells you who made a mistake. Access control decides how big the mistake can be.

5.1 Many domains, many owners

The problem grows with the portfolio. An MSP or agency runs zones for dozens of clients; a larger company has zones that belong to different departments, brands or countries. Each zone has its own people who should be able to change it, and many more who should not. When DNS sits in a registrar account, the usual workaround is one shared login for everyone: then any person can change any domain, and the log, if there is one, cannot tell them apart.

What you want instead is access per person and per zone: the client's developer can edit their own zone and nothing else, the marketing team can read the records of the brand domain, your on-call engineer can fix any zone, and every entry in the log names the person who did it.

5.2 Rules that keep the blast radius small

Most teams do not need everyone to be able to edit every zone:

• Give people write access only to the zones they work on, and read-only access where they only need to look.
• Give monitoring and reporting tools read-only keys.
• Give each automation (certificate renewal, CI deploys) its own key, so you can revoke one without breaking the others.
• Review members and keys when people change roles or leave.

As a second record that does not depend on any provider, export your zones on a schedule and commit them to a repository. Any provider that exports BIND-format zone files works; with PrimeDNS it looks like this:

curl -s -H "X-API-Key: $PRIMEDNS_KEY" \
  https://api.primedns.net/v1/zones/example.com/export > zones/example.com.zone
git -C zones add example.com.zone
git -C zones commit -q -m "zone snapshot $(date -u +%F)" || true

git log -p zones/example.com.zone then shows what changed between snapshots, even if it cannot show who.

6 How PrimeDNS handles this

DNS is the product here, not an extra that comes with a domain. PrimeDNS was built for teams that need to answer "who changed it" in minutes, not after a support ticket, and for people who look after many zones for clients or departments. Where it differs from the options above:

• The previous value is in the entry. Each change shows old and new content, TTL and priority side by side, so rolling back does not depend on a backup.
• DNS changes are easy to isolate. Filter by zone and action and you see record changes only, without scrolling past unrelated settings.
• Nothing to set up in advance. No trail, no storage bucket, no separate service: the log is on from the first change, on every plan.
• Two years of history, not 90 days, and longer on request on the Business plan.
• A spreadsheet in one click. CSV export in the panel and through the API, ready for an auditor or your SIEM.
• Access down to a single zone. Invite a person with a role on one zone, several zones or the whole account, and give them a different role on each: DNS Manager on a client's zone, DNS Viewer on another, nothing on the rest.
• One login across client accounts. A person can be a member of several PrimeDNS accounts and switch between them in the panel, so an MSP or agency engineer works in each client's account under their own name, and each client's log shows exactly who did what.
• Access to the log follows roles: the owner and Admins see everything, Billing sees only billing entries.

Every PrimeDNS account has an Audit Log in the panel. Every change to a record, made in the panel or through the API, adds an entry with the time in UTC, the user, whether the change came from the panel or the API, the client IP, and the old and new content, TTL and priority. The log also records zone creation, deletion, import and export, DNSSEC being turned on or off, API key and team changes, and sign-ins and two-factor changes.

You can filter by zone and action and export the result as CSV, in the panel or through the API with a key that has the dns:read scope:

curl -s -H "X-API-Key: $PRIMEDNS_KEY" \
  "https://api.primedns.net/v1/audit?zone=example.com&event_type=dns&format=csv" -o audit.csv

A CSV request returns up to 1000 entries; use offset to page through more. Entries are kept for two years and then deleted. On the Business plan the retention can be extended if you need a longer history; ask us.

Access to the log follows team roles. The account owner and members with the Admin role see everything, the Billing role sees only plan and payment entries, and the other roles (DNS Manager, DNS Viewer, Monitoring) cannot open it. Team members can be limited to specific zones. Team access is part of the Professional and Business plans.

Step-by-step instructions are in the guides for the Audit Log and Team & RBAC.

Information about other providers is based on their public documentation as of 2 October 2026. Product names and trademarks belong to their owners. Spotted something out of date? Write to This email address is being protected from spambots. You need JavaScript enabled to view it..