2026-10-21 08:02:33 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

cover_image

安全 DNS 部署指南

原创

钟智强
钟智强

哪吒网络安全

2026年7月26日 22:31
马来西亚

在小说阅读器读本章

去阅读


导读 DNS 是每一个企业网络架构不可或缺的组成部分。针对企业 DNS 基础设施的攻击，会威胁到该企业的每一项网络运营。本指南面向两类读者——网络安全决策者与一线网络/安全运营团队——系统讲解如何在零信任与纵深防御框架下，把 DNS 从「纯运营组件」升级为「基础安全控制层」。本文为 NIST SP 800-81r3 的完整中文精译，涵盖保护性 DNS、权威服务、递归/转发服务、存根解析器四大主题，并附 DNS 协议教程与术语表。全部 4 张原图已按中文重绘。

导读 DNS 是每一个企业网络架构不可或缺的组成部分。针对企业 DNS 基础设施的攻击，会威胁到该企业的每一项网络运营。本指南面向两类读者——网络安全决策者与一线网络/安全运营团队——系统讲解如何在零信任与纵深防御框架下，把 DNS 从「纯运营组件」升级为「基础安全控制层」。本文为 NIST SP 800-81r3 的完整中文精译，涵盖保护性 DNS、权威服务、递归/转发服务、存根解析器四大主题，并附 DNS 协议教程与术语表。全部 4 张原图已按中文重绘。

执行摘要

域名系统（DNS）是一种把人类可读的域名（如 example.com）映射到机器可读信息（如 IP 地址 192.0.2.1）的标准化机制。它被广泛部署于组织内网以支撑内部功能，也在互联网关键基础设施中维护，支撑几乎每个网络、每种规模下互联网的核心功能。

DNS 所处的中心位置，使它能够在零信任与纵深防御风险管理方法中充当网络安全的基础层。这类具备安全能力的 DNS 服务通常被称为「保护性 DNS（protective DNS）」部署，是保护组织网络的关键考量。DNS 基础设施已不再只是一项服务，它同时是一种可以成为企业安全架构重要组成部分的安全控制。

本版指南承认了 DNS 角色的这一转变，并为现代 DNS 部署提供如下高层建议，供网络与安全负责人参考：


五条高层建议 ① 在技术可行处普遍部署保护性 DNS，以获得覆盖全网的额外安全能力：实时阻断有害/恶意流量；过滤不符合组织策略的流量类别；生成实时与历史 DNS 查询/响应数据以支撑数字取证与事件响应（DFIR）；作为纵深防御/零信任的一环与更广的安全生态集成；协助满足对违规站点（如版权、法律限制）的阻断合规要求。 ② 在可行处对内外部 DNS 流量加密。 ③ 部署 DNSSEC 以保护 DNS 数据的完整性。 ④ 部署专用 DNS 服务器以缩减攻击面。 ⑤ 遵循全部技术指引，使 DNS 部署与协议尽可能安全、有弹性。

五条高层建议 ① 在技术可行处普遍部署保护性 DNS，以获得覆盖全网的额外安全能力：实时阻断有害/恶意流量；过滤不符合组织策略的流量类别；生成实时与历史 DNS 查询/响应数据以支撑数字取证与事件响应（DFIR）；作为纵深防御/零信任的一环与更广的安全生态集成；协助满足对违规站点（如版权、法律限制）的阻断合规要求。 ② 在可行处对内外部 DNS 流量加密。 ③ 部署 DNSSEC 以保护 DNS 数据的完整性。 ④ 部署专用 DNS 服务器以缩减攻击面。 ⑤ 遵循全部技术指引，使 DNS 部署与协议尽可能安全、有弹性。

一、引言

本文提供 DNS 部署指南，用以保护 DNS 协议与服务器、缓解滥用与失陷的影响，并将 DNS 用作贯穿全组织的基础安全控制层。以下先简述 DNS 的相关背景，再审视促成本次更新的威胁态势变化。

1.1　域名系统

从用户视角看，互联网上每个节点或资源都由唯一的域名标识；但从网络组件视角看，唯一的资源标识符是 IP 地址（IPv4 或 IPv6）。通过域名而非 IP 访问资源需要一套翻译系统，这正是 DNS 的首要任务，该过程称为「名称解析」。

DNS 最初仅聚焦于为互联网资源提供名称解析；随着基础设施演进，其范围已扩展到私有网络内部的域名翻译。今天的 DNS 部署必须同时为互联网地址与私网地址提供解析，使终端能够无缝访问内外部资源。在现代组织中，DNS 是互联网运营的核心与关键：几乎所有请求与连接都依赖它，因此必须正确配置、安全管理。一旦命名空间或服务器被恶意者控制，DNS 便可能成为进一步入侵的威胁向量。

与此同时，DNS 的中心地位也使它能被用来保护组织的其余部分——DNS 服务器能洞察终端的连接与数据流，往往能比其他系统更早阻止安全事件。因此，本文将 DNS 作为组织网络防御的一个基础层来给出指引。

1.2　DNS 对网络弹性、纵深防御与零信任的影响

DNS 基础设施是任务关键的：一旦失效，整个网络及其应用都会不可用或直接停摆。作为数字弹性的关键要素，DNS 应被定期评估或重新评估。

近年网络安全最佳实践越发强调「纵深防御」——即没有任何单一防御措施是万无一失的，最好的防御来自多层保护。这种风格更灵活、可扩展、更具弹性，也更契合零信任原则（假设任何元素、节点或服务都不能被隐式信任）。然而，DNS 在零信任战略中常被忽视，一旦被隐式信任便会形成显著缺口。组织应利用 DNS 来强制安全策略、阻止访问恶意/未授权资源，并为 DFIR 提供资产可见性。

零信任意味着从「以位置为中心」转向「以身份、上下文、数据为中心」的细粒度控制。由于 DNS 解析可能对查询公共域名的终端开放，组织应保护 DNS，防止它被用作绕过零信任控制的通道——例如部署保护性 DNS，或针对特定终端类别设定专门的解析器配置。DNS 也是可用于访问决策的富化数据来源：查询日志可纳入威胁检测计划，DNS 服务既是策略决策点/策略创建的信息源，也是策略强制点。

1.2.1　OT、IoT 与关键基础设施中的 DNS 用例

