DNS 中的“幽灵域名”问题：成因、影响及 Oh Dear 的解决方案

原文标题：The ghost domain problem in DNS, and what we're doing about it 作者：Mattias Geniar (Oh Dear 创始人) 发布日期：2026年6月2日

背景

在域名系统（DNS）的运维与监控领域，存在一个鲜为人知但极具隐蔽性的边缘案例：幽灵域名（Ghost Domain）。即使是对 DNS 有深入理解的专业人士，也往往未曾遇到过这种情况。

当一个域名被注册局（Registry）从区域文件中移除后，它可能会在长达数天的时间里，对 uptime 监控服务（Uptime Checkers）显示为“健康”状态。这种现象并非 Oh Dear 独有，而是由 DNS 递归解析器的缓存机制与注册局的数据验证策略共同作用产生的系统性偏差。

目前，该问题已在 DNS 研究圈子里被记录，并有一个活跃的 IETF 草案（draft-ietf-dnsop-ns-revalidation）正在讨论解决方案。然而，由于其技术门槛较高且隐蔽性强，许多 uptime 监控产品运行多年却无人察觉。本文将深入剖析这一问题的成因，并介绍 Oh Dear 团队为此所做的底层架构调整。

核心内容

1. 幽灵域名的触发机制

幽灵域名的产生，通常源于注册局对域名持有者数据验证的严格政策。当域名持有者的联系信息未能通过验证时，注册局会采取以下措施之一：

• .de 区域：DENIC 会在截止日期前移除未验证的域名，随后将其删除。
• .eu 区域：EURid 会暂停域名，若数据仍未验证，将其移至“已撤回”（withdrawn）状态。
• .fr 区域：AFNIC 会执行资格和联系能力检查，可暂停并最终删除未修正数据的域名。
• ICANN gTLDs (.com, .net, .org 等)：根据 2013 年 WHOIS 准确性计划，注册商（Registrar）需在收到验证请求 15 天无回应后，暂停、终止或将域名置于 clientHold 状态，从而将其从区域发布中移除。

关键矛盾点： 尽管注册局或注册商已从父区域（Parent Zone）中将该域名移除，但域名自身的权威名称服务器（Authoritative Nameservers）仍然照常响应查询。

• 对于不再持有子区域记录的解析器，查询结果应为 NXDOMAIN（RCODE 3，表示名称不存在），即浏览器显示错误。
• 但对于背后拥有长期存活递归解析器缓存的 uptime 监控服务，查询结果可能完全正常。

这并非浏览器与监控工具的区别，而是**冷缓存（Cold Cache）与热缓存（Warm Cache）**的区别。网站实际上已不可用，但监控器却认为它“看起来很好”。

2. 故障根源：递归解析器的缓存层级

以 Oh Dear 在法兰克福的一个监控节点为例，其 DNS 解析链路如下：

PHP/curl → glibc nsswitch → /etc/resolv.conf (127.0.0.53) → systemd-resolved stub → 上游递归解析器（由托管提供商运行） → 权威名称服务器（域名的 DNS 提供商）

问题并不出在 Oh Dear 的服务器或用户的服务器上，而是出在上游递归解析器的缓存层。这是递归 DNS 工作的固有特性：使 DNS 快速响应的缓存层，同时也是让“死亡委派”（Dead Delegation）保持“温暖”的罪魁祸首。

3. 技术原理详解：为什么缓存会欺骗监控器？

这一机制在学术文献中已有记载（如 2012 年 NDSS 的 Ghost Domain Names 论文及 2023 年的后续研究 Ghost Domain Reloaded），其核心依赖于 RFC 2181 的可信度规则。具体步骤如下：

1. 首次查找：递归解析器查询 example.de，向 .de 父服务器发起请求。父服务器返回委派信息：“我不托管 example.de，但其名称服务器是 ns1.example-dns.net 和 ns2.example-dns.net。”这是父侧委派 NS RRset。解析器随后直接查询这些名称服务器，权威服务器返回包含相同名称列表的响应，这是顶点 NS RRset（Apex NS RRset）。
2. 子区域副本覆盖父区域副本：根据 RFC 2181 的排名规则，子区域权威服务器（example.de）返回的副本优先级高于父区域（.de）返回的委派副本。因此，解析器缓存中，子区域的副本替换了父区域的副本。
3. A 记录过期：当域名的 A 记录过期或被移除后，解析器再次查询 example.de 的位置。由于缓存中仍存有“热”的顶点 NS RRset（仍指向 ns1 和 ns2），解析器直接查询这些权威服务器。
4. 权威服务器继续响应：权威名称服务器并不知道注册局已移除委派，因此它们继续正面响应查询。
5. 循环：新的 A 记录被缓存，TTL 窗口重新开始。

只要顶点 NS RRset 在缓存中保持活跃，父区域通常不会被再次咨询。即使减少检查频率也无法解决问题，因为只要解析器在 TTL 到期前重新获取了顶点 NS RRset，幽灵域名就会继续存活。

4. 行业现状：其他监控服务如何应对？

作者调研了 Pingdom、UptimeRobot、StatusCake、Site24x7、Datadog Synthetics 和 Better Stack 等主流监控服务的公开文档和架构说明，未发现任何一家公开记录了对该问题的防御措施。

• Pingdom 的案例：其博客文章承认，每个探测服务器都运行独立的 Bind9 缓存 DNS 服务器。BIND 的默认最大缓存 TTL 为一周，这恰好是幽灵域名可以存活的典型时间窗口。
• 域名到期监控的局限性：虽然 Oh Dear 和其他工具提供域名到期监控，但这仅关注注册日期，无法检测域名是否因验证失败而被注册局从区域中移除。

这并非针对任何特定厂商的批评，而是因为这是一个隐藏在 HTTP 层产品之下的 DNS 层问题，直到有人深入挖掘才会被发现。

5. Oh Dear 的解决方案

为了彻底解决这一问题，Oh Dear 正在对架构进行以下收紧调整：

1. 本地递归解析器：在每个监控工作节点上运行 Unbound，执行完全递归，而不是转发给共享的上游解析器。这使得团队可以完全控制缓存参数。
2. 限制缓存时间：Unbound 默认将缓存记录限制为一天，Oh Dear 将其强制限制为一小时。一旦缓存的顶点 NS RRset 过期，下一次查询必须从最近的缓存切点（通常是 TLD 名称服务器）重新开始迭代，从而发现委派已被移除的事实。
3. 强化引用路径验证：启用 harden-referral-path 选项，并配合更深的 target-fetch-policy。这使得解析器在下行过程中重新检查所遇到的 NS 数据，而不是盲目信任缓存中的委派信息。

关键要点

• 幽灵域名定义：指域名已被注册局从区域文件中移除（如因验证失败被暂停），但由于递归解析器的缓存机制，监控工具仍认为其处于在线状态的错误现象。
• 根本原因：递归解析器缓存了子区域权威服务器返回的 NS 记录（Apex NS RRset），且该记录的优先级高于父区域的委派记录。只要缓存未过期，解析器就会继续向已失效的权威服务器查询，从而得到错误的“在线”响应。
• 普遍性：这是一个 DNS 层的系统性问题，涉及 .de、.eu、.fr 及所有 ICANN gTLDs。目前主流监控工具（如 Pingdom, UptimeRobot 等）均未公开解决此问题，主要受限于其使用的递归解析器（如 BIND, systemd-resolved）的默认缓存策略。
• 解决方案核心：