近日，美国网络安全和基础设施安全局（CISA)发布了加密域名系统(DNS)实施指南，供联邦民事机构满足与DNS流量加密相关的要求，并增强其IT网络的网络安全态势，以与美国联邦民事机构保持一致。管理和预算(OMB)备忘录M-22-09，推动美国政府走向零信任网络安全原则和国家网络安全战略。
传统上，DNS协议不支持确保信息请求或响应的机密性、完整性或真实性的方法。M-22-09 特别呼吁各机构在技术上可行的情况下对DNS 流量进行加密，同时法定要求要求各机构使用CISA 的保护性DNS 功能进行出口DNS 解析。本指南将帮助各机构针对机构网络、DNS基础设施、本地端点、云部署以及漫游、游牧和移动端点实施当前可行的技术功能。
执行摘要
本文件旨在为联邦机构提供实施指导，以满足管理和预算办公室(OMB) 备忘录M-22-091 中规定的与域名系统(DNS) 流量加密相关的联邦要求，并增强其IT 网络的网络安全态势。除其他要求外，备忘录还特别要求各机构在技术可行的情况下使用加密的DNS 流量。根据M-22-09 和《美国法典》第6 编第 663条注释 "机构责任"，各机构还必须在所有出口DNS 解析中使用CISA 的保护性DNS 功能。从广义上讲，本文件旨在指导机构网络从业人员并协助实施当前可行的技术能力，以帮助确保以下几点：
1.机构 DNS 基础设施使用 CISA 的保护 DNS 服务作为其上游提供商。
2.对机构网络进行配置，以防止终端设备和应用程序直接与第三方DNS 提供商通信，无论是使用传统DNS 协议还是新的加密DNS 协议。
3.在技术支持的情况下，机构DNS 基础设施支持在与机构端点通信时使用加密DNS。
4.机构漫游或游牧端点配置为通过机构内部DNS 基础设施或保护DNS（使用安全访问服务边缘(SASE) 和/或安全服务边缘(SSE) 或类似解决方案）解决端点DNS 请求。或者，机构可能会要求漫游或游牧端点通过VPN 进入机构环境，以确保它们执行适当的DNS 解析，但这可能会给这些端点带来性能问题。
5.在技术支持的情况下，机构云部署应配置为使用经授权的DNS 提供商（即机构内部DNS 基础设施或保护DNS）和加密的DNS 协议，并防止未经授权的DNS 流量流向第三方DNS 提供商。
6.机构内部端点已配置相关策略，以确保其应用程序和操作系统使用授权DNS 配置（即使用机构内部DNS 基础设施的加密DNS 或SASE/SSEE 解决方案），以及明确禁用应用程序级DNS 解析（除非使用机构内部DNS 基础设施）的策略。
为帮助机构人员了解要求并参与过渡工作，本文件提供了一系列资源：
一份实施清单，提供了所需变更的非优先级高层次视图，并按资产类别组织了单个行动项目。
分阶段实施建议，帮助确定实施清单的优先次序。
技术指导和参考资料，以支持清单中各项变更的实施。
本文件根据当前机构和供应商的情况，以及CISA 保护 DNS的现有功能，概述了满足要求的可能方法。
虽然本文件主要针对FCEB 机构，但其他组织可能会发现它是其自身零信任工作的有用资源。
1. 背景
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 产品还可以防止端点解析恶意域，从而保护联邦企业，帮助检测和减轻网络威胁。
01
假定和限制
CISA关于"解决联邦网络DNS解析问题"的备忘录鼓励使用加密DNS协议，而OMB的M-22-09备忘录则要求在技术支持的情况下使用加密DNS协议。
联邦机构必须将离开机构网络和设备的所有 DNS 流量路由到 CISA 的保护 DNS 功能。
保护性 DNS 和 DNS 加密不影响 .gov 域名的权威 DNS 托管。
本指南的重点是各机构根据当前的机构和供应商情况以及CISA保护性DNS的当前可用功能可以采取的可行行动。在此基础上，本指南提出了以下假设：
并非所有目前部署在 FCEB 网络上的技术都支持加密 DNS 协议，许多技术只支持传统的非加密 DNS 协议。
保护 DNS 只能由机构 DNS 解析基础设施（如内部 DNS 基础设施、云解析器、SASE/SSE 解析器）直接访问，（由于现有协议中缺乏验证机制）单个用户终端无法直接访问。
在机构外环境中运行的漫游和游牧端点无法直接访问机构内部 DNS 解析服务。
本指南不涉及机构权威 DNS 基础设施，也不涉及递归解析器与权威服务器之间的 DNS 流量。
如果这些假设对某个机构不成立，那么该机构可以采用与指南所述不同的方法来实现本指南的目标。如果机构选择了不同的方法，则需要确保该方法符合所有规定的目标。
2. 机构实施清单
本核对表提供了适用于联邦机构的当前要求和最佳实践的高级概览，涉及DNS 流量加密和使用CISA 的保护DNS 进行上游DNS 解析。执行这些步骤的详细指导可参见第3 节和附录A。
机构 DNS基础设施
机构 DNS 基础设施的配置是为了支持使用加密 DNS 协议的机构端点。
机构 DNS 基础设施使用保护 DNS 作为上游提供商。
机构 DNS 基础设施与保护 DNS 通信时使用加密 DNS 协议。
机构 DNS 基础设施已配置为禁用 DNS 根提示、DNS 优先级和任何其他可能导致基础设施绕过使用保护型 DNS 的机制。
可选：对机构 DNS 基础设施进行配置，以解析迫使未配置的应用程序禁用 DNS-over-HTTPS 的域（例如 Firefox 的金丝雀域）。
机构SASE/SSE 解决方案
机构 SASE/SSE 解决方案被配置为通过 SASE/SSE 解决方案发送所有设备 DNS 查询以进行解决。
机构 SASE/SSE 解决方案配置为在与机构端点通信时使用加密协议。
机构 SASE/SSE 解决方案被配置为通过 SASE/SSE 解决方案转发机构端点的所有 DNS 请求。
机构 SASE/SSE 解决方案在解析来自机构端点的 DNS 请求时，被配置为使用授权 DNS 提供商（即机构内部 DNS 基础设施或 CISA 的保护 DNS）。
机构 SASE/SSE 解决方案被配置为在解析来自机构端点的 DNS 请求时，禁用任何可能绕过使用授权 DNS 提供商的机制（如 DNS 根提示、循环转发），除非请求纯粹由 SASE/SSE 解决方案内部解析，或保护性 DNS 不可用。
机构内部端点
机构内部端点被配置为使用内部 DNS 基础设施（如内部缓存解析器）。
在技术支持的情况下，机构端点被配置为使用机构 DNS 基础设施的加密 DNS 协议。
拥有支持应用级 DNS 解析的应用程序的机构端点已进行适当配置，以便
o 使用适当配置的操作系统或SASE DNS 解析机制，而不是应用级DNS 解析，或
o 仅在内部或另行授权的DNS 基础设施上使用应用级加密DNS 解析。
对机构端点进行配置，以禁用未经授权的 DNS 配置，最好使用集中机制（如网域政策、配置管理系统）。
机构漫游和游牧终端
机构漫游（在机构外）和游牧端点被配置为使用：
o SASE/SSE 解决方案使用加密协议向授权DNS 提供商（即机构内部DNS 基础设施或保护DNS）发送 DNS请求，或
o VPN 解决方案，允许他们在SASE/SSE 解决方案不可用的情况下使用机构内部DNS 基础设施。
对机构端点进行配置，以禁用未经授权的 DNS 配置，最好是使用即使在端点无法访问机构企业服务的情况下也能执行该配置的机制。
机构网络
机构网络的配置只允许从授权的内部 DNS 服务器与外部第三方解析器通信。
机构网络配置为阻止所有未经授权的出口和入口 DNS 流量，包括
o 传统的未加密 DNS：机构可阻止通过 53 端口的流量，动态方法可允许以独立于端口的方式阻止传统的未加密DNS。
o DNS-over-TLS：各机构可通过端口853 阻止流量，动态方法可允许以独立于端口的方式阻止DNS-over-TLS。
o DNS-over-QUIC：各机构可通过端口853 阻止流量，动态方法可允许以独立于端口的方式阻止DNS-over-TLS。
o DNS-over-HTTPS：各机构可阻止通过443 端口传输到外部知名DNS-over-HTTPS提供商的流量，但应考虑采用可阻止与目的地无关的流量的机制（如断点续传、零信任网络架构）。
机构云部署
在技术支持的情况下，机构云部署可直接或通过 SASE/SSE 解决方案配置使用保护 DNS 作为上游提供商。
机构云部署在技术支持的情况下，可直接或通过 SASE/SSE 解决方案配置为使用加密 DNS 协议进行上游解析。
机构云部署在技术支持的情况下配置为阻止所有未经授权的 DNS 流量。
机构云部署配置为禁用未授权的 DNS 配置，最好使用自动机制（如域政策、配置管理系统）。
01
分阶段实施
鉴于将现有机构企业过渡到使用加密DNS和保护性DNS的复杂性，机构可以考虑分阶段实施，随着时间的推移过渡其企业的一部分。虽然机构的考虑因素将推动最佳方法的制定，但机构应优先考虑防止使用未经授权的DNS提供商、实施保护性DNS保护以及为漫游和游牧端点加密DNS。
分阶段的方法如下：
第 1 阶段：使用保护性 DNS - 机构将其内部 DNS 基础设施配置为使用保护性 DNS 作为上游 DNS 提供商。机构将其 SASE/SSE 解决方案配置为使用保护 DNS 或机构内部 DNS 基础设施作为上游 DNS 提供商。机构将其基础设施即服务部署配置为使用保护性 DNS 或机构内部 DNS 基础设施作为上游 DNS 提供商。考虑到现有的法定要求，所有 FCEB 机构应该已经实施了第 1 阶段的要求。
第 2 阶段：阻止未经授权的 DNS 流量 - 机构对其网络和安全 Web 网关进行配置，以阻止传统未加密 DNS 的 DNS 流量以及与未经授权端点之间的新加密 DNS 协议的 DNS 流量。机构使用集中配置管理来配置机构内部端点和应用程序（如 Web 浏览器），使其仅使用机构内部 DNS 基础设施，禁用任何可能与未经授权的 DNS 提供商一起使用加密 DNS 的配置。
第 3 阶段：使用保护性 DNS 加密 DNS 流量 - 机构配置其内部 DNS 基础设施和 SASE/SSE 解决方案，以便在与作为上游提供商的保护性 DNS 通信时使用加密 DNS。
第 4 阶段：为漫游和游牧端点加密 DNS - 机构将其漫游和游牧端点配置为使用 SASE/SSE 解决方案，通过授权 DNS 提供商（即保护 DNS 或机构内部 DNS 基础设施）解析所有 DNS 请求。即使漫游和游牧端点无法访问机构企业服务，机构也会使用配置管理解决方案为这些端点执行适当的安全 DNS 配置。
第 5 阶段：加密云部署中的 DNS 流量 - 机构将其云部署配置为使用加密 DNS，通过授权 DNS 提供商（即保护 DNS 或机构内部 DNS 基础架构）解析所有 DNS 请求。
第 6 阶段： 加密内部部署端点的 DNS 流量 - 机构配置其内部 DNS 基础设施，以支持使用加密 DNS 协议接收 DNS 请求。机构配置其内部端点（在技术支持的情况下），以便与机构内部 DNS 基础设施一起使用加密 DNS 协议。或者，机构可将其内部端点配置为使用 SASE/SSE 解决方案，类似于其漫游和游牧端点。
3. 实施指南
以下小节介绍了相关技术的背景和M-22-09 的要求，以及实施加密DNS 和使用CISA 保护 DNS服务的更详细指导。
01
加密DNS
加密 DNS旨在确保客户端和服务器之间DNS 流量的保密性和完整性。现有的加密DNS 协议提供客户机-服务器和服务器-服务器流量保护，但不提供客户机与特定域的DNS 授权服务器之间的端到端加密。DNSSEC是 DNS的协议扩展，可验证域名信息的真实性和完整性，它与加密DNS 截然不同，不属于本文档的讨论范围。
加密 DNS流量的方法多种多样，现成的软件和硬件支持程度也各不相同：
DNS-over-HTTPS: DNS-over-HTTPS 是一种得到广泛支持的协议，可实现 DNS 加密。该协议使用现有网络协议作为传输机制，便于在现有网络中使用，也可通过代理服务器使用。不过，这种对现有网络协议的使用会与其他网络流量混为一体，因此比传统 DNS 和其他加密 DNS 协议更难监控和阻止。
DNS-over-TLS ：DNS-over-TLS 是另一种标准协议，它将 DNS 协议封装在标准 TLS 会话中，使用专门分配给 DNS-over-TLS 的明确定义端口 853。不过，可能需要对代理服务器进行配置，以支持通过新端口传输新的流量类型。
DNS-over-QUIC: DNS-over-QUIC 是使用 QUIC 传输协议的最新加密 DNS 协议。虽然它同样使用了现有的网络流量协议，但与 DNS-over-HTTPS 相比，DNS-over-QUIC 目前只得到了更有限的供应商解决方案和服务的支持。
03
保护性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 的方法
通过机构 DNS 基础设施访问：机构将其内部 DNS 基础设施（即内部缓存解析器）配置为使用保护 DNS 作为 DNS 解析的上游提供商，终端使用这些内部 DNS 服务器。除了支持传统的内部环境外，这种模式还支持其他机构环境（如云部署）。
虽然漫游或游牧端点有可能通过VPN进入传统机构环境并使用这些服务器，但这种方法会给这些端点带来性能问题。各机构应考虑采用其他方法，使漫游或游牧端点能够使用保护DNS，而无需连接到传统的机构内部环境。
通过机构 SASE/SSE 访问：越来越多的机构正在部署 SASE/SSE 服务，其端点可使用这些服务进行外部访问，包括 DNS 解析。SASE/SSE 服务可以配置为使用保护 DNS 或机构内部 DNS 基础设施来解析域。这种模式可使保护 DNS 的使用与网络位置无关，便于漫游或游牧终端使用。
此外，如果 SASE/SSE解决方案使用机构内部DNS 基础设施来解析域名，漫游和游牧终端将能够解析机构内部域名和其他未公开发布的资源。各机构需要与SASE/SSE 提供商合作，确保所有来自终端的DNS 流量都被路由到提供商，并确保提供商使用适当的DNS 服务和加密协议来解析这些请求。
内部资源
保护性 DNS只能解析公开可用的地址。机构可能拥有只能通过内部DNS 服务器解析的服务或其他资源（如内部应用程序、Microsoft Active Directory 资源），绕过这些内部DNS 服务器的机构端点将无法解析这些资源。
在技术可行的情况下，各机构可考虑将机构内部资源公开寻址。这种方法符合联邦零信任战略，并可确保机构端点能够解析这些服务，而不受其域名解析方式的影响。或者，机构可考虑使用SASE/SSE 解决方案使端点能够访问其内部资源，而不要求资源可公开寻址。在这些情况下，机构应通过SASE/SSE 解决方案提供这些资源，而与端点的部署位置无关。虽然这种模式更符合"零信任"原则，但各机构需要了解并考虑任何可能与SASE/SSE 解决方案不兼容的潜在遗留用途。
机构还可以考虑让漫游或游牧端点连接到机构环境来访问这些内部资源（例如，通过VPN连接到内部环境）。但是，不建议采用这种方法，因为用户的所有网络流量都需要通过机构环境进行路由，这可能会给用户带来性能和可用性问题。
03
机构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 协议进行任何DNS 通信的情况下，他们需要了解并考虑到这种通信缺乏保密性或完整性。
为满足 M-22-09的加密 DNS要求，使用外部加密机制（如通过IPsec 隧道传输未加密的DNS:53 流量）不能取代加密DNS 协议。
保护性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 不会影响这些配置的运行。
04
机构SASE/SSE 解决方案
许多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 配置进行更改，或将未经授权的更改自动恢复到已知的良好状态。
05
机构端点
为满足M-22-09 的要求，机构端点需要在技术可行的情况下使用加密协议来解决其DNS 查询，并且只能使用授权的DNS 提供商（即机构内部DNS 基础设施或保护DNS），无论其在内部环境、云环境、游牧环境或漫游环境中运行。此外，应用程序和操作系统可能会在默认情况下以绕过机构和CISA DNS 保护的方式启用加密DNS。各机构需要明确配置其端点和应用程序，禁用这些加密DNS 协议，或使用授权配置来解析使用加密协议的DNS 查询。各机构还需要在更新应用程序或操作系统时维护这些配置。
加密 DNS支持
应用程序和操作系统已开始支持使用加密DNS 协议。附录A 包括实施指南，其中讨论了目前支持加密DNS 协议的具体产品。不过，从高层次来看，配置端点使用加密DNS 协议的方法包括：
操作系统支持： 操作系统开始包含对加密 DNS 协议的本机支持。本机支持可简化配置，减少操作系统升级对端点 DNS 配置的影响。
SASE/SSE 解决方案： 如上一节所述，SASE/SSE 解决方案可支持使用加密通信，通过授权 DNS 提供商（即授权机构内部 DNS 基础设施、保护 DNS）解决端点 DNS 查询。这些解决方案可支持操作系统不包含本机支持的端点。此外，这些解决方案还能为各终端提供更加统一的支持，使各机构能够使用单一配置，而不受终端操作系统版本的影响。
网络浏览器/应用程序支持： 网络浏览器和其他应用程序可能支持 DNS 加密。不过，这种方法只能为特定网络浏览器或应用程序的 DNS 解析提供保护，而端点上的其他应用程序和底层操作系统则不受保护。此外，由于应用级 DNS 解析可能会绕过操作系统或 SASE/SSE DNS 解析及相关保护，因此在使用其他加密 DNS 选项时，应明确禁用应用级加密 DNS 解析。
应用程序和操作系统对加密DNS 的支持通常包括默认配置，即当加密DNS 查询失败时，使用传统的未加密DNS 协议重试DNS 请求。此外，实施可能会寻找网络的某些特征来决定是否降级为未加密DNS。各机构需要确保对其终端进行配置，以明确禁用降级为未加密DNS 的功能，从而确保恶意实体无法迫使它们使用不安全的协议。
应用程序和操作系统对加密DNS 的支持通常带有软件配置选项（包括潜在的默认配置），可绕过本地DNS 配置使用已知支持加密DNS 协议的外部提供商。机构需要防止端点通过直接访问未经授权的DNS 提供商（如第三方公共提供商）来绕过DNS 保护。除了直接阻止未经授权的提供商使用加密DNS协议外，各机构还需要配置端点以禁用此类配置，并应使用全企业范围的策略来确保全面执行。由于新软件和更新软件可能包括启用加密DNS 协议的新配置，各机构将需要一个流程来跟踪其部署的软件（包括操作系统和应用程序）对加密DNS 的支持情况，以确保为其端点提供适当的配置。
保护性DNS支持
端点可通过机构内部DNS 基础设施或SASE/SSE 解决方案进行配置，以使用保护性DNS 保护。
通过机构 DNS 基础设施： 可以将端点配置为使用机构内部 DNS 基础设施，进而使用保护型 DNS。通过使用机构内部 DNS 基础设施，端点将能够解析机构内部资源（如内部应用程序、Microsoft Active Directory 资源）。虽然这种配置对永久驻留在内部环境中的端点有效，但它要求漫游和游牧端点通过 VPN 接入机构环境，这可能会给这些端点带来性能问题。
通过 SASE/SSE：可将端点配置为使用保护 DNS 的 SASE/SSE 解决方案。SASE/SSE 解决方案可让机构端点使用保护性 DNS，而不受游牧、漫游、移动设备、内部部署或云部署的影响。这种位置独立性对于可能在不同环境间移动的端点（如漫游端点、移动设备）尤其有帮助。如果机构拥有终端需要能够解析的内部资源，则机构需要确保 SASE/SSE 解决方案使用机构内部 DNS 基础设施作为上游提供商。
06
云部署
云提供商和服务对如何执行DNS解析提供不同程度的控制，各机构需要了解可用的配置机会。虽然具体选项取决于云提供商及其提供的特定服务，但以下内容提供了常用选项的高级概览：
基础设施即服务（IaaS）： 机构可以对其 IaaS 部署进行配置，以便将部署中端点的所有外部 DNS 流量发送到使用加密 DNS 协议的授权 DNS 提供商（即保护 DNS 或机构 DNS 基础设施）。或者，机构也可以配置端点（如虚拟机）直接使用授权 DNS 提供商的加密 DNS 协议。
平台即服务 (PaaS)： PaaS 端点的 DNS 通常作为 PaaS 基础架构的一部分进行管理。在这种情况下，可以配置 PaaS 基础架构，将外部资源的 DNS 查询转发给授权的 DNS 提供商（即保护 DNS 或机构 DNS 基础架构）进行解析。或者，PaaS 端点（如容器）可以直接使用授权 DNS 提供商的加密 DNS 协议。
软件即服务 (SaaS)： 机构对 SaaS 部署中如何执行 DNS 的控制可能有限。通常情况下，这些部署将使用云提供商的 DNS 解决方案，机构需要了解并考虑这些服务所提供的保护和可见性方面的任何潜在差异。
云部署可能包括各种云服务，每个部署都是一个独特的用例。例如，机构部署的网络服务可能由身份即服务（Identity-as-a-Service）解决方案组成，用于管理部署内的身份；网络应用防火墙即服务（Web Application Firewall-as-a-Service）解决方案用于管理对网络服务的访问；网络服务的PaaS 和 IaaS解决方案的混合；以及数据库即服务（Database-as-a-Service）解决方案用于存储数据。在这些情况下，机构可能只能为其整体云部署的一部分配置DNS解析。机构需要了解并考虑这些差异，以确保提供相应级别的保护和可视性。例如，网络服务部署可能会确保所有外部域在进入云部署之前都已解析，并且部署仅使用内部地址进行通信。
07
防止未经授权的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 端口（如53、853）传输的TCP 和UDP 流量来部分实现，这些流量的目的地不是授权提供商。不过，由于DNS-over-HTTPS使用的是普通端口和协议，因此可能需要使用其他方法来阻止这些流量。如果各机构已启用"断点续传"机制（无论是在内部部署还是通过SASE/SSE 服务），就有可能直接阻止指向未授权提供商的DNS-over-HTTPS 流量。但是，如果不使用"断点续传"功能，机构可能需要使用其他机制来阻止此类流量（例如，阻止与知名DNS-over-HTTPS 提供商的通信）。
对于允许访客用户终端的访客无线网络等环境，各机构应遵循相同的指导来阻止未经授权的流量，并将所有出口DNS 流量路由到保护性DNS。此外，访客网络应将所有流量隔离到专用IP范围，以便安全设备和分析人员能够轻松区分访客网络流量和机构企业网络流量。
08
可见性
DNS 加密会妨碍依赖访问未加密DNS 流量来获得可见性的现有网络解决方案。由于DNS 流量已加密，各机构将需要通过可从客户端和服务器端点获取DNS 活动可见性的解决方案来获得类似的可见性。这种基于端点的可视性要求加密的DNS 流量只能在授权客户端和机构具有可视性的服务器之间（例如，授权端点和机构内部DNS 服务器、机构内部DNS 服务器和保护DNS）。由于端点、端点位置和端点可用信息的多样性，机构可能需要整合多个来源的数据，以获得全面的可见性。
保护性 DNS 日志：保护性 DNS 日志可提供机构缓存解析器进行的所有 DNS 查询和相关响应的信息。虽然这些日志可以提供机构域名解析的总体情况，但机构可能需要更多的上下文来确定发出请求的具体端点。
机构 DNS 服务器日志：机构 DNS 服务器日志可以提供机构内部端点以及连接到机构内部环境的漫游或游牧端点执行的 DNS 解析的可见性。但是，由于漫游、游牧或云端点可能会使用绕过机构 DNS 服务器的 DNS 解析方法，因此这些日志可能无法提供全面的可见性。
SASE/SSE 日志：SASE/SSE 日志可提供使用 SASE/SSE 的端点所执行的 DNS 解析的可见性，无论这些端点是在内部还是远程。在整个企业使用通用解决方案的情况下，SASE/SSE 解决方案可提供跨机构端点的统一可见性。但是，配置不当的漫游、游牧或传统端点可能会绕过 SASE/SSE 解决方案，从而限制机构的可见性。
设备日志：无论是通过端点检测和响应 (EDR)、移动设备管理 (MDM) 还是其他解决方案获取的设备日志，都可以提供设备执行的域名解析的可见性。虽然许多解决方案都提供或可以访问 DNS 信息，但根据设备类型（如移动设备与工作站）的不同，通过这些解决方案获得的信息也会有很大差异。此外，由于这些日志是由设备提供的，因此从设备接收信息时可能会出现延迟，或配置错误的设备无法提供信息；而且，如果恶意实体入侵了设备，他们可能会限制或破坏从设备发送的信息。
云日志： 云提供商的日志可能会提供有关机构云部署执行的 DNS 解析的信息。对于某些云环境，可能会有机构端点执行的 DNS 解析的直接日志。但是，对于某些环境或部署，可能没有托管服务执行的 DNS 解析的直接日志。在这些情况下，机构可能需要从其他日志（例如，云部署进行的包含 DNS 名称的连接日志）中重建 DNS 解析。
声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
