DNS Automation

DNS automation turns repeated DNS work into controlled workflows.

Good automation does not bypass operations discipline. It makes the safe path easier:

validate -> preview -> review -> apply -> verify -> drift check

Start with DNS Operations for the operating model. Use this page to choose the right automation surface and build workflows that do not surprise production.

Automation Surfaces

DNScale DNS automation usually fits one of four surfaces.

Avoid using several writers for the same record set. If Terraform manages www.example.com, the dashboard and scripts should not also manage it as a routine path.

Safe Workflow Shape

Use this baseline for production automation:

pull request:
  validate
  preview diff
 
protected branch:
  apply
  verify
 
scheduled:
  drift check

For GitHub examples, see GitHub Actions DNS Workflows. The same shape applies to GitLab CI, Buildkite, Jenkins, and other CI systems.

For GitLab-specific YAML, protected environments, and variable handling, see GitLab CI DNS Workflows.

Credentials

Credentials define the blast radius of automation.

Use:

• zone-scoped keys instead of account-wide keys where possible
• separate read/preview credentials from write/apply credentials
• separate production and staging credentials
• CI secret stores or a secret manager
• short-lived credentials where your internal platform supports them

Avoid:

• committed API keys
• one global token for every zone
• write tokens exposed to untrusted pull requests
• local developer tokens reused by CI

For product-side key handling, see Multi-User Accounts and Zone Access Control and the API authentication docs.

What to Automate

Good candidates:

• tenant verification TXT records
• environment-specific A, AAAA, CNAME, and ALIAS records
• DNS-01 challenge records for certificate issuance
• standard email DNS bundles for new domains
• bulk record imports and normalizations
• multi-provider sync
• daily drift checks
• migration preflight checks

Risky candidates:

• registrar-side NS changes without human approval
• DS/DNSKEY updates without DNSSEC runbook review
• MX or DMARC enforcement changes without mail-owner review
• deletion of broad TXT records without ownership context
• automatic low-TTL changes that never restore normal TTLs

Automation should reduce repeated manual work, not remove ownership.

Pull-Request Preview

Every production DNS automation path should answer this question before apply:

What records will be added, changed, or deleted?

For Terraform:

terraform fmt -check
terraform validate
terraform plan

For DNSControl:

dnscontrol check
dnscontrol preview

For direct API automation, build your own dry-run mode. It should print the intended changes without mutating the provider.

Drift Detection

Run a scheduled drift check for zones managed by code.

Drift usually means one of three things:

• someone made an emergency dashboard edit
• another automation path changed the same record
• the provider has state that was never imported into code

Drift is not automatically bad. It is a signal that the source of truth needs reconciliation.

Common Workflows

Tenant verification

Application creates a scoped TXT record:

_verify.customer.example.com TXT "dnscale-verify=..."

Rules:

• keep TTL low but not zero
• include an expiry owner in your internal system
• delete stale values after verification
• avoid writing outside the tenant's delegated name

DNS-01 certificates

Certificate automation writes _acme-challenge TXT records.

Rules:

• use a credential scoped to the validation zone
• clean up challenge records after issuance
• support multiple simultaneous TXT values
• verify propagation against authoritative DNS before asking the CA to validate

Read Let's Encrypt DNS-01 Challenges with DNScale and lego DNS-01 with DNScale.

Bulk changes

Bulk changes need stronger guardrails:

• preview every affected record
• split high-risk records into a separate change
• apply in batches when possible
• verify representative names after each batch
• keep export snapshots before and after

Emergency rollback

For code-managed DNS, rollback should usually be a commit:

git revert <change>
terraform plan
terraform apply

or:

git revert <change>
dnscontrol preview
dnscontrol push

After rollback, verify authoritative DNS first, then recursive DNS.

Related Guides

• DNS Operations
• DNS as Code Best Practices
• DNS in CI/CD Pipelines
• GitHub Actions DNS Workflows
• GitLab CI DNS Workflows
• Managing DNS with Terraform
• Managing DNS with DNSControl
• Multi-Provider DNS with Terraform and DNSControl