Module 6 · 6.1
TTL and cache
Module 6: Time, cache and transferring · Reading time: 7 minutes
Learning objective: After this lesson, you can explain what a record's TTL is, how caches use it and which TTL to choose in which situation.
Key concepts: TTL (Time To Live), cache, resolver cache, cache of your computer and browser, counting-down TTL, typical TTL values (300, 3600, 86400)
Why DNS remembers
In lesson 1.4 you saw how a resolver looks up an answer: first at a root server, then at the TLD server and finally at the domain's authoritative nameserver. If this had to happen again with every click on a website, the internet would be a lot slower and nameservers would collapse under all the queries.
That's why resolvers remember each answer for a while. This memory is called the cache. If someone else asks for the same name, the resolver immediately gives the answer from its cache, without making the whole journey again.
The question then is: how long may the resolver remember an answer? The domain's owner decides that, with the TTL of each record.
What the TTL is
TTL stands for Time To Live: the time a record may stay in a cache, in seconds. Each record has its own TTL. In a zone, it looks like this:
example.com. 3600 IN A 192.0.2.10
www.example.com. 3600 IN A 192.0.2.10
example.com. 3600 IN MX 10 mail.example.com.
_dmarc.example.com. 14400 IN TXT "v=DMARC1; p=quarantine"The number after the name is the TTL. Here, the A and MX records may be remembered for an hour (3600 seconds) and the DMARC record for four hours (14400 seconds).
Common values:
| TTL | Is | When do you use it? |
|---|---|---|
| 300 | 5 minutes | Just before and during a transfer, or if you change records often |
| 3600 | 1 hour | A good default for most records |
| 14400 | 4 hours | Records that rarely change |
| 86400 | 1 day | Records that almost never change, such as NS records |
The TTL is a number between 0 and 2,147,483,647 seconds (2^31 - 1, as stated in RFC 2181). In practice, you rarely encounter anything above a day or two. Many resolvers also apply their own maximum, often a day or a week.
The countdown
The TTL isn't a fixed clock for the whole world. Each resolver only starts counting the moment it fetches the record.
An example. The A record of example.com has TTL 3600.
- At 10:00, provider A's resolver requests the record. It gets
192.0.2.10and may remember it until 11:00. - At 10:40, provider B's resolver requests it. It remembers it until 11:40.
- At 10:45, you change the record to
198.51.100.10. - Users of provider A see the new address from 11:00, users of provider B only from 11:40.
If you look up the record at a resolver that already has it in its cache, you'll see a TTL in the output that keeps getting lower. At the authoritative nameserver, you'll always see the full value:
; at the authoritative nameserver
example.com. 3600 IN A 192.0.2.10
; at a resolver, 25 minutes later
example.com. 2100 IN A 192.0.2.10It's useful to know this: if your resolver still shows 2100 seconds, it will keep giving the old answer for another 35 minutes.
Who remembers what
It's not only your internet provider's resolver that has a cache. There are more layers:
- The resolver of your provider, your company network or a public resolver (for example 1.1.1.1, 8.8.8.8 or 9.9.9.9).
- Your router at home or at the office, which often acts as a small resolver itself.
- The operating system of your computer or phone.
- Your browser, which sometimes also keeps DNS answers for a while.
Each layer is in principle supposed to follow the TTL, but not every layer does so precisely. That's why it can take slightly longer on your laptop than on your colleague's. You can read how to clear these caches in lesson 6.2.
Choosing the right TTL
A short TTL seems handy: changes then become visible everywhere quickly. But there's a downside. Resolvers then have to request the record again much more often. This makes the first loading of your site a fraction slower, and if your nameservers are briefly unreachable, your domain becomes unreachable sooner. With a TTL of one hour, resolvers can bridge a brief outage at the nameserver using their cache.
A few rules of thumb:
- Default: 3600 seconds. That's a good balance.
- For a planned change: temporarily 300. Lower the TTL at least one old TTL period before the change. If it was 3600, do this at least an hour in advance, a day is safer. If it was 86400, do it at least a day in advance. After the change, set it back. You can read how to handle this during a transfer in lesson 6.3.
- Lower than 60 seconds has little use. Some resolvers ignore very short TTLs and apply their own minimum.
- Lowering a TTL only works once the old TTL has expired. If you lower the TTL from 86400 to 300 and change the address straight afterwards, resolvers that had just fetched the record will still keep the old value for a whole day.
That last point is the most common mistake with TTLs. The new, shorter TTL first needs to make its own way into all caches.
In practice: what it looks like in a panel
In the example panel DirectAdmin, the TTL appears as a separate column in DNS Administration. You change the TTL of one record using the pencil icon next to that record. With the OVERRIDE TTL VALUE button, you set one TTL for all of the domain's records at once. In My WebOké, you see the TTL in the record list on the DNS tab, and you choose it in the window where you add or edit a record.
Other panels work similarly: with cPanel, Plesk, Cloudflare and most registrars, the field is also called TTL. Sometimes you choose from a list (for example "5 minutes", "1 hour", "Auto") instead of typing a number in seconds. With Cloudflare, "Auto" means 300 seconds for records without proxying.
Summary
- The TTL determines how many seconds a DNS answer may stay in a cache.
- Each resolver counts from the moment it fetched the record; that's why not everyone sees a change at the same time.
- At the authoritative nameserver you see the full TTL, at a resolver a counting-down value.
- 3600 is a good default; temporarily lower it to 300 before a planned change, and do so at least one old TTL period in advance.
Quiz
Exercise
Exercise Z6.1: TTL at the source and at the resolver. Use an online DNS tool or dig to look up the TTL of the A record of sidn.nl, directly at one of sidn.nl's own nameservers (for example ns1.sidn.nl). Enter the TTL in seconds. Then look up the same record at a public resolver and enter that TTL as well. Explain in one sentence why the two numbers can differ.
dig A sidn.nl @ns1.sidn.nl
dig A sidn.nl @9.9.9.9Exercise O6.1: Set it yourself in your practice zone. In your practice zone <code>.dnspractice.euttl-test. pointing to <code>.dnspractice.eu192.0.2.61, with a TTL of 300 seconds. Lower the TTL to 60 seconds, as you would before a transfer, and leave the address unchanged. Then check with dig at the practice zone's nameserver whether the new TTL is there. Submit once the TTL is 60.
The practice zone uses short TTLs (between 30 and 300 seconds), so you don't have to wait; on your real domain, you'd use, for example, 3600 as a default and 300 just before a change.
Exercise O6.1
You'll do this exercise in your own practice zone: a real DNS zone on WebOké's nameservers, just for you. Sign up with your email address. You'll get a login link by email and then come back to this lesson. We only use your address for the course.
Further reading
The steps in these articles are about WebOké's panels; other panels work similarly.