摘要

  • ZDNS 的 ICANN 材料、AS38345 路由公告和多个顶级域委派，足以支持“网络与逻辑服务证据为中等”这一判断，却不足以证明每个地点各有一套独立设备、链路和故障域。
  • 北京 M5 三期的 732 个机柜、两台 3,517 千瓦冷机、两座 84 立方米蓄冷水池和五台 2,500 千伏安柴油机组，都是托管设施总量，不能计入 ZDNS 自有或可用容量。
  • 对采购方真正有意义的不是地点数或峰值宣传，而是逐站点功能、已装与备用资源、最大站点退出后的承载余量，以及路由撤回、数据库恢复、DNSSEC 应急和托管数据恢复的有日期实测结果。

先把一个“全球能力”问题拆成两条证据线

评估权威 DNS 或注册局后台服务时，最容易出现的错误，是把能在互联网中看到的东西与能在机房里归属的东西相加，最后得出一个看似完整、实际上无法核算的“全球容量”。ZDNS 的公开材料正好说明为什么这种算法站不住脚。一边是很容易观察的逻辑与网络表面：ICANN 列表中的服务类型、自治系统公告的 IPv4 与 IPv6 前缀、根区委派中出现的权威端点，以及分布在不同城市的托管依赖。另一边则是更难回答的物理问题：每个地点究竟装了多少属于或专供 ZDNS 的服务器、交换端口和安全设备，平时用了多少，最大站点下线以后还剩多少。

这两条线都重要，但它们的证据强度不同。公开材料足以让我们把网络与逻辑服务证据评为“中等”：服务范围有正式申请记录，路由表面能够被多个数据源观察，顶级域委派也显示出真实的权威服务关系。不过，对“可归属于 ZDNS 的物理容量”和“可用的故障切换余量”，证据只能评为“弱”。八个地点行不是八套可审计设备，732 个机柜也不是 ZDNS 的机柜数，前缀数量更不是服务器或吞吐量的替代单位。

因此，本文不会给 ZDNS 一个混合后的单一容量分数。这样做不是谨慎到拒绝判断，而是先选对判断对象。采购方可以合理确认其存在广泛可见的 DNS 网络和一套多层服务组合；采购方同样应该明确，公开记录没有把这套组合逐一落到账面化的物理资产、故障域和剩余承载能力上。只有把两条证据线分开，地点、路由、机柜和恢复承诺才不会互相冒充。

还需要把“物理资产、已装能力、可用余量、恢复成绩”再拆成四层。机柜、冷机和柴油机属于设施资产；放入其中并接入网络的服务器与安全设备才形成已装能力；扣除普通负载、峰值负载和共享占用以后，剩余部分才可能成为故障切换余量；真正让余量具有可信度的，则是故障发生后成功接管并恢复正确状态的测试结果。前一层是后一层的必要条件，却从来不是充分条件。大型机房可以只给某租户很小的配额，充足设备也可能被日常负载占满，而闲置设备若没有数据、密钥、路由和操作准备，仍不能在目标时间内接替。

证据等级也不是对企业优劣或事故概率的直接评分。“弱”表示外部材料不足以量化归属和余量，不等于已经证明没有冗余；“中等”表示多类公开记录互相支撑网络与服务存在，也不等于每一次查询和变更都得到持续审计。这样的语言边界很重要：它既防止以未知代替负面事实，也防止以局部正面记录覆盖未回答的问题。采购决策可以在此基础上确定下一步所需材料，而不是把研究结论误读成一张万能的安全证书。

公司身份可核对，但旧登记不能被写成一条想象中的沿革

目录中的法人标签保留了 “ZDNS Internet Domain Name System Beijing Engineering Resrarch Center Ltd.” 这一拼写，其中 “Resrarch” 出自 APNIC 持有人记录。当前 ICANN 申请则使用修正后的公司名称，并列出商用名称 ZDNS。对研究者而言，两个写法的差异首先是记录口径问题，而不是“两家公司”的证据。APNIC 的 AS38345 RDAP 记录和ZDNS 联系页面可以帮助核对这些标签，但拼写差异本身不支持另设主体、改组或转让的结论。

