摘要

  • Digity, LLC 是目前在公开记录中登记为.case和.radio的赞助组织（sponsoring organisation），这两个顶级域名分别通过 IANA 的独立流程转移至该公司；公开记录建立的是有边界的注册局责任，而非对 DNS 的主权控制权。
  • 当前根区记录显示两个命名空间的技术联系人和 RDAP 服务路径不同。这表明存在不同的公共控制路径，而非完整的私有架构或可直接得出的可靠性评分。
  • 协议、转让、续约、DNS/DNSSEC 观测、RDAP 对象、公开注册服务、协议标准共同建立了真实能力与责任，但并不证明长期可靠性或客户生产结果。
  • 监管、集成、维护、可移植性与授权异常响应在常规工作由专业供应商和自动化完成时，仍然是持续的运营成本。

图片说明：随文配图为维基媒体基金会数据中心的通用服务器布线照片。该图并未展示 Digity, LLC、其员工、场地、.case或.radio的注册后台、CentralNic、CORE、客户、事故、私有架构、可测量可靠性或生产结果。

Digity, LLC 目前在 BTW 目录中作为公司对象出现，并在 IANA 根区数据库中作为.case和.radio的赞助组织出现。[1][2][3] 两个顶级域名均为通过有记录的转移流程到达 Digity，而不是直接最初委托给公司。IANA 在 2023 年 5 月发布了.case转移报告，并在 2026 年 2 月发布了.radio的独立报告。[4][5] 这段历史使 Digity 成为一个有价值的技术公司研究对象，因为它提出了一个关键运营问题：当一家负有责任的机构继承两个具有不同历史、公共服务路径、政策背景和技术联系人的命名空间时，如何保持准确记录并持续提供服务？

公开证据确认了真实的控制边界。它包括赞助组织记录、权威 DNS 委托、IPv4 与 IPv6 胶水记录、DNS Security Extensions 材料、WHOIS 服务、RDAP 终端、注册协议、转让、续约、公开注册界面、托管职责和应急连续性机制。[2][3][6][7][8][9][10][11][12][13][14][15][16] 其中还包括定义 RDAP 查询与响应行为以及验证解析器如何处理 DNSSEC 数据的标准。[17][18][19] IANA 的 RDAP bootstrap 文件提供了路由层，指示客户端对每个 TLD 发送查询的目标。[20]

这些记录不披露 Digity 的私有架构、人员编制、供应商合同、部署拓扑、安全控制、事故历史、注册量或客户结果。.case的 IANA 记录显示 CentralNic 为其技术联系人，并指向 CentralNic 的 RDAP 基础路径；.radio记录则将 CORE Association 列为技术联系人并指向rdap.nic.radio。[2][3] 这些是可见的角色与端点差异，并不能证明完整的后端设计。公开的服务主机名并不等于合同或技术责任的完整地图。

因此分析保留三个层次：

  • 模型或系统能力：一个协议端点可回答定义好的查询，委托可发布名称服务器与 DS 数据，注册局流程可接受授权变更，托管流程可保留定义好的数据集。
  • 产品可靠性：这些功能在维护、供应商故障、人员更替、错误输入和运营者交接时，仍需持续正确、可达、安全、可观测和可恢复。
  • 客户生产结果：某注册商、注册者、播出机构、应用方或安全团队实现了可归因的实际业务结果。

公开记录支持有边界的能力评估，并确认了可靠性问题清单。它不支持“客户生产结果”的主张。某次 DNS 或 RDAP 观测成功并不能形成长期基准，合约义务也不代表目标在所有周期内达成。该区分是评估注册局时避免编造测试、客户、故障和内部设计推断的核心。

主要发现是：Digity 的两个 TLD 组合将责任归集，但执行路径仍各自可见。这样可形成有用的隔离，但也带来监管、集成、维护与异常处理成本。关键技术问题不在于某种后端模式更优，而在于 Digity 在组织与服务变化时，能否保持权威记录、运行服务、合同责任与恢复权限在两个命名空间之间一致。

