此外，小的选择促使整个互联网生态系统依赖于Google，Cloudflare等，这意味着要显着改善每个人的处境变得越来越困难。证明限制ISP收集和利用个人数据的合理性在政治上并不困难（至少在美国以外的许多司法管辖区中）。但是，一旦大多数互联网依靠Google和Cloudflare来提供“免费”功能，就可以尝试这样做。 DNS服务，然后您会发现自己已经烧毁了所有网桥（除了Google和Cloudflare之外，其他任何地方都阻塞了端口53），并且不再具有任何实际的杠杆作用。他们只要拿起球回家就可以了，然后您的公民或客户就会抱怨，如果我根本无法执行自己感兴趣的活动，什么是隐私？看起来，这是一个难以解决的难题，需要兼顾这些竞争需求-便利与隐私，安全性等等。但是，走一条我们不太确定它在哪里前进的道路与走一条很明显会导致不希望有的终点的道路之间存在差异，即使它比现状要好一点。无论如何，后一条路永远不会消失。 Google和Cloudflare希望您使用他们的DNS服务，因为它不仅使他们赚钱，而且随着越来越多的人依赖它们，它有望在未来带来更大的收益。今天是正确的，在可预见的将来仍然如此。无论如何，如果方便是您的主要目标，则解决方案很简单：只需运行本地递归解析器即可。 NLnet实验室unbound是FOSS系统中最受欢迎的本地解析器之一（也许仅次于systemd-resolved）。它的声誉是不容置疑的，它支持所有最新的标准，其程度比systemd解析的（包括DoT和DoH，客户端*和*服务器端）要高得多，并且它是一流的递归，缓存解析器。而且，它由一系列有据可查的API组成，这意味着将您自己的本地解析器缝合起来相对比较容易，该解析器可以透明地执行您想要的任何高级后备魔术。 OpenBSD会这样做：他们在默认安装中提供未绑定的内容，但也提供了自己的定制“ road warrior”。基于未绑定库的解析器。如果愿意，systemd可能决定使用这些库；实际上，它仍然可以。便利和隐私问题的合并之所以发生，很大程度上是由于systemd-resolved本身的不足。仅当您无法可靠地执行递归查询时，才需要选择Google或Cloudflare作为后备。即使这样，这些选项也不是互斥的-您可以首先尝试使用DHCP声明的服务器；如果不起作用，请尝试递归；如果不起作用，则通过DoT / DoH退回给Google。重申一下，libunbound使所有事情都可以触及，而这只是编写systemd-resolved堆栈的工作量的一小部分。[1] [1]并不是说我认为systemd-resolved堆栈是不好的。对于集群体系结构，我完全可以依靠它来代理上游（到DHCP声明的服务器）。