时间线也需要同样克制。ZDNS 的公司介绍页面把成立时间表述为 2013 年，而 AS38345 的登记早于这一时间；APNIC 的 AS38345 Whois 查询还保留较早的 KNET 联系信息。这里能够确认的只有“网络登记历史比公司自述成立时间更早”以及“旧联系信息仍在登记材料中”。公开事实并没有给出收购、前身、资产承继或所有权链条，所以不能为了让时间线更顺畅，就自行补上一段企业沿革。

这项身份辨析看似与容量无关，实际上决定了资产归属研究的起点。如果研究者把历史自治系统记录直接视为当前公司自建资产，就会把登记时间误当成设备持有时间；如果又把托管设施总量并入，误差会进一步放大。更可靠的做法是逐层保留名称、登记主体、当前申请主体和商用名称，并在出现证据空白时停下来。身份能够关联，并不意味着过去每一项网络资源或现在每一处机房基础设施都已经完成了法律与运营归属证明。

ICANN 的通过记录说明服务资格范围，不等于持续审计每次部署

在 2026 年的新通用顶级域名计划中，ICANN 已评估注册服务提供商申请列表记录 ZDNS 已通过 Main、DNS、DNSSEC 和 Proxy 四类服务，并具备国际化域名支持。这是一条分量很重的逻辑服务证据，因为它来自正式评估记录，而不是单纯的市场自述。ICANN 对 2026 年 RSP 计划的说明则给出了这类评估所处的制度背景。

不过，“申请通过”回答的是提交材料是否满足相关评估要求，不是对所有客户、所有地点和每一时刻的持续认证。它不会自动告诉读者：八个地点各承担什么功能；同一套硬件是否在不同服务之间共享；某个站点停机时还有多少备用算力；某次配置错误发生后实际恢复了多久。即使服务类型写得很完整，也不能把评估结论延伸成对每一项运行状态的实时背书。

ZDNS 的 Main RSP 申请还提供了备份、监控、恢复控制和全天候响应等陈述，这使我们能够描述其控制设计，却仍不能替代有日期的演练结果。评估材料与运行实绩之间并非互相否定：前者回答“设计和承诺是什么”，后者回答“在指定负载和故障条件下是否做到”。把这两个问题混为一谈，既会高估评估的含义，也会错过采购尽调中最值得追问的实证部分。

注册局、托管解析与客户侧设备是三种不同的运行表面

ZDNS 的产品范围很宽。ICANN 基础注册局协议所处的注册局制度环境，与公司页面展示的顶级域平台、云解析和核心设备并不是同一个层次。ZDNS 顶级域平台涉及注册局功能、数据托管、DNSSEC 以及 WHOIS/RDAP 等能力；ZDNS 云解析页面介绍权威 DNS、全局流量调度、HTTPDNS 和 BGP/任播等网络服务；ZDNS 核心设备页面则呈现可部署到客户环境的独立设备线。

这三种表面必须分开核算。注册局后台关心域名对象、数据库、托管数据与签名状态；托管权威 DNS 关心公告前缀、节点健康、查询负载与缓存之外的权威一致性；客户侧设备又可能运行在客户自己的机房、网络和变更制度之下。一个产品名称覆盖多个功能，并不意味着这些功能共享同一地点、同一故障域或同一恢复目标。反过来，客户侧设备数量也不能拿来增加 ZDNS 托管网络的机柜数。

这种分层还影响“服务中断”的含义。权威节点在某个城市不可达，未必意味着注册数据库停止更新；注册数据库可以访问，也不代表所有权威端点已经获得正确区域数据；DNSSEC 签名状态异常时，纯粹增加普通查询服务器可能没有帮助。采购方若只问“你们有多少节点”，得到的往往是把不同层次合在一起的答案。更有效的问题是：哪一项服务由谁运行、状态保存在何处、依赖哪些托管方、切换时需要哪些共享控制面，以及各层的恢复证据是否分别存在。

八个地点行证明托管依赖，不能直接当作八个独立节点

ZDNS 申请所附的数据中心材料列出八行地点：北京的 CSNET、北京酒仙桥、成都、香港 HKIX，以及 Cogent 在洛杉矶、芝加哥、法兰克福和纽约的地点。这份表很有价值，因为它把抽象的“全球”落到了具体地名和外部依赖上。HKIX 公共运营网站与Cogent 网络地图也能帮助理解其中两个托管或互联环境，但它们不会自动揭示 ZDNS 在这些环境中的专属资源。