身份与两个分别转移的委托

组织身份重要，因为根区变更权与一个精确机构绑定，而非宽泛品牌。BTW 目录提供了本次研究所用的当前公司对象。[1] IANA 将 Digity, LLC 列为.case与.radio的赞助组织，但两个记录显示与该组织相关的地址和技术联系人不同。[2][3] 这种差异本身并非错误，而是说明法定身份、当前联系人数据与变更权限是需要持续对齐的运营状态。

IANA 对.case的转移报告将 Digity 标记为拟定管理方，并将申请方匹配、联系人确认、技术符合性和其他处理过程标记为完成。[4].radio的对应报告对同类检查也显示后续转移完成。[5] 这些报告表明每次申请都通过了既定的过渡门槛，但并未说明所有技术组件都已迁移，所有流程均未变化，或后续运行达到某一可靠性水平。

基础转让文件补充了合同层。.case的转让记录显示协议权利与义务转移给 Digity，.radio的转让文件对该 TLD 起到同样作用。[10][11] 转让具有意义，因为它确认了协议下的责任方，但不能解读为软件、基础设施、人员、数据迁移或供应商分配的结构图。合同责任可转移，同时技术执行仍可能部分由专业组织承担，按阶段变化，或对不同服务采用不同路径。

续约文件显示，义务关系在初始转让后仍在持续。[12][13] 续约并非简单延长时间戳，它维持持续关系：根区数据、注册服务、安全义务、数据托管、报告与连续性控制必须保持一致。ICANN 的当前协议索引提供了每个 TLD 的协议材料公开清单。[6][7]

在这里，“注册局-记录者”原则有价值。Digity 是当前记录的两项委托注册局运营者，这一角色很关键但有边界。Digity 不拥有 DNS 根，也不对标签用途拥有主权，亦不排除 ICANN、IANA、注册商、技术服务商、递归解析器、网络运营者、法院和政策机构的作用。技术系统中的合法性依赖于准确记录、授权变更、符合标准的运行服务和连续性。

一次转移至少形成四类关联清单：

  1. 授权清单：法人实体、协议、批准联系人、已认证账号以及可提出或批准变更的人。
  2. 命名空间清单：TLD 标签、根委托、胶水与 DS 数据、WHOIS 与 RDAP 路由、预留名称、域名状态与注册商关系。
  3. 依赖清单：提供商、凭证、证书、密钥、网络、监控系统、数据存储、托管流程及支持路径，保障命名空间持续运行。
  4. 证据清单：让复核者重建权威状态、变更时间、批准人员及独立复核方式的记录。

公开来源公开了前两类的部分内容，以及第三、四类的合同要求。公开源未展示 Digity 的私有清单。这是证据边界，不是支持强或弱控制的理由。

两次转移发生在不同时间、不同前任背景下。.case曾转移给其他企业运营者后才到达 Digity；.radio先与 European Broadcasting Union 相关联，后被转移至 Digity。[2][3][4][5] 一个过渡计划不能将其历史视为可替换。政策承诺、注册商关系、公开预期、服务提供商、保留数据与异常队列可能不同，即使根区最终状态看似接近。

实务上的控制是逐 TLD 的过渡记录，应明确哪些义务和资产已转移、哪些留给供应商、哪些在转移后变更，以及何种证据证明当前状态。共享的公司所有权可以统一记录形式，但不能抹去关键差异。

运行 DNS、DNSSEC、WHOIS 和 RDAP 的控制面

IANA 页面列出每个 TLD 的四个权威名称服务器，分别为a、b、c、d，并位于对应nic域名下，带有 IPv4 与 IPv6 glue。[2][3] 一次边界观察在.case与.radio均发现了预期的四个名称，并在采集时观察到 DS 记录。该观察表明所选公共路径在当时返回了连贯的委托数据，但不能证明全球可达性、实例独立性、持续可达性或特定响应时延目标。

