We build our client executables in a debian squeeze docker container exactly because of those glibc versioning issues. This way, they run on all currently supported linux distributions, even on RHEL 6.
Economically, it's usually more expensive to use serverless functions for a constant level of load. At least on AWS but I'd be surprised if the math turns out differently on Azure. So your intuition (low traffic or bursts) for serverless is quite correct, IMO. I usually try to move any stuff that doesn't fit with typical web server loads to serverless functions, e.g. cpu-intensive one-time tasks like image resizing or generating argon2id hashes, etc. But even for those loads it might be more economical to put them on separate instances/scaling groups if they can saturate those and the load is predictable enough.
I'm not buying into the whole "top-down government-controlled" argument against the DNS system. Yes, the US has control over ICANN and therefore the root name servers, but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC). It's currently the ISPs' choice and it more and more transfers over to central resolver like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Even operating system vendors have a lot of influence on the default settings for DNS resolver (take the ones advertised via DHCP or choose some other ones). Even browsers could choose to look up names directly at a resolver of their choosing instead of relying on the OS. What gets in the way of this are local corporate-wide domains and the like, but there are several ways to deal with this. The main argument I want to make is, that the power over DNS is not as much with the US Government as you might think.
The owner of com. (which is effectively the US govt) can hand out whatever records it likes for anything under .com.
All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
And what happens when you (and everyone else) finds out you can no longer trust DNSSEC signatures on .com.? Stop using all of .com?
> but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC).
How does OpenNIC know how to answer the question "where is ycombinator.com"?
> All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
As opposed to the current system, which also gives you a false sense of security while being vulnerable to exactly the same .COM attack, but also to even more types of attacks?
First of all that doesn't matter, because people trust what DNS does regardless of whether it claims to be secure or not. I've never seen anyone or any software distrust a DNS response unless they already know what it was supposed to be. The only exception I know of is Let's Encrypt, which does check DNS responses from multiple sites around the world to verify that they're the same, something which isn't really a security guarantee, it's just a heuristic. And which practically nobody else does and which normal users aren't capable of doing.
Furthermore, what we build on top of DNS and which is supposed to protect from DNS attacks and does claim to be secure, like the CA PKI system, actually depends on DNS to be secure (which it isn't) in order to obtain the certificates. Not to mention the CA PKI system also depends on all certificates authorities in the entire world to be well-behaved.
Stipulate that you can spoof, for any non-LetsEncrypt CA in the world, any DNS response you want. Pick any CA in the Mozilla trust store that you choose. Spoof a response to verify a MAIL.GOOGLE.COM certificate. What do you think happens next?
What would happen next is that the attacker would succeed in getting his certificate for mail.google.com signed by the CA (remember, there are certificate authorities including Let's Encrypt that sign certificates based on DNS responses alone, but selectively spoofing the A record for the HTTP server would also work).
Presumably the CA would have to have published an entry to the CT log for this certificate. This would allow browsers to verify that the certificate generated by the attacker can be trusted and therefore it could be used by the attacker to perform a man-in-the-middle attack on the Gmail interface against any user in the entire world, without anyone noticing it during the attack.
Some time after the attack has already occurred, Google or someone else would presumably notice that the certificate wasn't actually created by Google, even though everything was correctly published in the CT logs like it was expected for any other normal certificate (I'm being very generous here, multiple companies don't even notice their domains are about to expire until it's too late, including Microsoft).
At this point, it would be expected for browser vendors like Mozilla and Google to distrust this CA because they would assume the CA generated a certificate for a Google domain fraudulently. However, the CA wasn't actually the perpetrator of the attack but it also couldn't prove that it wasn't, and since the browsers don't trust them anymore, the innocent company would be ruined and all their employees would be fired and become miserable.
Meanwhile, hundreds of millions or possibly billions of devices (like Android smartphones) who don't update their system software for months or years (or even never) would still have the now-bankrupt CA in their certificate root stores for a very long time (remember, not all certificate root stores are managed by browsers, some are installed at the OS level), so the attacker could still keep attacking these devices, almost indefinitely, without any issue (especially if he repeats the attack, which he can do indefinitely, ruining many CAs until he somehow got caught).
This is all assuming we're talking about a certificate for an HTTPS server, which is the best case scenario.
If we're talking about a certificate for an SMTP server or a DNS server then the problem is even worse, not in this exact scenario, but in the scenario where one of the many certificate authorities behaves maliciously and generates a fraudulent certificate itself (signing it) but doesn't publish an entry to a CT log, so the attack would never be noticed because SMTP servers and DNS servers don't check SCTs.
