AFRINIC 的乌干达 Anycast 节点其实是两项服务，不是一项

摘要

• UIXP 将两张 AFRINIC DNS 网络分别列为直连成员：AFDSP／NS2 使用 AS37177，DotARPA 使用 AS37181。AFRINIC 的部署指南又为它们分配了不同的 IPv4、IPv6 服务前缀。
• NS2 承担辅助权威 DNS，接收主服务器的区域数据，并不决定区域内容；DotARPA 属于独立的反向 DNS 基础设施。对其中一项服务的观测不能替另一项作证。
• UIXP 目录、AFRINIC RDAP 和 PeeringDB 记录能够证明身份与交换接口，却不能证明抓取时刻的 BGP 公告、路由服务器参与、本地查询命中、应用可用、时延或韧性。
• 可复核的“乌干达节点”凭证必须逐项服务记录：ASN、服务前缀、对等方式、启用与健康状态、所服务命名空间、观测点、应答实例和时间。

先不要过早把两行合成一个点

UIXP 对自己的目录写得相当克制。页面说明，列出的网络直接连接到交换中心的 peering LAN。AS37177 那一行名为“AFRINIC - DNS - AFDSP”，对等策略标为开放，加入年份为 2025；AS37181 那一行名为“AFRINIC - DNS - DotARPA”，同样标为开放和 2025。组织名称相同，网络号码与服务名称不同。

页面紧接着划出边界：若要判断成员是否使用路由服务器、又公告了哪些前缀，应当查询 looking glass。这不是一句无关紧要的免责声明，而是目录与运行证据之间的分界。目录表明某个 ASN 在交换网络上有一个可建立对等关系的接口；它并不描述此刻 BGP 会话是否建立、过滤器允许了什么、哪些邻居接受了什么路由，更不描述某台解析器最后把数据包送到了哪里。

PeeringDB 的公开 API 从另一侧印证了这两个接口。在冻结的响应里，AS37177 与 AS37181 都出现在 UIXP 的 ix_id 422 下。AS37177 的 peering LAN 地址尾部是 IPv4 的 .5 和 IPv6 的 ::5；AS37181 的地址尾部则是 .6 与 ::6。它们是交换网络上的互联地址，不是 DNS 服务向外发布的 Anycast 前缀。

两类地址回答不同问题。对等地址回答“路由器在哪里见面”；服务前缀回答“这次会话可能把哪个目标带给邻居”。只知道前者，不能推导后者已经公告；看见后者的注册记录，也不能推导它已经通过这一个交换点传播。把对等地址、服务地址和 DNS 应答地址混写在同一格里，会制造一种虚假的连续性，仿佛从目录行可以直接走到用户体验。

因此，公开地图用一个 Kampala 标记代表合作地点，并非必然错误。但运行账本若也只有一个标记，就会丢掉最有用的信息：这是同一交换表面上的两名路由主体、两套服务链。

AS37177：NS2 的身份与权限边界

AFRINIC 的 Anycast 部署指南把 NS2 明确映射到 AS37177，并给出 IPv4 前缀 196.216.168.0/24 和 IPv6 前缀 2001:43f8:120::/48。项目主页把这项服务描述为面向非洲国家和地区顶级域名及区域 DNS 基础设施的 Anycast 辅助服务。

“辅助”决定了它能做什么，也决定了它不能替谁作决定。AFRINIC 在 DNS 支持页面把 AfDSP 解释为 secondary／slave DNS：区域数据由主服务器传送过来，AFRINIC 不管理区域内容。它可以维护一份具有权威应答能力的副本，并通过分布式路由增加可达路径；它却不因为托管副本而取得修改域名、资源记录或区域政策的权力。

这个区分让服务的重要性更准确，而不是更弱。辅助 DNS 的价值恰恰来自控制面的分离：区域管理者保留内容决定，服务运营者负责把既定数据可靠地送到更多位置。若把“托管”写成“管理”，故障时就会向错误主体追问；若把“辅助”写成“无关紧要”，又会忽视它对权威应答连续性的贡献。

