Is it feasible to set my domain's TTL to a very low value (a couple of minutes) so that, if my main host goes down for an extended period of time, I can update the DNS records in my main host to point to my secondary host's IP, thus directing new visitors -- once the DNS propogation is finished -- to my secondary host's servers? Or is this not even possible, perhaps even stupid? I'm just trying to figure out an inexpensive way to prevent downtime.

If it is possible, how low is too low for a TTL?

  • 2
    Using some other sort of redundancy like a cluster, load balancing, reverse proxy, etc, would work better in most circumstances. A low TTL will also add traffic to your DNS servers. This will (mostly) work as sysadmin explains below.
    – Chris S
    Sep 30, 2010 at 21:13
  • 1
    Be aware that more and more systems are completely ignoring TTL settings, regardless of what they are, and caching the data for whatever period they see fit. Annoying and inconvenient as this is there is nothing we can do about it. Oct 14, 2010 at 7:42

3 Answers 3


Low TTLs only work so far, as some DNS resolvers don't honor TTLs below certain, completely arbitrary levels. Even if you set your TTLs to 5 minutes, it can still take up to 48 hours for the change to fully flush from DNS caches on the Internet. What makes this problem worse is that Malware authors use this very trick to change where their command-and-control servers are kept (this is called "fast flux DNS" link), so a countermeasure for this is to not honor TTLs below a certain level.

It is possible to do what you want, and by the standards it should be completely workable, but it is not reliable.


If your host is so unreliable that you're trying to find ways to engineer around them, I'd suggest finding a new host. Having said that, you can use lower TTLs to make changes go through faster, but as has already been mentioned there are many resolvers out there which will impose a minimum TTL and override the one you set if it's below their internal minimum.

The other thing with a low TTL is that if you have a failure of all of your DNS servers (or a resolver is unable to reach at least one of them in any case), a lower TTL will cause your site to disappear more quickly than it would otherwise. It also causes more lookups than a higher TTL would which can, in some cases, make your site feel slower than it would otherwise as a result of continually having to refresh the DNS information. This can be mitigated by setting the TTL to be higher than the average session length on your website.

A TTL of 20-30 minutes isn't unreasonable, but in production environments I wouldn't go any less than an hour unless some known pending change was scheduled to take place which called for a temporarily lower value.

  • 1 hour seems to be the smallest TTL many DNS servers support. I usually set my TTL to an hour, unless the site is very static or I have some limits on my DNS system.
    – mfarver
    Sep 30, 2010 at 21:10

[Some commercial service I'm redacting mention of] has clients that employ the exact failover scenario you described.

The difference is that the system is completely automated. It monitors your servers and modifies the dns records on the fly. It reacts quite a bit faster than an admin getting a page, crawling out of bed, putting on the coffee pot, and changing the records manually. It is also immune to the "just woke up, fat-fingered a record" effect :D

In real life observations, the current client behaviour is that they do flood over the live server pretty quickly.

Despite the fact that there may be some disruption, if the only other option is to be completely down, then being available for the great majority of clients si a pretty good option.

The 48 hours mentioned above does not exist for the contemplated usage. That is for dns propogation time which is related to changing the registered name servers at the registrar level. This is not the same as changing records at an unchanged name server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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