作为互联网基础设施中无处不在的一环，DNS 也存在于难以采用更高级安全范式的场景，尤其是制造业、关键基础设施与物联网（IoT）中的运营技术（OT）。这些设备常因算力低、位置或可达性受限、定制化设计、老旧遗留软件、极高可用性要求等难以防护。

DNS 服务能在不影响 IP 网络运营设备的前提下，提供额外的安全与监控层。这种在既有策略之上「叠加」的风险缓解，是迈向完整纵深防御的一步，也是关键基础设施等高可用数字化服务的首选路径。可选手段包括：利用保护性 DNS 的能力；实施高度受限的 DNS 防火墙，把 OT/IoT 设备的通信限制在其安全运行所必需的系统范围内。

1.3 ~ 1.5　使用方式、读者与目标

●文档结构：第 2 节讲 DNS 作为安全架构组件的建议；第 3 节讲权威服务的威胁与防护；第 4 节讲递归服务；第 5 节讲存根解析器。

●目标读者：① 网络安全高管、决策者与策略制定者（对应第 1、2 节的高层背景与影响分析）；② 一线网络与安全运营团队（对应其余技术章节）。

●目标：为支撑企业运营的 DNS 基础设施（数据与协议）提供安全指引，并阐明其在整体安全态势中的角色，包括部署保护性 DNS、用 DNSSEC 保护数据完整性、用安全传输层保护查询/响应事务。

二、DNS 作为组织安全战略的组成部分

DNS 对网络连接至关重要，其普遍部署使它成为一种有效的安全机制：网络上各类客户端（本地、云端、IoT）都已在使用它，因此任何由 DNS 基础设施提供的保护都会惠及所有依赖它做名称解析的客户端。

在典型通信中，第一步就是用 DNS 把目标域名解析为 IP，解析完成前通信无法开始。CISA 指出「DNS 基础设施是攻击活动常见的威胁向量」。即便 DNS 流量被加密，系统仍需保留互联网访问，这让恶意者得以搭建用于命令控制（C2）与数据渗漏的权威服务器——此时加密反而对其有利。因此必须对安全解析器实施严格控制与审计，只允许具备恰当策略配置的解析器与互联网通信。

使用 DNS 的另两大优势是规模与效率：DNS 经数十年演进已能支撑互联网级的海量客户端；由于查询先于通信流发生，用 DNS 强制策略可在恶意/可疑通信流启动前将其阻断，从而减少全网未授权流量，减轻防火墙、SOC 等其他安全要素的负担。

2.1　保护性 DNS（Protective DNS）

保护性 DNS 是一种增强了安全能力的 DNS 服务，用于分析查询与响应并采取行动缓解威胁：阻断对恶意网站的访问，阻止恶意软件、勒索软件、钓鱼等攻击的投递。它可以由厂商以服务形式提供、部署在内部基础设施上，或二者结合。


混合部署的价值云端服务通常能利用更大规模的威胁情报、提供更实时的分析；但若云服务不可用，配置为「失败开放」（回退到普通递归解析）的组织会希望本地也具备保护性 DNS 能力以确保防护。因此在可行处应采用这种云 + 本地的混合方案。

部署保护性 DNS 的目标包括：把 DNS 服务用作策略强制点（PEP），在域名解析这一环节实时阻断有害流量（通常在恶意活动开始前），并防止 DNS 协议被滥用（如经 DNS 渗漏数据）；按类别阻断流量；把 DNS 用作改善零信任态势的信息源；作为纵深防御的一环与更广安全生态集成；协助满足对违规站点阻断的合规要求。

2.1.1　威胁情报与遥测

随着新网络技术涌现、攻击面演变，DNS 始终是保护各类环境用户、监控并中断恶意通信的恒定控制点。它不局限于单一威胁类型，常能在复杂的多阶段攻击推进前将其阻断，也能防护钓鱼、勒索、数据渗漏带来的诈骗或凭证窃取。

这一方法要求把威胁情报集成进 DNS 解析器。情报最有效的落地方式是通过 DNS 防火墙：从静态/动态阻断列表到响应策略区（RPZ），可经不同架构无缝接入解析链。此外还可用 DNS 阻断列表（DNSBL）或信誉阻断列表（RBL）发布威胁信息供客户端决策。二者最大区别在于：DNSBL/RBL 在客户端（如邮件服务器软件）执行，而 RPZ 在 DNS 基础设施内执行——因此无论客户端功能如何，RPZ 都能提供保护。

2.1.2　名称解析过滤

名称解析过滤指对 DNS 解析施加安全相关策略的基础设施。例如，保护性 DNS 可拒绝解析已知用于钓鱼或标识恶意 C2 的域名，转而返回诸如 NXDOMAIN（「域名不存在」）之类的响应，并记录触发策略的查询以提示潜在感染。

保护性 DNS 通常通过在本地 DNS 服务、云端安全递归服务或二者组合上配置 DNS 防火墙/RPZ 实现。就本地 RPZ 部署而言，有两种典型模型：靠近客户端或靠近互联网。靠近互联网可实现最集中的部署、控制成本，但牺牲客户端可见性；靠近客户端能最大程度将活动归因到单个客户端，但成本更高或每设备可用情报更少。图 1 展示了一个采用云服务、同时为内网主机保留本地转发器的企业示例。

图 1　企业使用云端保护性 DNS + 本地转发器

DNS 防火墙允许管理员指定由 DNS 服务强制的安全策略（如过滤特定域名或 IP）。许多安全组织提供威胁数据「订阅源」以动态更新防火墙/RPZ；组织可把自己的名称服务器配置为 RPZ 的二级服务器，自动同步最新威胁信息。本地部署的 DNS 防火墙（或本地管理的 RPZ）具备低时延、高存活性、性能影响小等优点，能在数分钟内跨整个网络缓解威胁。

互联网上也有安全递归 DNS 服务，组织可将互联网域名查询转发给它们。为覆盖最全，保护性 DNS 应能分析所有记录类型（如 MX、SOA、TXT）。云方案在可扩展性、存储与算力上更强，但存在保密性下降、时延更高、查询来源归因困难等劣势。组织可组合使用二者，以兼得本地的低时延与云端的可扩展性。

2.1.3　DNS 用于数字取证与事件响应（DFIR）

政府机构与受监管企业应实施健全的 DNS 流量日志机制以满足合规。日志应同时捕获当前与历史流量，并与其他系统日志集成，以便与云工作负载、设备或用户活动关联，增强可见性与可审计性。

