DNS in CI/CD Pipelines

DNS changes are production changes.

An A record can move users. An MX record can break mail. A TXT record can fail domain verification. A DS record can make a signed domain disappear behind SERVFAIL.

That is why serious DNS changes should follow the same path as code:

pull request -> check -> preview -> review -> apply -> monitor

The Safe Pipeline Shape

Use four stages:

The important separation: pull requests should not mutate production DNS.

What to Check

Your check stage should catch boring mistakes before a human reviewer reads the diff.

Good checks:

• zone file or config syntax
• duplicate records
• invalid CNAME combinations
• missing trailing dots in raw zone files
• SPF lookup count
• TTL bounds
• protected record deletion
• DNSSEC-sensitive changes
• provider authentication

Examples:

dnscontrol check
terraform fmt -check
terraform validate

For policy checks, keep rules explicit:

Do not delete MX records without approval.
Do not lower TTL below 60 seconds.
Do not edit production apex records from non-production workspaces.
Do not change DS records without a migration ticket.

What to Preview

The preview stage should answer one question:

What DNS records will change if this is merged?

For DNSControl:

dnscontrol preview

For Terraform:

terraform plan

The output should be attached to the pull request. Reviewers should not have to run the command locally to see the blast radius.

Applying Changes

Apply only after merge to a protected branch:

main branch -> apply workflow -> provider API

Use branch protection:

• required review
• required status checks
• no direct pushes
• separate approval for production environments

If the provider supports scoped credentials, the apply token should be scoped to the exact zone or account role it needs.

DNScale supports zone-scoped API keys, which is the right default for CI. A leaked token for example.com should not be able to edit every customer-facing domain.

Drift Detection

Drift is what happens when published DNS no longer matches code.

Common causes:

• emergency dashboard edits
• another automation job
• manual registrar changes
• failed partial deploys
• provider-side imports

Run a scheduled preview or plan:

dnscontrol preview
terraform plan -detailed-exitcode

Alert when drift appears. Do not silently overwrite it without review; the manual change may have been an incident fix.

Rollback

Rollback should be a normal code change:

git revert <bad-change>

Then let the same pipeline check, preview, and apply it.

For high-risk migrations, prepare the rollback commit before you start. DNS rollback is time-sensitive because resolver caches keep old answers until TTL expiry.

Secret Handling

Bad pattern:

DNSCALE_API_KEY=... in repo

Better pattern:

CI secret store -> environment variable -> provider tool

Best pattern:

• one token per zone or environment
• no production token in pull-request workflows from forks
• short rotation process
• audit log review
• separate read-only token for drift checks when possible

Terraform vs DNSControl vs API Scripts

Avoid custom scripts for the main production path unless you are prepared to maintain validation, diffing, retries, and rollback yourself.

Minimal Pipeline Policy

For production DNS:

1. All changes through pull requests.
2. Preview output attached to the PR.
3. Apply only after merge to protected branch.
4. Zone-scoped write credentials.
5. Scheduled drift detection.
6. Manual dashboard edits documented and backfilled into code.
7. DNSSEC and delegation changes require extra review.

That is enough to prevent most DNS accidents.

Related Reading

• DNScale Terraform provider guide
• DNScale DNSControl guide
• Multi-provider DNS deployment
• DNS migration with zero downtime
• DNS as code best practices