AboutFree templates
How-to · DNS and domains

Lower DNS TTL before a migration

At the end you will have shortened how long resolvers cache your MX, A, CNAME or NS records, so the real cutover change reaches people quickly and can be rolled back quickly.

Updated 9 steps8 official sources
Start hereBack to the playbook
Before you start

What you need before step 1

Applies to: Any public DNS zone, at any DNS host (Cloudflare, GoDaddy, Amazon Route 53, Azure DNS, Google Cloud DNS, your registrar or web host)

Admin roles you need

  • A login to the DNS host account that serves your zone with permission to edit records (this is the company your NS records point to, which may not be your registrar)

Licences

None needed.

Download

BIND 9 from ISC (includes dig)Only needed on macOS or Linux if the dig command is missing. ISC lists source code and pre-compiled packages for popular Linux distributions.https://www.isc.org/download/Download

Also have ready

  • Windows: nslookup and the PowerShell cmdlet Resolve-DnsName are part of Windows. Open Command Prompt or Windows PowerShell from the Start menu; no download needed.
  • macOS or Linux: use the Terminal app and the dig command.
  • A list of the records you will change at cutover (usually MX, the SPF TXT record, autodiscover CNAME, and A or CNAME records for the website).
  • At least two days of lead time before the cutover if you are changing nameservers (see step 6).
Step by step

9 steps

  1. 1

    Understand what TTL controls

    Where: Reading only

    TTL (time to live) is a number of seconds stored on every DNS record. RFC 1035 defines it as the time interval that the resource record may be cached before it should be discarded. Resolvers that have already cached a record keep returning the old value until that time runs out.

    That is why you lower TTL before the change. Amazon's Route 53 guide puts it plainly: changing the TTL at the same moment as the record will not make the change take effect faster, because resolvers already hold the old value for the old TTL.

    You should see: You know which records you will change at cutover and that you need to lower their TTL at least one full old-TTL period ahead.
  2. 2

    Find which company hosts your DNS

    Where: Command Prompt on Windows, or Terminal on macOS or Linux, on your admin PC

    Ask for the domain's NS records. The domain part of the names returned usually identifies the DNS host to log in to (for example a name ending in cloudflare.com means Cloudflare). Type the first line on Windows or the second on macOS or Linux, replacing contoso.com with your domain.

    nslookup -type=ns contoso.com
dig NS contoso.com +short
    You should see: Two or more nameserver host names are listed. Write them down; one of them is used in the next step.
  3. 3

    Read the current TTL on each record

    Where: Command Prompt on Windows, or Terminal on macOS or Linux

    Query one of your own nameservers directly (from step 2) so you see the configured TTL, not a cached countdown from your ISP. On macOS or Linux use dig: the number in the second column of the answer is the TTL in seconds. On Windows use nslookup with -debug and read the ttl = line. Repeat for each record type you will change (MX, TXT, A, CNAME, NS).

    dig @ns1.example-dns.com contoso.com MX +noall +answer
dig @ns1.example-dns.com www.contoso.com A +noall +answer
nslookup -debug -type=mx contoso.com ns1.example-dns.com
    You should see: A line such as contoso.com. 3600 IN MX 10 mail.contoso.com. (dig) or ttl = 3600 (nslookup). Note each value: this is how long you must wait after lowering it.
  4. 4

    Open the DNS records page at your DNS host

    Where: Web browser, signed in to your DNS host's control panel

    Open the zone for your domain and find the record list. Use your host's own instructions as the reference for the exact screens:

    You should see: You can see the records for your domain, each with a TTL field or column.
  5. 5

    Lower the TTL on the records you will change

    Where: DNS host control panel > your domain > DNS records > Edit (per record)

    Edit each record you will change at cutover and set its TTL to a short value your host allows, for example 300 seconds (5 minutes). Do not change the record's value yet. Select Save.

    Hosts have limits: Cloudflare allows DNS only records between 60 seconds (30 on Enterprise) and 1 day, and proxied records are fixed at Auto (300 seconds). Google Cloud DNS lets you choose a unit (seconds, minutes and so on) next to the TTL box. If your host offers only preset values, pick the lowest one.

    You should see: The record list shows the new, shorter TTL against each record you edited.
  6. 6

    For a nameserver change, lower the NS TTL too

    Where: DNS host control panel (NS records in the zone) and, if offered, your registrar

    If the cutover moves DNS hosting to a new provider, also lower the TTL of the NS records. Amazon recommends a value between 60 and 900 seconds and notes that some resolvers cache the NS TTL from the parent (registry) servers, so that value matters too. Many registrars do not let you change it; if yours does not, plan for the longer wait in the next step.

    You should see: NS records in your current zone show the shorter TTL.
  7. 7

    Wait for the old TTL to expire

    Where: Calendar

    Wait at least as long as the old TTL you noted in step 3. For a 3600-second record that is one hour; for an 86400-second record that is a full day. For nameserver changes, Amazon suggests waiting two days after lowering the NS TTL, because registrars commonly use 24 to 48 hours on nameserver records.

    You should see: The wait period has passed before you schedule the cutover.
  8. 8

    Confirm the short TTL is being served

    Where: Command Prompt on Windows, or Terminal on macOS or Linux

    Query a public resolver (here Google Public DNS at 8.8.8.8) and check that the TTL it returns is at or below your new value.

    dig @8.8.8.8 contoso.com MX +noall +answer
