【国际视野】美国网络安全和基础设施安全局发布《加密 DNS 实施指南》

传统上，DNS协议不支持确保信息请求或响应的机密性、完整性或真实性的方法。M-22-09 特别呼吁各机构在技术上可行的情况下对DNS 流量进行加密，同时法定要求要求各机构使用CISA 的保护性DNS 功能进行出口DNS 解析。本指南将帮助各机构针对机构网络、DNS基础设施、本地端点、云部署以及漫游、游牧和移动端点实施当前可行的技术功能。

本文件旨在为联邦机构提供实施指导，以满足管理和预算办公室(OMB) 备忘录M-22-091 中规定的与域名系统(DNS) 流量加密相关的联邦要求，并增强其IT 网络的网络安全态势。除其他要求外，备忘录还特别要求各机构在技术可行的情况下使用加密的DNS 流量。根据M-22-09 和《美国法典》第6 编第 663条注释 "机构责任"，各机构还必须在所有出口DNS 解析中使用CISA 的保护性DNS 功能。从广义上讲，本文件旨在指导机构网络从业人员并协助实施当前可行的技术能力，以帮助确保以下几点：

为帮助机构人员了解要求并参与过渡工作，本文件提供了一系列资源：

虽然本文件主要针对FCEB 机构，但其他组织可能会发现它是其自身零信任工作的有用资源。

2022年1月26日，OMB发布了备忘录M-22-09，联邦零信任战略，以支持第14028号行政命令"提高国家网络安全"，使民事机构的企业安全架构与零信任原则保持一致并以此为基础。

该备忘录要求FCEB各机构确保"所有流量必须在可行的情况下尽快加密和验证。

本文件的目的是根据M-22-09《美国政府迈向零信任网络安全原则》，为FCEB机构提供实施加密DNS协议的指导。

DNS 是支持和启用企业IT 的基石。但传统上，DNS并不支持确保信息请求或响应的机密性、完整性或真实性的方法。虽然域名系统安全扩展（DNSSEC）等解决方案可以验证响应的真实性和完整性，但作为查询基础的通信协议仍未加密，这就为对手提供了监控的机会，在完整性和真实性未得到严格验证的情况下，还可能篡改请求或响应。目前已开发出各种协议，支持对DNS 请求和响应流量进行加密；这类协议正越来越多地集成到产品中，从而简化了可提高DNS 通信完整性和保密性的解决方案的部署。

CISA 的保护性 DNS产品支持加密的 DNS通信，可帮助机构将其在《美国法典》第6 编第 663条注释中的责任与M-22-09 中规定的要求保持一致。此外，保护性DNS 产品还可以防止端点解析恶意域，从而保护联邦企业，帮助检测和减轻网络威胁。

CISA关于"解决联邦网络DNS解析问题"的备忘录鼓励使用加密DNS协议，而OMB的M-22-09备忘录则要求在技术支持的情况下使用加密DNS协议。

本指南的重点是各机构根据当前的机构和供应商情况以及CISA保护性DNS的当前可用功能可以采取的可行行动。在此基础上，本指南提出了以下假设：

如果这些假设对某个机构不成立，那么该机构可以采用与指南所述不同的方法来实现本指南的目标。如果机构选择了不同的方法，则需要确保该方法符合所有规定的目标。

本核对表提供了适用于联邦机构的当前要求和最佳实践的高级概览，涉及DNS 流量加密和使用CISA 的保护DNS 进行上游DNS 解析。执行这些步骤的详细指导可参见第3 节和附录A。

鉴于将现有机构企业过渡到使用加密DNS和保护性DNS的复杂性，机构可以考虑分阶段实施，随着时间的推移过渡其企业的一部分。虽然机构的考虑因素将推动最佳方法的制定，但机构应优先考虑防止使用未经授权的DNS提供商、实施保护性DNS保护以及为漫游和游牧端点加密DNS。

分阶段的方法如下：

以下小节介绍了相关技术的背景和M-22-09 的要求，以及实施加密DNS 和使用CISA 保护 DNS服务的更详细指导。

加密 DNS流量的方法多种多样，现成的软件和硬件支持程度也各不相同：

