DNS 的 Delegation、Zone Cut、NS、Glue、Bailiwick、Lame Delegation 和 DS 有什么区别？

核心概念速查

Zone 与 Domain 不是同义词

Domain 是 DNS 名字树中的一个节点及其后代概念，Zone 则是由一组权威服务器管理的数据范围。一个 domain 下可以存在多个 zone，因为管理员可以在下级名称处建立委派。

例如 example.com 是一个 zone，管理员可以把 shop.example.com 委派为独立子区。此时 www.example.com 仍由父区管理，而 api.shop.example.com 由子区管理。不能仅凭域名中点号数量判断 zone 边界；必须查看委派 NS RRset。

RFC 1034 将 DNS 数据库按名字空间中的“切口”划分成区域。切口以下的连通部分由新区域负责，父区只保留让解析器找到子区所需的委派数据以及必要 Glue。

Delegation：父区移交权威责任

委派发生在父区：父区在某个名称上放置 NS RRset，指向负责子区的权威名称服务器。递归解析器查询子区名称时，父区通常不返回最终答案，而是返回 referral，引导解析器去询问子区服务器。

委派不是把全部子区记录复制到父区，也不是 URL 跳转。父区保留 NS 和必要的 Glue；A、MX、TXT 等子区权威数据由子区服务器维护。注册域名时在注册商控制台填写 Nameserver，本质上是在注册局或上级区域建立或更新委派。

父区委派与子区 apex 的 NS RRset应保持一致。两侧数据可能由于运维变更短暂不同，但长期漂移会导致缓存中的解析器看到不同服务器集合，出现只有部分网络失败的情况。

Zone Cut：权威边界在哪里

Zone Cut 是父区与被委派子区之间的边界。父区在 cut 处包含委派 NS，但不再对 cut 以下普通数据拥有权威；子区在自己的 apex 包含 SOA 和权威 NS，并管理下方未再次委派的名称。

Referral 响应的 Authority 区段通常带有子区 NS，AA 位的含义应结合响应类型理解。父服务器对父区是权威的，但返回的是委派，而不是对子区目标记录作最终权威回答。

排查时可从根开始执行迭代查询，逐级观察每个 cut：根指向顶级域，顶级域指向注册域，注册域还可能继续委派子域。任何一级缺失或错误都会截断后续解析。

NS：存的是服务器名称，不是服务器 IP

NS 记录的 RDATA 是名称服务器的域名，例如：

example.com.  86400  IN  NS  ns1.example.net.
example.com.  86400  IN  NS  ns2.example.net.

NS RRset 并不直接存放 IP。解析器还需要把 ns1.example.net 和 ns2.example.net 解析为 A 或 AAAA 地址，才能向它们发送查询。名称服务器域名是否位于被委派区内部，决定是否必须依赖 Glue。

建议部署多个在网络、故障域和运营路径上具有适当冗余的权威服务器。仅配置两个名称却都指向同一台主机或同一不可用网络，形式上满足数量，实际没有获得容灾能力。

Glue：为 in-domain 名称服务器提供启动地址

假设 example.org 的权威服务器是 ns1.example.org。要解析 example.org，递归解析器必须联系 ns1.example.org；但要知道该服务器 IP，又似乎需要先解析 ns1.example.org，形成循环。

父区因此在委派响应的 Additional 区段提供该服务器的 A/AAAA 地址，这类用于使委派可达的地址信息称为 Glue。RFC 9471 明确：生成 referral 时，服务器必须包含所有可用的 in-domain 名称服务器 Glue；如果受消息大小限制不能全部放入，则必须设置 TC=1，让客户端换用其他传输获取完整响应。

Glue 是父区中的非权威地址副本，子区 apex 下仍应存在对应名称服务器的权威 A/AAAA 记录。两处地址变化需要协调更新。只改子区而不改注册局 Host Object 或父区 Glue，会让部分解析器在 TTL 期间或更长时间继续访问旧地址。

In-domain、Sibling 与 Out-of-bailiwick

RFC 8499 将 in-bailiwick 名称服务器进一步分成 in-domain 和 sibling domain。对于 child.example.com 的委派：

• ns.child.example.com 是 in-domain，因为它位于被委派名称之下；
• ns.other.example.com 是 sibling，因为它仍在父 zone example.com 内，但不在 child.example.com 内；
• ns.example.net 是 out-of-bailiwick，因为它不属于父 zone example.com。

In-domain 名称服务器必须有 Glue，否则解析可能无法启动。Sibling Glue 允许出现，有时能解决兄弟区之间的循环依赖，但并非一般情况下都必需。Out-of-bailiwick 名称服务器的地址应通过其自身正常委派链解析；父区附带的相关地址不能当作该外部名称的权威数据。