全量记录 DNS 流量可能耗费资源，若处理不当会影响 DNS 服务的性能与可用性。可考虑云方案、高效日志格式（如 DNSTAP）或选择性记录。但被保护性 DNS 判定为恶意/未授权的域名，其查询与响应应始终记录。组织可在送入 SIEM 前移除已知安全域名的条目以降本，但应保留完整日志以备取证。此外，将 IP 映射到失陷资产还需实时跟踪可归因元数据及其分配历史（如 DHCP 租约历史），并把保护性 DNS 日志接入 SIEM 或日志分析平台以实现快速告警。

2.2　保护 DNS 协议

DNS 是必须保持开放以支撑互联网连接的基础服务，因而被威胁者用作发送恶意软件、渗漏数据、与 C2 通信的战略载体。IETF 早期发布过主要聚焦查询/响应角色的 DNS 威胁模型，但还有其他方面需要额外防护。

若组成某服务的一台或多台 DNS 服务器失陷，服务本身即告失陷，且往往能规避检测地对客户端造成短期或长期损害。硬化服务部署至关重要，其中有三个同等重要的要素：

●① 保护内外部的权威与递归 DNS 服务免受威胁；

●② 使用加密 DNS 与认证保护隐私与保密性；

●③ 使用 DNSSEC 保护 DNS 数据的完整性与真实性。

DNSSEC 是一套用于保护 DNS 协议通信免遭破坏的标准化扩展，是更广义 DNS 安全的一部分，应与其他最佳实践与协议特性一同实施。DNSSEC 能提供完整性保护，但不提供保密/隐私保护——后者由 DoT、DoH、DoQ 等技术提供（见 4.2.1）。对消息来源与完整性的认证则由事务签名（TSIG，基于 HMAC）实现；HMAC 见 RFC 6151 与 FIPS 198-1，TSIG 的 HMAC 见 RFC 8945。


DNS 卫生与最佳实践威胁者可利用配置错误与失效的域名/名称服务器注册来严重破坏 DNS 完整性。组织应建立健全流程，持续监控与校验其公共域名的完整性，并提升对「冒充本组织域名」企图的可见性。第 3 节将深入拆解因缺乏 DNS 卫生而产生的威胁及最佳防护。

2.3　保护 DNS 服务与基础设施

DNS 软件必须运行在既有主机平台上（硬件、固件、软件）。任一环节失陷都可能危及 DNS 服务并级联为重大运营故障或完整性/保密性损失。可能危及主机、平台或软件的失陷示例包括：

●平台/组件漏洞：操作系统、系统软件或主机上其他应用可能被攻击，导致解析服务拒绝，或（云端场景下）威胁到虚拟机监控程序或底层云基础设施。

●拒绝服务：大量查询发起 DoS，或借助众多第三方 DNS 服务器发起 DDoS；资源耗尽型攻击不依赖查询量，而以消耗大量处理器/内存的查询致服务降级或失效。

●未授权配置变更：平台级配置文件因保护不足被破坏或未授权修改，可致 DNS 主机间通信中断乃至服务完全失效。

保护平台与主机意味着遵循相关最佳实践安全地部署 DNS 所依赖的非 DNS 组件（如安全配置操作系统、厘清硬件供应链）。这些超出本文范围，但组织应精心规划网络的高层架构以保护 DNS 等高关键性要素，并为 DNS 服务器提供健壮、安全的网络连通性以确保正常运行。

2.3.1　专用 DNS 服务

攻击者会攻击任务关键系统（尤其承载多个关键组件的目标）以最大化事件破坏。为保证弹性，应限制多个任务关键服务共存于单一系统（职责分离）。即便 DNS 运行在安全的操作系统上，同机其他软件的漏洞也可能危及其安全与可用性。因此承载 DNS 的基础设施应专用于该任务并加以硬化，以缩减攻击面、确保资源充足，并为日志、加密 DNS、保护性 DNS 等留出容量。若无法完全专用，纳入 DHCP 等相关核心服务可能是合适的折中。


权威 vs 递归：分离部署权威名称服务器从自身区域文件/数据库产出资源记录（RR），应关闭递归；递归功能则从缓存或向其他服务器查询来提供解析，应限制接受查询的客户端数量与位置。二者应在不同安全策略下运行以缓解缓存投毒等攻击。任何可从互联网直接访问、或直接访问互联网的实例，应配置为权威或递归其一，而非兼任；仅内网可达的服务器则常同时承担两者（托管内部区域数据并为客户端提供递归），此时合并是可接受且实用的。此外应把权威服务器按客户端与数据类型分为公私两组：外部服务器置于 DMZ/公有托管、仅对外部客户端可见、服务面向互联网的区域；内部服务器置于防火墙边界内、对外不可达。未被指定为名称服务器的主机不应运行/存在 DNS 软件——安全审计时应从非名称服务器主机上移除 DNS 服务端实现。

权威 vs 递归：分离部署权威名称服务器从自身区域文件/数据库产出资源记录（RR），应关闭递归；递归功能则从缓存或向其他服务器查询来提供解析，应限制接受查询的客户端数量与位置。二者应在不同安全策略下运行以缓解缓存投毒等攻击。任何可从互联网直接访问、或直接访问互联网的实例，应配置为权威或递归其一，而非兼任；仅内网可达的服务器则常同时承担两者（托管内部区域数据并为客户端提供递归），此时合并是可接受且实用的。此外应把权威服务器按客户端与数据类型分为公私两组：外部服务器置于 DMZ/公有托管、仅对外部客户端可见、服务面向互联网的区域；内部服务器置于防火墙边界内、对外不可达。未被指定为名称服务器的主机不应运行/存在 DNS 软件——安全审计时应从非名称服务器主机上移除 DNS 服务端实现。

2.3.2　DNS 服务器的弹性与高可用

作为关键服务，DNS 服务器应尽量做到有弹性、高可用，以保障业务连续性——可通过网络与地理分散、以及服务器备份与恢复的最佳实践实现。每个区域必须有一台权威主服务器和一台或多台权威从服务器；组织至少应有两台权威服务器位于不同网段，并在地理上分散（不同物理站点），例如部分在自有场地、部分在托管服务或合作组织，或依赖云托管 DNS。

若由组织自托管区域信息，管理员应使用「隐藏主（hidden primary）」权威服务器，网络上只暴露从服务器。隐藏主不出现在区域的 NS RRset 中；所有对外可见的名称服务器实际都是从服务器（通过区域传送或数据库复制持有区域数据副本），从而避免攻击者定位主服务器。隐藏主应只接受来自指定从服务器集合的区域传送请求，并拒绝其他所有区域传送请求（理想情况下也拒绝其他 DNS 查询）。

