Regarding your valid concerns about the PSL, as long as you have a domain already, you can just make a CNAME record to a free dynamic DNS provider's sub-domain record, I've done this for years with a No-IP ddns.net record. I don't especially recommend No-IP as the 30 day verification is a bit annoying, but at < 1 minute of work per month, it's tolerable for a free service and $2.50 a month is an order of magnitude more than what I feel a single dynamic DNS record is worth.
Since I moved to having a pfSense box at home, I'm using Cloudflare for dynamic DNS, no extra fee and works perfectly, but like I said above, probably not available on typical home routers without a regular machine behind the router having to poll your IP to detect needed updates of a dynamic DNS record.
As I was on Namecheap, I was initially going to use their dynamic DNS option, but it turns out it's behind a higher fee to enable full API access to administering your domain, totally stupid, but with their having been bought out by the PE entity I wouldn't want to stay with them anyway.
See, before the cloud, you used to deploy your code to actual physical servers. If your site became really popular you needed more than one server to run it.
Before commercial and open source load balancers became a thing we literally used HTTP redirects to distribute load. You might visit www.example.com and get redirected to www13.example.com, which was an actual box in a datacenter.
I don't think the internet would exist today if websites just randomly fell over once the number of simultaneous users exceeded the capacity of a single server.
We'd have certainly adapted if we couldn't share cookies, but it would have been a lot messier.
So no, you cannot reliably control load balancing using one domain name pointing to multiple IP addresses. (IP anycast is better suited, but much harder to implement)
There's a lot of people thinking about this though. One somewhat related example is https://datatracker.ietf.org/doc/draft-manelidis-dnsop-domai..., which has a double-opt-in DNS TXT record mechanism. That draft and forthcoming discussions on the mailing list are a good place to understand the complexities here.
DNSSEC is not widely deployed, and so we cannot rely on the authenticity of DNS.
Maybe if we had DNSSEC, then we could rely on it for publicsuffix. Maybe lots of others things could be more easily solved if we had that too.
DNSSEC automation is coming, e.g. https://www.rfc-editor.org/info/rfc10026/. It might never become mainstream, but don't let anyone tell you that we couldn't benefit from having DNS authenticity!
host -t TXT github.io.
etld_depth=2The part that bites harder than cookies: PSL is the closest thing the web has to an entity table. If you live on a shared suffix — anything under mooo.com, dyndns.org, the ten thousand other free subdomain hosts — every crawler and every answer engine collapses you into the parent. Your page inherits the reputation of however many hundred thousand strangers happened to register next door. That's why free-subdomain sites are functionally invisible to search and to AI answers regardless of how good the content is. It's not a quality problem, it's a missing identity boundary, and there's no content fix for it.
The whole thread is basically that tradeoff in different clothes. Free DNS, free TLS, free hosting, free subdomain — every one of those gives you something real and quietly puts you in a bucket where nobody can tell you apart from the worst neighbor in it.
I'm familiar with the process to lift those limits, and Let's Encrypt has been amenable to bumping the certs as high as 250,000 but balked at 500,000, saying, "This is too large for us to support"
(I run a DNS service nip.io / sslip.io, and lots of my users request certs, so I'm always bumping into the limits)