这也说明本稿为何不重复此前对 AFRINIC ccTLD 地图的统计。区域清单回答哪些域可能使用 NS2；UIXP 的问题则是 AS37177 的服务前缀是否从乌干达实例被公告，哪些网络学到了路由，哪些查询确实落到了那里。前一项研究可以靠域名、地址和前缀归属做集合连接，后一项必须加入时间、BGP 视角、应用健康与查询实例。二者共用若干来源，但证明对象并不相同。

AFRINIC RDAP 记录确认 AS37177 以及上述 IPv4、IPv6 地址块归在 AFRINIC 的组织记录下。这是稳固的注册身份线索，却不是实时路由表。RDAP 不会告诉我们抓取时 196.216.168.0/24 或 2001:43f8:120::/48 是否出现在 UIXP looking glass，不会说明公告经过路由服务器还是双边会话，也不会标出接收查询的物理或虚拟实例。

从注册身份到一条 DNS 回答，至少要跨过五道接缝：服务前缀被正确公告，邻居按策略接受，路由选择把数据包送往某个 Anycast 站点，站点的 DNS 进程处于健康状态，所查询的区域又确实装载在这项服务上。公开页面把第一组身份写清楚了，但它没有假装其余步骤已经完成。

AS37181：DotARPA 不是 NS2 的别名

DotARPA 使用另一组标识。部署指南把它映射到 AS37181、IPv4 前缀 196.216.169.0/24 和 IPv6 前缀 2001:43f8:110::/48。这两组前缀与 NS2 的数值很接近：IPv4 只在一个八位组上相差一，IPv6 也只替换了一个字段。相似便于管理，却也特别容易在表格或告警里被抄错。号码相近不是服务相同的证据。

功能同样不同。AFRINIC 将 AS37181 描述为与 RFC 5855 所规定的反向 DNS 基础设施相关的 DotARPA 服务。RFC 5855 为 IN-ADDR.ARPA 和 IP6.ARPA 使用专门的名称服务器身份，目的是把反向树从其他 DNS 功能的共同故障域中分离出来。独立 ASN 和服务前缀让这种职责区分在路由层也变得可见。

但“反向 DNS 基础设施”并不等于“非洲所有 PTR 查询都会在这里回答”。DNS 查询需要沿委派、转介与缓存工作；Anycast 又让路由决定某个来源到达哪一份实例。具体结果取决于查询名称属于哪个命名空间、递归解析器是否已有缓存、解析器能看见哪些路由，以及被选实例的应用状态。只有逐查询、逐时间的观测，才可以把 UIXP 这一位置加入因果链。

DotARPA 也不能因为与 AFRINIC 的 root-server-copy 项目都涉及 DNS 分布，就被写成根服务器。AFRINIC 对根服务器副本项目的介绍明确说，AFRINIC 是促成者而不是副本运营者；实际运营责任仍属于对应的根服务器组织。NS2、DotARPA 和根副本可以在同一基础设施政策讨论中出现，却有不同的权威来源、运营主体与故障含义。

AS37181 的 RDAP 与 PeeringDB 记录所证明的内容，和 AS37177 一样有限而重要：资源登记在谁名下、在什么交换场所有什么接口。它们既不证明当前公告，也不证明查询响应。更关键的是，任何来自 AS37177 的成功测试都不能拿来填补 AS37181 的空白。

Anycast 把“在哪里”变成一个观测结果

Anycast 的基本机制是让多个服务实例公告相同地址，由路由系统根据每个来源可见的路径选择其中一个。用户无需手动挑选站点，运营者也能在多个地点提供同一个服务入口。代价是“节点在本地”不再是一句自足的事实。

