Build a DNS Change Checklist for Teams

## Why Teams Need a DNS Change Checklist DNS changes are among the most impactful yet poorly tracked operations in infrastructure. A single misconfigured A record can take down a production service. A forgotten MX record can silently break email delivery. Without a standardized process, teams rely on tribal knowledge that fails under pressure. A DNS change checklist eliminates guesswork. It forces the team to document intent, validate assumptions, and prepare for failure before any record goes live. Whether you are adding a CNAME for `api.myproject.is-pro.dev` or migrating MX records, the checklist ensures every change follows the same predictable workflow. ## Pre-Change Audit Steps Before making any DNS modification, run through a pre-change audit. **Document the current state.** Capture a snapshot of every record you plan to modify using `dig` or your provider's API. Record exact values for A, AAAA, CNAME, MX, TXT, SRV, and NS records. Store this snapshot where the team can access it. **Identify all dependencies.** An A record change affects SSL certificates, health checks, load balancers, and monitoring alerts. Before changing the IP behind `api.myproject.is-pro.dev`, verify that every system referencing that subdomain will continue to function. **Check propagation timing.** Lowering a TTL should happen before the actual IP change. If your current TTL is 86400 seconds, a change today may not fully propagate for 24 hours. Plan TTL reduction at least 48 hours before the primary change. **Verify zone permissions.** Confirm who has write access to the zone. Document the account or API token that will be used, and ensure it is valid. **Communicate the change window.** Notify on-call engineers and anyone who might receive alerts. A brief notification at the start prevents confusion when monitoring systems fire. ## Staging and Validation Never apply DNS changes directly to production without validation. Even simple A record changes can interact with caching layers and certificate systems in unexpected ways. **Test in a staging zone.** Create a staging zone that mirrors production. Apply changes there and query them with `dig` against a custom nameserver. This catches typos and propagation issues before they affect production. **Validate record syntax.** A CNAME target must point to a valid hostname, not an IP. An MX record requires a priority value and a valid mail host. TXT records for SPF or DKIM must conform to specific rules. Run each record through a DNS validator before deployment. **Confirm certificate compatibility.** If you are adding a subdomain that requires HTTPS, verify your SSL certificate covers the new hostname. Wildcard certificates for `*.is-pro.dev` cover all subdomains, but custom domains need explicit coverage. **Test resolution from multiple locations.** DNS is distributed. A record that resolves from your office may not resolve from a cloud region. Use tools that query from multiple locations to validate consistency. ## Rollback Procedures Every DNS change must have a rollback plan documented before the change is applied. The plan includes old record values, revert steps, time required, and who is authorized to execute it. **Save exact pre-change values.** Record the complete set of values for every record you are modifying. If you are changing an A record from `192.0.2.1` to `198.51.100.1`, document both values with the original TTL. **Define rollback triggers.** Establish criteria for when a rollback should happen. Common triggers: the new record does not resolve after five minutes, dependent services report errors, SSL handshakes fail, or monitoring detects increased error rates. **Practice rollback procedures.** Run through the rollback at least once in staging. Time how long it takes and identify blockers. Create a script that applies all revert values atomically rather than requiring manual entry under pressure. **Set a rollback deadline.** Decide how long you will wait for a change to propagate before declaring failure. A 15 to 30 minute window works for most production changes. ## Post-Change Monitoring DNS changes are not complete when records are updated. They are complete when you have confirmed the new configuration works. **Verify resolution from external resolvers.** Query the changed record against `8.8.8.8` and `1.1.1.1`. Confirm the response matches the expected value. Stale data indicates the old TTL is still cached. **Check service health.** Monitor health endpoints, error rates, and response times. DNS breakage shows up as 5xx errors, connection timeouts, or certificate warnings. Set up a 30-minute monitoring window after every change. **Validate email delivery.** If you modified MX records, send test emails and verify delivery. Check MX resolution using `dig MX yourdomain.com`. Confirm that SPF, DKIM, and DMARC records remain consistent. **Update documentation.** After the change is confirmed working, update internal DNS documentation with the new values, the date, and the reason. ## Automation and Tooling Manual DNS changes are error-prone. As infrastructure scales, automate common operations. **Use Infrastructure as Code.** Define DNS records in Terraform, Pulumi, or similar tools. This provides version control, peer review through pull requests, and automatic documentation. **Implement automated validation.** CI pipelines can validate DNS record syntax before deployment. Add a pre-deployment step that checks formats, verifies CNAME targets resolve, and confirms certificate coverage. **Set up continuous monitoring.** Deploy tools that check resolution from multiple locations every few minutes. When a record changes unexpectedly, the team gets alerted immediately. **Log all changes.** Maintain an audit trail of every DNS modification. Log who made the change, when, what values were set, and what the previous values were. ## Common Mistakes to Avoid **Changing TTL and IP simultaneously** is the most common error. Reduce TTL first, wait for full propagation, then change the IP. Combining both means you cannot quickly revert because old TTL values remain cached. **CNAME conflicts** cause silent failures. A CNAME cannot coexist with any other record for the same name. Adding an A record where a CNAME exists will drop the A record or cause resolution failures. **Ignoring email records** during subdomain changes leads to delivery problems. Even when changing only an A record, verify that MX and TXT records for the root domain remain intact. **Leaving stale records** creates security risks. Unused records can be hijacked if an attacker gains access to your provider. Audit and remove records that are no longer needed. ## Frequently Asked Questions **How often should we review DNS records?** Review your full zone at least once per quarter. Check for stale records, unnecessary entries, and TTL settings. A quarterly audit takes less than an hour. **What TTL should I use for frequently changed records?** Set a TTL of 300 seconds (5 minutes) for records that change regularly. This allows rapid propagation while keeping query volume manageable. For stable records, 3600 seconds works well. **Can I make DNS changes during business hours?** Yes, if you follow the checklist. The pre-change audit, staging validation, and rollback plan are designed to make safe changes at any time. **How do I handle DNS changes across multiple providers?** Treat each provider as a separate change event. Apply changes sequentially. Complete and verify the change at one provider before starting the next. **What tools are essential for a DNS change workflow?** At minimum, a DNS record validator, a multi-location resolution checker, and a monitoring tool with alerting. `dig` and `nslookup` are on every system. For team workflows, use an IaC tool like Terraform and a shared runbook.