DNS Operations

DNS operations is how teams keep domains, email, certificates, and production traffic stable while records keep changing.

The goal is not to make DNS complicated. The goal is to make every change predictable:

owner -> plan -> review -> change -> verify -> monitor -> rollback if needed

Use this page as the operating hub for DNScale DNS workflows. For automation patterns, see DNS Automation. For a symptom-first diagnostic tree, start with DNS Troubleshooting.

Operating Principles

Production DNS should have a small set of rules:

• Every production zone has an owner.
• High-risk records require review.
• Planned cutovers include TTL preparation.
• Verification checks both authoritative and recursive DNS.
• Emergency changes are backfilled into code or documentation.
• Rollback is written before the change begins.

DNS is not only a routing system. It controls web traffic, email delivery, certificate issuance, service discovery, and third-party domain verification.

Change Workflow

Use a repeatable workflow for every meaningful production DNS change.

For small TXT verification records, this workflow can be lightweight. For MX, NS, DS, DNSKEY, CAA, apex, and migration changes, write the steps down before you start.

High-Risk Records

Some records deserve stricter handling because mistakes create outages outside the DNS dashboard.

If the record controls production traffic, email, certificates, or DNSSEC, treat it as high risk.

Verification Commands

Start with authoritative data. This bypasses resolver cache and proves what the provider is serving:

dig @ns1.dnscale.eu example.com A +short
dig @ns1.dnscale.eu example.com SOA +short

Then compare recursive resolvers:

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +short

For delegation and DNSSEC path issues:

dig +trace example.com
dig +dnssec example.com A

If authoritative DNS is correct but recursive resolvers differ, the issue is usually TTL/cache state. If authoritative DNS is wrong, fix the zone data first.

Migration Runbook

DNS migrations are where operations discipline matters most.

Use this shape:

1. Inventory every record, including hidden platform records.
2. Lower TTLs before the change window.
3. Import and validate the zone at the new provider.
4. Run old and new providers in parallel where possible.
5. Switch NS records at the registrar.
6. Verify parent delegation, authoritative answers, recursive answers, DNSSEC, email, certificates, and application health.
7. Keep the old provider active until query traffic has stopped and parent NS TTLs have expired.

Read DNS Migration Guide before touching registrar NS records.

Troubleshooting Paths

Use symptoms to choose the right path:

Avoid changing records until you know which layer is wrong.

Monitoring

DNS monitoring should answer four questions:

• Are authoritative servers reachable?
• Are answers correct from major resolver networks?
• Are latency and error rates changing?
• Are old providers still receiving queries during a migration?

For network-level measurement, see DNS Network Performance Monitoring. For redundancy design, read Primary DNS vs Secondary DNS and DNS Failover Design Patterns.

Rollback Checklist

Before a high-risk change, write down:

• previous record values
• previous TTLs
• commands that prove the previous state is restored
• rollback owner
• rollback deadline
• health checks that trigger rollback
• known cache behavior after rollback

Rollback is not always instant. Resolver caches may hold the changed value until TTL expiry. This is why planned TTL reduction matters.

Related Guides

• DNS Automation
• DNS Troubleshooting
• DNSSEC Failure Troubleshooting
• CAA Debugging Guide
• DNS Migration Guide
• DNS TTL Best Practices
• dig command tutorial
• nslookup tutorial
• DNS Network Performance Monitoring