2.3.3　保护性 DNS 生态的互操作性

部署保护性 DNS 时，须确保它与更广安全生态互操作，使其对整体安全模型是「加分项」而非孤立控制。这包括：确保 DNS 服务是纵深防御的一部分；将查询/响应数据与阻断/重定向记录经 SIEM/SOAR 上报以便与其他安全事件关联；能经 API 访问部署在保护性 DNS 中的威胁情报供评估与 DFIR 使用；确保各组件使用符合 IETF RFC 的标准化、可互操作协议与 API；向生态其他组件共享与转发相关 DNS 数据。

三、管理对权威服务的威胁

权威 DNS 服务器的首要职责是回答其权威区域的查询。这些服务器含有区域文件，内含名称到地址映射（IPv4 的 A 记录、IPv6 的 AAAA 记录）或地址到名称映射（PTR 记录）。权威角色可面向外部（互联网）客户端、内部客户端或两者。注意：某些虚拟化平台（如 Kubernetes）有自己的内部 DNS，通常不作为委派区域挂接到全局 DNS，此时以下建议可能不适用。

权威名称服务器分为主（primary）与从（secondary）两类。主服务器含由区域管理员创建与编辑的区域文件，有时被配置为允许授权客户端动态更新；从服务器持有主服务器区域文件的副本，复制通常经「区域传送」完成——主服务器区域内容变化时经 DNS NOTIFY 通知从服务器，后者随即发起区域传送（全量 AXFR 或增量 IXFR）。为提升容错，组织通常有多台从服务器。当权威角色由云服务提供时，往往不区分主从，且可能用区域传送以外的方式同步数据；从客户端视角看主从无差别，主角色仅在客户端经 DNS UPDATE 更新记录时才相关。


为何权威域必须防护配置错误或过期的 CNAME 记录、名称服务器委派，会让威胁者接管组织对外域名，借其良好信誉对本组织用户发起鱼叉钓鱼或用于恶意软件活动。威胁者还越来越多地注册「仿冒（look-alike）」域名——并非目标组织所有，但用户易误以为与其相关。

3.1　区域传送威胁与防护

区域传送把区域数据复制到多台服务器以提供容错。虽未有正式 IETF RFC 记录其威胁，但两类常见威胁是：

●拒绝服务（DoS）：区域传送涉及整区数据，相对普通查询极耗网络资源；错误或恶意的频繁传送请求会压垮主/从服务器。

●未授权区域修改：区域传送的响应消息可能被篡改。

将允许发起区域传送的从服务器限制为一组已知实体，可缓解 DoS。识别这些实体常用 IP 地址，但 IP 可被伪造并不安全。保护主从间区域内容完整性的一种方式是发布 ZONEMD 记录（区域内容的哈希摘要），从服务器可据此校验传送结果是否与主服务器一致；其优点是无需共享密钥。

IETF 另设有 TSIG 机制，基于共享密钥做服务器互认并对传送请求/响应签名以防篡改；由于参与传送的服务器一般限于同一管理域，基于共享密钥的双边信任模型对多数组织足够。也可用非对称密码（公钥）经 SIG(0) 记录认证事务，其可用 DNS 中的公钥校验、无需预先信任关系，但计算开销更大；因多数传送发生在已有信任关系的各方之间，TSIG 通常更易实现。TSIG/SIG(0) 仅提供认证与完整性；区域传送的保密性可用 TLS 提供（RFC 9103），或由 IPsec 等更低层机制在主机/基础设施层提供。

防护落地上：权威服务器（尤其主服务器）应配置 ACL 指定接受区域传送请求的主机，把主服务器的传送限制到从服务器；从服务器应完全禁用区域传送，除非它需向其他从服务器提供传送（此时同样用 ACL 保护）。

3.2　区域内容威胁与防护

●瘸腿委派（Lame Delegation）：错误的区域委派会使子区域不可达（DoS）或时断时续（若某个 NS RRset 条目指向不存在的服务器）。权威管理员应定期核查从父区域到本区域、以及本区域内各子委派的委派信息正确性。

●区域漂移与区域抖动：SOA 记录中 Refresh/Retry 过高且区域频繁变更时，主从数据可能不一致（区域漂移，zone drift）；设得过低则从服务器频繁发起传送（区域抖动，zone thrash），加重主从负载。Refresh 应据区域预期变更率设定，常见 1200 秒（20 分钟）至 432000 秒（12 小时）乃至 864000 秒（1 天）；Retry 是失败刷新后重试的等待时间，应为 Refresh 的一个分数。

3.3　动态更新威胁与防护

动态更新指 DNS 客户端实时修改权威服务器区域数据（RFC 2136）。常见威胁：未授权更新（新增非法资源、删除合法资源、篡改委派信息）；更新篡改；重放攻击（捕获后重发的更新请求）；以及大量动态更新导致的降级/中断（动态更新比应答查询更耗资源，且在部分软件中优先级更高——这也是强烈建议对允许动态更新的区域使用专用隐藏主的原因）。

防护上，TSIG 可同时满足区域传送与动态更新的安全目标：除动态更新消息前置字段自带的部分重放保护外，TSIG 通过在请求中加入带签名的时间戳，使服务器可判断请求时序是否在允许范围内；也可辅以 IPsec 等更低层机制。动态更新只能发往持有可写副本的主服务器，且请求通常来自 DHCP 服务器等，因此应仅接受来自授权发送方（经 TSIG 或 ACL）的更新。

3.4　DNS NOTIFY 威胁与防护

DNS NOTIFY 是主服务器发出、促使从服务器启动刷新（查询 SOA 检查序列号）并在有更新时发起区域传送的消息。由于 NOTIFY 只是一个信号，安全风险很小，主要风险是伪造的 NOTIFY 消息——它会增加从服务器工作负载（但只有主服务器确有更新时才会真正发生传送）。因影响低，防护做法是配置从服务器只接受来自本区域主服务器（或对配置为从其他从服务器传送的情形，来自那台从服务器）的 NOTIFY；若已对一组主机启用 TSIG，则 NOTIFY 也会随之受 TSIG 保护。建议保持通知开启，以便更新快速传播；多数软件还能通知 NS RRset 中未列出的隐藏/隐匿服务器。

