From my short experience, the issue isn't that "the new service isn't available for the user" but "the new service isn't available FOR THE CLIENT". Cue - "why isn't it up yet" emails/calls with "it will take up to x hours to propagate".
Problems with low DNS TTLs
151–160 of 163 posts
Re: Problems with low DNS TTLs
#152I noticed Cloudfront sets a TTL of 60 seconds on its distributions and also on the elastic load balancers. You pay for every Route 53 lookup if you have an ALIAS record pointing there, as is typical. So AWS does not have an incentive to set it any higher. But if I understand it correctly, you can point a CNAME with a long TTL to the appropriate cloudfront.net record, and then you only pay for the CNAME one. The cloud…
Am I missing something? Aren't ALIAS lookups free? https://aws.amazon.com/route53/pricing/ "DNS queries are free when both of the following are true: The domain or subdomain name (example.com or acme.example.com) and the record type (A) in the query match an alias record. The alias target is an AWS resource other than another Route 53 record."
Queries to ALIAS records that are AWS resources (ELB, CloudFront), etc are indeed free. The reason is directly related too; we want to be able to raise and lower the TTL value without customers being impacted.
Re: Problems with low DNS TTLs
#153As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
I would put a reasonable floor on short TTLs (5 minutes?), but yes, it's nice in an emergency to be able to send everyone someplace new. Sucks if you're down, hacked, etc, and can't do anything about an existing long TTL other than wait it out. Edit: Worth noting there's lots of software that seems to only resolve hostnames at first connection, then hangs onto it forever. Lots of java internals for example, unless yo…
Nginx as reverse proxy does this and it's burned me.
Re: Problems with low DNS TTLs
#154Earlier quoted context omitted.
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.
> 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.
There were major providers that at one point in time overrode TTLs to a minimum week if under 24h.
Re: Problems with low DNS TTLs
#155I'am running local caching dnsmasq with minimum TTL of 1h. Modern internet experience is really awful without it.
Re: Problems with low DNS TTLs
#156As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
15 mins is the shortest I would want to go. Otherwise, your app is going to be perceived as slow (by your users) because it has to do a bunch of needless DNS lookups a lot.
I doubt the perception in slowness is really going to be that different between a 5 min TTL and a 15 min TTL.
1. DNS lookups add on the order of 100ms to load time.
2. In both cases (5 min and 15 min) the user is going to do a DNS lookup on the first page, then have cached DNS while they browse for a bit, then have a DNS lookup at some point in the future.
Most web sessions are relatively short, so I doubt most users would even notice the difference where they see an extra 100ms load time at, say, 2 points in their session instead of 1.
In my experience the appropriate use of the preconnect and dns-prefetch hints has a much bigger impact on perceived performance than worrying about DNS TTLs beyond 5 min.
Re: Problems with low DNS TTLs
#157As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
User perspective:
As a user with 20+ years of experience, I have never regretted using authoritative DNS as the source for DNS data instead of DNS caches. Instead of using a shared cache, I bind local authoritative servers loaded with zone files containing the DNS data that applications need to the loopback. IME, lookups are faster than with a cache.
IMO as a user, recursive queries to shared caches are overrated. I want to know what lookups the applications I use are making and I want control over what DNS data is available to them. IME, giving applications license to lookup any resource at any time means this permission will be abused to further the interests of the online ad industry and all those who service it instead of 100% serving the interests of the user.
For example, a commercial router's management console does not need to be able to look up the addresses of ad servers. Letting it have access to a remote shared cache, or even a local one, that does recursive queries is unnecessary. The user has already paid for the router.
Re: Problems with low DNS TTLs
#158Earlier quoted context omitted.
But those are no valid use cases which was my question. So there are no valid use cases at all?
> Administrators wanting their changes to be applied immediately, because it may require less planning work. Why is this not valid?
Valid migration plan should be able to handle it without very short TTL.
Re: Problems with low DNS TTLs
#159Earlier quoted context omitted.
Am I missing something? Aren't ALIAS lookups free? https://aws.amazon.com/route53/pricing/ "DNS queries are free when both of the following are true: The domain or subdomain name (example.com or acme.example.com) and the record type (A) in the query match an alias record. The alias target is an AWS resource other than another Route 53 record."
Queries to ALIAS records that are AWS resources (ELB, CloudFront), etc are indeed free. The reason is directly related too; we want to be able to raise and lower the TTL value without customers being impacted.
Intersting. I stand corrected.
Re: Problems with low DNS TTLs
#160I've often wished there was a way a web server could respond to requests with "Your DNS is out of date. Use this IP instead".