“在乌干达”可能有四层含义。第一，设备或虚拟机部署在乌干达设施中；第二，服务 ASN 在 UIXP peering LAN 上有接口；第三，本地网络确实学到了服务前缀；第四，某个本地解析器发出的查询由乌干达实例回答。四层之间有合理联系，却不存在自动继承。机器可以存在而路由未公告，路由可以存在而应用失效，应用可以健康而某家网络选择别的路径，查询也可能因缓存根本没有到达权威服务器。

RFC 4786 特别提醒，BGP 可达不等于应用健康。若 DNS 进程故障而前缀仍在公告，路由系统会高效地把查询送进一个不能工作的实例。Anycast 运营因此需要把应用健康与路由撤回或流量抑制机制相连。仅靠“BGP 有路由”的绿色状态，无法替代端到端查询。

相反，DNS 进程可以完全健康，本地网络却不一定选择它。该网络也许没有参加路由服务器会话，也许期待双边对等，也许因过滤规则没有接受前缀，或者自身路由政策偏好另一站点。Anycast 选择的是 BGP 拓扑与政策下的路径，不是地图上的直线距离；地理上最近的实例不保证成为路由上最优的实例。

RFC 7094 由此把 Anycast 的效果定义为需要多观测点测量的对象。一个 looking glass 只能说明一个收集器看到的路由；一个 DNS 探针只能说明一个来源在一个时刻收到的回答。要谈区域模式，应当在分布式观测点重复测量，并能识别或可靠推断应答实例。没有实例身份，低时延也可能来自另一站点；没有连续时间，单次成功也不能代表可用率。

AFRINIC 的项目说明把性能与韧性列为预期收益。这些目标与 Anycast 架构相符，不能因为本稿强调证据边界就被反向写成“没有收益”。冻结的来源包只是不包含 UIXP 接入前后的对照时延、故障切换试验、持续可用率或区域查询落点分布。因此，最强结论应当停在“具备实现收益的架构与接入表面”，而不是越过缺失数据宣称“收益已经被测得”。

两项服务背后还有一条共担责任线

部署指南不仅列地址，还列出主机方的能力门槛：需要具备 BGP 能力，区分管理网络与 peering 网络，并提供可运行 OVA 的环境。公布的最低虚拟资源为两颗虚拟 CPU、4GB 内存和 10GB 磁盘。这些是部署接口，不是 UIXP 现场拓扑图。来源没有说明两项服务是否各自运行在一台虚拟机、是否共用物理服务器、是否具备冗余节点，也没有给出机房级布局。

职责被分配给不同主体。主机方提供基础设施、电力与网络连接，维持可用条件并在中断时通知 AFRINIC。AFRINIC 维护软件与配置，负责安全事项，协调 BGP，监控服务健康，并与主机共同排障。这种分工是正常的专业协作；它也意味着“AFRINIC 节点故障”不足以构成诊断。

若 BGP 路由仍在、DNS 却不回答，需要同时检查应用健康、撤路逻辑以及软件或主机基础设施。若 DNS 健康、某个 UIXP 成员却学不到路由，问题可能位于路由服务器参与、双边会话、前缀过滤或成员自己的策略。若 NS2 正常、DotARPA 失败，一个总括的“节点在线”状态会掩盖一半事实。若 IPv4 正常而 IPv6 缺失，按 ASN 聚合也仍然太粗。

责任凭证不应急于找一个承担所有后果的机构，而应保留每个可控交接点：哪项服务、哪个 ASN、哪个地址族、哪种对等方式、哪条健康信号、哪份实例观测，以及谁有能力修复该接缝。只有这样，公开问责才不会变成把复杂服务推给最显眼的名字。

五类公开记录不能相互冒名

要判断现有资料到底说了什么，可以把它们分成五类。第一类是项目说明，回答 AFRINIC 希望提供什么服务、架构的目标是什么。第二类是资源登记，回答 ASN 与地址块登记在谁名下。第三类是交换目录，回答谁在 peering LAN 上留下了什么接口。第四类是路由观测，回答某个收集器在某个时刻从哪个邻居学到了哪个前缀。第五类是应用观测，回答具体查询由哪个实例以什么结果处理。