3.5　最小化信息泄露

作为运营安全的一部分，应尽量减少无需凭证即可从 DNS 服务器收集到的信息——这些信息可被用来对服务器发起攻击或快速摸底组织网络。并非所有泄露都可避免（某些信息必须公开 DNS 才能正常工作），本节给出在不损害核心功能前提下减少泄露的建议。

攻击者可利用 MX、SRV、TLSA、TXT 等记录类型了解可用服务，也可用 RP、HINFO、LOC 及万能 TXT 等旨在向人/应用传达信息的记录来摸清网络主机——例如查询 HINFO 找出列明已知有漏洞的 OS/平台的主机。因此最佳实践是把这些记录类型排除在面向互联网的区域之外。TXT 记录需更谨慎权衡：SPF、DKIM、DMARC 等认证邮件技术都用 TXT 存储发信策略，是否属于信息泄露需逐案判断。

3.6　外部权威域完整性

●悬空 CNAME 利用：当 CNAME 指向的规范名，其父域不再由目标组织注册时，威胁者可注册该父区域，使解析落到其控制的域；若规范名解析到的 IP 已不再使用而被攻击者获得，也可被利用。管理员应定期监控与评估这些域的配置与注册，不再需要的 CNAME 应删除。

●瘸腿委派利用：当子域委派给某 DNS 托管商而服务合同到期时，威胁者可与控制委派中所列服务器的托管商签约来劫持该子域解析。若区域被从托管服务删除但原委派未从注册服务移除，也存在类似威胁。管理员应主动校验外部权威命名空间中无瘸腿委派，删除时须同时移除全部委派信息与区域数据本身。

●仿冒域利用：威胁者大量使用仿冒或错拼（typosquat）域名冒充目标组织，借其良好信誉大幅提升钓鱼/恶意软件活动的成功率，手法包括细微变体或字符替换（如来自国际书写系统的同形字）。最佳实践是监控新注册以发现此类攻击、并在可行时防御性注册仿冒域；对退役委派也应监控再注册，或在可行时将其「停放」一段时间。

3.7　运营建议：资源记录 TTL

每个 RRset 都有自己的 TTL，告知递归服务器与客户端该数据可缓存多久（秒）。管理员可设默认 TTL，也可按 RRset 单独指定。默认 TTL 应长到足以让缓存有用、又短到使变更能快速传播。还须考虑 DNSSEC 签名有效期：TTL 应小于覆盖该 RRset 的 RRSIG 有效期，否则 DNSSEC 不感知的缓存可能存储将失效的记录。


TTL 取值建议 TTL 宜为小时量级，推荐范围 1800 秒（30 分钟）至 86400 秒（1 天）。频繁变化的记录可设低些以清除陈旧数据；不常变化的可设高些以优化缓存收益。特殊负载均衡场景可能用 ≤60 秒，但对 DNSSEC 签名的 RRset 应避免 ≤30 秒的极低值。TTL 为 0 绝不应使用（会在部分缓存实现中引发大量问题），即便 5–30 秒也远好于 0。对 DS、DNSKEY 等记录，运营上可能希望较短 TTL，以便在（尤其是紧急）密钥变更时更快清除旧信息、限制已知/潜在密钥泄露被利用的时间窗。

TTL 取值建议 TTL 宜为小时量级，推荐范围 1800 秒（30 分钟）至 86400 秒（1 天）。频繁变化的记录可设低些以清除陈旧数据；不常变化的可设高些以优化缓存收益。特殊负载均衡场景可能用 ≤60 秒，但对 DNSSEC 签名的 RRset 应避免 ≤30 秒的极低值。TTL 为 0 绝不应使用（会在部分缓存实现中引发大量问题），即便 5–30 秒也远好于 0。对 DS、DNSKEY 等记录，运营上可能希望较短 TTL，以便在（尤其是紧急）密钥变更时更快清除旧信息、限制已知/潜在密钥泄露被利用的时间窗。

3.8　权威服务的 DNSSEC 签名考量

DNSSEC 是为 DNS 数据增加来源认证与完整性保护的一组协议扩展（RFC 9364），旨在防止数据被篡改。数字签名以 RRSIG 记录封装覆盖响应中的某个 RRset，用于校验的公钥存于 DNSKEY RRset；通过从已签名数据到系统预配置可信公钥（信任锚）构建「签名与公钥的验证链」来建立信任。密钥在运营上常区分为区域签名密钥（ZSK）与密钥签名密钥（KSK）。DNSSEC 保证完整性但不保护保密性（保密由 DoH/DoT/DoQ 提供）；反之 DoH/DoT/DoQ 只保护查询/响应事务，不为响应数据提供完整性与来源认证。

注意：因命名之故，DNSSEC 常被与更广义的「DNS 安全」混为一谈，但它只是整体的一个组件，实现全面 DNS 安全还需更多工具。

3.8.1　DNSSEC 密钥考量与算法参数（表 1）

DNSSEC 基于公钥密码生成数字签名，当前算法集见 RFC 8624；结合 SP 800-57、SP 800-131A 对密钥强度与生命周期的建议，得到下表参数。由于 DNS 响应总大小受限（否则需回落到 TCP），管理员应关注密钥与签名大小对响应大小的影响——因此 ECDSA、Ed448 等优于 RSA（密钥与签名更小）。

签名算法	DNSSEC 代码	公钥长度（比特）	签名长度（比特，未含 RRSIG 编码）
RSA with SHA-256	8	2048 或更大	约 2050–4100
ECDSA P-256 with SHA-256	13	256	512
ECDSA P-384 with SHA-384	14	384	768
Ed25519	15	256	512
Ed448	16	456	912

SP 800-57 按用途给出所需安全强度与生命周期：112 比特强度可用至 2030 年，之后提升至 128 比特（此为签名用途，为兼容不具相同要求的实体，验证侧允许使用旧密钥/算法套件）。某些组织（如联邦机构）还要求使用 FIPS 140 认证的密码模块。表 1 未含后量子密码（PQC）算法——撰写时 DNSSEC 的 PQC 用法尚未标准化，但管理员应在其被标准化、工具更新后考虑迁移；由于 DNSSEC 不提供保密性，「先存储、未来解密」的量子威胁并不适用。

