What TTL should you use for DNS records?

Every DNS record has a small field that usually stays at whatever the dashboard suggested: the TTL. It decides how long a change takes to reach your visitors, how many queries your DNS provider receives and whether your site stays reachable when something goes wrong.

There is no single right value, only the right value for each record and each moment. The choice gets simple once you know what the TTL controls and what it costs to set it too high or too low.

What does the TTL control?#

TTL (time to live) is the number of seconds a resolver may keep a record's answer in cache before asking the authoritative server again. RFC 1035 defines the field, and RFC 2181 sets the maximum at 2147483647 seconds. Resolvers may enforce a lower ceiling: RFC 8767 recommends capping it at 7 days (604800 seconds).

It is a direct trade-off, which Cloudflare's TTL documentation sums up like this: a longer TTL raises the chance of a cached answer and speeds up lookups, but makes changes take longer to go into effect. In the worst case, a change takes the entire old TTL to go live, as the article on DNS propagation explains.

Which criteria define the right TTL?#

Before you pick a number, answer five questions:

1. How often does this record change? An MX that has not changed in years can take a long TTL. The A record of a server you might replace next month cannot.
2. Do you need to switch the target quickly in an emergency? If your contingency plan is pointing the domain at another server, the TTL is the minimum recovery time for anyone who already has it cached.
3. How many queries does the domain get? Some DNS providers bill per query. The Route 53 documentation notes that a longer TTL reduces resolver calls, latency and your bill.
4. What happens if the authoritative DNS goes down? With a long TTL, resolvers keep answering from cache for longer.
5. Is the record behind a proxy or CDN? In that case the visitor gets the edge IP, and the provider usually fixes the TTL.

What are the common values and their pros and cons?#

Values below 60 seconds are rarely worth it. Many providers do not even allow them: each one sets a minimum and a maximum, sometimes different per plan, as Cloudflare's TTL documentation shows.

Which TTL should each record type use?#

The record types are explained in what DNS records are. Here is the recommendation for each:

• A and AAAA (the IP of a site or API): 3600 if the server is stable; 300 if you may still change hosts or IPs. If your host asks for a CNAME instead of an A record, follow that advice, as A vs CNAME shows.
• CNAME: 3600 in most cases. The CNAME's target has its own TTL, set by whoever runs that name, and the resolver honors both.
• MX (email): 3600 or more. Email copes well with slow changes, because sending servers retry.
• TXT (SPF, DKIM, domain verification): 3600. When you set up a new verification, 300 lets you fix a typo without waiting.
• NS: 86400 or whatever your DNS provider sets. The delegation in the parent zone (such as .com or .uk) has its own TTL, set by the TLD operator, and you do not control it.
• Records with health checks and failover: 60 seconds or less. That is the recommendation in the Route 53 failover documentation, so clients react quickly to changes in health status.

There is also the cache for negative answers. If someone looks up a name before you create it, the resolver keeps the "does not exist" answer for the lower of the SOA TTL and the SOA MINIMUM field, according to RFC 2308. If you create subdomains often, a MINIMUM of 300 to 3600 avoids long waits.

Which TTL should you use before a migration?#

The TTL that matters during a switch is the old record's, not the new one's. That is why the reduction has to come first:

1. Note the current TTL. If it is 86400, you need 1 day of lead time.
2. Lower the TTL to 300 (or 60, if every minute counts).
3. Wait for the entire old TTL to pass.
4. Change the record's value and confirm that everything works.
5. Raise the TTL back to 3600 or more.

This is the same routine the Route 53 documentation recommends: start with a short value, such as 300 seconds, and raise it after you confirm the new settings are correct. For the steps to point the domain, see how to point a domain to your app.

Does a very low TTL have downsides?#

It does, which is why setting 60 seconds on everything "just in case" is not worth it:

• More queries. Every resolver goes back to the authoritative server each minute. With providers that bill per query, it shows up on the invoice.
• Slower first visits. The less time an answer stays cached, the more visitors pay for the full trip to the authoritative server.
• Less resilience. If your DNS provider is attacked or goes down, a long TTL keeps the domain answering from cache. RFC 8767 describes resolvers that serve expired answers in that case, but not all of them do.

The balance for most projects is 300 during changes and 3600 the rest of the time.

How do you check a record's TTL?#

Use dig. First, find the domain's authoritative servers:

dig NS example.com +short

If you query one of them directly, you see the configured TTL. If you query a public resolver, you see how long that cache has left:

dig @ns1.dns-provider.example example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

In the answer, the number between the name and IN is the TTL in seconds. Query the resolver twice: the number goes down until the cache expires.

To see the value used for negative caching, query the SOA. The last number in the answer is the MINIMUM field:

dig example.com SOA +short

How to do this on Square Cloud#

On Square Cloud, custom domains are available from the Standard plan up. The dashboard shows the DNS records you need, and you create them at your registrar or DNS provider. Since the zone stays with you, that is where you set the TTL, using the criteria above.

The dashboard shows the validation status in real time, issues TLS automatically and accepts internationalized domain names (Punycode). If you are bringing a domain that already points somewhere else, lower the TTL before changing the records and follow the validation in the dashboard.

Meanwhile, every web app stays reachable on its *.squareweb.app subdomain with HTTPS, on every plan. See how to set it up on the domains page.