前面三类都在冻结来源中，后面两类没有被本稿捕获。缺少后两类，不会推翻前面三类；同样，前面三类再完整，也不能替后两类说话。这种排列避免了两种常见错误：一种是因为没有公开测量，就声称服务不存在；另一种是因为服务身份和接入都很清楚，就假定运行效果已经得到证明。

项目说明本身也需要按语气读取。AFRINIC 描述 Anycast 对性能与韧性的预期，是一项架构主张；它告诉主机与参与者为什么要部署，而不是一份 UIXP 现场的测量结果。要把“预期”升级为“已实现”，至少需要定义基线、观测范围和成功条件。没有基线，低时延可能原本就存在；没有范围，一个城市的样本不能代表一国；没有成功条件，偶尔命中本地实例不能等同于稳定本地化。

RDAP 则几乎走向另一端。它适合证明资源身份与登记范围，不适合证明运行。即使登记完全正确，路由也可能尚未公告、被过滤、被撤回或从另一站点出现。反过来，一条现场看到的路由也不能单独证明其登记、用途与运营授权。将注册与路由放在同一凭证里，不是为了让一方替代另一方，而是为了发现两者不一致时必须停下来复核。

UIXP 与 PeeringDB 的目录位于中间。它们比抽象项目说明更接近互联现场，却仍是声明性记录。“开放”对等策略意味着愿意建立某类关系，不等于每个成员已经与其交换路由；“直接连接”意味着接口位于交换网络，不等于服务前缀此刻可见；成员年份可以说明目录中的时间属性，却不能替代安装、启用、首次公告或首次成功查询的时间。

真正的路由记录需要把前缀写出来。对 AS37177，应分别查找 NS2 的 IPv4 与 IPv6 前缀；对 AS37181，应分别查找 DotARPA 的另一对前缀。若 looking glass 只显示 ASN 而不显示路径与前缀，证据仍然不足；若只显示其中一个地址族，也不能把结果扩大到双栈。路由服务器视角还应和至少一个参与网络的视角对照，因为收集器看到的最佳路由不一定等于每个成员实际选择的路由。

应用记录要比“端口可达”更具体。DNS 查询需要标明名称、类型、递归或权威模式、返回码、应答内容摘要、实例识别方法与时间。若目的是证明本地实例，应说明识别依据，而不能仅用往返时间猜测；若目的是证明辅助区域完整，应将期望区域清单与实际加载状态连接；若目的是证明故障切换，应记录健康变化、撤路时间和流量重新落点，而非只截取恢复后的成功响应。

这五类证据分开保存之后，争议就能被缩小。有人质疑“节点是否存在”，可检查基础设施与交换接入；有人质疑“路由是否本地”，可检查 looking glass 与成员视角；有人质疑“DNS 是否工作”，可检查逐实例查询；有人质疑“谁决定区域内容”，则回到主服务器与辅助服务器的权限分工。一个总括的绿色状态无法提供这种定位能力。

用反证保护结论

一项稳健结论还应说明什么现象会让它改变。若 UIXP looking glass 显示两对服务前缀都经可识别会话稳定出现，目录证据就能向路由证据前进一步。若多个乌干达网络的探针持续识别出本地 AS37177 与 AS37181 实例，并有与外部基线可比的时延数据，就可以对“本地化”和“性能”提出有范围的结论。若应用故障后路由按设计撤回并由其他站点接管，则可以对特定故障情景下的韧性提出证据。

反方向也一样重要。若只看到两条 PeeringDB 接口而看不到服务前缀，不能说部署失败，只能说运行证明尚未闭合；接口记录可能领先或滞后于现场状态。若一个探针落到别处，也不能直接说乌干达实例失效，因为路由政策可能有意选择另一条路径。若 NS2 正常而 DotARPA 没有观测，不能把“一个成功、一个未知”改写成“整个节点正常”或“整个节点异常”。

