Send, receive, and shield emails with PostScale. One API, EU-hosted. PostScale

    Operations

    DNS Change Review Checklist: Ship DNS Changes Without Outages

    A practical DNS change review checklist for production records, TTL preparation, authoritative and recursive verification, rollback, monitoring, and PR reviews.

    Start freeBrowse guides

    Answer snapshot

    Review DNS changes before they ship. Classify the risk, confirm record syntax, lower TTLs before planned cutovers, capture rollback values, verify authoritative DNS first, then compare recursive resolvers after cache expiry. If authoritative answers are wrong, fix the zone. If authoritative answers are correct but recursive answers differ, you are usually looking at resolver cache state.

    What you'll learn

    • Classify DNS changes by outage risk before review
    • Catch high-risk record mistakes in apex, CNAME, MX, TXT, CAA, NS, DS, and DNSKEY changes
    • Prepare TTLs and rollback values before a production change window
    • Verify authoritative answers separately from recursive resolver cache state
    • Use a copyable PR template for DNS changes

    Most DNS outages are not caused by obscure protocol behavior. They are review failures.

    Someone changes the wrong apex address. A CNAME replaces a record that still needs MX. An SPF edit breaks quoting. A DS record remains at the registrar after DNSSEC is disabled. A rollback value is missing, and the team discovers the old IP from Slack history during an incident.

    This checklist is for production DNS changes. Use it with the DNS Operations hub, DNS Troubleshooting, DNS TTL Best Practices, and the dig command tutorial.

    Quick Checklist

    Copy this into small DNS change tickets:

    ## DNS change review
 
- [ ] Zone and owner are identified.
- [ ] Exact record name, type, old value, new value, and TTL are shown.
- [ ] Risk level is marked: low / medium / high.
- [ ] Record syntax was checked for this type.
- [ ] TTL was lowered in advance if fast rollback matters.
- [ ] Rollback value and rollback owner are written down.
- [ ] Authoritative verification command is included.
- [ ] Recursive resolver verification command is included.
- [ ] Post-change health check or monitor is included.
- [ ] Related DNSSEC, CAA, email, certificate, or delegation impact was reviewed.

    If the change controls production traffic, email, certificate issuance, delegation, or DNSSEC, require a second reviewer.

    Why DNS Changes Need Review

    DNS has two properties that make small mistakes expensive:

    • It is upstream of applications, email, TLS certificates, and customer onboarding.
    • It is cached by recursive resolvers, operating systems, browsers, networks, and applications.

    Changing a record is quick. Recovering from a cached bad value may not be quick.

    A review should answer five questions:

    QuestionWhy it matters
    What exact record set is changing?Same owner name and type must be reviewed together.
    Who owns the service behind it?DNS reviewers may not know the application impact.
    What breaks if the new value is wrong?The answer determines risk level and approval.
    How do we prove the change worked?Verification commands must be ready before publish.
    How do we roll back?Rollback needs exact previous values and TTL expectations.

    A "record set" means all values with the same owner name and type. For example, all TXT values at _acme-challenge.example.com are one TXT record set for review purposes.

    Classify the Change

    Classify before debating syntax. A low-risk TXT verification record does not need the same process as a DS rollover.

    Low Risk

    Low-risk changes are isolated and easy to reverse:

    • adding a temporary TXT ownership verification record
    • adding a non-production subdomain
    • changing a staging or development record
    • adding a CAA authorization that does not remove existing CAs
    • lowering TTL ahead of a future reviewed change

    Review requirements:

    • one reviewer
    • exact old and new values
    • authoritative verification command
    • cleanup date for temporary records

    Medium Risk

    Medium-risk changes can affect users but usually have contained blast radius:

    • changing www from one CNAME target to another
    • updating a single service subdomain such as api.example.com
    • rotating a DKIM selector while the old selector remains published
    • changing SPF includes without moving to a stricter DMARC policy
    • adding a new MX backup host without removing the current primary path

    Review requirements:

    • service owner approval
    • rollback value
    • TTL plan
    • authoritative and recursive verification
    • application or mail-flow health check

    High Risk

    High-risk changes can create broad outages or hard-to-debug failures:

    • apex A, AAAA, or ALIAS changes
    • production CNAME changes for application routing
    • MX migration
    • SPF, DKIM, or DMARC changes that affect mail authentication
    • restrictive CAA changes
    • NS changes at the zone or registrar
    • DS, DNSKEY, or DNSSEC signing changes
    • wildcard records
    • deleting records that may be used by customers or third parties

    Review requirements:

    • second reviewer
    • written rollback plan
    • TTL preparation before the change window
    • authoritative, recursive, and service-level verification
    • monitoring window after publish
    • explicit go or rollback criteria

    Records That Need Extra Review

    Some record types fail in predictable ways. Use this table during review.

    RecordExtra review
    Apex A / AAAA / ALIASConfirm both IPv4 and IPv6 behavior, health checks, CDN origin expectations, and previous values.
    CNAMEConfirm it does not coexist with other data at the same name, and confirm the target exists.
    MXConfirm priorities, hostnames, trailing dots in zone files, target A/AAAA records, and mail provider cutover timing.
    SPF TXTConfirm one effective SPF policy, valid quoting, no accidental removal of current senders, and lookup count risk.
    DKIM TXTConfirm selector name, key value, line splitting, and overlap between old and new selectors.
    DMARC TXTConfirm policy, alignment mode, reporting addresses, and staged rollout before p=reject.
    CAAConfirm all issuing CAs are still authorized, including wildcard policy via issuewild.
    NSConfirm parent delegation, child-zone NS, glue where needed, and old provider overlap during migration.
    DSConfirm it matches the live DNSKEY before publishing, and remove stale DS before disabling DNSSEC.
    DNSKEYConfirm signing state, key rollover stage, RRSIG validity, and resolver validation.

    For CAA-specific failure modes, see the CAA Debugging Guide. For DNSSEC validation failures, see DNSSEC Failure Troubleshooting.

    Pre-Change Checklist

    Use this before touching the record.

    ## Pre-change DNS checklist
 