密钥生命周期是密钥对应被视为活跃并使用的时段，之后退役不再用于签名。DNSSEC 签名密钥的推荐最大生命周期为 1–3 年，其值完全由企业内部策略设定、在 DNSKEY/RRSIG 中无表示。退役旧密钥对、引入新密钥对的动作称为「密钥轮换（rollover）」：ZSK 轮换有自动化工具、可少人工干预；KSK 轮换涉及（可能由不同组织运营的）父区域，须父子双方协同，操作前应了解父区域偏好的 KSK 轮换方式。若可行，建议用硬件安全模块（HSM）存储私钥（通常是 KSK），尤其对重要权威区域。

3.8.2 ~ 3.8.7　RRSIG 有效期、存在性否认、算法迁移、内部区域、时间源

●用 RRSIG 有效期限制密钥泄露影响：缩短 DNSKEY 的 TTL 与 RRSIG 有效期（及父区域对应 DS）可限制攻击者利用已泄露密钥伪造响应的时间窗。DNSKEY 的 RRSIG 有效期宜短（如 5–7 天），且应显著长于 TTL（过低会导致更频繁的重签名）。

●哈希化的存在性否认（NSEC/NSEC3）：最初规范允许通过连续查询 NSEC 记录「遍历（walk）」整个区域枚举其内容。NSEC3 用哈希后的 FQDN 缓解，但会增加服务器/客户端负担，且往往仍可获得完整所有者名列表。更稳妥的做法是使用 NSEC；若因本地策略仍需 NSEC3，应按 RFC 9276 设定参数以降低 DoS 风险。此外 NSEC3 目前仅指定 SHA-1，而 SHA-1 已被证明可能更易受攻击——若将来指定更强哈希，应计划迁移。

●紧凑存在性否认（替代方案）：IETF 正在推进的「紧凑存在性否认」响应，要求权威服务器生成通常在「查询类型不存在」时才出现的 NSEC(3) 响应；客户端行为不变，可作为缓解区域遍历的替代方案。

●DNSSEC 算法迁移：因算法弱点或策略需迁移新算法时（流程见 RFC 6781），为避免验证方误判为降级攻击，应先加入新算法签名，再加入新算法 DNSKEY，父区域 DS 最后加入；移除旧算法时先删 DNSKEY 公钥、再删签名。迁移期两套 RRSIG 并存会使响应变大、可能需要 TCP，须评估响应大小与操作复杂度。

●对内部区域签名：对多数组织价值有限，一般不推荐（除非如政府机构等有明确要求）。三大难点：难以接回互联网信任链（否则需在各验证解析器管理额外信任锚）；动态更新的区域每次更新都要重签名、计算量大；当权威与递归合并在同机（内部 DNS 常见）时签名意义不大。若确需，宜为内部区域单独委派以建立到根的信任链（但会泄露委派名），或不从外部区域委派（隐藏内部区域，但需各验证解析器维护其公钥）。

●使用权威时间源：DNSSEC 签名与验证都需正确时间来编码/校验 RRSIG，签名方应有权威时间源并用安全方式（如带冗余源的网络时间安全 NTS，RFC 8915）维护正确时间。

四、管理对递归/转发服务的威胁

递归名称服务器代表一批客户端执行名称解析，也称缓存名称服务器或递归解析器。它响应存根解析器的查询，过程可能涉及查自身缓存、转发给指定服务器、经一系列迭代查询递归地询问各权威服务器，或这些方式的组合。

某些实现可同时作权威与递归：为权威区域给出权威应答，同时为其他区域执行解析。执行递归需允许递归查询，这使其比不允许递归的服务器更易受攻击；因权威信息可能被污染，把「互联网可访问的（外部）名称服务器」同时配为权威 + 递归并非好的安全实践，但对不可从互联网访问的纯内部服务器则是可接受且高效的配置。递归服务经 IP 访问（本地或云端）；云端具全球可用性与更大更活跃的缓存，但在控制与可见性上有取舍。

4.1　对递归/转发服务的威胁

被污染的事务查询与传入响应会威胁递归服务器。威胁包括：失陷的权威服务器（对源自递归服务器的查询）；被投毒的递归缓存（对源自存根解析器或转发递归服务器的查询）；诱导递归服务器查询某名称后立即发送伪造响应以插入恶意答案（历史上已有缓解措施）；用特定查询触发软件缺陷以发起 DoS 或影响运营；被动监听存根解析器发出的查询导致隐私损失或被推断主机上运行的应用/服务；以及域名所有者不当的 DNSSEC 管理（如密钥轮换期间，虽非恶意）。

递归缓存可能被下列攻击投毒：数据包拦截（窃听请求并抢在真实响应前伪造名称服务器应答）；ID 猜测与查询预测（暴力猜测 DNS 请求头的 ID 字段乃至 QNAME/QTYPE 后注入伪造数据）；来自失陷权威服务器的响应；对万能记录应用了错误的展开规则（致合成 RR 不生成，引发 DoS）；以及从响应中移除 RR（致解析失败与 DoS）。

4.2　防护建议

DNSSEC 提供数据认证但不保护查询/响应事务的保密性——按最初规范，DNSSEC 与非 DNSSEC 的查询/响应都以明文发送，易被被动监听，从而暴露主机通信对象、形成客户端「指纹」用于日后追踪。（同时，一些组织的安全服务也正是用 DNS 监控来发现未授权通信或潜在恶意软件。）

4.2.1　加密 DNS

存根解析器与递归服务器之间的通信传统上未加密，其二进制编码广为人知、易被解码，因而长期面临拦截与欺骗，可能泄露敏感信息或把用户重定向到恶意站点。为此 IETF 发展出统称「加密 DNS」的多项增强：

●DoT（RFC 7858）：在 TLS 上运行传统 DNS 协议（与 HTTPS 同一加密层），使用 TCP 853 端口。

●DoH（RFC 8484）：在 HTTP 上运行 DNS（HTTP 再跑在 TLS 上），使用 TCP/UDP 443 端口。

●DoQ（RFC 9250）：在 QUIC 上运行 DNS（QUIC 含跑在 UDP 上的加密传输层），使用 UDP 853 端口。

这些协议都可选地允许递归服务器向存根解析器认证自身，从而应对拦截与欺骗。

▍ 加密 DNS 指引与建议

美国政府要求联邦文职行政部门（FCEB）机构在技术支持处使用加密 DNS 与机构端点通信。许多组织会发现其可用的加密 DNS 协议受限于应用/操作系统当前支持的协议；还可能需配置应用（如浏览器）使其加密 DNS 不绕过承担控制与日志职责的本地解析器。某些端点（如 IoT）自身可能不具使用加密 DNS 的软件模块，需要一台充当递归服务的转发 DNS 服务器（见图 2）。

