我的问题源于 7 月 2 日发生的 CloudFlare 事件。该事件发生在他们的系统上，部署了恶意软件，导致包括我们在内的大多数客户停机。https://blog.cloudflare.com/cloudflare-outage/
有没有办法让 CloudFlare 管理我们的 DNS，同时在它之上或与之一起准备一个备用的冗余名称服务器，以防 CloudFlare 再次出现故障？或者有某种解决方案可以在 CloudFlare 网络之外增加冗余，但当我们的服务仍在 CloudFlare 上时仍能正常工作？
我对任何类似的想法都持开放态度。
我唯一想到的办法是让外部观察者应用程序监控我们的设置状态，如果在 DNS 级别出现像最近这样的重大问题，只需将注册商 DNS 服务器更改为我们通过注册商 API 维护的备用 DNS 服务器即可。该备用 DNS 服务器将提供一些故障安全记录，允许访问我们的项目，但缺少 CloudFlare 的 CDN 和流量负载平衡功能。
这是否是解决我的问题的可能甚至首选的解决方案？
关于我们项目设置的一些背景：
我们的项目零停机时间至关重要，我们为此付出了巨大的努力。在服务器/服务级别，我们的项目是完全冗余的，我们在美国三个区域为所有服务（haproxy、应用程序、数据库）配备了冗余服务器。数据库由 Galera Cluster 多主服务器处理，除了内部协商机制之外，它还由自定义外部观察员应用程序监控，该应用程序可以重新配置其中一个数据库服务器以充当主服务器，即使所有三个数据库服务器以某种方式彼此分离。因此，即使两个区域发生故障，剩余区域的数据库也会提升为主服务器，而其他两个区域将从集群中移除，等待手动干预 - 这是最坏的情况。此设置的前端是 CloudFlare，它为我们在 DNS 级别进行负载平衡，流量在三个区域之间分配，然后根据服务器负载和连接时间从一个服务分配到另一个服务，还允许跨区域分配请求。由于 CloudFlare 规模过于庞大，我们错误地认为它没有成为单点故障，但事实上它确实是单点故障，正如我们在最近由他们造成的停机事件中看到的那样。
值得一提的是，我们不能也不想与 CloudFlare 分道扬镳，99.9% 的时间里它们对我们来说都很棒，它们的 Argo 服务为我们带来了巨大的速度提升，此外，我们最终只会得到另一个 CDN，它仍然会存在单点故障，并且容易出现同样的问题。
答案1
值得关注的是：https://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
您将不得不放弃从 Cloudflare 控制台管理 DNS。但是 https://www.cloudflare.com/dns/当您不想允许他们（完全）管理您的 DNS 时，提供了几种替代方案。
Cloudflare 要求用户在注册 Cloudflare 时更改其 DNS。如果您无法将 DNS 移动或更改为 Cloudflare，则可以通过 CNAME 使用企业订阅设置 Cloudflare。您还可以将 Cloudflare 设置为辅助 DNS 提供商...
主辅 DNS
现有 DNS 提供商充当主 DNS，包括记录和解析的管理。记录更新由主 DNS 提供商进行。配置完成后，主 DNS 提供商会自动更新 Cloudflare 的 DNS。Cloudflare 的 DNS 和主 DNS 提供商都会看到 DNS 流量，递归服务器会决定使用哪个 DNS。
