摘要
- Dyn 在 2016 年 10 月遭受 DDoS 攻击，使得权威 DNS 成为客户故障切换问责问题，因为许多服务变得无法访问，尽管它们自身的应用堆栈并非主要目标。
- Dyn 控制其托管 DNS 基础设施、缓解合作伙伴关系、客户沟通和事后声明。客户控制域名架构、辅助 DNS 计划、监控、注册商准备和事件决策规则。
- 独立测量和研究（包括 ThousandEyes 和后来的 DNS 冗余工作）表明，单提供商 DNS 集中化为许多域名带来了实际风险。
- Mirai 和 IoT 僵尸网络记录很重要，但它们不能抹去提供商和客户的职责。僵尸网络问责、提供商弹性和客户故障切换是同一公共可用性问题的不同层面。
- 最持久的教训是，DNS 故障切换是一种经过演练的操作纪律，而不是采购清单上的一个选项。辅助提供商、TTL 选择、区域同步、DNSSEC、监控和公共通知必须在攻击前协同工作。
DNS 故障可能隐藏在健康应用背后
Dyn 事件清晰地展示了用户通常看不到的依赖关系。一个网站、流媒体服务、社交平台、支付工具或媒体资产可能拥有正常运行的应用程序服务器，但如果用户无法解析名称，它们仍然可能无法访问。地址簿在应用程序应答之前失败。对用户来说，这种区别可能无关紧要。服务就是挂了。但对问责审查来说，这种区别很重要，因为负责任的控件不同。
Dyn 保存的关于 2016 年 10 月 21 日 DDoS 攻击的声明描述了针对托管 DNS 基础设施的攻击、多波攻击、缓解合作伙伴以及因地区和时段不同的客户影响。该声明是 Dyn 第一手资料，但并非完整的客户损失地图。它告诉我们提供商遭受了攻击，且托管 DNS 是攻击面。
ThousandEyes 的分析《Dyn DNS 基础设施的 DDoS 攻击》有助于展示客户故障切换问题。它报告了来自监控观测点的严重查询失败、许多受影响网站，以及在高度依赖 Dyn 的域名与拥有更多样化 DNS 安排的域名之间的差异。具体数字反映了测量数据集，而非整个互联网，但教训是可靠的：名称解析架构可以决定提供商攻击是否会演变为客户中断。
问责测试首先从分离层面开始。Dyn 在基础设施弹性、DDoS 缓解、状态沟通和客户指导方面有职责。客户在域名架构、提供商多样性、故障切换测试和用户沟通方面有职责。僵尸网络运营者对恶意流量负责。将任何单一层面视为整个故事都会掩盖其他层面。
辅助 DNS 并非魔法开关
RFC 2182《辅助 DNS 服务器的选择与操作》虽然古老但仍然有用，因为它陈述了一个基本的弹性原则：权威 DNS 服务器不应共享相同的局部故障模式。在现代托管 DNS 中，这一原则变得更加复杂。客户可能使用多个提供商、任播网络、DNSSEC、注册商控制、自动化区域管理、API 集成和 CDN 关联记录。多样性仅在运营上真实时才有价值。
辅助 DNS 可能作为控件失效，如果区域过期、DNSSEC 管理混乱、提供商依赖相同的上游、监控无法检测部分故障、注册商变更缓慢、员工不知道谁能授权更改、或者记录过于动态而无法安全同步。添加第二个提供商但从未测试故障切换的客户并未解决问题。它只是买了一个假设。
关于主要网站和服务在 DNS 解析中缺乏冗余的研究很有价值，因为它将 DNS 集中视为可衡量的架构。该论文的数据集并非通用普查，但它支持更广泛的观点：提供商多样性和经过测试的冗余并非自动实现。许多组织依赖单一托管 DNS 提供商，因为它简单、集成且通常可靠。这种简单性的代价在提供商级事件中显现。
因此，董事会层面的问题不是“我们有辅助 DNS 吗？”，而是“我们能否证明在主要 DNS 提供商受到攻击时，名称解析能够存活？” 该证明需要区域同步、监控、操作权威、运行手册、DNSSEC 处理、联系列表和测试证据。没有这些，辅助 DNS 可能只是图表而非恢复路径。
客户故障切换始于攻击之前
客户故障切换通常被想象为危机行动：提供商挂了，切换到备用。实际上，DNS 故障切换始于日常架构。哪个提供商托管权威区域？多个提供商的名称服务器是否已在注册处委托？记录是否同步？动态记录是通过一个系统还是多个系统控制？TTL 是否适合预期的变更率？DNSSEC 签名是否跨提供商兼容？谁可以更改注册商设置？谁可以宣布 DNS 紧急情况？谁告知客户？
这些决定并不光鲜，但它们决定了客户是否能在 DDoS 事件中采取行动。如果第二个提供商尚未委托，注册商变更可能需要时间并产生传播不确定性。如果区域数据过时，故障切换可能将用户指向错误端点。如果 DNSSEC 密钥未协调，用户可能看到验证失败。如果监控无法区分提供商故障与应用故障，团队可能排错错误的层面。
CISA 关于理解和应对分布式拒绝服务攻击的指导强调准备、基线、提供商协调和响应程序。NCSC 的拒绝服务指导集合提出了相同的一般观点：了解服务、了解防御、制定计划并测试。DNS 客户应将其转化为特定领域的演练。
演练应具体。假设主要权威 DNS 提供商受到攻击，且从主要区域部分不可达。组织能否看到故障？能否验证应用健康？能否与提供商沟通？能否在不出错 DNSSEC 的情况下移动或依赖辅助 DNS？能否更新公共状态页面（如果状态页面依赖相同 DNS）？能否向用户解释事件？如果答案不确定，则故障切换计划尚未成为控件。
提供商透明度需要客户行动细节
在 DNS 提供商攻击期间，客户需要的不仅仅是缓解正在进行的保证。他们需要可操作的确定性。哪些区域受影响？哪些服务降级？权威响应是否失败或延迟？特定记录类型是否受影响？客户应降低 TTL、转移流量、激活辅助提供商，还是等待？API 是否可用？状态更新是否在独立于受影响 DNS 的基础设施上？下一次更新何时到来？
Dyn 的公开声明命名了攻击阶段和缓解工作。这很有用。但客户故障切换视角询问客户在攻击活跃时能利用这些信息做什么。没有经过测试的故障切换的客户可能只能观望。拥有委托的辅助 DNS、独立状态沟通和准备就绪的决策规则的客户可以决定是度过事件、转移某些记录，还是警告用户。提供商透明度和客户准备相互增强。
状态问题很微妙。DNS 提供商自己的状态页面、邮件更新、社交媒体渠道、支持门户和 API 文档在 DNS 受到攻击时必须保持可达。如果客户无法访问真相来源，他们可能依赖社交媒体、谣言或第三方监控。提供商应将状态沟通设计为带外连续性服务。
客户沟通也很重要。如果主要在线服务因 DNS 故障而不可达，用户可能不明白是服务、ISP、本地设备、账户还是支付系统出了问题。有准备的客户应拥有不共享相同故障模式的公共状态渠道，并应坦率解释依赖关系。“我们的应用正在运行，但部分用户无法解析我们的域名，因为我们的 DNS 提供商正受到攻击”比通用的宕机语言更有用。
Mirai 使僵尸网络问责不可避免
Dyn 攻击与 Mirai 和 IoT 僵尸网络问题密不可分，但不应将 Mirai 用于扁平化分析。CISA 在 Dyn 之前的警报《Mirai 及其他僵尸网络带来的 DDoS 威胁升级》警告 Mirai 和已发布源代码增加了 DDoS 风险。同行评审研究《理解 Mirai 僵尸网络》解释了不安全设备如何被大规模招募。
DOJ 记录后来提供了刑事问责背景。部门宣布了涉及重大 DDoS 攻击案件的指控和认罪，后来又有个人因参与影响 Dyn 的 IoT 攻击而认罪。这些记录很重要。它们表明恶意流量并非天灾。
但僵尸网络问责并不能替代提供商和客户的控件。犯罪僵尸网络可能制造洪水，但提供商仍需要缓解能力和沟通，客户仍需要故障切换计划。僵尸网络层面解释了流量为何可能。DNS 架构层面解释了为何无关服务变得不可达。客户架构层面解释了为何某些客户比其他人更容易暴露。
NIST 关于增强抗僵尸网络弹性的报告以及后来的 IoT 指导如NISTIR 8259A显示了政策讨论如何转向设备生命周期、制造商责任和生态系统激励。这是必要的，但也很慢。DNS 客户不能等到 IoT 生态系统修复后才测试故障切换。
测量将轶事转化为架构
宕机叙事可能很快变成轶事。用户说 Twitter 挂了。另一个说 Spotify 正常。第三个说问题是区域性的。提供商说缓解正在进行。测量有助于将这些观察转化为架构。ThousandEyes 从多个观测点测量了 DNS 故障。RIPE Labs 使用 RIPE Atlas 观察发布了《快速了解 Dyn 攻击》。RIPE Labs 还讨论了《DNS DDoS 的复杂性》，包括递归重试行为以及区分攻击流量与合法 DNS 查询的困难。
测量对问责很重要，因为它显示了故障在哪里可见以及在哪里不可见。提供商可能看到攻击量。客户可能看到查询失败。用户可能看到不可达服务。递归解析器可能重试。缓存可能根据时机掩盖或放大效应。不同区域可能经历不同结果。没有测量，各方都从片面视角争论。
学术工作如《当堤坝决口：剖析 DDoS 期间的 DNS 防御》通过检查 DNS 防御行为、缓存和特定层面弹性增加了另一层面。要点不在于一篇论文可以裁决每个 Dyn 客户影响。要点是 DNS 弹性可以被研究、测量和改进。它不是只能在灾难后解释的谜团。
客户应将独立 DNS 监控作为自身证据的一部分。监控应从多个区域和网络测试权威响应，比较提供商，在解析失败时发出警报，并确定是应用还是名称解析层失败。如果组织无法独立于其提供商看到 DNS 故障，它可能在关键时刻盲目。
公共服务连续性也依赖名称解析
Dyn 事件根据同期报道影响了众多流行在线服务，如芝加哥太阳报/美联社关于网络攻击扰乱互联网服务的报道和《卫报》关于重大 DDoS 破坏对重要网站的访问的报道。这些命名服务大多是私有的，但连续性教训同样适用于公共服务。政府门户、紧急信息页面、公共卫生预约工具、法庭立案系统或税务服务也可能因 DNS 缺乏弹性而消失。
公共部门的连续性提出了更高的责任。私有媒体或娱乐服务可能损失收入和信任。公共服务可能影响权利、截止日期、福利、健康、法律获取或紧急信息。因此，公共买家应将 DNS 弹性纳入采购和保障。他们应询问权威 DNS 托管在哪里，辅助 DNS 是否已委托，DNSSEC 是否经过运营测试，注册商凭证是否受保护，以及状态沟通是否独立。
这不仅仅是技术清单。这是对公共地址簿的治理。DNS 委派权力决定了当用户输入名称、点击链接或使用应用时他们被引向何处。如果该权力集中而没有经过测试的恢复路径，公共访问可能依赖于单一提供商吸收攻击的能力。这对某些服务可能是可接受的，但对另一些则不可接受。区别应明确。
公共机构还应进行用户端测试。如果主域名受损，公民是否仍能找到紧急信息？备用域名是否提前传达？官方社交渠道是否已验证？呼叫中心是否知道如果网站不可达该说什么？当系统不可用时截止日期是否延长？名称解析只是公共连续性的第一步，但它是让其他步骤启动的那一步。
合同应要求证据，而不仅仅是可用性
托管 DNS 合同通常强调服务级别、支持、安全和可用性。Dyn 之后，客户应要求证据权利。提供商将分享哪些事件数据？承诺什么状态节奏？哪些客户特定影响信息可用？存在哪些导出和区域传输机制？如何支持辅助提供商？提供商的 DDoS 缓解合作伙伴和升级路线是什么？紧急情况下如何验证变更？
可用性百分比可以隐藏共模风险。提供商可能满足历史可用性目标，但仍代表客户最重要名称的集中故障域。因此，合同审查应包括架构问题：客户能否在违反支持条款的情况下运行多提供商 DNS？API 和区域格式是否可移植？提供商是否支持跨提供商的 DNSSEC 安排？客户能否获得重建部分中断影响所需的日志？
Oracle 宣布收购 Dyn描述了 Dyn 的市场角色和企业客户群。该收购不应被视为仅由攻击导致。它确实表明托管 DNS 和互联网性能服务是重要的商业基础设施。购买此类服务的客户应将其视为关键依赖，而非商品附加项。
证据权利也保护提供商。如果提供商能够展示攻击时间线、缓解步骤、客户通知和恢复里程碑，它可以将自身控制与客户架构和僵尸网络条件区分开来。弱的证据记录容易招致不精确的指责。强的证据支持公平分配。
问责问题是谁能证明故障切换
公开记录留下了许多未知数：完整的攻击流量混合、每个受影响的域名、所有客户配置、Dyn 的内部容量决策、个别客户损失以及确切的合同职责。这些未知数很重要。它们阻止了任何一方独自承担全部损害的简单主张。它们也使问责标准更实用：谁能证明故障切换？
Dyn 能通过公开声明和客户沟通证明其部分响应。独立监控者能证明从特定观测点观察到的 DNS 故障。客户原则上能证明他们是否有辅助 DNS、是否委托、区域是否最新、DNSSEC 是否工作、应用是否健康以及用户是否收到明确通知。僵尸网络起诉能证明部分犯罪层面。每个证明回答不同的问责问题。
对客户来说，关键的证明是事前。提供商中断后记录的故障切换计划很弱。中断前测试的计划才是控件。测试应包括主要提供商受损、辅助提供商行为、注册商访问、DNSSEC 验证、监控、状态页面独立性、客户沟通和回滚。它应该足够无聊以定期运行，足够严肃以暴露错误假设。
对提供商来说，可信的修复包括缓解能力、透明状态、客户指导、对多提供商架构的支持以及清晰的事件证据。对公共机构和关键服务来说，可信的修复包括服务排名和备用沟通。对 IoT 生态系统来说，可信的修复包括减少僵尸网络燃料的设备安全改进。Dyn 案例位于所有这些层面的交汇点。
真正的 DNS 练习比图表更难
最后的教训是运营性的。DNS 图表可以显示两个提供商和许多名称服务器。真正的练习显示组织能否使用它们。练习应从部分权威 DNS 故障开始，在一个或多个区域。监控应检测到它。事件团队决定是否采取行动。DNS 团队确认区域时效。安全团队确认凭证。沟通团队更新独立状态渠道。业务负责人了解哪些服务受影响。法律或合规团队记录截止日期和用户影响。
然后团队应测试变更。记录能否从辅助提供商正确服务？递归解析器是否按预期行为？DNSSEC 是否验证？移动应用、API、CDN 集成、电子邮件和身份流程是否仍然工作？日志是否保存？受影响区域的用户是否恢复？组织能否解释 DNS 与应用健康的区别？能否恢复正常而不造成另一个中断？
结果应记录为证据，而不仅仅是通过或失败。哪些假设是错误的？哪些联系人过时了？哪个提供商界面令人困惑？哪些名称缺乏辅助覆盖？哪个状态页面共享故障模式？哪些记录过于动态而无法手动处理？这些发现才是练习的真正价值。
Dyn 2016 年 DDoS 事件仍然相关，因为它揭示了一个安静的事实：公共互联网通常依赖那些弹性不如背后服务的名称。权威 DNS 不仅仅是管道。它是用户找到服务的路径。客户故障切换问责始于该路径在设计、测试和治理之后，且在任何攻击者瞄准它之前。
DNSSEC 和自动化可能使故障切换更难
DNSSEC 提高了真实性，但如果密钥管理、签名、委派和操作角色未被理解，它可能使多提供商故障切换复杂化。客户通过一个提供商签署区域，然后在压力下尝试移动，可能会发现验证失败成为第二次中断。正确的教训不是避免 DNSSEC，而是将 DNSSEC 纳入故障切换演练，使真实性和可用性一同测试。
自动化也有类似的双刃效应。API 驱动的 DNS 变更、基础设施即代码、动态记录、流量引导和 CDN 集成可以使日常操作高效。它们也可能使紧急故障切换更脆弱，如果只维护单一提供商集成，或者自动化管道依赖受影响的提供商。手动控制台回退可能太慢；自动回退可能未经测试。负责任的设计应明确在提供商故障期间哪些自动化值得信赖，哪些人工批准仍然是必需的。
因此，演练应包括加密和自动化检查。团队能否重新生成或预置密钥？能否安全同步记录？能否防止脑裂 DNS 答案？能否避免来自禁用管道的过时记录？能否测试负缓存和 TTL 行为？能否从多个递归解析器验证？这些细节听起来狭隘，但它们决定了故障切换是否对真实用户有效。
状态页面需要独立名称
一个尴尬的故障模式是状态页面依赖与所解释服务相同的 DNS 路径。如果用户无法解析主域名，他们也可能无法解析状态域名。一个认真的客户故障切换计划应将状态沟通置于独立的名称、提供商和渠道上。它还应该包括不都共享失败依赖的社交渠道、邮件列表、客户门户和支持脚本。
这不仅仅是沟通偏好。在 DNS 事件期间，公众可能不知道是服务坏了、用户 ISP 坏了、设备坏了还是账户被入侵。独立状态渠道减少了不确定性和支持负担。它也给公司一个地方来解释应用是否健康、DNS 是否受损、故障切换是否进行中以及用户应期待什么。
对公共服务来说，独立状态更为重要。试图提交表单、检查福利、寻找紧急建议或满足法律截止日期的公民需要一个可靠的替代信息来源。状态渠道应在政府网络之外和不同区域测试。如果身份部分属于中断，它不应依赖相同的身份提供商。它应对非专家易懂。
采购应将 DNS 视为关键依赖
组织通常将云托管、身份、支付处理、电子邮件和数据存储审查为关键服务，而将 DNS 视为小项。Dyn 事件主张改变这一优先级。如果 DNS 失败，许多其他投资将变得不可达。采购审查应询问提供商是否拥有可信的 DDoS 容量、透明的事件沟通、独立状态、对辅助 DNS 的支持、可导出区域、DNSSEC 指导、客户特定报告和紧急联系人。
审查还应询问客户承诺做什么。提供商无法单独实现客户的完整故障切换架构。客户必须维护准确的区域、在适当时委托辅助名称服务器、保护注册商账户、测试变更、分配决策权，并从独立位置监控解析。购买提供商弹性而不准备客户就绪的合同是不完整的。
关键性应按服务分级。营销微网站可能容忍较长的 DNS 中断。支付网关、紧急门户、身份端点、客户使用的 API 或公共卫生服务则不能。分级防止了过度工程和危险的忽视。它使团队在用户损害最高之处投入弹性努力。
递归解析器和缓存使用户体验复杂化
权威 DNS 只是解析路径的一部分。递归解析器、缓存、TTL、负缓存、重试行为和用户网络条件都塑造人们的体验。在 Dyn 事件期间，一些用户可以访问服务而其他用户不能。某些缓存记录可能暂时掩盖了权威故障。其他解析器行为可能增加了压力。这种复杂性就是为什么独立测量如此重要。
客户不应假设从总部成功的查询证明全球可用性。他们需要跨区域、网络和解析器类型的观测点。他们应测试企业 DNS、公共解析器、ISP 解析器、移动网络和云监控位置。他们还应该监控 DNS 解析与应用响应之间的差异。如果 DNS 首先失败，应用监控可能永远不会运行。
用户支持脚本应反映这种复杂性而不让用户淹没在术语中。它可以说部分用户因为名称解析受损而无法访问服务，应用本身正在被监控，团队正在与 DNS 提供商合作。如果可能，它应提供替代渠道。清晰的语言减少了因无法从笔记本电脑解决权威 DNS 中断而反复排错的用户。
僵尸网络预防很慢，因此客户准备必须快
Mirai 显示，不安全的 IoT 设备可以制造流量，淹没资源良好的目标。关于 IoT 安全、设备标签、基线能力、默认凭证和更新支持的政策工作是必要的。它也很慢。设备部署多年，所有者可能不修补，制造商可能消失，源代码可被重用。依赖 DNS 的客户不能使其连续性取决于首先改善的僵尸网络生态系统。
这并不意味着僵尸网络预防无关紧要。这意味着各层面应诚实。政府、制造商、ISP 和安全社区应减少僵尸网络燃料。DNS 提供商应构建和购买缓解能力。客户应设计故障切换。用户应接收清晰的沟通。没有任何单一层面能承担全部负担，一个层面的失败不应成为另一个层面忽视的借口。
这种分层观点对董事会很有用。董事会可能问 DDoS 问题是否是“提供商的工作”。答案部分是的，部分不是。提供商必须防御其基础设施。客户必须决定一个提供商是否足以应对相关业务流程。董事会拥有风险接受度。如果关键收入或公共服务路径依赖单一权威 DNS 提供商，那是一个董事会级依赖。
公开记录应区分中断和依赖
DNS 事件后，公共报道通常列出受影响品牌。这对展示规模很有用，但可能模糊因果关系。一个命名服务可能因 DNS 提供商受攻击而对某些用户不可达，而服务自身的应用保持健康。另一个服务可能因其自身配置而受影响不同。第三个可能受多提供商 DNS 或缓存记录保护。当报道区分提供商中断、客户依赖和用户影响时，问责得到改善。
相同的区分应出现在公司事后分析中。客户应说明其应用是否失败、DNS 解析是否失败、故障切换是否工作以及将改变什么。如果客户只说“第三方中断影响了我们”，读者无法判断客户是否有合理的架构。如果它只说“服务不可用”，读者无法识别依赖。正确的语言应具体而不过度分享敏感细节。
提供商事后分析应同样避免将客户视为单一类别。一些客户可能需要更好的架构。一些客户可能需要更好的指导。一些客户可能因攻击条件超出假设而受影响尽管设计强大。客户特定细节可能保密，但总体教训仍可分享。当提供商和客户事后分析以兼容类别发言时，市场学习更快。
问责测试设计为无聊
最好的 DNS 弹性项目是有意无聊的。它保持区域同步。它定期测试故障切换。它保护注册商访问。它记录 DNSSEC。它从多个地点监控。它维护独立状态渠道。它培训不止一个人。它记录决策。它审查提供商证据。它按用户损害排名服务。它在知名僵尸网络将教训带回头版之前做这些事情。
无聊的控件容易被推迟，因为 DNS 通常工作。Dyn 的攻击显示了这种自满的代价。当权威层失败时，用户感觉事件突然，即使架构决定是旧的。问责意味着在还有时间改变时让那些旧决定可见。
公共互联网依赖大多数用户从未看到的信任和可达性链。Dyn 使一个链接可见。负责任的响应不是恐慌、指责或每个服务需要相同昂贵架构的普遍规则。它是一个纪律性的问题：对于此服务，考虑此公共或商业后果，我们能否证明当主要 DNS 路径受到攻击时，用户仍能找到我们？
故障切换所有者不应模糊
DNS 位于团队之间。基础设施可能拥有区域。安全可能拥有 DDoS 风险。应用团队可能拥有端点。营销可能拥有域名。法律可能拥有注册商合同。客户支持可能拥有状态沟通。在提供商攻击期间，模糊变成延迟。组织应该知道谁可以宣布 DNS 故障切换、谁可以更改委托、谁可以批准 DNSSEC 操作、谁可以更新状态消息以及谁可以承担面向客户的风险。
所有者在事件前应有权力。如果故障切换需要从未一起练习过的人召开紧急会议，计划很脆弱。决策仍可包括检查，但检查应经过排练。命名故障切换所有者不意味着一个人单独行动。它意味着组织知道哪个角色协调决策。
注册商控制是相同依赖的一部分
许多 DNS 计划低估了注册商访问。如果组织需要更改名称服务器委托或 DS 记录，注册商凭证、多因素认证、锁定状态和批准工作流程很重要。提供商级 DNS 事件可能变得更糟，如果注册商账户不可访问、没有紧急程序而过度保护、或由已离职员工持有。注册商准备应与 DNS 提供商准备同样认真对待。
测试应避免鲁莽的实时更改，但可以验证谁有访问、需要哪些批准、如何处理锁定、紧急联系人如何工作以及如何回滚更改。它还应验证注册商通信独立于受影响域名。如果唯一能批准更改的人接收邮件的域依赖相同 DNS 路径，流程可能在最坏时刻失败。
客户证据应保留用于日后归因
DNS 中断后，客户可能需要将损害归因于提供商失败、自身架构、上游解析器行为和应用问题。该归因需要证据。监控日志、提供商状态消息、解析器测试、客户影响报告、支持工单和内部决策应被保留。没有它们，事后分析变成记忆和指责。
证据保留还帮助决定架构是否应改变。如果中断仅影响某些区域的用户，响应可能与全球故障不同。如果辅助 DNS 正确应答但应用仍然失败，DNS 计划可能不是主要问题。如果客户无法访问状态页面，沟通架构需要工作。如果 DNSSEC 验证在故障切换期间失败，安全和 DNS 团队需要联合修复计划。
证据应在事件还新鲜时审查。等待数月将技术事实变成民间传说。简短、纪律性的审查可以识别保留记录、重新审视决定和重新运行测试。Dyn 的事件鼓励在下一个提供商级攻击前养成该习惯。
服务所有者应了解 DNS 故障对用户的影响
DNS 风险应为每个服务所有者转化。运行公共 API、支付页面、身份端点、紧急信息站点或客户门户的团队应了解如果名称无法解析，用户会失去什么。他们应了解缓存记录是否提供短暂缓冲、移动用户是否与企业用户受影响不同、以及支持人员是否能提供可用替代方案。没有这种转化，DNS 仍是基础设施抽象，直到中断到达客户。
服务所有者还应提前决定可接受残余风险水平。如果用户后果低，有些服务可以容忍单一提供商。其他服务需要辅助 DNS、独立状态和频繁演练，因为公共或商业损害高。该决定应记录为风险接受，而非隐藏在技术默认设置内。
DNS 演练应包括业务时钟
技术 DNS 演练可以成功，而业务仍然未能及时行动。演练应包括业务时钟：客户损害何时开始、支持量何时上升、法律或监管通知何时可能需要、收入或公共服务截止日期何时受影响、以及高管何时必须决定是否激活辅助安排。这些阈值因服务而异，因此应由服务所有者与基础设施和安全团队设定。
演练还应测试回滚。紧急 DNS 变更可以解决一个问题，但如果过时记录、DNSSEC 设置、注册商锁定或应用依赖未仔细恢复，可能创造另一个问题。因此，负责任的故障切换计划包括返回正常服务的路径、正常服务安全的证据以及告知用户问题已关闭的沟通。Dyn 的教训不仅仅是关于如何从攻击路径移开。它是关于证明组织能在压力下管理整个依赖生命周期。