图 2　传统 Do53 与 DoH 混合使用

虽然这并非完整的零信任架构，但仍能对出站 DNS 流量施加严格策略；视对响应性与可用性的架构要求，企业递归解析器也可实现为云服务。

▍ 使用考量与密码指引

加密 DNS 对增强在线隐私与安全至关重要，可减少 DNS 欺骗、中间人等风险。但它会带来额外开销（收发消息需加解密），组织应在大规模部署前确保名称服务器有足够资源应对查询负载；加密也会使排障更难（网络排障工具无法直接看到查询/响应内容，但这些信息在名称服务器本身仍可获得）。密码上：各类加密 DNS 都支持服务器认证，需在每台接收加密查询的服务器上配置证书（可由公有或内部 CA 签发）；若支持，应只允许 SP 800-52 许可的密码套件，云端提供商应据此评估；部分组织还要求对 TLS/DTLS 使用 FIPS 140 认可的密码模块。

4.2.2　限制使用公共 DNS 提供商

为确保用户不使用未授权的公共 DNS，组织应：

●阻断从内网到互联网的出站 DNS，仅允许授权的名称服务器（如转发器）直连——因 DNS 使用 UDP/TCP 53 两个知名端口，可用防火墙规则或路由器 ACL 实现；

●尽可能将存根解析器限制为仅对授权 DNS 服务使用加密 DNS；

●用防火墙/ACL 阻断未授权 DoT（知名 TCP 853，易于阻断）；

●用 RPZ + 防火墙阻断未授权 DoH——DoH 与 TLS 同用 443 更难阻断，RPZ 可阻断已知 DoH 服务器的域名解析，防火墙可阻断运行在专用 IP 上的公共 DoH；

●用防火墙/ACL 阻断 DoQ（知名 UDP 853）；

●用移动设备管理（MDM）等集中方案阻止用户配置未批准的外部加密 DNS。

4.2.3 ~ 4.2.4　QNAME 最小化 · 检测 DNS 数据渗漏

●QNAME 最小化：并非协议扩展，而是改变递归服务构造迭代查询的方式——只暴露获取「下一步」所需的最少信息，从而增强隐私。代价是可能有少量额外查询，但随缓存填充其开销随时间可忽略。

●检测与缓解经 DNS 的数据渗漏：应建立控制以检测并阻断把数据隧穿进 DNS 包的未授权应用。基于签名的系统能识别知名隧道工具，但也应考虑定制化工具。可疑迹象常包括：单主机异常高的查询量；异常或变化的查询模式；对看似古怪的 QNAME 的查询（可用 QNAME 熵测量发现）；对已知恶意域（经威胁情报）的查询。注意：被动观测的网络工具在加密 DNS 下会受影响，除非被配置为代理或转发器。

4.2.5　启用 DNSSEC 验证（表 2）

配置 DNSSEC 验证需两步：配置服务器执行验证；配置一个或多个受信公钥作为信任锚。选哪些公钥属组织安全策略范畴，但因 DNS 的层级结构，公钥在层级中越高，可用其验证的响应范围越广，如下表。

示例公钥	可验证范围
根 “.”	所有已签名的 TLD 及其下
.gov	“.gov” 下所有已签名名称
example.gov	仅 “example.gov” 域内名称

因此，应将互联网根密钥配置为信任锚。

4.2.6　维护 DNSSEC 信任锚

当某区域更新其签名密钥（密钥轮换）时，凡把该区域密钥配为信任锚的验证解析器都必须获取新密钥，否则来自该区域（及其委派区域）的签名响应会验证失败。存在自动化流程（RFC 5011）让区域向验证解析器示意其正在轮换；由于管理员未必能收到带外的轮换提前通知，依赖手动更新信任锚存在风险。验证解析器管理员应启用自动信任锚轮换并监控日志以确保递归服务稳定。

4.3　运营建议

设置递归服务器时还可：因不宜允许来自互联网的查询，可将其置于防火墙后、阻断入站 UDP/TCP 53；把递归服务器配置为只接受内部主机的查询并为其递归（经实现相关的 ACL 或网络配置）。此外，提供 DNSSEC 验证或 DoH/DoT/DoQ 的递归服务器需要权威时间源（DNSSEC 验证与证书校验都依赖当前时间），应配置主备时间源及安全的联系方式（如 NTS）。

五、管理对存根解析器的威胁

需要访问网络资源的软件（浏览器、邮件客户端、云应用、操作系统）都使用一种称为存根解析器（stub resolver，常简称客户端）的 DNS 客户端。它为软件所需资源构造解析查询并发往企业内的递归服务器，通常配置为向两台或更多递归服务器发送以提供容错。

操作系统层存根解析器是 OS 内集中的 DNS 客户端，通过系统级配置的递归解析器为所有应用处理查询；应用层存根解析器则在特定应用内独立运行、绕过 OS 解析器直接处理查询（现代浏览器支持 DoH/DoT 者常见）。当应用层存根覆盖系统默认设置时，二者可能产生冲突或互补，形成分层解析。

5.1　保护存根解析器

存根解析器配置项不多，管理员通常只需填入一台或多台递归解析器的 IP（建议至少两台以提升可用性），可手动或经 DHCP/DHCPv6 下发。还可用任播（anycast）在 DNS 服务 IP 与各递归服务器之间加一层抽象，降低单台服务器丢失对客户端的影响（对只会使用一台 DNS 服务器的应用尤为重要）。


防范篡改存根设置的恶意软件有一类已知恶意软件会篡改系统存根解析器设置，把查询导向另一台（通常是恶意的）递归服务器，再将用户引向恶意站点或投放广告等非预期内容。对策是：阻断除已知递归服务器外的全部出站 DNS，或用其他安全工具维持端点安全配置；部署企业移动性管理（EMM）软件可确保存根正确指向授权 DNS 服务器，并管理与强制关于「集成存根解析器软件」的审批与使用策略。

防范篡改存根设置的恶意软件有一类已知恶意软件会篡改系统存根解析器设置，把查询导向另一台（通常是恶意的）递归服务器，再将用户引向恶意站点或投放广告等非预期内容。对策是：阻断除已知递归服务器外的全部出站 DNS，或用其他安全工具维持端点安全配置；部署企业移动性管理（EMM）软件可确保存根正确指向授权 DNS 服务器，并管理与强制关于「集成存根解析器软件」的审批与使用策略。

