aa.ns.charter.com 的离奇案例

# aa.ns.charter.com 的古怪案例 来源: https://mikehowells.com/2026/06/21/the-curious-case-of-aa-ns-charter-com/ *或者：一个 Pi\-hole 日志中的异常条目如何引向 Charter 权威 DNS 中一个存在七年的 bug。* --- 一切始于日志中的一行记录。 我在家庭网络的几台树莓派上运行了 Pi\-hole。它能屏蔽广告、追踪器，以及一大堆我不希望设备回传的遥测端点。多数时候我不去管它。但偶尔我会调出查询日志，看看流量情况，并扫描任何看起来奇怪的东西。 引起我注意的是这个： `aa\.ns\.charter\.com`。每小时一次。被屏蔽。来自我的一台域控制器。 Charter 就是 Spectrum，我的 ISP。这个主机名看起来像是他们的一台域名服务器。查询来自房子内部，某种意义上。一台运行 Active Directory 的 Windows Server 每小时向 Pi\-hole 请求解析这个名称，而 Pi\-hole 将其标记为已屏蔽。 许多原因可能导致某个东西出现在 Pi\-hole 日志中。大多数都很无聊。这个起初看起来也很无聊。但我花了几分钟探究，本以为五分钟就能解决的谜团，却变得有趣得多。 以下是我发现的。 ## 环境配置 让我先描述一下环境，因为有些细节重要，大多数并不重要。 我在家庭实验室运行了三台 Windows Server 2025 域控制器：SKYE、BOYD 和 EMMA。它们都在一个平坦的 `192\.168\.2\.0/24` 子网上。它们处理名为 `howells\.lan` 域的 Active Directory 和内部 DNS。 来自这些 DC 的出站 DNS 通过两个 Raspberry Pi\-hole 实例，Pi3 和 Pi4。DC 将查询转发给 Pis；Pis 运行上游的 dnscrypt\-proxy，后者使用加密 DNS 连接到 Cloudflare、Quad9 和 NextDNS。Pi\-hole 屏蔽其 33 个广告列表中的任何内容，而 dnscrypt\-proxy 对通过的所有内容执行严格的 DNSSEC 验证。 整个管道被设计成以一种特定方式保持偏执：每个外部查询都经过加密、验证和过滤，每层都有冗余。 我注意到的查询命中了 Pi3，客户端为 SKYE（`192\.168\.2\.11`），请求 `aa\.ns\.charter\.com` 的 A 记录。Pi\-hole 返回了 `0\.0\.0\.0` 并将其标记为已屏蔽。 我的第一个想法是：33 个广告列表中的哪一个捕获了 Charter 域名服务器主机名？这似乎很奇怪。广告列表通常针对广告网络和追踪器，而不是 ISP 基础设施。 ## 第一次走弯路 Pi\-hole 有一个内置工具正是用于此类问题。它叫“在列表中查找域名”。你输入一个主机名，它会明确告诉你你的哪个已安装阻止列表包含它。 我输入了 `aa\.ns\.charter\.com`。 零个。 所以无论发生了什么，都不是因为阻止列表命中。Pi\-hole 将查询标记为已屏蔽，但我的任何列表都没有告诉它这样做。这很有趣。Pi\-hole 不会随意屏蔽东西。还有其他因素产生了“已屏蔽”状态。 我检查了查询日志中的响应时间。A 记录是 69 微秒。这不是真正的上游查询，而是一个缓存或合成的响应。无论 Pi\-hole 在做什么，它几乎瞬间就返回了一个答案。 我查看了上游解析器实际返回的内容。从 Pi3 上，我对 dnscrypt\-proxy 上游运行了直接 dig，然后绕过它直接询问 Cloudflare 和 Quad9： 三个解析器，我的 dnscrypt 链、Cloudflare 的 `1\.1\.1\.1` 和 Quad9 的 `9\.9\.9\.9`，都返回了相同的结果。`aa\.ns\.charter\.com` 解析为 `0\.0\.0\.0`。 这完全改变了情况。Pi\-hole 并非在“查询列表并拒绝”的意义上屏蔽该查询。Pi\-hole 是从上游接收到权威答案 `0\.0\.0\.0`，识别出它是一个 null/沉洞地址，并在 UI 中将其标记为屏蔽。这是 Pi\-hole v6 的默认行为：任何解析为 `0\.0\.0\.0`（或 AAAA 为 `::`）的 A 记录都会被当作屏蔽响应处理，无论来源如何。 所以问题不在于“为什么 Pi\-hole 屏蔽这个”，而是“为什么 `aa\.ns\.charter\.com` 解析为 `0\.0\.0\.0`，以及为什么我的域控制器每小时询问一次？” 实际上是两个问题。我从第二个问题开始。 ## 追查进程 如果 SKYE 上有什么东西每小时生成一次 DNS 查询，我想我能找到它。如果你知道往哪里看，Windows 对此类事情有相当好的仪表化。 我从活动网络连接开始。`Get\-NetTCPConnection`，过滤到所有出站流量： PID 7956 建立了三个出站连接，其中两个到微软 IP 空间的 80 端口。有希望。我查了一下进程。 是开始菜单。 我在调查时 SKYE 上有一个活动的 RDP 会话。开始菜单正显示在屏幕上，做开始菜单该做的事，显然包括每十秒轮询一次微软端点以获取“推荐”和动态磁贴更新。这是我在 Pi\-hole 中每十秒看到的真实条目，`g\.live\.com`，被尽职地屏蔽了。但这并不是我每小时一次的 Charter 查询。进程不对，但至少我确认了我知道如何找到正确的。 另一个 PID，2760，是 `WpnService`，Windows 推送通知服务。这是意料之中的。它维护一个到微软通知基础设施的长连接 TLS 连接，用于 toast 通知。也不是我的罪魁祸首。 接下来我查看了计划任务，运行时间接近 :19 标记，因为 Charter 查询每小时都在 `:19:32` 到达。 `Collection`。每小时一次。下次运行在 6:19:56 PM。这可疑地接近我的 Pi\-hole 模式。 该任务位于 `\\Microsoft\\Windows\\Software Inventory Logging\\Collection`，运行一个名为 `silcollector\.cmd publish` 的命令，以 SYSTEM 身份运行。我从未听说过 SIL（Software Inventory Logging），但几分钟阅读告诉我，它是一个 Windows Server 功能，设计用于定期盘点已安装的软件和许可数据，并将其发布到配置的目标。它在 Server 2012 R2 中引入，用于数据中心合规报告。 这感觉像是答案。一个 SYSTEM 上下文的任务，每小时运行，做某种盘点和遥测，并可能在此过程中接触网络。 我检查了 SIL 是否实际配置为发布到任何地方： 没有。SIL 已停止，没有目标 URI。但运行 `silcollector\.cmd publish` 的计划任务仍然启用，并且仍然每小时触发一次。该 cmd 文件会进行库存收集，无论是否有任何内容被发布。 我以管理员用户身份手动运行该 cmd，观察 Pi\-hole 的实时查询日志，然后等待。 在接下来的 30 秒内，我看到了对 `roaming\.svc\.cloud\.microsoft`、`accounts\.google\.com`、`app\.ps\.five9\.com`、`fonts\.googleapis\.com` 以及一些其他 Office 和浏览器遥测端点的查询。全部来自我的活动 RDP 会话。 没有 `aa\.ns\.charter\.com`。一个都没有。 SIL 不是罪魁祸首。时间只是巧合。 我错了，但至少我学到了一点：无论什么生成了 Charter 查询，它并没有使用标准的 Windows DNS 客户端解析器。如果使用了，手动调用 SIL 应该会在紧接着的事件中浮现出*一些*与 Charter 相关的东西。生成每小时查询的进程绕过了 Windows DNS 客户端 API。 ## 一个不太吻合的模式 我从 Pi3 提取了大约过去 24 小时内 `aa\.ns\.charter\.com` 的完整查询历史。 两件事引人注目。 首先，节奏并非严格每小时一次。有些小时被跳过。13:00、16:00、17:00，没有。模式是“大约每小时一次，偶尔有遗漏”。这不是你可以从固定计时器的计划任务中得到的东西。而是从一个执行周期性操作但在条件不匹配时偶尔跳过的进程中得到的。 其次，秒偏移量在一天中发生了变化。较早的条目是 `:28:39-40`。后面的条目是 `:19:27-33`。早上 8:28 到 9:19 之间发生了某些重启，计时器重置到了新的偏移量。 我检查了那段时间窗口内的系统事件日志，寻找服务启动： 常规的 Windows Update 维护。在这两个时间戳之间发生了某些重启，新的实例拾取了新的启动时间锚点。驱动每小时查询的任何东西都与一个会重启的服务相关联，而不是与固定的时钟相关联。 这有助于解释节奏漂移。但还不能解释原因。不过它确实确认了我正在寻找的是一种长期运行的后台进程，而不是一个计划任务。计划任务基于绝对时钟时间触发。长期运行的进程每小时执行一次，是基于其自身启动时间的偏移量触发，并在重启时重置。 这正是我要找的模式。 ## 解读线索 我回过头更仔细地查看了 Pi3 在每次 `aa\.ns\.charter\.com` 查询之前立即记录的查询。 Charter 查询并不是孤立出现的。它是一个序列中的第二步。第一步是对 `ip6\.arpa` 中的一个名称的 SOA 查询。 `ip6\.arpa` 是 IPv6 地址的反向 DNS 命名空间。当你想问“这个 IPv6 地址拥有什么主机名？”时，你通过反转地址的十六进制半字节并附加 `.ip6\.arpa` 来构造反向查找名称，然后请求 PTR 记录。 SKYE 正在询问的名称解码为 Charter Communications 的 `2600:6c00::/24` 分配中的一个 IPv6 地址，这是他们住宅服务使用的公共空间。 因此，通过 SKYE 运行的查询是对一个 Charter IPv6 地址的反向 DNS 查找。查询链遍历了 ip6.arpa 的委托，最终到达 Charter 对该块的权威域名服务器。在这个交换过程中的某个地方，我的 DNS 服务器最终解析了 aa.ns.charter.com。我当时还不知道为什么。 这重新定义了一切。我不是在寻找“一个查询 Charter 的进程”，而是在寻找“一个对 Charter 空间内的 IPv6 地址执行反向 DNS 的进程”。 我检查了我的 AD 集成 DNS 区域中是否有任何包含该范围 IPv6 地址的记录： powershell 就在那里。我的局域网上的两台 Windows 机器已将其公共 IPv6 地址注册到我的内部 AD DNS 区域中，而这些地址位于 Charter 的空间内。客户端机器正在定期尝试为其 Charter IPv6 地址注册反向 PTR 记录，而域控制器正在转发该注册所需的名字服务器查询。 现在问题变成了：Charter 的基础设施到底出了什么故障，导致这个查询产生 `0\.0\.0\.0` 响应？ ## Charter 的踪迹 我从根服务器向下追踪委托链到 Charter，寻找 `aa\.ns\.charter\.com` 进入画面的位置。 委托看起来是干净的。IANA 指向 ARIN 的域名服务器用于 `6\.2\.ip6\.arpa` 父区域。ARIN 将 `c\.6\.0\.0\.6\.2\.ip6\.arpa`（Charter 的 `2600:6c00::/24` 反向区域）委托给 `auth1`–`auth4\.charter\.com`。这些是 Charter 当前的权威域名服务器，当我查询它们时，它们以权威方式响应。 那么 `aa\.ns\.charter\.com` 是从哪里进入链中的？ 我直接向 Charter 的权威服务器询问该反向区域的 SOA 记录： 就在那里。 SOA 记录，即 Start of Authority（授权起始），标识区域主域名服务器的记录，将 `aA\.ns\.charter\.com` 命名为主服务器。该主机名早已退役。它解析为 `0\.0\.0\.0`，大概是作为一种故意的空路由，以便任何仍试图将其用作域名服务器的客户端迅速失败并保持失败状态。 但 SOA 本身仍然引用它。序列号是 `2019081361`，解码为 2019 年 8 月 13 日。Charter 已经近七年没有更新这个 SOA 了。 这就是原因，尽管并非我最初设想的那样。我的机器并不是出于好奇而读取那个 SOA。它们正试图为其 Charter IPv6 地址注册一个反向 PTR 记录，而这是一个动态 DNS 更新。这些更新的协议是 RFC 2136，它说更新必须发送到区域的主域名服务器。为了找到主域名服务器，更新程序首先请求区域的 SOA，然后读取 MNAME（主域名服务器）字段，该字段命名了它。这个区域的 MNAME 是 aa.ns.charter.com。所以我的 DNS 服务器解析 aa.ns.charter.com 以获取发送更新的地址。Charter 返回 0.0.0.0。更新无处可去，而 Pi-hole 看到 0.0.0.0 答案并将其标记为已屏蔽。 这个 bug 很小：一个 ISP 的一个 SOA 记录的一个字段中有一个过时的主机名。但是，从那个字段到我的 Pi-hole UI 显示每天数十条“已屏蔽”条目，这一连串后果很好地说明了 DNS 如何以本地无人能看到的方式悄然崩溃。 ## Charter 为什么这样做？ 最可能的答案是“Charter 可能更新了他们的委托，但没有更新他们的区域文件”。 当 Charter 在 2010 年代的某个时候重构其权威 DNS 基础设施时，他们正确地将 ARIN 的委托更新为指向他们的新名称服务器（`auth1`–`auth4\.charter\.com`）。并且他们对旧主机名采取了谨慎的处理：不是完全删除它们（这会导致遗留客户端激进地重试 NXDOMAIN），而是将它们指向 `0\.0\.0\.0`。任何仍试图将其用作域名服务器的客户端都会以稳定、可预测的方式失败闭合。 这实际上是很好的工程。陷阱在于他们忘记更新区域内部的 SOA MNAME 字段。区域文件仍然将 `aa\.ns\.charter\.com` 命名为主域名服务器。大多数客户端从不读取 MNAME。它只是元数据，只有在有东西试图更新区域时才重要。但任何尝试动态更新的东西，比如注册反向 PTR 记录的 Windows 机器，都必须解析 MNAME 以找到发送更新的位置。而当它这样做时，它就生成了我所看到的噪音。 Charter 可能并不知道。这个 bug 从他们那边是沉默的。它不产生错误、客户投诉或运营影响。唯一注意到的人是在恰好拥有 Charter 地址空间中 AD 集成 AAAA 记录的环境中运行自己的递归解析器，并且恰好足够仔细地查看 DNS 日志以思考 `aa\.ns\.charter\.com` 在那里做什么的人。 ## 我遗漏了什么 此时我以为已经掌握了整个故事。我起草了一份 bug 报告发送给 Charter 的 NOC。我准备结束调查。 但我还有一个挥之不去的问题。每小时查询只来自 SKYE。而不是 BOYD。也不是 EMMA。为什么三个原本相同的 DC 中只有一个？ 我尽可能深入地检查了所有可能的差异。FSMO 角色。操作系统版本。计划任务。DNS 服务器缓存内容。清理设置。存根区域。条件转发器。没有任何东西能区分 SKYE 和其他两个 DC，从而解释原因。 最终我意识到我一直在查看错误的数据。我一直在搜索 Pi3 的查询日志。但 BOYD 的 DNS 转发器仅指向 Pi4，而不是 Pi3。如果 BOYD 生成相同的查询，它们会在 Pi4 上，而不是 Pi3。 我在两个 Pis 上安装了 sqlite3，并针对两个 pihole-FTL 数据库运行了相同的查询： sql 终端输出来自对 Pi4 的 pihole-FTL 数据库的 sqlite3 查询，显示来自客户端 192.168.2.10 的十五个每小时一次的 aa.ns.charter.com 查询。（https://mikehowells.com/wp-content/uploads/2026/05/2026-05-20_20-43-52.png）同样的查询，这次是在 Pi4 上而不是 Pi3 上运行。BOYD（192.168.2.10）整个时间也一直在生成相同的每小时 Charter 查找。我只是在查看错误的 Pi-hole，而且我还没有弄清楚域控制器上的哪个进程是罪魁祸首。综合来看，情况完全不同了。