Three jobs, one template
The change type dropdown on the first task shows the record change steps, the provider move with its DNSSEC ordering, or the registrar review, and hides the rest. Whoever picks up the request follows the same steps.
DNS Change & Domain Renewal Checklist Template
DNS mistakes rarely announce themselves. Mail stops arriving, a certificate fails to renew or a domain lapses on an expired card, and resolvers keep serving the old answer long after you notice.
This free DNS change checklist covers the two jobs that keep a domain working. IT teams, web teams and MSPs use it to make record changes and DNS provider moves safely, with a zone export, lowered TTLs, approval, checks with dig and a written rollback, including the DNSSEC ordering that catches people out. It also runs the domain renewal and registrar review: expiry dates, auto-renew, registrar and registry locks, account MFA, contacts and defensive domains.
Three Kinds of Domain Work, Three Different Risks
A record change, a move to a new DNS provider and a domain renewal all touch the same name, but they fail in different ways and are undone in different ways. The first task asks which one this is, and the checklist shows only the phases that apply.
Record change
Edit records in your zone
Examples: a new A record, an MX switch, an SPF or CAA update.
Cached for: the record’s TTL.
Rollback: restore the old value from the zone export.
Provider move
Change who answers for the zone
Examples: new nameservers at the registrar, a move to a new DNS host.
Cached for: the parent’s NS TTL, two days in .com.
Rollback: point back to the old nameservers, which must still serve the zone.
Renewal & registrar review
Keep the domain itself safe
Examples: renewing, checking locks, removing a leaver from the registrar account.
Risk: expiry, hijack or an unauthorised transfer.
Output: a domain table reviewed on schedule.
Lowering a TTL only helps if you do it early. A resolver that cached the record under the old TTL keeps it until that TTL runs out, so a record at 86,400 seconds needs its TTL lowered a full day before the change. New names have a trap of their own: if anyone queried a name before it existed, resolvers may cache the “does not exist” answer for the lower of the SOA record’s TTL and its minimum field. Mail cutovers add MX, SPF and DKIM records to the same sequence; the Email Migration Checklist covers those in detail.
What the DNS Change & Domain Renewal Checklist Covers
Six phases cover all three kinds of work. Phase 2 appears for record changes and provider moves, Phase 3 for record changes, Phase 4 for provider moves and Phase 5 for renewals, and a failed verification adds a rollback task.
Phase 1
Phase 1: Request, Access & Zone Export
The change type chosen on the first task decides which of Phases 2 to 5 appear.
- Open the record and choose the change type — record change, nameserver or DNS provider move, or domain renewal and registrar review, with the implementer and approver picked from your members
- Confirm named access to the registrar and DNS host — individual accounts with MFA, not a shared login nobody can trace
- Export the zone file from the current DNS host — it is both the backup and the rollback; attach it to the task
- Record the current TTLs and SOA values — the SOA’s TTL and minimum field set how long a “does not exist” answer is cached
- List what depends on the records involved — MX, SPF, DKIM, DMARC, CAA, domain verification TXT records and ACME validation CNAMEs
- Check whether the domain uses DNSSEC —
dig DS example.com +shortreturns the DS record if it does; a provider move must handle it
Phase 2 — Changes
Phase 2: Plan, Lower TTL & Approve
Tasks are hidden for a domain renewal. The approval on the last task halts the checklist until the approver decides.
- Write the exact change — name, type, old value, new value and TTL, copied from the zone rather than typed from memory
- Write the rollback — the old values from the export, and who can apply them out of hours
- Check the change against DNS rules — no CNAME at the zone apex or beside other records, and SPF within its limit of 10 DNS lookups
- Lower the TTL on affected records ahead of time — to 300 seconds, at least one full old TTL before the change
- Raise the change record and agree the window — with the owners of mail, web and other dependent services available
- Approve the change — the named approver records approved or not approved, with the reason
Phase 3 — Record change
Phase 3: Make & Verify the Record Change
Tasks appear only for a record change. If the result is recorded as Fail, the rollback task appears.
- Make the change at the DNS host inside the window — and note the time; old answers may persist for the lowered TTL after it
- Query every authoritative nameserver directly —
dig @ns1.yourdnshost.net www.example.com A +short; all of them should agree - Check public resolvers —
dig @8.8.8.8anddig @1.1.1.1; Google Public DNS and Cloudflare both offer a tool to purge a cached name - Test the service itself — load the site, send test mail and check SPF, DKIM and DMARC results in the headers
- Record the verification result — pass, or fail with what broke and which resolvers still return the old answer
- Roll back to the exported values — then find the cause before trying again
Phase 4 — Provider move
Phase 4: Nameserver or DNS Provider Move
Tasks appear only for a provider move. If the result is recorded as Fail, the rollback task appears.
- Recreate every record at the new provider — import the zone export, then check TXT, CAA, SRV and provider-specific alias records by hand
- Compare the zones record by record before delegating — query the new provider’s nameservers directly; they answer before the registrar points at them
- Deal with DNSSEC before the switch — use a multi-signer migration if both providers support it, or remove the DS record and wait at least its TTL first
- Change the nameservers at the registrar — keep the old zone live and unchanged for at least 48 hours, and make any urgent edit at both providers
- Sign the zone at the new provider and add its DS record — once the new delegation has settled; check the chain with DNSViz or
dig +dnssec - Record the verification result — pass, or fail with the names or resolvers that are not resolving
- Restore the old nameservers — the old provider still holds the full zone, which is why it stays live
Phase 5 — Renewal
Phase 5: Domain Renewal & Registrar Review
Tasks appear only for a domain renewal and registrar review. The domain table lives in this phase’s first task.
- Record every domain in the domain table — registrar, expiry date, auto-renew, lock, DNSSEC and owner, including campaign domains and old brands
- Turn on auto-renew and check the payment card on file — an expired card is a common reason auto-renew quietly fails
- Send registrar notices to a monitored role address — ICANN requires reminders about a month and a week before expiry, which help nobody in a leaver’s inbox
- Confirm the registrar lock on every domain —
clientTransferProhibitedin the RDAP or WHOIS status - Consider registry lock for critical domains — it blocks updates, transfers and deletion, nameserver changes included, until the registrar verifies a request out of band
- Review registrar account access — MFA for every user, leavers removed, and a short list of people who can unlock or transfer
- Decide on defensive and typo domains — keep those that protect the brand or catch mistyped email; let campaign leftovers lapse on purpose
Phase 6
Phase 6: Restore, Record & Close
- Restore normal TTLs once the change has held — often after 24 hours; long TTLs cut query load and ride out short provider outages
- Close the old provider’s zone only after traffic has left it — and only once DNSSEC validates on the new one
- Update the domain table and DNS documentation — owners, registrar, expiry and the purpose of every non-obvious record
- Confirm the next registrar review date — the recurring schedule opens the next review on its own
- Sign off and close — the implementer confirms the result, with before and after zone exports attached
DNS and Domain Timings to Plan Around
These values set how long a change takes to reach everyone and how long you have before a lapsed domain is gone. Some vary, so check your own registry and registrar.
| Timing | Typical value | What it means for the change |
|---|---|---|
| Record TTL | Your choice: often 3,600 to 86,400 s, 300 s during a change | Lower it at least one old TTL before the change |
| Negative caching | The lower of the SOA TTL and the SOA minimum (RFC 2308) | A name queried before it existed stays “missing” for that long |
| .com and .net delegation | 172,800 s (two days) | Keep the old provider serving an identical zone for at least 48 hours |
| DS record at the parent | Often 86,400 s (one day) | Remove or replace it in the right order, then wait it out before the next step |
| Registrar expiry notices | About one month and one week before expiry, and one within five days after | Required by ICANN’s Expired Registration Recovery Policy for gTLDs; send them to a monitored address |
| Redemption Grace Period | 30 days after a gTLD registration is deleted | The registrant can still restore the name, usually for a fee; do not plan on it |
| Transfer restriction after registration or transfer | 60 days, being replaced by 30 days | ICANN’s updated Transfer Policy; record and nameserver changes do not trigger it |
DNSSEC is where provider moves go wrong. If resolvers still hold a DS record for keys the new provider does not use, validating resolvers return SERVFAIL and the domain disappears for their users. Cloudflare’s migration guide shows the multi-signer route: each provider publishes the other’s signing key, both DS records sit at the registrar during the move, and the old provider’s key is removed only after waiting at least one and a half times the old DS record’s TTL. Where either provider cannot do that, remove DNSSEC first, move, then sign again.
The registrar account is the other weak point: whoever signs in can change nameservers, redirect mail and web traffic and obtain certificates for your domain. MFA, few users and a registrar lock cover most domains. For the few that would stop the business, registry lock, offered by Verisign for .com and .net and by many other registries through registrars, sets server-level statuses that only a verified manual request can lift. ICANN’s updated Transfer Policy calls the transfer code a Transfer Authorization Code (TAC); treat it like a password.
Why Run DNS Changes and Domain Reviews in CheckFlow?
No change without a rollback
The zone export attaches to the first phase, and the checklist halts at the approval until the approver picked on the first task decides. Record Fail on the verification and the rollback task appears; the audit trail shows who changed what and when.
Every domain on a review cycle
A table inside the renewal task holds registrar, expiry, auto-renew, lock and DNSSEC for each domain, and a data set keeps the domain list reusable. A quarterly or annual recurring schedule opens the registrar review, and tags keep each client’s domains separate for MSPs.
Moving mail means MX, SPF and DKIM changes in a fixed order, covered step by step in the Email Migration Checklist. CAA records and ACME validation CNAMEs decide whether certificates renew, so check any change to them against the SSL/TLS Certificate Renewal Checklist.
DNS changes on production services belong in your change process, run through the IT Change Management Checklist. See how approvals halt a change until someone decides in CheckFlow’s change management checklist software, and how scheduled reviews open themselves with recurring checklists.
Frequently Asked Questions
How far ahead should I lower a DNS record’s TTL?
At least one full period of the current TTL before the change, because resolvers that cached the record under the old TTL keep it until that runs out. A record at 3,600 seconds needs an hour; one at 86,400 seconds needs a day. Lowering to 300 seconds is common. Restore the normal TTL once the change has held.
How long does a nameserver change take?
Up to two days for .com and .net, whose delegation records carry a TTL of 172,800 seconds, plus the time your registrar takes to send the change to the registry. Many resolvers pick it up sooner, but plan for the full 48 hours and keep the old provider serving an identical zone throughout, so whichever nameservers a resolver asks give the same answer.
How do I change DNS provider with DNSSEC turned on?
Either migrate with both providers signing, where each publishes the other’s key and both DS records sit at the registrar until the move completes, or remove DNSSEC first. To remove it, delete the DS record at the registrar, wait at least its TTL (often a day), change the nameservers, then sign the zone at the new provider and add its new DS record. Changing nameservers while an old DS record is still cached breaks resolution for validating resolvers.
What is the difference between registrar lock and registry lock?
Registrar lock sets client statuses such as clientTransferProhibited, which anyone signed in to your registrar account can remove. Registry lock sets server statuses, serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited, at the registry itself. Lifting it needs a verified manual request through the registrar, so a stolen registrar password alone cannot change your nameservers.
What happens if a domain expires?
For gTLDs such as .com, ICANN’s Expired Registration Recovery Policy requires the registrar to send reminders about a month and a week before expiry and another within five days after. Registrars handle the first weeks after expiry differently. If the registration is deleted, a 30-day Redemption Grace Period lets you restore it, usually for a fee; after that anyone can register it. Country-code domains follow their own registry’s rules.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.