5.2　存根解析器的 DNSSEC 考量

多数存根解析器无法执行 DNSSEC 验证、甚至完全不理解 DNSSEC，须依赖上游验证递归解析器代为验证。在可信的组织网络中这风险不大——只要存根与其递归服务之间的链路被保护（如用本文前述的末跳机制），存根即可视为「在使用」DNSSEC。但管理员应注意：DNSSEC 验证失败会由上游验证方看到、而非发起查询的存根（后者通常只收到通用错误），故排查解析错误时应检查验证方日志以排除 DNSSEC 验证失败。

5.3　为移动主机提供服务的建议

移动/游牧主机常在可信企业网之外接入，因此要么自行验证，要么与企业批准的 DNS 服务保持可信连接。若移动主机能自行验证，应对其套用与企业验证方相同的信任锚与验证策略；在企业内外网间迁移时可能需要不同配置（在企业网内依赖企业验证方，在外网自行验证）。理想情况下，管理员可通过为内外部区域使用不同名称（从而使用不同信任锚，若内部区域已签名）来规避此问题。

若移动主机不能自行验证，则须有回到企业网的安全隧道、或到已批准递归 DNS 服务的安全连接。许多企业已为移动主机提供访问内部资源的手段，可把一台验证递归服务器作为服务之一经安全通道提供；或将企业移动主机配置为使用已批准的云端递归服务，从而无需连回企业基础设施。

附录 A　DNS 协议教程

术语 DNS 可指全局命名空间、运营该命名空间的基础设施，以及主机用来把域名解析为 IP 或其他信息的协议。本附录做高层概览。

A.1　DNS 命名空间与基础设施

DNS 基础设施由遍布全球、地理分散的计算与通信实体组成，命名空间按层级组织。最顶层是根域，以一个点（“.”）表示；其下一层是顶级域（TLD）。根域只有一个，TLD 有很多，每个 TLD 都是根域的子域；TLD 又各有许多子域，常称二级或企业级域。

在域名表示中根域符号通常省略。以 marketing.example.com 为例：最右标签 “com.” 是 TLD，向左 “example” 是二级/企业级域，最左 “marketing” 是三级域；从当前层级串接到根区的全部标签构成完全限定域名（FQDN）。本文中 FQDN 简称为域名。

现有一千多个 TLD，分为三类：国家代码 TLD（ccTLD，如 .uk、.in、.jp，逾 240 个）；有赞助的通用 TLD（如 .edu、.gov、.int、.mil、.aero、.coop、.museum）；无赞助的通用 TLD（如 .com、.net、.org、.biz、.info、.name、.pro）。

图 3　DNS 命名空间层级（DNS 树）

希望注册域名的用户须联系被授权的注册商（registrar）；注册商核实名称在对应注册局（registry）处可用后为其注册，注册局再将新名称写入数据库并在 DNS 中发布。某些域（如国家代码、gTLD）由同一组织兼任注册局与注册商。取得企业级域后，组织可创建子域来标识各职能单元的资源（如 example.com 下建 “shipping” 子域）。

为便于分组，DNS 定义了「区域（zone）」概念：区域可以是整个域或含若干子域的域，是名称服务器中的可配置实体，描述某域及选定子域集合下所有互联网资源的信息。区域是 DNS 命名空间的管理构件（域则是结构构件），因此「区域」常指作为独立管理实体来管理的域（如根区、.com 区）。

A.2　DNS 查询与响应

当用户在浏览器输入 www.example.com，浏览器会联系一种称为存根解析器的解析器，后者再联系本地递归名称服务器（见图 4）。

图 4　DNS 解析过程

递归（解析）服务器先查缓存是否已有该资源（如 www.marketing.example.com）的 IP；若无，再查是否有 marketing.example.com 区域的名称服务器信息；若缓存中有其 IP，则下一步查询直接发往该服务器或层级中更高的服务器。

若缓存未命中，解析服务器须从命名空间最顶层（根服务器）开始查询——根服务器的联系由几乎每台名称服务器都有的「根提示（root hints）」文件启用。根服务器含其子区（TLD）的名称服务器信息；TLD（如 .com）含其子区（如 example.com）的信息，这种「某区域携带的、关于其子区名称服务器的信息」称为委派信息（delegation information），用于把对更低层资源的解析请求转介出去。由于本例请求指向三级域资源，根服务器须把请求转介到更低层。

这种携带委派信息的响应称为转介（referral）：它给出与请求相关的 TLD 区（.com 区）名称服务器的名称与 IP。解析服务器据此向 .com 区服务器发查询，后者给出 example.com 名称服务器的转介；若 marketing.example.com 包含在 example.com 区内，向 example.com 的名称服务器查询即可得到该资源的 IP。综上，名称服务器提供三种功能：对子区的转介；域名到 IP 的映射（或反向）；对不存在条目的错误消息。这三种功能都用同一个称为区域文件的数据库完成——区域文件含两类信息：权威信息（区域内所有域的所有资源）与委派信息（子区名称服务器信息），后者出现的位置称为委派点。要透彻理解协议，请参阅 IETF 维护的 DNS 协议规范。

附录 B　术语表

DNS 相关通用术语由 IETF 在 RFC 9499 中汇集定义。以下为不在其中或需额外语境的术语。

悬空 CNAME（dangling CNAME）

CNAME 将别名映射到规范名，规范名再解析到 IP。若规范名的记录被移除，CNAME 便「悬空」；若规范名在组织控制之外，恶意者可能取得其管理控制（如规范域注册已过期）。

DNS 卫生（DNS hygiene）

维护安全、有弹性、良配置 DNS 环境的实践：主动管理与监控配置以消除瘸腿委派、悬空 CNAME 等脆弱点，移除不再使用的 RRset，并持续监控与缓解仿冒域以防钓鱼与冒充。

加密 DNS（encrypted DNS）

DoT、DoH、DoQ 等用于加密存根解析器与递归服务器之间通信的手段的统称。

伪造响应（forged responses）

不同于合法权威服务器预期应答的响应，可源自失陷的权威服务器或被投毒的递归缓存。

瘸腿委派（lame delegation）

把区域委派给对该区域不权威的名称服务器；可能因子域过期未从父域移除，或委派的名称服务器变更未与父域同步而发生。