保护 DNS 是由CISA 提供给FCEB 机构使用的DNS 解析器服务，它取代了传统的E3A DNS Sinkholing功能。该服务具有保护功能，有助于防止机构端点访问已知或可疑的恶意域，同时为机构和CISA 提供机构解析的域的可见性。各机构必须将其出口DNS 查询路由到该服务，并让其端点使用该服务，无论是移动、漫游、游牧、内部部署还是云部署。保护性DNS 服务支持IPv4 和 IPv6上的 DNS-overHTTPS和 DNS-over-TLS。此外，该服务还支持经授权的FCEB DNS 基础设施的传统非加密DNS。

图 1显示了各机构可用于使端点使用保护型DNS 服务的各种方法。即使在企业内部，不同端点访问保护型DNS的方法也可能不同。此外，当端点的网络位置发生变化时（例如，漫游设备被移出企业内部，企业内部虚拟机故障转移到云环境），端点可能需要使用不同的方法。

图1：使用保护性DNS 的方法

虽然漫游或游牧端点有可能通过VPN进入传统机构环境并使用这些服务器，但这种方法会给这些端点带来性能问题。各机构应考虑采用其他方法，使漫游或游牧端点能够使用保护DNS，而无需连接到传统的机构内部环境。

此外，如果 SASE/SSE解决方案使用机构内部DNS 基础设施来解析域名，漫游和游牧终端将能够解析机构内部域名和其他未公开发布的资源。各机构需要与SASE/SSE 提供商合作，确保所有来自终端的DNS 流量都被路由到提供商，并确保提供商使用适当的DNS 服务和加密协议来解析这些请求。

为支持M-22-09，各机构需要确保在技术可行的情况下，其DNS基础设施在与上游DNS提供商以及机构端点通信时使用加密的DNS协议。此外，机构DNS基础设施应仅使用保护DNS作为其上游提供商，除非保护DNS不可用。

支持DNS 服务器软件开始包括对加密DNS协议的支持，包括在与客户端通信和与上游提供商通信时。在技术可行的情况下，机构DNS 服务器应使用加密的DNS协议，既用于与客户端通信，也用于与其他服务器通信。如果机构部署了多级机构管理的DNS 服务器，则应在其DNS 服务器之间的通信中使用加密DNS 协议。各机构需要确定其DNS 服务器解决方案及其客户端是否支持加密DNS。由于许多DNS 服务器供应商仍在将加密DNS 协议集成到其解决方案中，因此对DNS 加密的支持可能差别很大。例如，许多常用的DNS 服务器解决方案不支持加密DNS 协议，或者可能需要额外许可才能支持。此外，一些DNS 服务器解决方案可能只支持与上游提供商通信的加密DNS 协议，或者只支持与客户端通信的加密DNS。

各机构应尽可能考虑更新或更换不支持DNS 加密的基础设施。在无法更换DNS 基础设施的情况下，可以使用代理来处理加密DNS。如果 DNS基础设施不支持客户端使用加密DNS，则可使用代理接收通过加密DNS 协议发出的查询，然后使用传统的未加密DNS 将这些查询转发到DNS 基础设施。如果DNS 基础设施不支持与上游DNS 服务器一起使用加密DNS，则可使用代理从DNS 基础设施接收使用传统非加密DNS 的 DNS查询，然后使用加密DNS 将这些查询转发到上游DNS 服务器。各机构需要与DNS 服务器供应商合作，以了解这种模式的可行性。

在机构需要使用传统的未加密DNS 协议进行任何DNS 通信的情况下，他们需要了解并考虑到这种通信缺乏保密性或完整性。

为满足 M-22-09的加密 DNS要求，使用外部加密机制（如通过IPsec 隧道传输未加密的DNS:53 流量）不能取代加密DNS 协议。

各机构需要与CISA 的保护DNS 服务合作，了解如何以最佳方式配置其DNS 基础设施，将保护DNS 用作上游提供商，包括在与保护DNS 通信时使用加密DNS 协议。某些DNS 服务器可能不支持与上游服务器使用加密DNS 协议。为了支持这些不支持加密DNS 协议的服务器，可以安装一个代理，通过加密DNS 协议将服务器的DNS 上游查询转发到保护型DNS。各机构需要与DNS 服务器供应商合作，了解这种模式的可行性。