- [ ] Zone:
- [ ] Service owner:
- [ ] Change owner:
- [ ] Reviewer:
- [ ] Change window:
- [ ] Risk: low / medium / high
- [ ] Record name:
- [ ] Record type:
- [ ] Current value:
- [ ] New value:
- [ ] Current TTL:
- [ ] Temporary TTL:
- [ ] Normal TTL after verification:
- [ ] Source of truth: dashboard / API / Terraform / DNSControl / other
- [ ] Related records checked: A / AAAA / CNAME / MX / TXT / CAA / NS / DS / DNSKEY
- [ ] DNSSEC impact checked:
- [ ] Certificate issuance impact checked:
- [ ] Email impact checked:
- [ ] Rollback value:
- [ ] Rollback owner:
- [ ] Rollback deadline:
- [ ] Authoritative verification command:
- [ ] Recursive verification command:
- [ ] Application, email, certificate, or customer-facing health check:

    Do not rely on memory for rollback values. Capture the exact previous record set before publishing.

    dig @ns1.dnscale.eu example.com A +noall +answer +ttlid +norecurse
dig @ns1.dnscale.eu example.com MX +noall +answer +ttlid +norecurse
dig @ns1.dnscale.eu example.com TXT +noall +answer +ttlid +norecurse

    Replace ns1.dnscale.eu with the authoritative nameserver for the zone you are changing.

    TTL Preparation and Timing

    TTL planning is the part of DNS change review that gets skipped most often.

    The important rule:

    Lowering a TTL only helps after resolvers that cached the old high TTL have refreshed.

    If a record currently has TTL 86400 and you lower it to 300 five minutes before changing the value, many resolvers can still hold the old answer for up to 24 hours. Lower the TTL first, wait for the old TTL window, then change the value.

    Use this timing model:

    ScenarioPreparation
    Routine stable record editNo special TTL change if rollback speed is not critical.
    IP address or CNAME cutoverLower to 300 at least one old-TTL window before the change.
    MX migrationLower MX and related SPF/DKIM/DMARC records 24-48 hours before cutover.
    CAA tighteningLower before removing old CA authorization if renewal timing matters.
    NS migrationLower child-zone NS where possible, but remember parent-zone NS TTL is controlled by the registry.
    DNSSEC DS changeTreat DS TTL at the parent as part of the timeline.

    After the change is verified and stable, restore the normal TTL. Leaving everything at 60 or 300 seconds can increase authoritative query volume and make your DNS more sensitive to provider reachability.

    For deeper TTL guidance, use DNS TTL Best Practices.

    Verify Authoritative Answers First

    Authoritative verification proves what the DNS provider is serving now. It bypasses recursive resolver caches.

    Find the authoritative nameservers:

    dig NS example.com +short
dig +trace example.com NS

    Then query one or more authoritative nameservers directly:

    dig @ns1.dnscale.eu example.com A +noall +answer +ttlid +norecurse
dig @ns1.dnscale.eu www.example.com CNAME +noall +answer +ttlid +norecurse
dig @ns1.dnscale.eu example.com MX +noall +answer +ttlid +norecurse
dig @ns1.dnscale.eu example.com CAA +noall +answer +ttlid +norecurse

    For delegation:

    dig +trace example.com NS