根区列表是委托意图的权威记录，不是物理拓扑。四个名称并不一定意味着四台机器、四个站点、四条网络或四个故障域。Anycast 可将多个实例放在一个地址后面，而多个主机名仍可能依赖同一套控制系统。不能仅凭可见的名称、地址或联系人推断私有架构。

运行码优先并不意味着忽视记录。它意味着检验可见服务是否持续符合记录。一个有效运行模型应比较：

  • 批准的根区和注册局记录；
  • 直接的权威响应；
  • 来自独立路径的 DNSSEC 验证；
  • IPv4 与 IPv6 可达性；
  • 路由可见性与网络冗余；
  • 来自提供商控制面之外的监测；
  • 注册商交易行为；
  • RDAP 发现与响应语义；
  • 客户症状，但不据此直接定位故障。

每一层回答的问题不同。正确的根区页面不能证明每个权威实例都可达。一次递归查询成功不代表每个解析器看到相同状态。一次有效签名不代表下一次 rollover 就安全。一次 RDAP HTTP 成功不能证明每个对象字段实时正确。

DNSSEC 加入了安全元数据生命周期。RFC 4035 说明验证解析器如何认证 DNS 数据以及失败如何导致不安全或错误结果。[19] 父区域 DS 数据、子区域 DNSKEY 集、签名、有效期、算法和运行时钟必须保持同步。自动化可计算标签、比对记录、监测过期并发现不一致，也可能在授权或库存错误时快速重放错误状态。

安全的 DNSSEC 运行因此不只依赖能力软件。它还需要密钥保管、明确职责、计划序列、重叠窗口、可观测性、回滚边界和恢复访问。合法的 DS 值可能对目标密钥是错误值。正确提交可能在错误时间发生。监测系统可见故障，而授权响应器可能不可达。

WHOIS 与 RDAP 路径暴露了相关但不同的控制面。IANA 列出whois.nic.case与 CentralNic RDAP 基础路径用于.case，而.radio使用whois.nic.radio及nic.radio下的 RDAP 基础。[2][3] IANA 的 bootstrap 数据将 RDAP 客户端路由到对应注册局服务。[20] RFC 9082 定义查询格式与错误路径；RFC 9083 定义 JSON 响应结构、链接、提示、状态、事件、实体和错误行为。[17][18]

在采集时，查询nic.case返回了带有该标识的 RDAP 对象，查询nic.radio返回了对应的.radio对象。服务暴露的响应细节与状态集不同，这是预期的，因为对象与服务路径可能不同。观测只证明两条精确查询能获得响应，不代表完整性、字段准确性、持续可用性或两服务行为一致。

结构化 RDAP 相较于文本展示是能力提升，因为客户端可解析字段并追踪链接，但产品可靠性仍取决于 bootstrap 准确性、端点可达性、TLS、响应语义、更新时序、速率控制、隐私处理、事件一致性和有效错误信息。要形成客户生产结果，还需要具名用户或流程的基线、时间窗与测量窗口。本文未提供这类信息。

注册数据不仅是目录，它是注册商、注册者、安全团队、权利持有人、研究者与自动化系统都在使用的运营记录。其关键属性包括：

  • 唯一性：查询应返回预期对象，而不是模糊重复。
  • 准确性：字段在受控更新时间内反映权威状态。
  • 来源可追溯性：客户端可识别响应背后的服务与授权方。
  • 安全元数据：状态、事件、提示和链接在处理链路中不会静默丢失。
  • 连续性：在维护与过渡期间保持可发现性和响应可用。
  • 隐私：限制披露的同时不破坏对象含义。

公开协议定义了这些属性可如何表达，但未证明 Digity 的私有流程在维持它们。

后端异构性与集成边界

公开的.case与.radio记录并未呈现统一的供应商链。.case将 CentralNic 作为技术联系人并使用 CentralNic 的 RDAP URL；.radio则将 CORE Association 标为技术联系人并使用不同 RDAP 基础路径。[2][3] 公开证据因此只支持一个窄结论：两个 TLD 暴露了不同的技术责任与注册数据路径，但不能据此推出完整后端架构、合同范围、排他性、容量或事故表现。

