← Back

DNS as code

April 29, 2026

Editing production DNS by hand in a web console is the same anti-pattern as managing servers over SSH. The fix is the same one we already apply everywhere else: put it in version control.

DNS changes are quietly some of the highest-blast-radius edits you can make. A wrong A record points your whole site at nothing. A fat-fingered MX silently drops mail. A TTL bumped to a day means the mistake sticks around long after you fix the record. And the usual way to make these changes is to log into a panel, edit a field, and hope, with no diff, no reviewer, and no record of what it was before.

We stopped doing that to servers years ago. Infrastructure as code gave us review, history, and rollback for the machines. DNS is infrastructure too, and it deserves the same treatment.

What it looks like

With the dnswiz Terraform provider, a zone, a failover pool, its backends, a health check, and the record that points at the pool are all just resources you commit:

resource "dnswiz_zone" "acme" {
  name = "acme.com"
}

resource "dnswiz_pool" "api" {
  name             = "api-backends"
  selection_method = "weighted"
}

resource "dnswiz_pool_member" "api_us" {
  pool_id = dnswiz_pool.api.id
  target  = "203.0.113.10"
  weight  = 100
  enabled = true
}

resource "dnswiz_pool_member" "api_eu" {
  pool_id = dnswiz_pool.api.id
  target  = "203.0.113.20"
  weight  = 100
  enabled = true
}

resource "dnswiz_health_monitor" "api" {
  name     = "api-tcp-443"
  type     = "tcp"
  port     = 443
  interval = 30
}

resource "dnswiz_record" "api" {
  zone_id = dnswiz_zone.acme.id
  name    = "api"
  type    = "POOL"
  ttl     = 60
  pool_id = dnswiz_pool.api.id
}

That is a complete health-checked failover setup for api.acme.com, expressed in a file you can read in a pull request. The same provider also covers the rest of a zone: ordinary A, AAAA, CNAME, MX, TXT, SRV, CAA and ANAME records, zone policies, notification channels, and TLS certificates issued through DNS-01 for you.

What you get for it

Review before it ships. A DNS change shows up as a diff in a pull request. Someone who is not the person making the change at 11pm gets to see "this repoints the apex" before it is live.
A real history. Git already answers who changed the MX record, when, and why, with the commit message and the review attached. No separate audit feature required.
Rollback that means something. Reverting a bad DNS change is reverting a commit and running apply, not trying to remember what the value used to be.
Drift you can see. terraform plan tells you when the live zone no longer matches what is committed, so a hand-edit made during an incident does not silently become the new undocumented truth.
Reproducible environments. Staging and production zones come from the same module with different variables, instead of being assembled by hand twice and drifting apart.

The API is not an upsell

None of this works if programmatic access is a paid tier. We have used providers where API access to your own DNS is a monthly add-on, and it pushes you straight back to clicking in a console for the small stuff. In dnswiz the API is the product and the Terraform provider sits directly on it, so everything you can do in the dashboard you can do in code, on every plan. The dashboard is for looking; the code is the source of truth.

If the failover pool in the example is new to you, the GSLB write-up explains what it does and where it helps.