Choosing DNS TTLs
The TTL decides how long the rest of the internet is allowed to keep believing an answer you have already changed.
What it controls
A resolver that asks for your record caches the answer for the TTL in seconds. Until it expires, that resolver keeps serving the old value — your change is live at your nameservers and invisible to those users.
So the TTL is a trade: low means changes propagate quickly and your nameservers answer more queries; high means fewer queries, slightly faster lookups for users, and a change that takes hours to reach everyone.
Sensible values
- A and AAAA for a website
- 300–3600 seconds. An hour is a reasonable steady state.
- MX
- 3600–86400. Mail servers retry, so a slow change is rarely harmful.
- TXT for SPF, DKIM and DMARC
- 3600. Lower while you are setting them up and getting them wrong.
- NS
- 86400 or more. These change almost never and a mistake is expensive.
- CNAME to a third party
- Match what they recommend; they may move their endpoint.
- Anything you are about to change
- 300, set at least one old-TTL period in advance.
Lower it before, not during
This is the step people get wrong. If your TTL is 86400 and you lower it to 300 an hour before a migration, resolvers that cached the old record are still holding the old TTL as well — they will not come back for up to a day.
Lower the TTL at least as far in advance as the current TTL. For a day-long TTL, that means a day before. See planning a migration window.
Afterwards, put it back up once you are confident. A permanently 60-second TTL costs you query volume and gains nothing on a record that changes twice a year.
Why your change has not taken effect
Check at the source first, bypassing every cache:
dig @ns1.example.com www.example.com +short
If that is right and a public resolver disagrees, you are waiting on cache expiry:
dig @8.8.8.8 www.example.com +noall +answer
The TTL shown there counts down — it tells you exactly how many seconds that resolver will keep the old answer. That number is the honest answer to “how long until it works”.
Two other causes worth ruling out: you edited the zone and forgot to increment the serial, so your secondary is still serving the old data (see running your own DNS), or something closer to home — a browser, an operating system or a corporate resolver — is caching beyond the TTL, which several do.
Negative caching
If a name did not exist when someone looked it up, that absence is cached too, for the duration in your zone's SOA record. Create a new record and it can still appear missing for that long. Keep the SOA minimum modest, around 300–900 seconds, for exactly this reason.
See DNS records for what to point where.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base