nslookup -debug -type=mx contoso.com 8.8.8.8
    You should see: The TTL in the answer is 300 or lower (it counts down from your new value).
  9. 9

    Make the cutover change, then raise TTL again

    Where: DNS host control panel > your domain > DNS records

    Make the real change (for example change the MX records or change nameservers). Once mail and web traffic are flowing correctly, edit the same records and set the TTL back to a normal value, such as your host's default or the value you noted in step 3. Amazon suggests returning NS records to a typical value such as 172800 seconds (two days).

    You should see: The records hold their new values with a normal TTL, and lookups return the new values.
From experience

Expert tips

Start at least one old TTL before the cutover

Read the configured TTL on the authoritative server (dig @ns1.example-dns.com contoso.com MX +noall +answer), not on a public resolver, which shows a countdown. Lower it at least that many seconds before you change the value. A record at 86400 seconds needs a full day; put the lowering step in the project plan, not on cutover night.

Plan two days for nameserver moves regardless

Amazon notes the typical NS TTL is 172800 seconds (two days) and that some resolvers cache the NS records held by the parent (TLD) servers, which you usually cannot change. Amazon recommends 60 to 900 seconds for NS records you control and waiting two days after lowering. Assume some users follow the old nameservers for up to two days and keep the old zone working.

Know your DNS host's limits

Cloudflare allows DNS only records from 60 seconds (30 seconds on Enterprise) to one day, and its Auto setting is 300 seconds. Proxied records are always Auto (300 seconds) and cannot be edited, which is fine because the proxy, not DNS, decides where traffic goes. Check the minimum at other hosts before you rely on a very short value.

Create new hostnames early

A short TTL on an existing record does not help a record that does not exist yet. Resolvers cache "does not exist" for the lower of the SOA MINIMUM and the SOA TTL (RFC 2308). Create new names such as autodiscover, DKIM selectors or a new www target days ahead, even pointing at a placeholder, so they are already cached with a short TTL at cutover.

Raise the TTL again after the move

Once the new values are stable for a few days, put TTLs back to a normal value (Amazon suggests 172800 seconds for NS records). Long TTLs mean fewer queries to your DNS host and keep the site reachable from caches if the DNS host has an outage.

Check it worked

How to confirm it worked

  • Run dig @ns1.example-dns.com contoso.com MX +noall +answer against your own nameserver before cutover: the second column shows the short TTL you set.

  • Run nslookup -debug -type=mx contoso.com 8.8.8.8 on Windows: the ttl = line is at or below the new value.

  • After raising TTL again, repeat the query and confirm the normal TTL is back.

Undo

How to reverse it

Rollback:

Fully reversible. Edit the same records at your DNS host and put the TTL back to the value you noted in step 3. Lower TTL only means more DNS queries reach your host; it does not change where mail or web traffic goes.

Troubleshooting

Errors you might see

The old value still appears after the change

Cause: Resolvers cached the record under the old, long TTL before you lowered it. Amazon notes that changing the TTL at the same time as the record does not make the change take effect faster.

Fix: Wait out the old TTL. Next time, lower TTL at least one old-TTL period before the cutover.

The TTL field is greyed out or fixed at Auto (Cloudflare)

Cause: The record is proxied. Cloudflare fixes proxied records at Auto, which is 300 seconds.

Fix: No action needed for proxied records; Auto is already 300 seconds. For DNS only records you can choose 60 seconds (30 on Enterprise) up to 1 day.

Changes made in Route 53 do not show up in lookups

Cause: Amazon notes that if the domain registration uses the name servers of another hosted zone, responses will not reflect changes in the zone you edited.

Fix: Compare the NS records from dig NS contoso.com +short with the four name servers shown in the hosted zone details, and edit the zone that is actually delegated.

FAQ

Questions

What TTL should I use before a migration?

Use a short value your DNS host allows, such as 300 seconds. Cloudflare uses 300 seconds for Auto. For nameserver moves, Amazon recommends 60 to 900 seconds on NS records.

How far ahead should I lower TTL?

At least one full period of the old TTL. A record with an 86400-second TTL needs a day; Amazon suggests two days for NS changes.

Does lowering TTL cause downtime?

No. The record values stay the same; resolvers simply check back more often.

Why does my ISP show a different TTL from my DNS host?

Resolvers count the TTL down from when they cached the record. Query your own nameserver directly to see the configured value.

Sources

Official sources

Vendors change menus and requirements. Confirm on the source before you rely on a detail. Last checked 4 Nov 2026.

RFC 1035: Domain names, implementation and specification (TTL definition)Cloudflare DNS docs: Time to Live (TTL)Amazon Route 53: Making Route 53 the DNS service for a domain that is in useAmazon Route 53: I changed DNS settings, but they have not taken effectGoogle Cloud DNS: Add, update, and delete recordsMicrosoft Learn: Manage DNS record sets and records with Azure DNSGoDaddy Help: Manage DNS recordsISC: Downloads (BIND 9, includes dig)