DNS服务器通常支持一种称为DNS 根提示的功能。在某些情况下，这些提示可能会导致DNS 服务器切换到迭代解析模式。在这种运行模式下，DNS服务器将绕过上游递归解析器，直接与DNS 根服务器通信，从而与互联网上的其他DNS 解析器通信。各机构必须在所有支持此功能的机构管理端点上禁用根提示，以防止其DNS 查询绕过保护DNS 服务。

机构可将备份DNS 解析器（如知名公共解析器）配置为后备解析器，仅在保护DNS 解析器不可用（如服务中断）时使用。机构DNS 基础设施必须对这些后备解析器使用加密DNS。这种配置通常通过将保护DNS 配置为最高优先级服务器，并将后备DNS 服务器配置为较低优先级（如二级、三级）来启用。不过，由于DNS 服务器通常使用优先级作为建议，因此即使主服务器可用，它们也可能使用较低优先级的服务器。在配置备份DNS 解析器时，机构必须确保其配置只允许在保护DNS 不可用时使用DNS 服务器。此外，由于使用这些备份公共解析器会绕过保护型DNS 保护措施，因此各机构应确保其具备相应的机制（如警报），以跟踪备份DNS 解析器何时被用于替代保护型DNS。

有些机构采用"拆分 DNS "配置，即其 DNS基础设施根据请求解析的端点的网络位置，将相同的域、服务或资源解析到不同的地址。例如，机构可能会让在机构内部环境中运行的端点将可公开访问的机构服务解析到内部地址。当机构端点通过机构DNS 基础设施解析域时，使用保护DNS 不会影响这些配置的运行。

许多SASE/SSE 提供商会加密与端点的通信，并支持将端点DNS 查询发送到保护性DNS，使机构能够满足M-22-09 和保护性DNS 的要求。此外，机构端点可以利用这些功能，而不受游牧、漫游、移动设备、内部部署或云部署的影响。

为确保提供适当的保护，必须对端点进行配置，使其所有DNS 流量都能被SASE/SSE 服务拦截，并通过授权的DNS 服务（即保护性DNS 或机构内部DNS 基础设施）进行解析。通用SASE/SSE 部署可简化各种端点保护措施的部署和管理。

各机构需要与SASE/SSE提供商合作，确保流量只发送给授权提供商，包括禁用任何可能允许将流量路由到未授权提供商的机制（如DNS 根提示、根服务器、DNS故障转移、负载平衡）。只要所有无法解析的流量都被路由到保护DNS，SASE/SSE提供商就可以执行过滤和缓存。在技术可行的情况下，机构需要确保SASE/SSE 提供商在与授权DNS 服务通信时使用加密DNS 协议。

在某些情况下，机构可能拥有无法公开寻址的内部资源。为支持这些情况，可将SASE/SSE 提供商配置为使用机构内部DNS 基础设施。在这种情况下，可将SASE/SSE 提供商配置为通过机构内部DNS 基础设施路由部分或全部流量。不过，也有可能通过以下配置来限制机构DNS 基础设施的负载：SASE/SSE提供商使用保护 DNS解析外部资源，使用机构内部DNS 基础设施解析内部资源。

当端点在传统环境外运行时，它们可能会由于有意或无意的错误配置而绕过SASE/SSE 保护，如果没有补偿控制，机构可能无法确定端点绕过了保护。机构应考虑建立机制，防止对端点的SASE/SSE 配置进行更改，或将未经授权的更改自动恢复到已知的良好状态。

为满足M-22-09 的要求，机构端点需要在技术可行的情况下使用加密协议来解决其DNS 查询，并且只能使用授权的DNS 提供商（即机构内部DNS 基础设施或保护DNS），无论其在内部环境、云环境、游牧环境或漫游环境中运行。此外，应用程序和操作系统可能会在默认情况下以绕过机构和CISA DNS 保护的方式启用加密DNS。各机构需要明确配置其端点和应用程序，禁用这些加密DNS 协议，或使用授权配置来解析使用加密协议的DNS 查询。各机构还需要在更新应用程序或操作系统时维护这些配置。

应用程序和操作系统已开始支持使用加密DNS 协议。附录A 包括实施指南，其中讨论了目前支持加密DNS 协议的具体产品。不过，从高层次来看，配置端点使用加密DNS 协议的方法包括：