RFC 9471 要求父服务器应尽量在 referral 中包含可用 sibling Glue，但如果受大小限制而无法全部包含，不一定必须设置 TC。运维设计应避免依赖脆弱的 sibling 循环。

Bailiwick：约束附加数据的接受范围

Bailiwick 原意是管辖范围。在 DNS 解析中，它帮助递归解析器判断 referral 附加区中的地址数据是否与当前委派相关、能否安全缓存。父服务器可以为其管理范围内的名称提供 Glue，但对于范围外服务器名，不应因为它顺便出现在 Additional 区段就无条件信任。

这是一项重要的缓存污染防护。攻击者若能让解析器接受任意 referral 中的无关地址，就可能把其他域名指向伪造 IP。具体 bailiwick 检查算法属于解析器实现和相关规范范围，不能简化成“Additional 里的所有 A/AAAA 都可信”。

Bailiwick 与 in-domain 也不是完全相同的词。In-domain 是相对委派 owner name 的更具体分类，in-bailiwick 则相对包含委派的 zone origin 判断。排查报告应写出父区、委派名称和 NS 名称，避免只说“域内”而不说明参照边界。

Lame Delegation：父区说它负责，服务器却不负责

Lame Delegation 通常指父区把子区委派给某个名称服务器，但该服务器没有被正确配置为该子区的权威服务器。查询它时可能返回 REFUSED、SERVFAIL、非权威响应，或者根本没有相应 zone。

常见原因包括：注册商处保留了退役 NS；新服务器尚未加载 zone 就更新父区；子区名称拼写错误；隐藏主服务器与公共权威服务器同步失败；只在一部分 Anycast 节点部署了 zone。

如果 NS RRset 中只有一台服务器 lame，解析可能表现为间歇性失败，因为递归解析器会尝试不同服务器并缓存失败状态。监控只查询“最快的一台”会漏检。应逐个从多个网络和 IPv4/IPv6路径直接查询所有委派服务器，并确认响应 AA、SOA serial 和关键 RRset一致。

Glue 缺失与 Lame Delegation 的区别

Glue 缺失表示解析器可能无法找到 in-domain 名称服务器的地址；Lame Delegation 表示解析器找到了服务器，但该服务器没有正确为子区提供权威服务。二者都可导致 SERVFAIL，但证据不同。

若父区 referral 没有必要 Glue，问题在父区或注册局委派数据。若能取得 NS 地址且网络可达，但直接查询服务器未得到子区权威回答，则更接近 lame。也可能两种问题同时存在，例如迁移时父区地址旧、到达旧服务器后 zone 又已删除。

DNSSEC 中 DS 位于父区

启用 DNSSEC 后，子区发布 DNSKEY 并用相应私钥签名 RRset；父区发布 DS，DS 通过摘要等信息指向子区的某个 DNSKEY。验证解析器从已信任的父区验证 DS，再用 DS 验证子区 DNSKEY，从而把信任链延伸到子区。

DS 与 NS、Glue 的职责不同。NS/Glue解决“去哪里查询”，DS 解决“如何建立密码学信任”。没有 DS 的正常委派可以是不安全委派，数据仍可能解析但没有从父区继承 DNSSEC 验证；存在 DS 但子区 DNSKEY 不匹配，则验证器会把响应视为 bogus，用户通常看到 SERVFAIL。

密钥轮换或 DNS 服务商迁移时，必须协调父区 DS 与子区 DNSKEY 的传播顺序。先删除旧 DNSKEY、后更新父区 DS，或者父区还保留旧 DS 而新服务只发布新密钥，都可能中断验证。不能把 DS 当作普通 TXT 记录添加在子区中。

Parent NS 与 Child NS 为什么会不一致

父区的 NS RRset用于 referral，子区 apex 的 NS RRset是子区自己的权威数据。两者由不同管理平面维护：前者常在注册商或父区系统更新，后者在 DNS 托管平台更新。迁移时只改一侧，就会产生差异。

递归解析器通常先从父区获得服务器集合，再向其中某台请求；随后可能从子区 apex 获得另一个 NS RRset并缓存。不同解析器的缓存时间与到达服务器不同，因此父子不一致会制造难以复现的故障。

安全迁移应先让新旧服务器都完整托管 zone，添加新 NS 与必要 Glue，等待缓存传播并验证，再移除旧 NS。DNSSEC 场景还要把 DNSKEY/DS 迁移纳入同一个时间线。

Glue TTL 与地址变更

