DNS弹性就是业务弹性 | 为什么会出现服务中断

最近几周是否注意到Web应用程序加载出现问题？最近的一次重大云服务中断提醒了我们一个似乎总要等到下次危机才会想起的事实：如果DNS出现问题，所有依赖它的服务都会随之瘫痪。

这次是一家主要公有云提供商的问题。但每个数字服务提供商——实际上每个运营网络的企业——都曾在某个时刻遇到过DNS问题。在这次事件中，一个域名指向了无法解析的数据库服务，导致该提供商的许多客户及其内部服务无法访问该数据库，造成了广泛的中断。

我们以前见过这种情况。2016年，对最大DNS托管提供商之一Dyn的毁灭性分布式拒绝服务（DDoS）攻击使许多知名网站离线数小时。去年CrowdStrike的大规模中断实际上是由与DNS无关的软件错误引起的，但崩溃了运行CrowdStrike代理的Windows服务器和端点。这仍然导致了全球网络故障——因为许多这些服务器也在运行DNS。

为什么这个问题一直困扰着我们？因为几乎每个数字连接都始于向DNS服务器询问如何到达某个目的地。作为IP网络的"数字电话簿"，DNS处理着将人类可读的域名转换为IP地址这一平凡但极其重要的任务。当DNS失败时，应用程序无法找到其他端点的地址。没有地址，就没有连接。没有连接，就没有业务。

为什么DNS会失败？

作为一种协议，DNS被设计为相当有弹性（例如，如果一个权威DNS服务器失败，互联网上的递归DNS服务器会自动找到另一个来解析查询）。问题是DNS对数字通信如此基础，当出现问题时，其影响范围往往很大，波及许多其他连接和依赖项。此外，作为企业在线存在的基础元素之一，DNS是网络攻击的主要目标。

DNS失败的常见原因包括：

对DNS基础设施的攻击

威胁行为者不断探测面向公众的权威服务器。这使服务器面临各种威胁，从压倒DNS服务器的大流量 volumetric DDoS 攻击，到像DNS劫持这样的漏洞利用，后者会更改权威DNS记录以将查询定向到恶意站点。

配置错误

不幸的是，许多DNS问题是自我造成的，因为DNS服务器在处理错误时可能相当不宽容。看似小的问题——比如输入头信息时数字错位——可能导致重大中断。或者，如果在权威DNS服务器中引入错误，它可能开始发送非权威响应——互联网上的递归DNS服务器不会接受这些响应。

自动化出错

在云规模下，DNS更改是通过脚本进行的。如果错误信息以某种方式进入区域，这些错误数据会广泛且即时地传播。

单点故障

把所有鸡蛋放在一个篮子里从来都不是好主意——即使这是钱能买到的最好的篮子。如果一个提供商处理你所有的权威DNS，而该提供商出现中断，你在他们解决问题之前都将无法运作。

与其他服务共享空间

许多组织仍然从处理身份或其他服务的同一服务器运行DNS——实际上将DNS与另一个系统的健康捆绑在一起。正如我们在CrowdStrike中断期间看到的，问题不一定源自DNS本身。如果DNS所在的设备出现故障，你会得到相同的结果。

弹性DNS的实用指南

好消息是，组织可以采取许多措施来避免这类问题。最简单的步骤是利用DNS的内置弹性：给递归服务器多个权威DNS服务器选择。给存根解析器或DNS客户端多个递归服务器选择。并使用DNS任播在发生故障时自动将查询路由到最近的健康解析器。

以下是我多年来推荐的一些其他最佳实践：

多样化权威DNS

消除单点故障的最佳方法是运行异构的权威DNS服务器集——一些由信誉良好的云或SaaS提供商托管，一些在本地自托管。这样，如果你的云或SaaS DNS服务出现故障，自托管的权威DNS服务器仍然可用——你的网站和服务保持在线。当Dyn中断发生时，我曾与一个使用这种确切架构的团队交谈过。（他们支持在线交易，并每分钟监控其网站可达性。）当其他公司离线长达八小时时，他们几乎没有受到影响。

分离角色，解耦共享命运

不要将权威DNS与身份或其他服务共同托管在同一基础设施上。DNS对现代企业至关重要，应以此对待，严格分离职责。国家标准与技术研究院（NIST）的新草案建议明确说明了这一点：“即使DNS在安全操作系统上运行，该操作系统上其他软件程序中的漏洞也可能被用来危害DNS软件的安全性和可用性。因此，托管DNS服务的基础设施应专用于该任务，并为此目的进行加固。“1 沿着这些思路，不要对权威和递归角色使用相同的外部DNS服务器。始终将它们分开。

保护外部权威DNS免受DDoS和滥用

令人惊讶的是，许多公司让外部权威DNS服务器处于未保护状态。面向公众的名称服务器应能吸收DDoS洪水攻击并阻止协议漏洞利用，同时继续为合法查询服务。

多样化内部名称服务器

为确保内部DNS的弹性，在不同子网上的多个DNS权威服务器上托管关键区域——理想情况下在不同站点。并将它们部署在尽可能靠近使用它们的客户端的位置，这样查询就不必穿越整个网络，增加延迟。

持续测试和验证

任何时候对区域数据或DNS服务器配置进行任何重要更改时，确认你的服务器正在响应——并且正在权威地响应。从互联网或网络的远程部分运行定期探测，以验证关键域名正在解析且服务可访问。

集中DNS管理

如果你运行混合和/或多云环境，团队不断在专用DNS系统和工具之间切换，你总是离中断只有一次误操作之遥。尽可能在统一的、云无关的管理、控制和可见性点内整合DNS服务。当你可以从一个地方监控所有DNS，并在所有环境中使用相同的一致工作流和自动化时，出现问题的可能性要低得多。

最重要的建议

在网络健康时采取这些步骤，而不是等到出现问题。互联网几十年来一直具有弹性，因为DNS具有弹性——但只有在你这样设计时才是如此。在天空晴朗时投资于异构性、分离和验证，下次出现DNS小问题时，你将能继续正常解析。

脚注

安全域名系统（DNS）部署指南 | 对NIST SP 800-81r3的评论 | NIST, S. Rose, C. Liu, R. Gibson. 2025年4月。