材料把北京、香港、洛杉矶、芝加哥、法兰克福和纽约与任播关联，把酒仙桥和成都与单播服务关联。这里应注意“北京”这一城市标签与“酒仙桥”这一具体行不能重复计算成同一种部署。更重要的是，每一行描述的是服务对某一地点或网络环境的依赖，不是对一套独立物理节点的盘点。公开附件没有逐站点列出服务器台数、设备型号、交换端口、上联路径、地址映射、实时负载或承担的具体服务。

八行也不能自然等于八个故障域。两个地名不同的站点可能共享上游、控制面、软件版本、密钥状态或变更操作；同一城市的两个环境也可能具有真正的物理隔离，但需要链路和运营证据才能确认。海外四行都写有 Cogent 地点，这能证明地理分布，却不能单凭品牌和城市名确认入口、骨干、供电与远程运维完全独立。合理结论是“公开材料列出八项地点依赖”，而不是“ZDNS 拥有八座独立数据中心”或“任意七处都能接管最大一处的全部流量”。

732 个机柜属于宿主设施的边界，不属于 ZDNS 的容量账本

最醒目的数字来自北京 M5 三期证书附件：三个机房合计 732 个机柜，两台各 3,517 千瓦的冷机，两座各 84 立方米的蓄冷水池，以及五台各 2,500 千伏安的柴油机组。附件还明确，网络和布线不在证书范围内。数字如此具体，很容易让人产生“终于找到 ZDNS 物理容量”的错觉；然而同一份数据中心材料给出的其实是宿主设施总量，没有说明其中任何一个机柜、任何一瓦制冷能力或任何一台柴油机由 ZDNS 所有、专用或可在故障时调用。

因此，732 只能作为宿主依赖的证据：ZDNS 申报的服务与一处具备这些总体设施属性的环境有关联。它不能被写成“ZDNS 拥有 732 个机柜”，也不能与另外七行地点相加生成全球机柜总数。证书覆盖的设施总量与租户获配容量之间，至少还隔着租用范围、实际装机、功率上限、网络端口、交叉连接、共享冗余政策以及合同优先级等未知项。尤其在网络和布线排除在证书范围之外时，机电冗余并不能替代 DNS 服务最依赖的对外连通证据。

怀柔相关描述则给出约 20,000 平方米和超过 1,000 个机柜的总体规模，中国科学院计算机网络信息中心的机构介绍可用于理解这一机构背景。这里同样只能谈设施属性，不能把面积或柜数分配给 ZDNS。两个大型设施数字并列，也不能证明两边各有足以承载全部业务的镜像部署。要把宿主规模变成 ZDNS 可用容量，至少需要看到租用或专用范围、已装和备用设备、功率与网络承诺，以及故障时资源不会被其他租户或其他服务占用的说明；这些细节没有出现在所审阅的公开材料中。

AS38345 展示真实的双栈路由表面，但路由不是服务器清单

在观察期间，AS38345 公告了 24 个 IPv4 /24 和 12 个 IPv6 /48，并在广泛的路由收集点可见。RIPEstat 的自治系统概览、已公告前缀数据和路由状态数据从不同角度呈现这一网络表面，Cloudflare Radar 的 AS38345 页面则提供另一项公开观察入口。对于“这个网络是否在公开互联网中活跃、是否同时存在 IPv4 与 IPv6 公告”而言，这些是有意义的证据。

但一个 /24 或 /48 不是一台服务器，更不是一份吞吐量承诺。前缀可以由少量设备公告，也可以承载大量后端；同一前缀可以借助任播从多个地点出现，而多个前缀也可能集中依赖同一控制面或少数物理环境。路由收集器能看见的是控制平面的可达公告，不能直接看见查询成功率、响应时延、设备健康、机柜归属、端口利用率和可抵御的攻击余量。

“广泛可见”也不等于“物理路径广泛独立”。RIPEstat 的 ASN 邻接数据与路由一致性数据可帮助分析外部路由关系，但仅凭邻接或一致性观察，仍不能确认光纤是否走不同管道、不同城市是否共享上游瓶颈，或一个配置变更是否会同时影响多个公告点。路由证据应被用于确认网络存在和公告范围，而不是被折算为未公开的物理容量。

