DNS, the DevOps Way

At a DevOps Cape Town meetup, Gareth Dwyer presented a simple set of tasks that sparked an essential discussion: “Is this the DevOps way?”.

Email and backoffice DNS often suffer from brittle registrar web interfaces. Applying DevOps principles to DNS boils down to two clear objectives:

  • Transparency: Avoid ambiguity over who changed what, when, and why.
  • Reliability: Automate zone validation, syntax testing, and deployments.

The GitOps Flow for DNS

By treating zone files as Infrastructure-as-Code (IaC), DNS records originate from a version-controlled repository, while automation handles deployment.

With Google Cloud Platform, GCP Cloud DNS exposes a complete API, gcloud CLI, and web console.

Automated Deployment with Cloud Build

Using standard BIND zone file format allows validation via named-checkzone before import. A Cloud Build step looks like:

steps:
- name: gcr.io/cloud-builders/gcloud
  args: ['source', 'repos', 'clone', 'honigwachs-info-zone']
- name: gcr.io/cloud-builders/gcloud
  args: ['dns', 'record-sets', 'import', 'honigwachs.info', '--zone=honigwachs-info', '--zone-file-format', '--delete-all-existing']

The gcloud dns record-sets command validates input files at execution. When pushed to main, updates propagate across Google’s anycast edge infrastructure within seconds.

Sample BIND Zone File

$ cat honigwachs.info 
honigwachs.info. 21600 IN NS ns-cloud-b1.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b2.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b3.googledomains.com.
honigwachs.info. 21600 IN NS ns-cloud-b4.googledomains.com.
honigwachs.info. 21600 IN SOA ns-cloud-b1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

www.honigwachs.info. 300 IN A 151.101.1.195
www.honigwachs.info. 300 IN A 151.101.65.195