dig @a.gtld-servers.net example.com NS +noall +authority

    Use the parent nameserver for your TLD. a.gtld-servers.net is useful for many .com examples, but not for every TLD.

    For DNSSEC:

    dig @ns1.dnscale.eu example.com DNSKEY +dnssec +multi +noall +answer
dig @ns1.dnscale.eu example.com SOA +dnssec +multi +noall +answer
dig +trace +dnssec example.com

    If authoritative DNS is wrong, fix the zone or provider state. Waiting for propagation will not repair incorrect authoritative data.

    Verify Recursive Resolver Behavior

    Recursive verification shows what many users may see. It is affected by TTL and cache state.

    Compare several resolvers:

    dig @1.1.1.1 example.com A +noall +answer +ttlid
dig @8.8.8.8 example.com A +noall +answer +ttlid
dig @9.9.9.9 example.com A +noall +answer +ttlid

    Check email records:

    dig @1.1.1.1 example.com MX +noall +answer +ttlid
dig @1.1.1.1 example.com TXT +noall +answer +ttlid
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer +ttlid

    Check CAA:

    dig @1.1.1.1 example.com CAA +noall +answer +ttlid
dig @8.8.8.8 example.com CAA +noall +answer +ttlid

    Interpretation:

    Authoritative answerRecursive answerMeaning
    CorrectCorrectDNS has published and at least that resolver has refreshed.
    CorrectOld valueResolver cache is still within TTL or serving stale data.
    CorrectSERVFAILCheck DNSSEC, delegation, resolver policy, or authoritative reachability.
    WrongWrong or oldFix authoritative zone data first.
    No answerNXDOMAINCheck record name, zone, wildcard behavior, and negative caching.

    Authoritative correctness and recursive cache state are different things. Do not call a change failed only because one resolver still has the old answer within the expected TTL window. Also do not call a change successful only because one resolver happens to show the new value.

    Rollback Checklist

    Write the rollback plan before the change starts.

    ## DNS rollback plan
 
- [ ] Rollback trigger:
- [ ] Rollback owner:
- [ ] Previous record name:
- [ ] Previous record type:
- [ ] Previous value or full record set:
- [ ] Previous TTL:
- [ ] Current changed value:
- [ ] Current changed TTL:
- [ ] Command or PR that restores the old state:
- [ ] Authoritative verification command after rollback:
- [ ] Recursive verification command after rollback:
- [ ] Expected resolver cache behavior:
- [ ] Application, email, certificate, or customer-facing health check after rollback:
- [ ] Communication channel:
- [ ] Deadline to decide go / rollback:

    Rollback examples:

    # Confirm the previous apex A value before the change.
dig @ns1.dnscale.eu example.com A +noall +answer +ttlid +norecurse
 
# After rollback, prove the authoritative server is serving the previous value again.
dig @ns1.dnscale.eu example.com A +noall +answer +ttlid +norecurse
 
# Then watch recursive resolvers converge.
dig @1.1.1.1 example.com A +noall +answer +ttlid
dig @8.8.8.8 example.com A +noall +answer +ttlid
dig @9.9.9.9 example.com A +noall +answer +ttlid

    Rollback is cleanest when the changed record had a low TTL before the change. If the bad value was published with a long TTL, some resolvers may continue serving it until that TTL expires.

    Post-Change Monitoring

    Verification proves the record answer. Monitoring proves the service survived.

    Monitor the layer the record controls:

    Change typeWatch after publish
    Web apex or wwwHTTP 2xx/3xx rate, TLS handshake success, CDN origin health, p95 latency.
    API endpointError rate, connection failures, regional availability, synthetic checks.
    MXMail queue depth, inbound delivery, provider status, SPF/DKIM/DMARC results.
    SPF/DKIM/DMARCDMARC aggregate reports, bounce logs, authentication pass rate.
    CAACertificate renewal jobs, ACME errors, CA authorization errors.
    NSParent delegation, authoritative query volume at old and new providers.
    DS/DNSKEYDNSSEC validation, SERVFAIL rate, RRSIG expiry, DS/DNSKEY match.

    For broader operational monitoring, see DNS Network Performance Monitoring.

    Pull Request Template

    Use this block for DNS-as-code repositories or infrastructure PRs that touch DNS:

    ## DNS change
 
### Summary
- Zone:
- Record set:
- Change type: add / update / delete
- Risk: low / medium / high
- Owner:
- Reviewer:
 
### Current state
```text
name:
type:
value:
ttl:
```
 
