21–30 of 163 posts
What is the use cases for having the TTL shorter than 5 minutes?
Do you get faster web pages if you cache for a longer time? If you do, shouldn't web browsers "soft-invalidate" (use the entry, but update it right after) the cache entry when you're just past TTL and "hard-invalidate" (update it before using) after? Do they do that already?
What is the use cases for having the TTL shorter than 5 minutes?
One would probably be OK if it was 5 or 10 mins, but it depends on what's behind that dns entry and how often ISP can change the IP.
1. Create instance of service running version n+1
2. Switch public DNS records to point to new servers
3. Wait for TTL to expire
4. Turn off old servers
(Obviously I'm simplifying; if nothing else there should be testing steps in there)
Unless I've missed something, wouldn't the author's suggestion to artificially raise the TTL by ignoring the upstream TTL result in the application breaking for customers if they used a DNS resolver that did this?
It doesn’t sound like the author has ever operated a large scale service. There are reasons why every big operator has short TTLs and it isn’t because they are stupid.
It's everyone below that that don't operate very large scale services that will see the benefits from longer TTLs.
Once upon a time, I worked in a saas company that would sometimes switch customers to a new instance of a service by switching DNS records - 1. Create instance of service running version n+1 2. Switch public DNS records to point to new servers 3. Wait for TTL to expire 4. Turn off old servers (Obviously I'm simplifying; if nothing else there should be testing steps in there) Unless I've missed something, wouldn't the…
But I bet you still ran forwarders on the old hosts for at least an hour after you cut over DNS.
It doesn’t sound like the author has ever operated a large scale service. There are reasons why every big operator has short TTLs and it isn’t because they are stupid.
Once upon a time, I worked in a saas company that would sometimes switch customers to a new instance of a service by switching DNS records - 1. Create instance of service running version n+1 2. Switch public DNS records to point to new servers 3. Wait for TTL to expire 4. Turn off old servers (Obviously I'm simplifying; if nothing else there should be testing steps in there) Unless I've missed something, wouldn't the…
Yes, for 40 minutes to 1 hour. But I bet you still ran forwarders on the old hosts for at least an hour after you cut over DNS.
I promise you we did not.
I've never regretted a short TTL.
Earlier quoted context omitted.
I always was under the impression people lowered the TTL when updating records... which doesn't even really make sense since the change won't propagate until the previous TTL is overrun anyways. Then you were supposed to update it to a longer TTL when your change had propagated. So, I guess, after understanding things better... there is no use case really since if it's a new record your change will always propagate,…
You got the use case right, but I think you're still thinking about it wrong. In-use public DNS changes aren't something that just crop up and need to be done immediately. Eg. Five days from now, I'm going to make an infrastructure change that will affect public DNS. Today, I lower my TTL on affected records. Five days later I make the public changes, still using the lower TTL. Once I am satisfied my change will stay…