顶级域委派说明真实服务关系，却不披露客户隔离和节点归属

IANA 根区记录为研究提供了另一条强于市场表述的线索。.baidu 委派记录、.icbc 委派记录和.unicom 委派记录都把 ZDNS 列为技术联系人，并呈现共享的权威端点模式。这说明 ZDNS 与真实顶级域的技术服务关系可以从根区层面观察，不只是产品页面上的能力宣称。

不过，委派记录的职责不是披露底层资产。它告诉解析器应向哪些权威名称或地址询问，却不告诉读者这些端点背后有多少实体服务器、是否为每个客户保留独立资源、数据库和签名系统如何隔离、某个地址在哪座机房终止，或突发流量到来时各客户之间如何分配余量。多个顶级域使用相似端点模式，既可能体现共享网络的规模效应，也可能形成共享依赖；在缺少配置和负载资料时，两种含义都不能被单方面断言。

对采购方来说，顶级域委派最适合回答“服务是否真实落入公共 DNS 链条”，不适合回答“每个域得到多少专属容量”。如果要进一步评估集中风险，需要把名称服务器、地址、路由起源、站点功能、签名与数据库依赖连接起来，再观察共同失效点。当前公开记录能够建立这条分析路径的前半段，却没有给出足够的设备与客户隔离明细来完成后半段。

四组地址观察到多个路由起源，仍不能据此认定设备所有权

对选定权威地址的网络信息观察，涉及 203.99.24.1、116.169.54.111、223.72.199.37和2401:8d00:2::1。这些样本合起来显示，所观察的权威地址从 AS38345、AS4837、AS56048 和 AS24149 等不同自治系统起源出现。它扩展了“所有服务只由 AS38345 承载”的简单图景，也与附件中存在多种网络依赖的情况相呼应。

这里仍然不能跨过归属边界。路由起源说明某个前缀由哪个自治系统向外公告，不说明服务器由谁购买、机柜由谁租用、服务合同如何安排，也不证明不同自治系统一定通向不同设施或不同管道。即使地址分属不同起源，也可能共享控制软件、数据源、密钥管理或远程操作；即使同一自治系统起源，也可能在多个物理地点通过任播提供服务。

因此，多个起源更适合作为“进一步查明依赖关系”的提示，而不是可直接加总的冗余单位。理想的站点与功能矩阵应说明每个权威地址在哪些地点公告、由哪些网络承载、对应哪些服务和客户、撤回由谁触发，以及剩余站点是否具备接管流量的资源。公开网络数据给出了外部可观察部分，却没有补齐合同、设备、链路和操作边界。把路由起源称为“拥有四套独立基础设施”，会比证据多走好几步。

两个 RPKI 样本只能说明各自状态，不能变成永久安全评分

路由来源授权也是容易被过度概括的指标。研究时，对前缀 150.242.156.0/24 的RIPEstat RPKI 查询返回有效；对 1.8.1.0/24 的另一项 RPKI 查询返回未知。准确表述应当停留在这两个样本、这次观察和各自返回状态上。

“有效”表示该样本的可见路由起源与相应授权相符，它是积极信号，但不能覆盖自治系统的全部前缀，也不能保证 DNS 应用、服务器或数据本身安全。“未知”则表示未能依据可见授权把样本判定为有效或无效，不能写成发生劫持，更不能据此判定整个网络不可信。RPKI 状态会随着授权和公告变化，两个样本不构成永久性的总体得分。

对于 DNS 服务韧性，RPKI 只是路由控制的一部分。它不能说明任播节点是否健康、错误节点会不会继续公告、上游是否执行路由起源验证，也不能说明应用层是否返回正确答案。采购方可以要求完整前缀清单、授权覆盖情况和异常处置记录，但不应把单次查询的颜色标识等同于全网安全结论。正面的样本值得保留，未知样本也值得追问；二者都必须按其真实范围解读。

任播能绕开干净退出的节点，却不能替代剩余容量和状态恢复

