Why do you need a low ttl for those? You can add multiple IPs to your A/AAAA records for very basic load balancing. And DNS is a pretty bad idea for any kind of failover. You can set a very low ttl, but providers might simply enforce a larger one.
You don't want to add too many A/AAAA records, or your response gets too big and you run into fun times. IIRC, you can do about 8 of each before you get to the magic 512 byte length (yeah, you're supposed to be able to do more, 1232 bytes as of 2020-10-01, but if you can fit in 512 bytes, you might have better results on a few networks that never got the memo)
And then if you're dealing with browsers, they're not the best at trying everything, or they may wait a long time before trying another host if the first is non-responsive. For browsers and rotations that really do change, I like a 60 second TTL. If it's pretty stable most of the time, 15 minutes most of the time, and crank it down before intentional changes.
If you've got a smart client that will get all the answers, and reasonably try them, then 5-60 minutes seems reasonable, depending on how often you make big changes.
All that said, some caches will keep your records basically forever, and there's not much you can do about that. Just gotta live with it.
It's not good as a first line of defense for failover, but with some client software and/or failure mechanisms there aren't any better approachs I'm aware of. Some of the software I administer doesn't understand multiple A/AAAA records.
And a BGP failure is a good example too. It doesn't matter how resilient the failover mechanisms for one IP are if the routing tables are wrong.
Agreed about some providers enforcing a larger one, though. DNS propagation is wildly inconsistent.
If you add multiple IPs to a record, a lot of resolvers will simply use the first one. So even in that case you need a low TTL to shuffle them constantly
I desperately wish Stirling wasn't a webapp. Having to setup and launch a web server and browser to edit a PDF on my computer seems insane. We skipped the "foss, local app" stage, where Adobe dominates, and jumped straight to the web service model.
I think the core audience for Stirling PDF is a lot different from ours. Stirling PDF looks like there built for enterprise users and big business. We built LuxPDF to be more for students, small business owners, freelancers, etc. To be honest we saw our site as an alternative to FreeConvert & PDFCandy, not for Stirling PDF.
They pretty much told everyone that a proper integration for OpenSSL would take years. The server API seems to be in an early review state and slowly progressing.
As the blog post mentions, the main question is not why a including a QUIC implementation in OpenSSL will take years (that’s reasonable), it’s why the only way to do QUIC using OpenSSL is to use their implementation of the whole thing. The way QUIC hooks into TLS is admittedly a little bit peculiar, but it’s in no way impossible to separate the layers. The OpenSSL devs just decided they don’t want to.
While the price of energy production is likely to continue to fall, I fear that this will be completely overshadowed by the necessary investment in the grid. Both energy storage and the need to adapt the grid to the more decentralised nature of renewables could lead to a plateau in end user prices.
