5 ms·

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 t

by diafygi 14y ago

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?

jc4p 14y ago
Won't that lead to a slower page load time for a lot of people due to unnecessary DNS look-ups?
- ohgodthecat 14y ago
  It is a trade off and something you may want to consider depending on how you want your app/website to behave. Is that extra 300ms load a problem if it happens every five minutes? The answer will probably be no in many cases but in some it might just make the cut. The thing you can do is reduce the amount of dns requests in total like using high TTL for a cdn and have everything else served off your main site. Or if you have the option use a little bit less aggressive TTL is 1 hour downtime for an hour TTL a problem or not? Are you really going to need that instant switch of a DNS record and if you are maybe you should be looking at other ways to provide reliability.
stevencorona 14y ago
Low TTLs are a necessarily evil, otherwise you turn your load balancer into a SPOF.
elithrar 14y ago
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)
- saurik 14y ago
  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).
hwatson 14y ago
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.
- RyanGWU82 14y ago
  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.

by diafygi 14y ago

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?

jc4p 14y ago

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

ohgodthecat 14y ago
It is a trade off and something you may want to consider depending on how you want your app/website to behave. Is that extra 300ms load a problem if it happens every five minutes? The answer will probably be no in many cases but in some it might just make the cut. The thing you can do is reduce the amount of dns requests in total like using high TTL for a cdn and have everything else served off your main site. Or if you have the option use a little bit less aggressive TTL is 1 hour downtime for an hour TTL a problem or not? Are you really going to need that instant switch of a DNS record and if you are maybe you should be looking at other ways to provide reliability.

stevencorona 14y ago

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

elithrar 14y ago

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)

saurik 14y ago
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).

hwatson 14y ago

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.

RyanGWU82 14y ago
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.