Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 15 down vote accepted

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.

share|improve this answer

The standards (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: http://tools.ietf.org/html/rfc1033

RFC 1912 (from 1996) suggests that 3 days may be more appropriate for SOA records.

http://www.ietf.org/rfc/rfc1912.txt

share|improve this answer
4  
I'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
5  
Both 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 7 '14 at 16:02
6  
I'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) 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 at 6: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.

share|improve this answer
1  
Yes. CloudFlare defaults all their customers' TTLs to 300 seconds (5 mins) which is crazy short, but they obviously see benefits. – Simon East Feb 10 at 4:02

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.

share|improve this answer

4 hours should be just fine, providing an acceptable balance. That's what I use on most zones.

share|improve this answer
3  
That's probably way too short. – dmourati May 17 '11 at 0:19
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 7 '11 at 17:48
3  
When 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 3:17
    
@dmourati Is this prescribed in an RFC? – Joó Ádám Jan 3 at 4:38
    
Yes, see my answer above. – dmourati Jan 3 at 5:00

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.

share|improve this answer

(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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.