任播的价值在于，多个地点可以对外呈现同一地址，网络根据路由选择把查询送往可达实例。按照 RFC 4786 对任播服务运行的讨论，当故障节点干净撤回公告，路由能够重新收敛到仍在工作的地点。对权威 DNS 这类无连接查询服务而言，这是一种重要的分发与故障绕行手段。附件把六个城市标签与任播关联，也说明 ZDNS 的公开设计利用了这种机制。

然而，任播成功切换至少依赖两个条件：坏节点真的停止吸引流量，活节点还有足够能力接住流量。如果节点应用已失常却继续发布路由，用户可能仍被送到错误实例；如果最大站点退出后，其余站点已接近峰值，路由收敛只会把拥塞搬到别处。任播也无法修复被复制到所有节点的错误区域数据、全局错误配置、损坏数据库或丢失的签名状态。网络路径绕行与服务状态恢复是不同工作。

RFC 2182 关于辅助 DNS 服务器的建议强调避免共同失效条件，这为评估地点分布提供了更合适的视角：不是数地名，而是看服务器是否真正处于不同网络和故障环境。单播的酒仙桥和成都又提出另一组问题，它们承担什么功能、如何切换、地址是否变化、依赖哪些客户端或控制面。仅有“任播加单播”的标签，仍不足以计算最大站点丢失后的可用余量。

真正有说服力的证据应是一场有边界的故障试验：明确撤回哪个站点、在什么普通与峰值负载下进行、路由多久收敛、错误率和时延如何变化、其余站点最高利用率是多少，以及恢复原站点时是否出现振荡。没有这些数据，任播可以支持“具备绕行设计”，却不能支持“任意站点失效都无容量影响”。

宣传吞吐量说明目标尺度，不说明负载条件和站点余量

ZDNS 公布的能力数字包括每秒 3,000 次签名操作、15,000 对密钥、每秒 16,000 至 27,000 次 WHOIS/RDAP 查询、每天 20 亿次 DNS 解析，以及超过 99.999% 的可用性。这些数字集中出现在其顶级域平台等一方材料中，能够帮助读者了解产品希望表达的服务尺度，但公开页面没有同时给出带日期的方法、工作负载定义、设备清单、实际利用率、逐站点分配或最大站点失效后的测试结果。

不同单位也不能直接相加。签名操作受密钥保护设备和签名策略影响，密钥对数量更接近管理规模；WHOIS/RDAP 是面向注册数据的查询，DNS 解析则是另一类协议和缓存行为；每天 20 亿次若平均分布，与集中在短时峰值的资源需求完全不同。99.999% 若没有测量窗口、服务边界、排除项和失败定义，也无法换算成某个客户实际经历的中断时间。一个总量数字可能来自实验环境、设计上限、单项设备或多站点聚合，公开信息没有把这些口径逐一锁定。

采购方应把宣传数字当作可核验假设，而不是已完成的容量证明。问题可以从“最大是多少”改成“在什么请求结构、响应大小、签名比例、网络攻击背景和持续时间下达到；当最大站点退出时还能维持多少；数据是否来自当前安装环境”。若对方能提供按站点的普通负载、峰值负载和保留余量，再配合故障试验，数字才会变成可用于架构与合同判断的能力。否则，精确到千位的吞吐量仍可能比“有多少可用余量”更模糊。

两座 Tier III 或同等数据中心的陈述仍缺一张资源分配表

Main RSP 申请陈述至少使用两个相互独立、达到 Tier III 或同等标准的数据中心，并描述备份、监控、恢复控制和 24 小时值守响应。Uptime Institute 的等级概览有助于理解 Tier 概念关注的设施可维护性与基础设施安排，但不能替特定租户确认部署范围。申请中的“至少两个”是重要的设计陈述，却没有量化每处已安装硬件、备用硬件、端口承诺、抗攻击储备、最大站点业务占比或站点退出后的存活容量。

“相互独立”也需要按服务层解释。两座设施可以在供电和制冷上独立，却使用同一上游、同一远程运维权限、同一配置来源或同一密钥状态；也可能在网络和操作上做了充分隔离，但公开材料没有逐项展示。Tier 等级描述宿主设施的某些属性，不代表租户一定购买了所有冗余组件，更不保证应用在每个故障情形下自动恢复。

