Why DNS needs change control

Every other piece of critical infrastructure has a change process. Code goes through pull requests. Infrastructure changes go through Terraform plans. Database migrations get reviewed. But DNS? Most teams are still logging into a console and clicking buttons — the same way they did in 2005.

It's not because DNS doesn't matter. DNS is arguably the most critical layer — if it's wrong, nothing else works. Email stops flowing. Services become unreachable. Customers see error pages. And because DNS propagation takes time, rollbacks aren't instant.

The disconnect exists because DNS changes feel small. "I'm just adding a CNAME." "It's one TXT record." The changes are tiny, so the perceived risk is low — until a typo takes down production, or someone deletes a record they thought was unused, or an expired engineer's test record starts serving traffic to nowhere.

Code changes get reviewed because teams learned (the hard way) that even small changes can break things. DNS deserves the same rigor — not because every change is high-risk, but because when a DNS change goes wrong, the blast radius is enormous and the debugging is painful.

What change control means for DNS

DNS change control means that every modification to a production DNS zone follows a defined path: submit, review, approve, apply, verify. No one can make a production DNS change that isn't tracked and authorized.

That doesn't mean bureaucracy. It means visibility. You know who changed what, when, why, and who approved it. When something breaks at 3am, you can answer "what changed?" in seconds instead of minutes or hours.

Concretely, a DNS change under change control looks like this:

  1. An engineer submits a request: "Create CNAME api.example.com → lb-prod-01.example.com, needed for new API gateway deployment."
  2. A second engineer reviews the request, checks for conflicts, and approves it.
  3. The system applies the change to the correct DNS provider automatically.
  4. The system verifies the record exists and matches what was requested.
  5. The entire chain — request, approval, apply, verification — is logged permanently.

Compare that to the alternative: someone logs into Route 53, creates the record, maybe tells the team in Slack, maybe doesn't. Three months later, nobody knows why that record exists or whether it's still needed.

The four pillars

Submission: structured requests with context

Every change starts with a request that captures who is making the change, what they're changing, why they're changing it, and when it should take effect. This isn't paperwork — it's the information the approver needs to make an informed decision, and the information the on-call engineer needs at 3am when troubleshooting.

A good submission includes the record type, name, value, TTL, the target domain, and a plain-text reason. Pre-flight validation catches obvious problems before the request even reaches an approver — conflicts with existing records, invalid syntax, typos in record values.

Approval: independent review before execution

The two-person rule means the person who requests a change can't also approve it. This isn't about trust — it's about catching mistakes. A second pair of eyes asking "are you sure that CNAME should point there?" prevents outages that self-service can't.

Approvals need to be fast and frictionless. If approving a change means logging into a separate system, navigating to the right page, and clicking through three screens, people will find ways around the process. One-click approval from Slack or Teams removes that friction entirely.

Execution: automated apply with no manual steps

Once approved, the change should be applied automatically by the system — not by a human logging into a console. Automated execution means the change is applied exactly as approved (no typos during manual entry), applied to the correct provider (the system knows which provider hosts which zone), and applied consistently every time.

This also handles the complexity of multi-provider environments. If you have zones on Route 53, Azure DNS, and Windows DNS servers, the system routes each approved change to the correct provider using the appropriate protocol — AWS SigV4 for Route 53, OAuth2 for Azure, WinRM/PowerShell for Windows DNS.

Verification: confirm the change took effect

Applying a change isn't the same as the change being live. API calls fail silently. Providers have eventual consistency. Records might not propagate immediately. Verification means the system checks that the applied record actually exists on the provider with the correct value.

Beyond immediate verification, continuous drift detection catches changes that happen outside your workflow — someone modifying a record directly on the provider, an automated script making undocumented changes, or a partial failure that left records in an inconsistent state.

Implementing it step by step

Step 1: Centralize your zones

You can't control what you can't see. The first step is importing existing records from all your DNS providers into one system that serves as the source of truth. This is a read-only operation — you're pulling a snapshot of what currently exists, not changing anything.

For Windows DNS servers, this means importing via WinRM. For cloud providers (Route 53, Azure DNS, GCP Cloud DNS, Cloudflare), it's API-based import using existing credentials. For anything else, BIND zone file import works as a universal fallback.

This gives you a baseline — the known state that drift detection will compare against going forward.

Step 2: Establish the workflow

Define who can submit requests, who can approve them, and what requires approval. Not every change needs the same scrutiny — you might require two-person approval for production zones but allow self-approval for development zones. The workflow should match your team's risk tolerance, not impose unnecessary ceremony.

Decide on your approval policy: strict two-person rule for everything, two-person for production only, or optional with full audit trail. Even when bypassed, every action gets logged — you always know what happened.

Step 3: Connect notifications

The approval workflow only works if approvers actually see requests. Connect your team's communication channels — Slack, Microsoft Teams, Discord, or email — so new requests trigger immediate notifications with enough context to approve or reject without switching tools.

One-click approve/reject buttons in notifications mean an approver can review and act from their phone during an incident without logging into anything. The notification includes the full change details: record type, name, value, who submitted it, and why.

Step 4: Lock down direct access

Once your workflow is running smoothly, start restricting direct write access to your DNS providers. This is the step that prevents drift at the source. Use IAM policies to make provider consoles read-only for most team members. Issue scoped API tokens that only your change management system can use to write records.

Don't do this on day one. Let the team get comfortable with the workflow first, then tighten permissions. If you lock down access before the workflow is trusted, people will resent it.

Step 5: Enable drift detection

Even with access locked down, drift can still happen — through automation running with legacy credentials, provider-side changes, or emergency procedures that bypass the workflow. Drift detection continuously compares live DNS state against your approved baseline and alerts when discrepancies appear.

This is your safety net. It catches everything the workflow misses and gives you confidence that what you see in your change log matches reality.

Step 6: Integrate with CI/CD

For teams that manage DNS as part of deployments, CI/CD integration lets pipelines submit change requests through the same workflow. A GitHub Actions workflow or GitLab CI pipeline can create a DNS request as part of a deployment, and that request flows through the same approval and verification process as any manual change.

This extends your change control to automated processes without requiring them to use a different interface. Terraform changes can be tagged with their source and flow through the same audit trail. Webhook handlers accept requests from GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, and Azure DevOps natively.

Common objections

"It's too slow for emergencies"

This is the most common objection, and it's valid — if your workflow doesn't account for emergencies. A good change control system has a fast path: scheduled changes for planned work, expedited approval for urgency, and bypass-with-audit for genuine 2am outages where the approver is asleep. The bypass still logs everything — you get the audit trail even when you skip the approval step. You can review it the next morning.

"We only have a few zones"

Complexity isn't the reason for change control — auditability is. A team with three zones and 50 records still benefits from knowing who changed what and when. The question isn't "do we have enough DNS to justify a process?" — it's "can we answer 'what changed?' when something breaks?" If you can't answer that question in under 60 seconds, you need change control regardless of zone count.

"Our team is small, we trust each other"

The audit trail isn't about distrust. It's about visibility. Small teams have high context because everyone knows what everyone else is doing — until someone's on vacation, or a new person joins, or it's been three months and nobody remembers why that TXT record exists. The audit trail is organizational memory. It answers "why?" long after the person who made the change has forgotten.

The payoff

Teams that implement DNS change control consistently report the same benefits:

The investment is minimal — a few hours to import zones, a week to get the team comfortable — and the return is permanent visibility into one of your most critical infrastructure layers.