应用程序和操作系统对加密DNS 的支持通常包括默认配置，即当加密DNS 查询失败时，使用传统的未加密DNS 协议重试DNS 请求。此外，实施可能会寻找网络的某些特征来决定是否降级为未加密DNS。各机构需要确保对其终端进行配置，以明确禁用降级为未加密DNS 的功能，从而确保恶意实体无法迫使它们使用不安全的协议。

应用程序和操作系统对加密DNS 的支持通常带有软件配置选项（包括潜在的默认配置），可绕过本地DNS 配置使用已知支持加密DNS 协议的外部提供商。机构需要防止端点通过直接访问未经授权的DNS 提供商（如第三方公共提供商）来绕过DNS 保护。除了直接阻止未经授权的提供商使用加密DNS协议外，各机构还需要配置端点以禁用此类配置，并应使用全企业范围的策略来确保全面执行。由于新软件和更新软件可能包括启用加密DNS 协议的新配置，各机构将需要一个流程来跟踪其部署的软件（包括操作系统和应用程序）对加密DNS 的支持情况，以确保为其端点提供适当的配置。

端点可通过机构内部DNS 基础设施或SASE/SSE 解决方案进行配置，以使用保护性DNS 保护。

云提供商和服务对如何执行DNS解析提供不同程度的控制，各机构需要了解可用的配置机会。虽然具体选项取决于云提供商及其提供的特定服务，但以下内容提供了常用选项的高级概览：

云部署可能包括各种云服务，每个部署都是一个独特的用例。例如，机构部署的网络服务可能由身份即服务（Identity-as-a-Service）解决方案组成，用于管理部署内的身份；网络应用防火墙即服务（Web Application Firewall-as-a-Service）解决方案用于管理对网络服务的访问；网络服务的PaaS 和 IaaS解决方案的混合；以及数据库即服务（Database-as-a-Service）解决方案用于存储数据。在这些情况下，机构可能只能为其整体云部署的一部分配置DNS解析。机构需要了解并考虑这些差异，以确保提供相应级别的保护和可视性。例如，网络服务部署可能会确保所有外部域在进入云部署之前都已解析，并且部署仅使用内部地址进行通信。

各机构需要确保端点无法通过直接使用未经授权的DNS 提供商（如第三方公共DNS 解析器）来绕过DNS 保护。这一点尤为重要，因为应用程序和操作系统通过包含绕过本地DNS 使用外部提供商的配置（包括潜在的默认配置），越来越方便地使用加密DNS 协议。由于这些新配置使用加密DNS 协议，它们可能会绕过旨在限制访问未授权DNS 服务的现有机构控制。

各机构将需要了解它们为防止未经授权访问DNS 服务而实施的控制措施，并评估是否需要更新上述控制措施或增加补偿控制措施，以应对加密DNS 协议。各机构必须考虑为支持的操作系统和应用程序部署适当的端点DNS 配置机制，只允许使用授权DNS 服务（即保护DNS 或机构内部DNS 基础设施）进行加密DNS。这些机制应允许对这些端点配置进行集中管理（如组策略、配置管理）。虽然这些配置可在端点部署或更新时静态应用，但各机构应考虑采用防止更改DNS配置或将未经授权的更改自动恢复到已知良好状态的机制。当端点在传统环境之外运行时，这些执行机制就显得尤为重要，因为它们可能会因有意或无意的错误配置而绕过DNS 保护。如果没有补偿控制，机构可能无法确定端点绕过了保护。当不使用某些功能时（如通过TLS 或 DOH实现的应用级DNS），必须通过组策略或其他方式明确禁用这些功能。

各机构应利用 CISA发送的 DNS周报，监控离开内部网络的DNS 流量，以识别错误配置、恶意端点和其他潜在异常情况。

DNS 加密会妨碍依赖访问未加密DNS 流量来获得可见性的现有网络解决方案。由于DNS 流量已加密，各机构将需要通过可从客户端和服务器端点获取DNS 活动可见性的解决方案来获得类似的可见性。这种基于端点的可视性要求加密的DNS 流量只能在授权客户端和机构具有可视性的服务器之间（例如，授权端点和机构内部DNS 服务器、机构内部DNS 服务器和保护DNS）。由于端点、端点位置和端点可用信息的多样性，机构可能需要整合多个来源的数据，以获得全面的可见性。