Fair point but you also get exposed if the dns provider has an outage.

Self hosting will also bring its own set of problems and costs.

> > Keep your domain name registrar, DNS service provider and application infrastructure provider separately.

> Fair point but you also get exposed if the dns provider has an outage

The usual workaround here is to put two IP addresses in your A record, one that points to your main server on hosting provider A, and the other to your mirror server on hosting provider B.

If your DNS provider goes down, cached DNS should still contain both IPs. And if one of your hosting providers goes down as well, clients should timeout and then fallback to the other IP (I believe all major browsers implement this).

Of course this is extra hassle/cost to maintain, and if you aren't quite careful in selecting hosting providers A and B, there's a good chance they have coordinated failures anyway (i.e. both have a dependency on some 3rd party like AWS/Cloudflare).

Traditional non-cloud, non-weird DNS providers have sufficiently long TTLs, not the "60 seconds and then it's broken" crap that clouds do to facilitate some of their services.

Something like TTL 86400 gets you over a lot of outages just because all the caches will still have your entries.

Use multiple DNS providers. Some secondaries have thousands of anycast nodes that are provided for free. One can also condition their user-base to know of multiple domains that are on different registrar accounts and of course a few .onion domains.

You can switch DNS providers if you're able to edit the domain's nameservers.

You can also separate your DNS provider from your registrar, so that you can switch DNS providers if your registrar is still online.