### Proposed state
```text
name:
type:
value:
ttl:
```
 
### Impact review
- [ ] Production traffic impact checked
- [ ] Email impact checked
- [ ] Certificate / CAA impact checked
- [ ] DNSSEC impact checked
- [ ] Delegation / NS impact checked
- [ ] Customer or third-party dependency checked
 
### TTL plan
- Current TTL:
- Temporary TTL:
- Time TTL was lowered:
- Time old TTL window expires:
- Normal TTL after verification:
 
### Verification
```bash
# Authoritative
dig @ns1.dnscale.eu example.com A +noall +answer +ttlid +norecurse
 
# Recursive
dig @1.1.1.1 example.com A +noall +answer +ttlid
dig @8.8.8.8 example.com A +noall +answer +ttlid
dig @9.9.9.9 example.com A +noall +answer +ttlid
```
 
### Rollback
- Rollback value:
- Rollback command or revert PR:
- Rollback owner:
- Rollback trigger:
- Expected cache behavior:
 
### Post-change monitoring
- [ ] Service health checked
- [ ] Resolver behavior checked
- [ ] Logs, mail flow, certificate job, or synthetic monitor checked
- [ ] Temporary records or low TTL cleanup scheduled

    Adjust the record type in the dig commands. For example, use MX for mail routing, TXT for SPF and DKIM, CAA for certificate policy, and NS for delegation.

    Full DNS Change Review Checklist

    Use this fuller version for medium and high-risk changes.

    ## Full DNS change review
 
### Ownership
- [ ] Zone owner identified
- [ ] Service owner identified
- [ ] Change owner identified
- [ ] Reviewer assigned
- [ ] Emergency contact known
 
### Scope
- [ ] Exact zone confirmed
- [ ] Exact owner name confirmed
- [ ] Record type confirmed
- [ ] Full current record set captured
- [ ] Full proposed record set captured
- [ ] Source of truth confirmed
- [ ] No second writer manages the same record set
 
### Risk
- [ ] Risk classified: low / medium / high
- [ ] Apex, wildcard, delegation, DNSSEC, email, certificate, and customer impact reviewed
- [ ] Dependent records checked
- [ ] Delete operation reviewed as high risk unless proven safe
 
### TTL
- [ ] Current TTL captured
- [ ] Old TTL window understood
- [ ] Temporary TTL lowered if needed
- [ ] Normal TTL restoration planned
 
### Verification
- [ ] Authoritative query command prepared
- [ ] Recursive resolver comparison prepared
- [ ] `dig +trace` prepared for delegation changes
- [ ] DNSSEC check prepared for DS, DNSKEY, or signing changes
- [ ] Application, email, certificate, or customer health check prepared
 
### Rollback
- [ ] Previous values captured
- [ ] Rollback command or revert PR prepared
- [ ] Rollback owner named
- [ ] Go / rollback deadline named
- [ ] Expected cache behavior documented
 
### After publish
- [ ] Authoritative answer correct
- [ ] Recursive resolver behavior matches TTL expectations
- [ ] Service health is normal
- [ ] Monitoring window completed
- [ ] Temporary low TTL restored
- [ ] Temporary verification records scheduled for removal
- [ ] Source of truth and audit trail updated

    Related Guides

    Frequently asked questions

    What should every DNS change review include?
    At minimum: the zone, exact record name, type, old value, new value, TTL, risk level, owner, rollback value, authoritative verification command, recursive verification command, and monitoring or health check that proves the change worked.
    What is the difference between authoritative and recursive DNS verification?
    Authoritative verification queries the DNS provider's nameserver directly and proves what the zone is publishing now. Recursive verification queries resolvers such as 1.1.1.1, 8.8.8.8, or 9.9.9.9 and shows what users may see after cache behavior and TTLs.
    When should TTLs be lowered before a DNS change?
    Lower TTLs before planned cutovers, migrations, IP changes, MX changes, CAA changes, and anything where fast rollback matters. Lower them at least the length of the old TTL before the change, commonly 24-48 hours for production records.
    Which DNS changes are high risk?
    Apex A, AAAA, and ALIAS records, CNAME routing records, MX, SPF, DKIM, DMARC, CAA, NS, DS, DNSKEY, wildcard records, and any record used by production traffic, email, certificate issuance, DNSSEC, or customer onboarding should be treated as high risk.
    Can a DNS rollback be instant?
    The authoritative record can be restored immediately, but recursive resolvers may continue serving the changed value until its TTL expires. That is why the rollback plan must include TTL behavior, not only the old record value.

    Related guides

    Ready to manage your DNS with confidence?

    DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

    Start free