这类可见异构性之所以重要，在于标准化与隔离并非同义。共享公司所有者可以使用统一风险词汇、审批模型、证据格式和连续性策略；不同服务路径可降低某类共因故障，但也要求所有者在多个运营语境下保持专业能力、访问、监控和升级处理。

集成从责任开始。作为赞助组织，必须证明每个 TLD 谁有权提出变更。技术联系人可执行部分工作，但不一定拥有最终批准权；供应商可检测故障但未必能修改根区记录。Digity 可能持有合同责任，但仍需供应商证据后才可批准修复。只有当这些分离在压力场景下形成有效交接时，才是健康的。

集成继续在数据层展开。注册商交易必须形成预期注册局状态，该状态再体现在 WHOIS 与 RDAP、DNS 发布、状态码、计费或资格控制以及托管存款中。不同后端可实现同样协议，同时在运维工具、事件时序、密钥管理、维护窗口和支持升级方面不同。

.case的公开注册界面与.radio网站也显示不同产品语境。[14][15].radio页面定义了面向广播社区的命名空间并公开资格与政策声明；.case界面同样提供面向注册者的材料。公开的市场或政策文本界定预期用途与客户面向控制，但不证明执行一致性、案例量、注册成功率、滥用处理结果或产品可靠性。

拥有两条独立语境的运营者需要一套兼顾共性与差异的控制模型。可行设计包括：

  • 一份公司级授权与合同义务登记；
  • 每个 TLD 单独的提供商角色、联系人、凭证、端点和维护约束地图；
  • 关键变更的通用证据要求；
  • 当一条 TLD 需要隔离时，独立的预发布与回滚决策；
  • 不依赖任何一个后端仪表盘的外部监测；
  • 保留提供商特定证据的标准化事故记录；
  • 可测试的数据导出、凭证恢复与接班运营流程。

这些控制本身不能从公开源推断。它们是基于可见系统得出的决策测试框架。

可移植性是评估供应商锁定风险最具体的路径。专业供应商本身不必然是缺陷，反而可提供协议支持、规模化运营与成熟工具。锁定风险在于可问责运营者不能恢复权威数据、建立其他场景变更授权、复现必要服务或独立验证过渡。

有意义的可移植性审查应回答能导出什么、以何种格式、什么新鲜度、在谁的授权下、以及其他运行环境是否能消费。它应包含区文件、域名和联系人记录、状态、注册商状态、DNSSEC 材料或变更流程、政策历史、托管引用、支持工单和审计证据，同时要识别哪些知识只存于员工记忆或供应商专用界面。

转移历史使该问题从理论变为现实。.case与.radio已经更换过赞助机构。[4][5][10][11] 这不是意味着下一步必然再转移，而是提醒命名空间通常会超出特定公司与技术安排的生命周期，连续性依赖于记录与运行能力在变迁中保持一致。

合同、托管和应急连续性控制

.case与.radio的注册协议确立了围绕注册服务、注册数据、数据托管、互操作性、连续性与应急切换的义务。[8][9] ICANN 的协议索引和续约文件显示持续有效的合同框架。[6][7][12][13] 这些文件定义了义务和应急机制，并未证明事故发生或每一期服务水平达成。

数据托管处理的是一类难解对称性。日常运营方可能持有最新注册数据，但在接班或应急时，继任运营方需要在正常访问受阻时拿到这些数据。托管只有在存档完整、按时、格式正确、安全传输并可在有效授权下恢复时才有价值。文件存在但无法解密、验证或对账时，不构成可操作的恢复资产。

应急后端注册局运营商（EBERO）计划描述了一种有边界的机制，旨在运营者无法提供关键功能时保护核心注册局功能。[16] 该机制是外层安全边界，不是常规连续性的替代。激活需要清晰授权、可用数据、当前联系人、服务切换和沟通机制。它可在短期维持关键功能，但不一定立刻恢复全部业务流程。

