Hacker News Reader

Comment by diafygi | Hacker News Reader

Agreed, at the time we were quite confused and still are about the intricacies of TTL. Sucks that there's not really a good way to address it. Maybe just keep the TTLs at 300 always?

View on HN

Keep in mind that not all DNS caches—particularly those at large ISP's—respect sub-3600s TTL's.

(they do this in an effort to reduce load; whether it is truly effective on today's hardware is arguable)

Some ISPs (in particular, those in countries far from the US, such as those in the Middle East, although occasionally even Europe) do not even honor the hour-long TTL used by ELB (for reasons of latency, not load), so if you care about your traffic not being routed to someone else's server, you should not allow ELB to get exposed to end user requests (in my case, I use it to balance my backend servers, but the only incoming connections it handles are from CDNetworks, whom I know has a to-specification implementation of DNS caching).

Won't that lead to a slower page load time for a lot of people due to unnecessary DNS look-ups?

Nicer thing to do would be to have the maintenance IP as your last A record. If the client can't reach your regular servers, it will automatically fall back to the maintenance IP.

That's not actually how A records work. Clients are supposed to randomly select one of the A records, although this doesn't always distribute the load as randomly as it should. (My company's site used to have 4 A records for 4 load balancers, and we found that one of them received 25-30% more traffic than the rest.) Clients certainly don't have a mechanism to retry if one of them fails -- they'll be stuck with the failing IP for the length of the TTL.

Low TTLs are a necessarily evil, otherwise you turn your load balancer into a SPOF.

Reply on news.ycombinator.com