4 ms·

DNS rarely takes a day or more to do anything. The only place I have to wait on it is when I change my name servers at my registrar. If you set your TTLs low,

DNS rarely takes a day or more to do anything. The only place I have to wait on it is when I change my name servers at my registrar. If you set your TTLs low, the greatest amount of time you're looking at is probably an hour. Another option is dynamic DNS load balancing.

thaumaturgy 17y ago
Back when I was working for an ISP, we discovered that sbcglobal was ignoring the TTL for some domains.
pierrefar 17y ago
If they run an API, some hosts (Dreamhost) ignore the TTL for ages. I discovered this when one of my API users emailed me after a DNS change asking what happened. In the end my user had to edit their hosts file to over-ride Dreamhost's obscene DNS cache.
brk 17y ago
90% of the ISPs (just pulling that out of my ass) will respect DNS TTL times. However, the other 10% may not, and these are likely to be the large providers (Comcast cable modem customers, etc.) and will often set a TTL in their caching servers of 24hours minimum. On top of that, most browsers also cache DNS information. The best way, IMO, to get better than average availability on a budget is to put 2 haproxy servers at a colo provider that offers some geographic diversity, but can route IP traffic seamlessly between the two sites. These kinds of places will often be BYOS, and charge by rackspace used. Some bill in 1U increments, some you may have to get a 1/3 or 1/2 cabinet minimum. Use the IP of the haproxy server as your "public IP", then configure haproxy to direct traffic to 1 or more budget hosting providers. haproxy will generally handle all the session-management for something like an ecommerce site that requires a users connection go back to the same server each time. It's been a couple of years since I was heavily involved in this, but you're looking at about $300/mo minimum in colo/hosting fees to get into something that can offer some resiliency against the common outage. If a couple of hours of lost business have a value of more than $500, then you probably need to upgrade your infrastructure.

thaumaturgy 17y ago

Back when I was working for an ISP, we discovered that sbcglobal was ignoring the TTL for some domains.

pierrefar 17y ago

If they run an API, some hosts (Dreamhost) ignore the TTL for ages. I discovered this when one of my API users emailed me after a DNS change asking what happened. In the end my user had to edit their hosts file to over-ride Dreamhost's obscene DNS cache.

brk 17y ago

90% of the ISPs (just pulling that out of my ass) will respect DNS TTL times. However, the other 10% may not, and these are likely to be the large providers (Comcast cable modem customers, etc.) and will often set a TTL in their caching servers of 24hours minimum. On top of that, most browsers also cache DNS information. The best way, IMO, to get better than average availability on a budget is to put 2 haproxy servers at a colo provider that offers some geographic diversity, but can route IP traffic seamlessly between the two sites. These kinds of places will often be BYOS, and charge by rackspace used. Some bill in 1U increments, some you may have to get a 1/3 or 1/2 cabinet minimum. Use the IP of the haproxy server as your "public IP", then configure haproxy to direct traffic to 1 or more budget hosting providers. haproxy will generally handle all the session-management for something like an ecommerce site that requires a users connection go back to the same server each time. It's been a couple of years since I was heavily involved in this, but you're looking at about $300/mo minimum in colo/hosting fees to get into something that can offer some resiliency against the common outage. If a couple of hours of lost business have a value of more than $500, then you probably need to upgrade your infrastructure.