对 Digity 而言，两项转移 TLD 在多个层面提出连续性问题：

  1. 若仅一条服务路径失效，能否独立恢复每个 TLD？
  2. 当某个提供商身份体系不可用时，共享的公司权威是否仍可执行？
  3. 托管与导出流程是否与当前两条 TLD 的实施方式兼容？
  4. 根区、DNSSEC、WHOIS、RDAP、注册商和政策状态在恢复后能否重建一致？
  5. 外部观察者能否判断恢复状态为权威状态？

协议文件提供了提问的理由，但未提供上述问题的答案。

连续性具有时间维度。每日存档对某类数据可能足够，却可能对另一类数据过时。DNS 委托、域名状态、注册商交易、滥用案件、联系人与密码材料更迭速度不同。恢复目标应按缺失或过期状态的后果设定，而非采用单一通用指标。

连续性还具有知识维度。有效备份本身无法单独批准根区变更；导出库不能说明异常放行的原因；若缺少角色与生命周期证据，DNSSEC 密钥可能无法安全使用；联系人清单若已过期也无助于控制。可持续运营要求数据、权威、流程与可测试访问共同存在。

文章配图为 Wikimedia Foundation 服务器照片，仅作为通用布线与维护背景。它并未显示 Digity 的设施，也不构成该公司供应商、可靠性或安全的证据。

四大持续性成本

可见控制面在自动化或外包下仍会持续产生四类成本。

监督成本

监督成本将“技术上可行的动作”与“授权意图”连接。其包括角色复核、变更批准、独立核验、访问控制、政策解释、事件指挥和证据保留。两条 TLD 的组合必须避免看似统一的流程把错误假设套用于两个命名空间。

该成本不仅是审核工时。它还包括保留足够知识以质疑绿码面板，识别语法正确但属于错误 TLD 的值，并阻断权威不清的变更。也包括建立外部观测通道与在常规供应商门户不可用时仍可工作的恢复身份。

集成成本

集成成本存在于 Digity、IANA、ICANN、注册商、技术联系人、后端服务、托管、监控、法务流程与公共用户之间。标准减少了格式歧义，但不会自动对齐凭证、时钟、维护窗口、归属与升级链路。

不同的.case与.radio联系人和 RDAP 路径让该成本可见。[2][3] 一份通用的公司状态报告可能需要两个运营上下文的证据。事故分类可能需要在根委托、权威 DNS、DNSSEC、注册商交易、RDAP、政策与网络层面区分后再交付给正确责任人。

维护成本

维护成本用于保持能力。它涵盖软件与依赖更新、证书更新、DNS 和 DNSSEC 生命周期管理、数据库治理、监控变更、备份校验、托管存款、访问复核、联系人更新、注册商兼容、政策修订和恢复演练。

低频流程往往更昂贵，因为人员与平台在执行间发生变化。一个少用账号可能过期；一份运行手册可能已描述旧服务；恢复密钥可能存在却缺少可用审批路径；一次计划任务成功不代表已通过恢复演练验证。

异常处理成本

异常处理成本在预期序列失效时出现。示例包括联系人与授权记录冲突、部分 DNSSEC 换代、单栈可达、RDAP 对象可达但过期、注册商交易结果不明确、隐私请求与标准响应冲突、或提供商状态与外部观测相悖。[16]

这类情况需要场景与克制。并非每次探针失败都代表大规模故障，每次成功响应也不必然正确。并非每个客户症状都应归咎于注册局，反向误判同样会发生。运营者应保留证据、缩小范围、确认权威并执行不扩大影响的修复。

四类成本相互增强。维护不足会触发异常，集成薄弱会使异常定位更困难。监督不足会让错误变更扩大，缓慢的异常处理会拉长影响并导致矛盾性行动。一个按交易计费便宜的服务，依然可能高昂到难以负担地安全运行。

故障模式登记表

公开记录支持一套具体的故障模式分析，但不表示这些事件已在 Digity 发生。

1. 赞助机构身份漂移

