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.