Fedora and fallback DNS servers

Some jurisdictions do prohibit ISPs from selling user data. And some ISPs are genuinely good netizens. People in these situations (a not insubstantial number, even in the U.S.) accidentally failing over to Google or Cloudflare are objectively in a *worse* situation.

Furthermore, small choices that push the entire Internet ecosystem into reliance on Google, Cloudflare, etc, means it becomes increasingly difficult to significantly improve the situation for everyone. It's not politically difficult (at least not in many jurisdictions outside the U.S.) to justify restrictions on ISPs collecting and leveraging personal data. But try to do that for Google and Cloudflare once a majority of the internet is relying on them to provide "free" DNS service, and then you'll find that you've burned all your bridges (port 53 is blocked everywhere except to Google and Cloudflare) and no longer have any real leverage. They can just take their ball and go home and then your citizens or clients will complain, "what use is privacy if I can't perform the activities I was interested in at all."

Look, it's a difficult problem juggling these competing demands--convenience vs privacy, security, etc. No doubt about it. But there's a difference between taking a path which we're not quite sure where it leads, and taking a path that very clearly leads to an undesirable end, even if it's slightly better than the status quo. Anyhow, the latter path isn't ever going away. Google and Cloudflare want you to use their DNS services because it not only makes them more money, it promises even greater dividends down the road as more people become reliant on them. That's true today and it will remain true for the foreseeable future.

Anyhow, if convenience is your primary objective, the solution is easy: just run a local recursing resolver. NLnet Labs' unbound is one of the most popular local resolvers in FOSS systems (perhaps second only to systemd-resolved). It's reputation is unimpeachable, supports all the latest standards to a much greater degree than systemd-resolved (including DoT and DoH, client- *and* server-side), and it's a first-class recursing, caching resolver. Moreover, it's composed of a collection of well documented APIs, meaning it's relatively easy to stitch together your own local resolver that transparently performs whatever fancy fallback magic you could ever want. OpenBSD does this: they provide unbound in the default install, but also provide their own bespoke "road warrior" resolver built on the unbound libraries. systemd could have decided to use these libraries if they had wanted to; it still can, in fact.

Conflation of the convenience and privacy issues is happening largely because of deficiencies in systemd-resolved itself. Only if you can't reliably perform recursive queries do you need to resort to choosing Google or Cloudflare as the fallback. And even then the options aren't mutually exclusive--you could first try the DHCP-declared server; if that doesn't work try recursing yourself; if that doesn't work fall back to Google over DoT/DoH. And to reiterate, libunbound puts all that within reach with a fraction of the effort that has gone into writing the systemd-resolved stack.[1]

[1] Not that I think the systemd-resolved stack is bad. I had no qualms relying on it to proxy upstream (to the DHCP-declared servers) for our clustering architecture.