Glue 的 TTL 由父区控制，子区权威 A/AAAA 的 TTL 由子区控制，两者可能不同。即使已经修改名称服务器地址，递归解析器仍可能在旧 Glue TTL 到期前使用旧 IP。

RFC 9199 针对大型权威 DNS 运营者指出，in-bailiwick服务器的 A/AAAA TTL 宜短于或等于对应 NS TTL，因为 NS 过期并需要重新取得 Glue 时，相关地址也会被重新查询。具体注册局可能固定 Glue TTL，域名持有人未必能自行修改。

地址迁移时应让旧地址继续服务足够长时间，覆盖父区和子区缓存窗口。立即关闭旧服务器，会把计划内迁移变成部分用户不可达。

一套逐级验证方法

从根开始使用迭代查询或 dig +trace 观察 referral，但不要只依赖一次 trace。对每一级父服务器直接查询委派名称的 NS，记录 Authority 和 Additional 区段、TC 标志、A/AAAA Glue及 TTL。

随后解析每个 NS 主机名，逐台向其查询子区 SOA、apex NS 和业务记录，确认 AA 位与 SOA serial。比较父区 NS 和子区 NS。若启用 DNSSEC，再查询父区 DS、子区 DNSKEY、RRSIG，并使用验证器检查信任链。

还应从不同递归解析器、网络与地址族测试。最后保存变更前后证据，而不是只记录“网站能打开”。HTTP 可用性可能受浏览器缓存、Hosts 或 CDN 影响，不能证明 DNS 委派正确。

常见误区

“NS 有两条就一定高可用”忽略两台服务器是否真实独立且都权威。“名称服务器在子区内，只添加 A 记录就够了”忽略父区 Glue。“Additional 区段里的地址都是权威答案”忽略 Glue 的非权威性质与 bailiwick 检查。

“DS 应添加在子区 DNS 控制台”通常错误，DS 属于父区委派信息。“偶尔能解析就不是 lame”也错误，只要服务器集合中部分节点配置错误，就可能表现为间歇失败。“修改子区 NS 后迁移完成”则忽略父区委派仍可能指向旧服务器。

FAQ

1. Delegation 与 Zone Cut 是同一回事吗？

它们密切相关但角度不同。Delegation 是把子域权威责任交给子区服务器的动作与数据，Zone Cut 是名字空间中由此形成的父子区域边界。

2. 为什么 NS 记录不能直接填写 IP？

DNS NS RR 的数据格式是域名。服务器地址通过 A/AAAA 解析；必要时父区以 Glue 形式提供这些地址。

3. 什么情况下 Glue 是必需的？

当名称服务器名位于被委派区内部，即 in-domain 时，若没有父区 Glue，就会出现解析服务器名与访问子区之间的循环依赖。

4. Out-of-bailiwick NS 需要在当前父区添加 Glue 吗？

通常不需要，而且该父区提供的范围外地址不能作为对外部名称的权威数据。解析器应沿外部名称自身的委派链获取地址。

5. Lame Delegation 为什么有时只影响部分用户？

NS 集合中可能只有一部分服务器错误。不同递归解析器选择、缓存和网络路径不同，因此有些命中正常服务器，有些命中 lame 服务器。

6. Parent NS 与 Child NS 必须完全一致吗？

运维上应保持一致。迁移过程中可以短暂存在受控重叠，但长期不一致会造成解析器看到不同服务器集合和间歇性故障。

7. 有 DS 就代表 DNSSEC 配置正确吗？

不代表。父区 DS 必须与子区当前发布的 DNSKEY匹配，签名、时间和算法也需有效。错误 DS 反而会使验证解析器返回失败。

8. `dig +trace` 成功是否足以证明委派健康？

不足。还需逐台查询所有权威服务器、比较父子 NS、验证 IPv4/IPv6、Glue、SOA一致性和 DNSSEC信任链，并从多个网络复测。

参考来源

• RFC 1034, Domain Names — Concepts and Facilities：https://www.rfc-editor.org/rfc/rfc1034
• RFC 8499, DNS Terminology：https://www.rfc-editor.org/rfc/rfc8499
• RFC 9471, DNS Glue Requirements in Referral Responses：https://www.rfc-editor.org/rfc/rfc9471
• RFC 4033, DNS Security Introduction and Requirements：https://www.rfc-editor.org/rfc/rfc4033
• RFC 4034, Resource Records for DNS Security Extensions：https://www.rfc-editor.org/rfc/rfc4034
• RFC 9199, Considerations for Large Authoritative DNS Server Operators：https://www.rfc-editor.org/rfc/rfc9199