对 ZDNS 来说，最缺的不是又一个设施等级标签，而是一张把服务与资源对应起来的表。表中应至少区分注册数据库、托管数据、DNSSEC 签名、WHOIS/RDAP、权威 DNS、全局流量调度和管理控制；对每项服务列出主用与备用地点、普通和峰值负载、已装与空闲资源、网络依赖以及可接受恢复时间。只有这样，“两座独立数据中心”才能进一步回答“两座分别做什么”和“失去较大一座以后还剩什么”。

这也解释了为什么 732 个机柜不能弥补信息缺口。宿主设施可能规模巨大，而 ZDNS 只使用其中很小一部分；租户也可能拥有精心设计的小规模多站点部署。韧性取决于分配、隔离、负载和切换，不取决于楼内总机柜给人的视觉规模。没有资源分配表时，公开证据最多支持设施依赖和控制意图，不能支持可归属容量总数。

密钥轮换与每日托管是控制设计，最近一次结果仍需另行证明

ZDNS 的KSK 管理附件描述年度与紧急密钥签名密钥轮换、硬件安全模块和入侵检测监控、带外通信、桌面演练以及事后复盘设计。这些内容表明申请方考虑了 DNSSEC 事件中“何时轮换、如何沟通、怎样练习和怎样复盘”等关键环节。相比一句笼统的“支持 DNSSEC”，这类控制说明更接近可审查的运作设计。

但设计文件不是最近一次执行结果。公开附件没有告诉读者最近何时进行紧急轮换、耗时多久、是否出现验证失败、哪些客户参与、密钥和法定服务方如何分配，也不能证明每个客户环境都采用完全相同的安排。桌面演练能够发现职责和沟通问题，却不同于在受控条件下完成真实签名状态切换。硬件安全模块与监控工具存在，也不自动证明故障时备用设备、权限和人员能够按目标时间接替。

Main 申请还表示，完整注册数据托管每天进行，失败后会重试。这是一项必要的持续性措施，却只说明提交节奏和失败处理意图。每日存放不等于内容完整、文件可解密、接收方能够恢复，更不能单独推出实际恢复点目标。要证明恢复准备度，需要抽取托管数据、校验内容、在隔离环境中还原数据库，并记录可达到的恢复点和恢复时间；如果只知道“每天一次”，一天之内的数据暴露与失败重试期间的状态仍无法精确衡量。

密钥与注册数据是两个不同恢复对象，也不能用同一份成功记录相互替代。数据库还原成功，不代表签名密钥可用；DNS 节点仍能回答，不代表注册数据可正确更新；密钥轮换完成，也不说明各权威节点已经获得一致数据。成熟的证明应分别记录这些对象的演练，并增加它们重新汇合时的一致性检查。

恢复能力必须用有日期的故障结果连接网络、数据和人员

公开资料已经展示了备份、监控、全天候响应、任播、密钥轮换和托管数据等多个组成部分。问题不在于“什么都没有”，而在于这些部分尚未被一组公开、带日期、可相互对应的结果连接起来。网络层可以撤回路由，应用层要保持正确应答；数据库能够还原，DNSSEC 状态要保持有效；值守人员可以响应，还要证明在目标时间内完成判断、授权和操作。

最有区分度的测试之一是最大站点失效，而不是挑一个最小节点退出。先明确哪个站点承载最多查询、注册事务或签名工作，再在普通负载和接近峰值负载下将其隔离，记录剩余站点利用率、错误率、时延与路由收敛。若故障节点继续公告，还应检验健康检查和撤回机制能否避免黑洞。恢复时则要观察路由重新引入是否平稳，状态同步是否完整，是否出现旧数据重新覆盖新数据。

另一类是数据恢复：从备份或托管副本重建注册数据库，核对完整性、可解密性和时间点，再让 WHOIS/RDAP、注册事务和权威发布逐步恢复。DNSSEC 应急需要单独模拟密钥失效或必须紧急轮换的条件，记录带外沟通、授权、签名、分发与外部验证。每个测试都应给出开始时间、故障注入、环境、负载、成功标准、实际恢复时间、实际数据损失窗口与后续改进。