这种反证纪律并不追求怀疑一切。它保护的是每个证据对象的含义，让后续新增资料真正提高信息量，而不是迫使它们去修补一个过大的旧结论。对运行团队而言，能够明确说“此刻只证明到交换接口”比一个无法定位问题的笼统成功状态更有用。

一项节点叙事，需要两张服务凭证

凭证可以很小，却不能把两项服务压成一行。NS2 的固定身份应写作 AS37177，加 196.216.168.0/24 与 2001:43f8:120::/48；DotARPA 的固定身份应写作 AS37181，加 196.216.169.0/24 与 2001:43f8:110::/48。UIXP 的 .5／::5 与 .6／::6 对等地址应存放在独立字段，避免被误认成公开 DNS 服务地址。

路由部分按 IPv4、IPv6 分别记录：预期前缀是否可见，由哪个收集器看见，从哪个邻居或路由服务器学到，观测时间是什么。应用部分记录被检查的服务类别或命名空间，健康状态如何作用于路由，以及用什么实例标识确认应答位置。查询部分记录观测点、解析模式、查询名称与类型、响应码、时延和时间戳。测量批次的哈希可以让简洁摘要指向未被替换的原始数据。

这张凭证不会寻找一个万能字段。“已启用”不能证明当前路由；当前路由不能证明 DNS 健康；一次正确回答不能证明全部预期区域都已装载；一个低时延样本不能证明区域性改善；成员加入年份也不能被当成安装、首次公告或首次查询日期。可信度来自这些字段之间的明确接缝，而不是某个字段看上去足够权威。

对 UIXP 而言，这种凭证让其现有目录提示获得可执行的下游路径。对 AFRINIC 而言，它既能展示项目实际运行，又不会混淆 NS2 与 DotARPA 的职责。对准备建立对等关系的网络而言，它把需要接受的具体服务前缀摆在桌面上，而不是要求工程师从组织名猜测路由。

现有证据已经支持一句准确的话：两项具有不同 ASN、不同服务前缀和不同 DNS 职能的 AFRINIC 网络，被 UIXP 列为直接连接成员。现有证据还不支持一句更悦耳的话：一个乌干达节点已经让所有相关查询本地化、加速并获得韧性。后一句可以通过测量变成事实；在那之前，它需要两张凭证，而不是一个地图点。

来源

1. AFRINIC DNS Anycast 部署指南：https://dns.afrinic.net/deployment-guide/
2. AFRINIC DNS 项目主页：https://dns.afrinic.net/
3. UIXP 联网成员目录：https://www.uixp.co.ug/networks
4. UIXP 服务与路由服务器说明：https://www.uixp.co.ug/services
5. AFRINIC AfDSP 辅助 DNS 说明：https://afrinic.net/dns-support.html
6. AFRINIC 根服务器副本项目：https://afrinic.net/root-server-copy.html
7. RFC 5855：https://www.rfc-editor.org/rfc/rfc5855.html
8. RFC 4786：https://www.rfc-editor.org/rfc/rfc4786.html
9. RFC 7094：https://www.rfc-editor.org/rfc/rfc7094.html
10. RFC 1034：https://www.rfc-editor.org/rfc/rfc1034.html
11. AFRINIC RDAP，AS37177：https://rdap.afrinic.net/rdap/autnum/37177
12. AFRINIC RDAP，AS37181：https://rdap.afrinic.net/rdap/autnum/37181
13. AFRINIC RDAP，196.216.168.0/24：https://rdap.afrinic.net/rdap/ip/196.216.168.0
14. AFRINIC RDAP，196.216.169.0/24：https://rdap.afrinic.net/rdap/ip/196.216.169.0
15. AFRINIC RDAP，2001:43f8:120::/48：https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
16. AFRINIC RDAP，2001:43f8:110::/48：https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
17. PeeringDB API，AS37177：https://www.peeringdb.com/api/netixlan?asn=37177
18. PeeringDB API，AS37181：https://www.peeringdb.com/api/netixlan?asn=37181