I know it could be very different based on the situation, but for hosting a website with no plans to move the hosting server what is a good TTL to set on the DNS record?
7 Answers
I tend to leave it at Slicehost's default, 86,400 seconds (1 day). I drop it down to 10 minutes when I have a move pending and wait a day or two.
edit: These days (2016) I tend to keep it low - ~5 minutes.
- 32,469
- 7
- 81
- 105
-
That's quite a difference! It would be useful if the answer included the reasoning behind changing to a much lower TTL. – Anthony Geoghegan Jul 17 '17 at 22:25
-
3@AnthonyGeoghegan Modern servers can handle a lot more frequent requests, and now that I'm on highly reliable nameservers (AWS Route 53) I'd rather have the flexibility of being able to change DNS at a moment's notice. – ceejayoz Jul 17 '17 at 22:29
The standards recommendations (written a long time ago in 1987) suggest 86,400 seconds (1 day) as the minimum default TTL.
It is important that TTLs are set to appropriate values. The TTL is the time (in seconds) that a resolver will use the data it got from your server before it asks your server again. If you set the value too low, your server will get loaded down with lots of repeat requests. If you set it too high, then information you change will not get distributed in a reasonable amount of time. If you leave the TTL field blank, it will default to what is specified in the SOA record for the zone.
Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value.
Also, all RRs with the same name, class, and type should have the same TTL value.
See RFC 1033: https://www.rfc-editor.org/rfc/rfc1033
RFC 1912 (from 1996) suggests that 3 days may be more appropriate for SOA
records.
-
4I'd imagine DNS traffic from low TTLs was significantly more of a problem in 1987 and 1996 than in 2011/2012. – ceejayoz Nov 27 '12 at 22:33
-
7Both those standards you quote are referring to the "Minimum" field of the SOA record only, which is no longer used for determining the default or minimum TTL anyway, as was intended back when those standards were written. DNS best practices written 27 and 18 years ago were written when DNS - indeed the internet - was a different beast. Nowadays, 300 seconds (5 minutes) is a fairly common TTL for main A/AAAA records, although only useful when needing fast failover otherwise 6 hours+ would be more appropriate. NS records, and the A/AAAA records for the NS addresses, are usually 1 day or more. – thomasrutter Jun 07 '14 at 16:02
-
9I'm late to comment on this, but it should be noted that it is inappropriate to refer to either of those RFCs as "standards". ([RFC 1796](http://tools.ietf.org/html/rfc1796)) I'm noting this so that readers from today do not walk away from this Q&A with the wrong understanding. – Andrew B Feb 10 '16 at 06:02
I have noticed it is becoming more fashionable to have shorter TTLs to be able to respond in emergencies (particularly within HA DNS environments) quicker.
- 450
- 3
- 7
-
1Yes. CloudFlare defaults all their customers' TTLs to 300 seconds (5 mins) which is crazy short, but they obviously see benefits. – Simon East Feb 10 '16 at 04:02
-
-
@BogdanGusiev [See here](https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#CloudflareDNSFAQ-HowlongdoesittakeforaDNSchangeImadetopushout). They do this so that they can reroute websites quickly during DDOS attacks, and it also makes DNS changes very responsive, with low propagation times. – Simon East Oct 27 '20 at 00:59
Besides RFC 1912, users in Europe should also see RIPE-203, "Recommendations for DNS SOA Values", which recommends two days as a minimum TTL value.
I'd just leave it at the default set by your host, unless it's ridiculously high or low for some reason. Then if you ever do want to move bump it down to 20 minutes or so a couple of days before you plan to do the move.
- 37,618
- 10
- 90
- 145
(note: this post applies to the TTL on the indidivual A/AAAA records, some other record types can have longer TTLs because they don't represent single points of failure in the same way).
You really need to think about this in terms of your disaster recovery plans. It's not about when you intend to move the site (for intentional moves you can reduce the TTL in the runup to the move). It's about when your host vanishes off the face of the internet or kicks you out for a TOS violation or kicks you out because they can't handle the DDOS that came your way.
If you don't care about your site being down for a day or so in those circumstances then go ahead and leave the TTL on it's one day default. If you have PI address space and BGP transit in multiple locations from multiple providers and intend to handle disaster recover at a BGP level then go ahead and leave it on it's one day default. On the other hand if you are using DNS as your mechnism of diveting your taffic to a failover site then you want a much shorter TTL, 5 minuites is quite a common value.
- 4,056
- 10
- 29
4 hours should be just fine, providing an acceptable balance. That's what I use on most zones.
- 3,071
- 22
- 19
-
4
-
5@dmourati: It's 2011. For the overwhelmingly vast majority of small (i.e., under 1000 or so zones) DNS servers and for any and all clients the additional CPU load and bandwidth requirements are absolutely negligible. Of course, if your DNS servers go down for more than 4 hours you're SOL, but if that's important and you can't provide reliable DNS service you have no business hosting your DNS service on such a rickety foundation in the first place... – Mihai Limbăşan Jun 07 '11 at 17:48
-
3When a user asks a question that is answered directly in an RFC you direct them to the RFC regardless of what year it is. – dmourati Jun 21 '11 at 03:17
-
-