只有这些结果才能把“有控制”提升为“控制在规定条件下有效”。当前证据足以认为 ZDNS 对这些风险有设计和陈述，但没有提供完整的公开日期结果集。采购方不需要把缺少公开结果解释为没有演练；更准确的判断是，外部读者无法据此确认最近一次演练的范围与成绩。证据等级之所以在物理余量和可用切换方面偏弱，正是因为关键连接仍需非公开尽调来完成。

全球公共解析表面不等于注册数据、日志和密钥都在本地

DNS 的公共数据面天然面向全球。任播可以让用户从网络拓扑上较近的实例获得回答，多个城市的公告也能改善覆盖。但“回答来自附近”只说明查询在某处获得服务，不证明注册数据库、查询日志、备份、托管数据、签名密钥或管理控制也存放在同一司法辖区。数据面位置与控制面、持久数据和安全材料的位置必须分别核对。

这一区分对数据主权尤其关键。一个企业客户可能关心内部域名记录和日志是否离境；顶级域运营方会关心注册数据、托管副本与 DNSSEC 密钥的法律和服务方安排；普通解析用户看到的只是最终响应。八个地点行没有按数据类型列出存放与复制关系，也没有说明日志保留、备份位置或密钥的客户级分配，因此不能从城市清单直接推导合规结论。

客户侧可部署设备又增加一层差异。如果某项服务运行在客户自己的环境，数据位置可能由客户部署决定；若它依赖 ZDNS 的云端控制、更新或监控，仍需识别哪些信息会离开本地。相反，全球托管权威 DNS 可以在多个网络边缘回答，但核心注册数据可能集中在更少的地点。只有把“什么数据、由谁控制、在哪存储、复制到哪里、谁能访问、故障时转移到哪里”逐项回答，才能把“全球服务”与“本地合规”放在同一张可审计地图上。

因此，地理接近可以改善网络体验，却不能独自证明数据本地化。采购合同若要求特定区域存储或密钥控制，应把对象和例外写清，并要求对应证据，而不是接受“我们在该地区有节点”作为替代答案。

不同依赖者面对的是不同故障，客户数量不能换算成人员影响

ZDNS 的服务可能连接注册局运营方、注册商、域名持有人、递归解析服务、企业 DNS 客户以及更下游的互联网用户。这些群体依赖的层次并不相同。注册局运营方需要注册数据库、托管、DNSSEC 和权威发布保持协调；注册商依赖注册接口和数据一致性；域名持有人关心委派与解析；递归解析服务直接查询权威端点；企业客户还可能使用全局流量调度、HTTPDNS 或本地设备。

同一事件对各层的表现也不同。注册事务暂停时，既有域名可能继续解析；权威节点错误时，后台数据库可能仍可操作；日志或备份位置不符合约定时，用户未必立刻感知，却可能产生合规风险；签名状态失配则可能让执行 DNSSEC 验证的解析器拒绝答案。把所有结果压成一个“在线或离线”指标，会掩盖真正的恢复顺序和客户责任边界。

公开材料也不能支持把客户数、域名数或每天查询量换算成受影响人数。一个域名可能服务极少用户，也可能承载高影响业务；一个人可能访问许多域名，自动系统还会产生大量查询。没有客户分布和业务关键性资料时，任何“影响多少人”都可能是伪精确。更稳妥的影响评估应按服务层、客户类型、地域和持续时间描述，并明确哪些信息未知。

这种分层会反过来改善容量问题。权威 DNS 的峰值查询余量、注册事务处理能力、签名设备容量与数据恢复速度需要分别测量。只有在明确依赖者和服务对象以后，采购方才知道应要求哪一种故障结果，也不会用每天 20 亿次解析去替代数据库恢复或密钥应急证明。

一份可用的采购证据包应回答“哪儿、什么、多少、失去后怎样”

面对现有证据，采购方无需停在“资料不透明”的笼统评价上。可以要求一份范围明确的站点与功能矩阵：每行列出地点、宿主与网络依赖、承担的服务、任播或单播角色、对外地址、主要和备用数据源，以及是否存放数据库、日志、备份或密钥。矩阵不必公开客户敏感细节，但应能证明同一城市、同一网络品牌和同一控制面是否构成共同故障条件。

