Stop DNS Changes Without Approval in Your Organization

The accidental DNS change

Most DNS outages don't come from malicious actors. They come from well-meaning engineers who made a change that seemed fine at the time. A record updated with a typo in the IP address. A CNAME pointed to a decommissioned service. A TXT record deleted because it "looked old" but was actually the SPF record keeping your email deliverable.

These aren't failures of competence. They're failures of process. When anyone with access can make any change at any time with no review, mistakes are inevitable. The question isn't "if" but "when" — and whether you'll catch it before customers notice.

The fix isn't to restrict who can think about DNS. It's to add a checkpoint between "I want to change this record" and "the change is live in production." That checkpoint is an approval step.

What a DNS approval process looks like

At its simplest: one person proposes a change, a different person reviews and approves it, and only then does the change get applied to the DNS server or provider.

This is the same two-person rule used for code reviews, infrastructure changes, and financial transactions. It works because a second pair of eyes catches mistakes the first person can't see — not because of distrust, but because humans are bad at spotting their own errors.

In practice, a DNS approval workflow looks like this:

1. Submit. An engineer submits a request through a form or API: "Create A record staging.example.com pointing to 10.5.20.15. Reason: new staging environment for Q3 release."
2. Notify. The request triggers a notification to designated approvers — in Slack, Teams, email, or whatever the team uses. The notification includes all the details needed to make a decision.
3. Review. An approver checks the request. Does the record make sense? Is the IP valid? Does it conflict with anything existing? Is the submitter authorized to request changes in this zone?
4. Approve or reject. One click. If rejected, the submitter gets notified with a reason. If approved, the change moves to execution.
5. Execute. The system applies the approved change to the DNS provider automatically. No manual steps, no logging into consoles.
6. Verify. The system confirms the record exists and matches what was approved. The full chain is logged permanently.

Why teams resist approval processes

If approval workflows are so obviously useful, why doesn't every team have one? Because badly implemented approval processes create more problems than they solve. The common objections are valid:

"It's too slow"

If approving a DNS change takes 4 hours because the approver is in meetings all day, engineers will find ways around the process. They'll get direct console access "just for this one time" and never give it back. Or they'll batch changes up and submit them all on Friday, making review harder because there are 15 changes to evaluate at once.

The fix: make approvals fast. One-click approve from a Slack or Teams notification means the approver doesn't need to context-switch to a different tool. Most DNS changes are routine — a quick glance at the details is enough to approve. Median approval time for most teams is under 10 minutes.

"I'm the only person who understands DNS here"

In smaller teams, the person submitting the change is often the most qualified to evaluate it. Requiring approval from someone less knowledgeable feels backwards. Why should a junior admin approve a change submitted by the senior network engineer?

Two responses to this. First, the approval step isn't just about technical review — it's about having a second set of eyes on the specific values. Even experts make typos. Second, if you're the only person who touches DNS and you get hit by a bus, having every past change documented with context is a gift to whoever picks up after you.

"We don't have enough changes to justify a process"

If you make 3 DNS changes a month, a heavyweight process would be overkill. But a lightweight one — submit a form, get a notification, click approve — adds maybe 2 minutes of overhead per change. That's 6 minutes per month for a complete audit trail of every DNS modification. The overhead scales with the volume; for low-volume environments, it's negligible.

"Emergencies can't wait for approval"

Correct. A legitimate 2am outage where the fix is a DNS change shouldn't be blocked because the approver is asleep. Good approval systems account for this with either: expedited approval (page the on-call approver), self-approval with audit flag (make the change, it gets logged as "approved by submitter — emergency"), or bypass with mandatory post-incident review.

The point isn't to make emergencies impossible to handle. It's to make the emergency path clearly documented so you can review it later. "Who changed DNS at 2am?" should have an answer regardless of whether the normal approval process was followed.

Technical implementation

Implementing a DNS approval process requires three things:

1. A single submission interface

All DNS changes need to flow through one system. If engineers can still log into Route 53, or RDP to a DC and use the MMC console, or run PowerShell commands directly — the approval process is optional, and optional processes get skipped.

This means deploying a tool that accepts DNS change requests and is the only way to modify production DNS. Users interact with the tool; the tool interacts with the DNS providers.

2. Access restriction on providers

The approval process only works if direct write access to DNS providers is removed (or heavily restricted). For cloud providers, this means scoped IAM policies that allow the management tool's service account to write records, but restrict human users to read-only. For Windows DNS, it means removing DnsAdmins membership from individual accounts and giving it only to the tool's service account.

This is the step that makes the process enforceable rather than advisory. If people can't bypass it, they won't.

3. Notification delivery

Approval requests need to reach approvers instantly and be actionable with minimal friction. The best implementations put approve/reject buttons directly in the notification — the approver doesn't need to log into a separate system, navigate to a queue, find the request, and then act on it. They read the details in Slack or Teams and tap a button. Done.

Role design

A practical DNS approval process typically uses three roles:

• Submitter (user). Can request DNS changes. Can see their own request history and the current state of zones they have access to. Cannot approve their own requests.
• Approver. Can review, approve, or reject submitted requests. Can also submit their own requests (but can't self-approve). Typically senior engineers or team leads.
• Admin. Can configure the system, manage users and roles, and access the full audit trail. Can also bypass approval in emergencies (logged).

The key constraint: no one can submit and approve their own change. This is the two-person rule, and it's the single most important control. Everything else is details.

Handling scale

For teams processing dozens of DNS changes per day, individual approval of each record gets tedious. Approaches to scale:

• Bulk requests. Submit 10 related changes as one request (e.g., "adding DNS for new microservices cluster"). The approver reviews and approves the batch, not 10 separate items.
• Zone-based policies. Require approval for production zones (example.com) but allow self-approval for development zones (dev.example.com). The risk profile is different, and the approval burden should reflect that.
• Auto-approval for trusted sources. Changes submitted via CI/CD pipelines (tagged with a deployment ID and traceable to a merged PR) might be auto-approved because they've already been reviewed as part of the code review process.
• Pre-approved patterns. If your team routinely creates A records in a specific subnet for a specific zone, you could pre-approve that pattern and only require manual approval for changes outside the norm.

Measuring success

After implementing a DNS approval process, track these metrics:

• Median approval time. How long between submission and approval? If it's consistently over 30 minutes, you have a bottleneck that'll drive workarounds.
• Rejection rate. What percentage of requests get rejected? A healthy rate is 5-15% — enough to show the process catches real issues, not so high that it's blocking legitimate work.
• Bypass frequency. How often is the emergency bypass used? If it's weekly, your normal process is too slow. If it's once a quarter, that's a genuine emergency.
• Time to resolve DNS incidents. After implementing approvals, does incident resolution get faster? It should — because you can instantly answer "what changed?" from the audit log.
• Drift detections. If you have drift detection running alongside approvals, drift should decrease over time as you lock down direct access. If drift isn't decreasing, someone still has a workaround.

The end state

A mature DNS approval process means:

• Nobody makes unreviewed DNS changes to production. Period.
• Every change has a who, what, when, and why — permanently.
• Approvals take minutes, not hours.
• Emergencies have a fast path that's still audited.
• New team members can submit DNS requests on day one without needing server access or training on provider-specific tools.
• Compliance evidence is automatic, not a quarterly scramble.

It's not about bureaucracy. It's about making the 3am question — "who changed DNS and was it supposed to happen?" — instantly answerable.