Author probably never had to switch servers because of failure etc and then had to wait 24 hours until the traffic came back up while losing money and getting angry emails from clients who e.g. bought advertising.
Problems with low DNS TTLs
121–130 of 163 posts
Re: Problems with low DNS TTLs
#122The problem is that the DNS TTL is a feature designed for a static internet of the 70's or 80's. What this points to is a need for an authenticated DNS pushes for refresh/invalidation. All supporting resolvers could keep a list of supporting clients that were told that "foo is at address 42". If the record changes, the authoritative DNS server sends a DNSSEC signed unsolicited response to all previous requesters to u…
That is an insane amount of state for auth dns servers to maintain. “Pushing” the message out that the record has changed would also prove tricky to implement I’d say.
Worst case, 2^32 bits is 500MB. If you think that you'll get less than 134 million distinct queries, a simple list or a sparse array may be better.
Obviously you need one of these bitmaps for every change domain (i.e. 1 per zone, or 1 per A/AAAA/CNAME record set, operator choice), and you need to clear it every (extended) TTL.
So a CDN with 100,000 dynamic IP records might split themselves into 1,000 change domains of 100 records each, have a 1 hour TTL (expiry's staggered), and use 500GB ram to do this.
Re: Problems with low DNS TTLs
#123I 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."
Re: Problems with low DNS TTLs
#124Earlier quoted context omitted.
How would you use routing to balance load at that granularity?
Rather than get into a lot of details, here's some excellent starting points: [1] Google Cloud networking in depth: Cloud Load Balancing desconstructed - https://cloud.google.com/blog/products/networking/google-clo... [2] What is AWS Global Accelerator: https://docs.aws.amazon.com/global-accelerator/latest/dg/wha... [3] Tumblr: Hashing Your Way To Handling 23,000 Blog Requests Per Second: http://highscalability.com/b…
Yes, I understand how anycast works (I work for an anycast based CDN).
The issue is that you can't do percentage based routing with anycast... in fact, you can ONLY do shortest hop routing with anycast (at least for WAN anycast). That means that, while different edge networks can go to a different datacenter, every individual edge network will hit only a single datacenter.
The key issue is that anycast is a very blunt tool. You are relying on your BGP announcements to route traffic, but you aren't actually in control of where a particular request goes.
Re: Problems with low DNS TTLs
#125So you have a high TTL thinking that DNS servers will cache your IP, yeh right, DNS servers like Google DNS will only cache it for a few minutes. Doesn't matter if you have high or low TTL.
Re: Problems with low DNS TTLs
#126Earlier quoted context omitted.
The part that's missing in DNS is the ability to tell people that the cache expired. You can't really do this in DNS itself since a cached response will never hit the network. You could add a signal in the application protocol for example: . You'd also have to do that for SMTP, IMAP, etc. Probably not worth the complexity as low TTLs seem to work well enough with few enough downsides. DNS is already a tricky enough p…
Use a new (sub)domain. Your main domain can then simply redirect to whatever subdomain you wish.
A new subdomain normally will do the trick, but might be suboptimal due to the work needed to be done according to scale/tech/job involved. For example, doing this as a sys in a big company requires jumping through bureaucracy hoops, not to mention setting up ssl for it(I know there is letsencrypt but you know, some coporate doesn't want them). A short TTL will just be "Well just try it again in 10 minutes and it'll work."
Re: Problems with low DNS TTLs
#127I think it'd be more interesting to measure the impact on the end user. The article mentions a drop in queries, but aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? Is the difference really noticeable? 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'…
I think the impact of a low ttl is negligible for web sites. It would at least be nice with some actual measurements. The first visit wouldn't be dns-cached anyways and subsequent page loads will have other static resources already cached.
Re: Problems with low DNS TTLs
#128As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
The part that's missing in DNS is the ability to tell people that the cache expired. You can't really do this in DNS itself since a cached response will never hit the network. You could add a signal in the application protocol for example: . You'd also have to do that for SMTP, IMAP, etc. Probably not worth the complexity as low TTLs seem to work well enough with few enough downsides. DNS is already a tricky enough p…
(offline) Cache invalidation is a very hard thing to do. If you are going to ask the network if your DNS cache is still valid, you might as well get the latest value anyways, since DNS queries are tiny.
Re: Problems with low DNS TTLs
#129As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
"OH, thank god it's a 48 hour TTL". No one ever said this.
48hrs is excessively long. Most DNS servers will probably evict your entry from the cache before two days elapse anyway.
Less than a minute is excessively short. Most long-lived applications will internally cache your IP address for longer than a minute no matter what you do.
Re: Problems with low DNS TTLs
#130LOL lot of arguments for a feature that makes sysadmin/dev life easy once a year at the expense of degraded user experience every day (lot of sporadically broken ISP etc DNS servers civilians can't be expected to bypass). Digital littering.