第二部分是资源账。对每项服务和每个地点分别列出已装资源、备用资源、普通负载、峰值负载与保留余量，并说明测量日期和口径。DNS 查询、WHOIS/RDAP、签名、注册事务和存储不能混成一个单位；端口承诺、上游容量与抗攻击储备也应从服务器计算能力中分开。对于宿主设施，只记录 ZDNS 实际获配和可调用部分，不把 732 个机柜或超过 1,000 个机柜的设施总量放入租户容量。

第三部分是故障结果。路由撤回要记录收敛时间和错误变化；最大站点退出要记录存活站点的最高利用率；数据库恢复要记录完整性、实际恢复点和耗时；DNSSEC 应急要记录密钥、通信和外部验证；托管数据要完成可解密与可恢复检查。结果应包含日期、环境、负载、成功标准、偏差和整改，而不是只有“测试通过”四个字。

证据还要具备时效和可比性。同一项测试若发生在设备扩容之前、软件大版本变更之前或网络地点调整之前，就不能不加说明地代表当前状态；一次低负载下的顺利切换，也不能替代峰值条件下的容量结论。采购方应要求每份结果注明测试对象、服务版本、参与地点、初始负载和故障边界，并把后续重大变化与重新测试条件联系起来。这样做不是追求一份永不过期的证明，而是让读者知道结论适用于哪套系统、哪个时间点和哪种压力。

可比性同样能防止数字被口径变化美化。普通负载与峰值负载应使用一致的请求定义，切换前后应观察相同的错误和时延指标，恢复时间的起点也应明确是故障发生、告警触发还是人员确认。如果不同服务使用不同恢复目标，应分别报告，不能拿权威 DNS 的快速路由收敛覆盖数据库还原所需时间。对于未达到目标的项目，记录实际偏差和整改期限比删除失败结果更有价值，因为韧性判断依赖的是组织能否发现边界、修正弱点并再次证明。

最后是责任与地域。材料应说明每个服务由 ZDNS、宿主机房、网络方还是客户控制，故障通知和决策权在谁手中；对注册数据、日志、备份、密钥和控制服务分别说明存放与跨境情况。这样一来，八个地点会变成一张依赖图，宣传数字会变成可复核的工作负载，恢复承诺会变成可以对照合同的结果。采购问题也由“你们是不是全球网络”提升为“在我们关心的故障下，哪些能力仍然可用”。

最终判断：网络与逻辑证据中等，物理容量与切换余量证据弱

把全部公开线索放回各自位置后，结论并不矛盾。ICANN 评估记录显示 Main、DNS、DNSSEC、Proxy 与国际化域名支持；ZDNS 一方页面展示注册局、托管解析和客户侧设备等多条产品线；AS38345 的双栈前缀、根区中的顶级域委派以及多个路由起源，证明其服务具有真实、广泛可见的网络和逻辑表面。对这一层，证据等级为中等。

但物理层仍有决定性空白。八个地点行没有逐站点设备、功能和负载；北京 M5 三期的 732 个机柜及其机电总量属于宿主设施，不能归入 ZDNS 容量；怀柔的面积和机柜数同样不能分配；至少两个 Tier III 或同等数据中心的陈述没有带来已装资源、备用资源和最大站点份额。任播能够绕开干净撤回的节点，却只有在其余节点具备余量且状态正确时才构成可用切换。对可归属于 ZDNS 的物理容量与故障后余量，证据等级为弱。

这两个等级不能合并成一句“ZDNS 容量强”或“ZDNS 网络弱”。前者会让可见路由替未公开设备背书，后者又会忽略已经存在的正式服务与网络证据。更准确的编辑判断是：ZDNS 的全球 DNS 与注册局服务表面有据可循，其可审计物理资产和最坏情形恢复能力仍需要采购方通过非公开材料补齐。

最值得索取的不是更多城市名称，而是站点与功能矩阵、已装和备用资源、普通与峰值负载、路由撤回收敛、最大站点切换、数据库还原、DNSSEC 紧急操作、托管数据核验以及实际达到的恢复时间和恢复点。若这些结果能够按日期、范围和服务层交付，公开材料中的八个地点才可能转化为可度量的韧性；在此之前，732 个机柜仍只证明一项宿主依赖，而不是 ZDNS 可以拿来承诺的容量总数。