DNS as code

DNS as code is the practice of managing DNS records in version control (usually Git) and applying them via CI/CD pipelines to a DNS provider's API. Same idea as Infrastructure as Code (Terraform, Pulumi), applied specifically to DNS.

Instead of someone logging into Cloudflare's panel and clicking "Add record," DNS changes go through:

1. PR adding a record in a .yaml or .tf file.
2. Review, merge.
3. CI runs the apply step, calls the DNS provider's API.
4. Records are live.

What this gets you

• History. Every change is a commit. Who changed what, when, and why is in git log. Auditable.
• Reversibility. Bad change broke mail? git revert. Apply. Fixed.
• Diff-able review. PRs show diffs. Reviewers catch typos and rogue records before they land in production.
• Reproducibility. Set up a new environment by applying the same code. No "remember to add the staging MX records" tribal knowledge.
• No human-only access. Service accounts apply records via API. People review code; people don't touch the DNS panel directly.

Tooling

• Terraform with the provider plugin for your DNS host (Cloudflare, Route53, GoDaddy, Namecheap, etc.). The most popular path.
• Pulumi for teams that prefer real programming languages over HCL.
• OctoDNS (Github's open-source tool). Provider-agnostic YAML, supports multiple DNS hosts at once. Designed for the multi-provider failover case.
• DNSControl (Stack Exchange's tool). JavaScript-DSL-based, supports many providers.
• External-DNS (Kubernetes). Reads Ingress/Service annotations, syncs DNS records. Different use case but conceptually similar.

What it costs

Real cost: setting up the tooling, training the team, building a deploy pipeline, restraining engineers from "just adding a record real quick" through the panel. The last one is the hardest, because once the panel has drift from your repo, your repo is no longer the source of truth.

When this is overkill

A 3-person startup with 12 DNS records doesn't need DNS as code. The panel is fine. The investment makes sense around:

• 100+ records per zone.
• Multiple zones (multiple brands or environments).
• Multi-region or multi-provider setups.
• Compliance regimes that require change audit trails.

In a custom-domain SaaS

The internal DNS for your own product domain (yoursaas.com, your edge endpoints, your mail routing) is what you put in DNS as code. The customer-facing custom domains aren't typically managed this way: they're created and torn down too dynamically. Customer DNS lives in the database, applied via direct API calls from your service, with state tracked in your app, not in Git.