法定实体、ICANN 协议、IANA 赞助记录、目录对象与认证变更账号不再指向同一组织。技术上正确的请求可能因权威模糊而失败。检测需要跨记录对账；处置需由可问责主体发起、配套书面证据并执行受控更新序列。

2. 管理联系人信息过时

电子邮件、电话、邮政地址或角色名称在责任转移后未更新。常规服务可继续运行，但紧急变更权威会悄然退化。有效控制应测试联系人可达性和授权，而非仅字段是否非空。

3. 技术联系人归属不匹配

供应商或协会在工作范围变化后仍被保留为技术联系人，或新供应商在无完整升级记录下运行服务。Digity 可能收到报告，但无法将其转交到具备诊断访问的责任方。解决方式是按 TLD 建立与当前合同和系统一致的责任映射。

4. 转移清单缺失

转移可能移交合同责任，但遗漏了凭证、监控规则、政策例外、注册商依赖或支持历史。命名空间在缺失项未被触发时可能看似健康，在需要时却会失效。签署的交接清单不如经过转移资产演练更有证明力。

5. 根委托不匹配

IANA 目标名称服务器或 glue 与运营者目标配置，或与权威运行状态不一致。成因可能是不完整变更、库存过期或未授权请求。应在下一次更新前比对批准证据、直接权威响应与根记录。

6. IPv4 与 IPv6 可达性分歧

一个地址族可达，而另一个不能，或路由特征明显不同。仅测试单一地址族会给出错误成功。运营者需要独立双栈观测，并区分是委托、路由、过滤还是服务器原因。

7. 名称服务器相关性故障

四个公布名称可能依赖同一控制层、软件版本、路由策略、凭证或上游网络。公开记录会显得多样，但一个共用故障可影响多条路径。公开记录无法证明或否认该拓扑，韧性测试必须验证真实故障域。

8. DNSSEC 父子链不一致

父区 DS 与子区 DNSKEY 集无法形成有效链。验证解析器可返回伪造结果，而非验证解析可能看起来正常。预防需要分阶段切换、重叠窗口、独立验证、时钟治理与明确回滚条件。

9. 签名到期盲区

区签名临近过期却未形成有效告警，或告警仅存在于故障控制面中。当缓存数据过期后，服务才显现异常。外部校验与告警归属测试可降低风险。

10. 错误的 TLD 自动化

通用脚本或流程将.case数据应用到.radio，或反向应用。统一的自动化在错误假设下反复执行语义错误的操作。相比通用成功提示，更有价值的是按 TLD 的标识、不可变审核证据、隔离凭证与独立事后校验。

11. RDAP 引导偏移

IANA bootstrap 指向客户未能继续使用意图路径，或变更仅部分更新到缓存与客户端。[20] 直接端点检测可能成功，但基于标准的发现仍失败。既要监测发现层，也要监测服务行为层。

12. RDAP 对象过时

端点返回 HTTP 成功和有效 JSON，但状态、事件、链接或实体已过时。可用性监控会遗漏语义性故障。识别需要将结果与权威注册状态和受控更新时序进行比对。

13. RDAP 错误模型不兼容

客户端与服务端在查询形式、状态处理、通知、重定向或 RFC 9082/9083 所定义的错误响应上出现分歧。[17][18] 正常路径通过，而异常调查失败。合同测试应包含非规范请求、缺失、未授权和限速等场景，而不产生有害流量。

14. WHOIS 与 RDAP 含义分歧

传统 WHOIS 响应与结构化 RDAP 对象可能在呈现上不同，但关键状态与权威应保持可对照。隐私处理可不同，但不能让同一对象在语义上相互矛盾。

15. 注册商交易歧义

注册商在创建、更新、续费、转移或删除提交后超时，无法确认注册局是否已提交。盲目重试会重复提交或与现状冲突。需要幂等性、交易证据和明确对账路径。

16. 公共政策执行缺口

.radio的公开页面描述了资格与控制路径，但运营事件可能未沿预期路径处理或缺少可及的责任归属。[15] 政策文本是能力的证据之一，不代表一致执行。审查需具备案例证据、时间线和合规例外处理。

