Track Who Changed DNS Records in Active Directory

The problem with native Windows DNS logging

Windows Server does log DNS changes. In theory. In practice, getting useful information out of those logs is an exercise in frustration.

There are two logging mechanisms built into Windows DNS:

DNS Debug Logging

The old-school approach. You enable it in DNS Manager → server properties → Debug Logging tab. It writes a text file (usually dns.log in the %SystemRoot%\System32\dns folder) with raw query and response data. The format is dense, the file gets large fast, there's no structured parsing, and it logs DNS queries — not management operations. If someone created a new A record, you might see the replication traffic, but you won't get a clear "user X created record Y at time Z" entry.

DNS Analytical Event Log

The newer approach, available since Server 2012 R2. It lives under Event Viewer → Applications and Services Logs → Microsoft → Windows → DNS-Server → Analytical. It's disabled by default (you have to right-click and enable it). When enabled, it logs DNS server operations including record additions, modifications, and deletions.

This is closer to what you need, but it has serious limitations:

• It's disabled by default. If you haven't proactively enabled it on every DNS server, you have nothing. Most teams discover this during an incident.
• The events are low-level. You get event IDs like 522 (zone load), 540 (record create), 542 (record delete) — but the user context is often missing or shows the replication service account rather than the human who initiated the change.
• AD-integrated zones replicate changes. When someone creates a record on DC01, AD replication copies it to DC02. Both DCs log the event, but the replication event on DC02 shows the replication account, not the original user. Which DC did the change originate from? You'd have to correlate timestamps across DCs to figure it out.
• Log retention is short. Analytical logs have limited size and overwrite old entries. A DNS change from two weeks ago? Probably gone.
• No context. Even when you find the right event, it tells you "A record created" — not why it was created, who requested it, or whether it was authorized.

Active Directory object auditing

Because AD-integrated DNS zones store records as Active Directory objects, you can also use AD object auditing to track changes. Enable "Audit Directory Service Changes" via Group Policy, and Windows will log when AD objects (including DNS records) are created, modified, or deleted.

This gives you better user attribution (Security Event 5136/5137 includes the user account), but it comes with its own problems:

• Volume. AD auditing generates massive amounts of events across all AD operations — not just DNS. Finding DNS changes means filtering through all the noise.
• Requires a SIEM. The raw Security Event Log on a busy DC rolls over quickly. You need to be shipping these events to a SIEM (Splunk, Sentinel, Elastic) to retain and search them effectively.
• Still no "why." You'll know that jsmith modified the A record for app.corp.local at 2:47pm on Tuesday. You won't know if it was authorized, requested by someone else, or a mistake.

Why native logging falls short

The fundamental issue is that Windows DNS logging was designed for troubleshooting DNS server operations, not for change management. It answers "what happened on the server?" but not "who authorized this change and why?"

For a small team where the same two people make all DNS changes and can just ask each other, native logging is adequate. For anything bigger — multiple admins, compliance requirements, on-call rotations, delegated access — you need something that tracks the intent behind changes, not just the technical execution.

Here's what "good" DNS change tracking actually provides:

• Who submitted the change. Not the service account or replication account — the actual human who initiated it.
• Who approved it. If your process requires approval, the tracker should log who reviewed and authorized the change.
• When it was requested vs. when it was applied. These are often different, especially for scheduled changes.
• Why it was made. A plain-text description: "Adding CNAME for new staging environment per JIRA-4521."
• What the previous value was. If a record was modified, what did it point to before? This is critical for rollbacks.
• Instant search. "Show me every DNS change made to corp.local in the last 30 days" should take one query, not an hour of Event Viewer filtering.

Approaches that actually work

Application-level audit logging

The most complete solution is to route all DNS changes through an application that maintains its own audit log. Instead of engineers making changes directly on the server (where logging is limited), they submit changes through a tool that records every detail before executing the change on the server.

This flips the model. Native logging tries to reconstruct intent after the fact by examining server-side events. Application-level logging captures intent at the source — before the change even reaches the DNS server. The user types a description, clicks submit, and that entire context is preserved permanently alongside the technical details of what changed.

PowerShell wrapper scripts

A middle-ground approach: write a PowerShell script that wraps DNS cmdlets with logging. Engineers use the script instead of raw cmdlets, and the script logs the user, timestamp, change details, and any notes to a central location (a CSV, a database, a log management system).

This is better than nothing but fragile. It relies on everyone using the script, doesn't prevent direct MMC access, and breaks down the moment someone takes a shortcut. It's also purely honor-system — there's no enforcement, just convention.

SIEM-based reconstruction

If you already run a SIEM and have AD auditing enabled, you can build dashboards and alerts around DNS change events. Correlate Security Event 5137 (AD object creation in the MicrosoftDNS container) with the user account that initiated it. Set up alerts for changes to specific high-value zones.

This works for detection after the fact but doesn't help with the approval workflow. You'll know something changed, but you can't prevent unauthorized changes — only detect them. It's also expensive if your SIEM charges by ingestion volume, because AD audit events are high-volume.

What to look for in a solution

If you're evaluating tools to solve this problem, here are the capabilities that matter:

• Immutable audit trail. Logs can't be edited or deleted. Every entry has a timestamp, user, action, and the full before/after state of the record.
• Search and filter. Find changes by zone, record name, user, date range, or action type in seconds. Not "open Event Viewer and scroll."
• Export. CSV export for compliance evidence. SIEM forwarding (syslog) for integration with existing security tooling.
• Attribution to real users. The log shows the human who initiated the change, regardless of which service account executed it on the server.
• Context field. A place for "why" — a ticket number, a plain-text reason, a link to the request. Without this, you have what changed but not why.
• Retention. Logs should be retained for as long as your compliance policy requires (often 1-7 years), not until the Windows Event Log rolls over.

The compliance angle

If your organization deals with SOC 2, ISO 27001, PCI DSS, or HIPAA, the auditors will eventually ask about DNS change management. The specific questions vary, but they boil down to:

• "Can you show me who made this DNS change and when?"
• "Was this change authorized before it was applied?"
• "How do you ensure unauthorized DNS changes are detected?"

Answering these questions with "we check the Windows Event Log" is technically possible but practically painful — and auditors know it. Having a dedicated audit trail with clear attribution, approval records, and change history makes compliance evidence trivial to produce instead of a scramble every audit cycle.

Getting started

If you're currently relying on Windows Event Log for DNS change tracking (or worse, relying on nothing), here's the path forward:

1. Enable DNS Analytical Logging now. Even if you plan to implement a better solution, enabling the Analytical log on all DNS servers gives you a baseline. It's better than having nothing while you evaluate options.
2. Audit who has write access. List everyone who can currently modify DNS records — either through MMC, PowerShell remoting, or AD permissions. This tells you how many potential change sources exist.
3. Centralize changes through one interface. Deploy a DNS management tool that logs everything at the application level. Route all DNS requests through it.
4. Tighten permissions. Once the centralized interface is working, remove direct DNS write access from individual accounts. Funnel everything through the tool's service account.
5. Forward logs to your SIEM. The application audit log should integrate with whatever you already use for security monitoring — Splunk, Sentinel, Elastic, or just syslog to a central collector.

The end state is simple: one place to search, one place to prove compliance, and an instant answer to "who changed that record?"