17. 托管存款不可用

存款可能存在但不完整、过时、加密在不可用授权下或与恢复环境不兼容。任务完成日志不能等于连续性成功，校验与恢复演练必须验证可用状态而非任务指标。

18. 应急转换权威失效

出现重大问题时，但各方不能确认谁有权启动应急机制、发布数据、变更委托或发布状态。[16] 技术恢复能力会被权威缺口卡住。演练应覆盖审批与身份链，而不仅是数据迁移。

19. 提供商控制面故障

公共 DNS 可能仍可从分布实例响应，但门户、身份系统、监控或变更 API 不可用。此为“部分连续性”状态，不是完整健康。Digity 需要外部观测、恢复访问，并在不能变更时触发明确的事件门槛。

20. 客户症状归因错位

网站、邮件或应用故障时，可能在未分层区分委托、注册商状态、权威 DNS、解析、路由、证书、托管与应用层之前就将责任归给注册局。反向错误也存在：注册局故障被当作应用问题而忽略。带时间戳的证据链可避免两类误判。

这些故障模式不是对 Digity 的打分表，而是对可见责任边界的注册。其价值在于把模糊的韧性表述转成可观测的决策点。

领导层决策测试与证据边界

技术领导者应以保持“责任”与“私有实现”边界分离为前提来评估 Digity 的控制面。

第一，要求每个 TLD 的准确责任地图，区分合同责任、根区权威、技术运营、DNSSEC 保管、注册商支持、RDAP 与 WHOIS 运作、托管、政策案件、事故沟通和独立核验。.case与.radio的公开联系人显示为何单一供应商标签不足以代表全部。[2][3]

第二，追问转移证据在团队解散后如何保持可用。IANA 报告显示申请人、联系人与技术符合性门槛已完成。[4][5] 当前运营复核应说明如何保持该结果：联系人校验、访问复核、当前依赖地图、可测试导出和可重建变更历史。

第三，追问意图状态与运行状态如何比对。回答应包括根区记录、直接权威 DNS、DNSSEC 验证、IPv4 与 IPv6、RDAP 发现、响应语义与外部监测。一个仪表盘不应自行认证自身。

第四，追问如何控制两条服务路径差异。标准化应覆盖证据、审批、严重性和恢复原则；供应商级流程应保留各自安全需要的差异。通用模板有用，但不能将不同后端误当作同构。

第五，追问连续性证据，而非“连续性语言”。有用证据包括经验证的托管、恢复结果、恢复访问、DNSSEC 恢复、导出测试以及一条将两个 TLD 隔离的演练场景。EBERO 提供外层框架，但常态恢复属于运营方及其供应商责任。[16]

第六，追问任何可靠性主张的基础。产品可靠性必须定义服务、指标、观测窗口、测量视角、排除条件和故障处理。一次时间点内的 DNS 与 RDAP 正确观测只证明可观测能力，不是长期可用度指标。

第七，追问任何客户主张的基础。客户生产结果需要明确用例、基线、时间窗、测量方法、归因逻辑和限制。公开注册页面与 TLD 用途声明本身不能提供这些要素。[14][15]

第八，追问可移植性是否在现实权威条件下经过测试。数据可导出但常规系统可用时测试是有用但不完整。更强的演练应假设供应商账号、角色或控制面不可用，检验 Digity 能否建立权威、恢复可用状态并验证接替路径。

第九，追问如何防止异常成为默认策略。一次手工修复若无文档，可能留下未备案状态并被误判为权威结果。异常记录应保留证据、授权、范围、有效期和返回常规路径所需变更。

最后，追问明确不确定性的范围。公开记录不揭示私有拓扑、人员编制、合同细节、安全设计、事故响应时长或客户成果。可信复核应将这些项目标为未知，而非推断补全。这样可使剩余证据更有用，因为读者能识别记录建立的事实与运营方可证实事实之间的边界。

结论

Digity, LLC 的技术意义在于其已成为两个独立转移 TLD 的可问责注册局运营者。当前 IANA 记录、转移报告、协议与转让续约文件、公开注册服务、协议标准及有边界的观测共同建立了真实的 DNS、DNSSEC、WHOIS、RDAP 与连续性控制面。[2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20]

证据显示了能力与责任，但未揭示私有架构，也不证明长期产品可靠性或客户生产结果。.case与.radio技术联系人和 RDAP 路径的可见差异，应被解读为集成与连续性议题，而非关于薄弱或韧性的直接结论。

监督使授权意图持续对应技术动作。集成连接组织、协议与证据。维护保障密钥、数据、软件、联系人与恢复访问。异常处理则解决正确外观层之间出现冲突的案例。托管与应急切换提供外层安全边界，但仅在数据与权威仍可用时才有价值。

更广泛的教训是：当企业和技术变更发生时，命名空间能否存续，取决于记录是否准确、运行服务是否持续符合记录、以及可问责运营方是否能在不臆造状态的情况下进行权威转移或恢复。Digity 的两次转移史使这一原则具象化：责任所有权可以变化，但命名空间的运营连续性不能在合同、供应商与系统交接间消失。

来源

[1] BTW Directory, “Digity, LLC”：https://btw.media/en/directory/digity-llc

[2] IANA Root Zone Database, “.CASE”：https://www.iana.org/domains/root/db/case.html

[3] IANA Root Zone Database, “.RADIO”：https://www.iana.org/domains/root/db/radio.html

[4] IANA, “Transfer Report for case”：https://www.iana.org/reports/tld-transfer/20230531-case

[5] IANA, “Transfer Report for radio”：https://www.iana.org/reports/tld-transfer/20260225-radio

[6] ICANN, “.case Registry Agreement”：https://www.icann.org/en/registry-agreements/details/case

[7] ICANN, “.radio Registry Agreement”：https://www.icann.org/en/registry-agreements/details/radio

[8] ICANN, “.case Registry Agreement text”：https://itp.cdn.icann.org/en/files/registry-agreements/case/case-agmt-html-03sep15-en.htm

[9] ICANN, “.radio Registry Agreement text”：https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-agmt-html-21jul16-en.htm

[10] ICANN, “.case Assignment”：https://itp.cdn.icann.org/en/files/registry-agreements/case/case-assign-pdf-08-07-2022-en.pdf

[11] ICANN, “.radio Assignment”：https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-assign-pdf-05-01-2026-en.pdf

[12] ICANN, “.case Renewal”：https://itp.cdn.icann.org/en/files/registry-agreements/case/case-renewal-1-11-06-2025-en.pdf

[13] ICANN, “.radio Renewal”：https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-renewal-1-22-05-2026-en.pdf

[14] Digity, “.case registration services”：https://www.digity.case/case

[15] dotRadio, “.radio public registry surface”：https://www.nic.radio/

[16] ICANN, “Emergency Back-End Registry Operator”：https://www.icann.org/en/contracted-parties/registry-operators/resources/emergency-back-end-registry-operator

[17] IETF, RFC 9082, “Registration Data Access Protocol Query Format”：https://www.rfc-editor.org/rfc/rfc9082.txt

[18] IETF, RFC 9083, “JSON Responses for the Registration Data Access Protocol”：https://www.rfc-editor.org/rfc/rfc9083.txt

[19] IETF, RFC 4035, “Protocol Modifications for DNS Security Extensions”：https://www.rfc-editor.org/rfc/rfc4035.txt

[20] IANA, “RDAP Bootstrap Service Registry for Domain Name Space”：https://data.iana.org/rdap/dns.json

[21] CentralNic RDAP, “nic.case”：https://rdap.centralnic.com/case/domain/nic.case

[22] dotRadio RDAP, “nic.radio”：https://rdap.nic.radio/domain/nic.radio

[23] Wikimedia Commons, “Wikimedia Foundation Servers 2015-88”：https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Servers_2015-88.jpg