摘要

  • Draft 1 抓住了一个真实的运营问题：如果下游分配或再分配没有准确登记，公共责任记录与申请反向委派所依据的地址事实可能脱节。
  • 草案第 3.1 节拟对新的反向 DNS 委派设置登记前提；第 3.2 节拟通过 MyAFRINIC 和电子邮件提醒已有反向 DNS、却没有相应下游登记的 LIR；第 3.3 节则明确保留批准前已经存在的反向委派，只让规则面向之后的分配。
  • 反向 DNS 缺失不会让 IP 数据包停止路由，但 PTR 记录的缺失或正反向不一致，可能影响依赖地址到名称映射或一致性检查的服务。因此，委派不是无关紧要的装饰，也不能被夸大成网络连通性的总开关。
  • 数据库里“没有匹配记录”只证明查询结果没有找到预期对象，不能自行证明地址未使用、运营者违法、资源被放弃、权利丧失或应受处罚。记录滞后、粒度差异、待处理更新、认证问题和工作人员匹配错误都可能造成假阴性。
  • AFRINIC 在这里能正当承担的角色，是私人记账员、注册服务运营者和技术协调者：核验申请、指出具体缺口、保存变更历史、修正已证明的错误并维持连续性。它不是国家、监管机关、警察、检察机关、处罚机构、没收者、法院或主权者。
  • 最耐用的替代设计不是放弃准确登记，而是把准确性要求嵌入一条可核查、可纠正、可复核、可回滚的服务流程，并在法律权利出现争议时交由独立且有管辖能力的机构处理。

一项真实的记录问题，遇上一项真实的运行依赖

“No Reverse Unless Assigned”这个标题很容易诱导读者把争议压缩成二选一：要么支持数据准确，要么纵容不登记。Draft 1 的实际问题比这个口号复杂。它面对的是三个并不总能同步的对象：运营者在网络中真实使用和分配的地址、AFRINIC 数据库对这些下游安排的记录，以及 DNS 层级中为相应地址范围配置的反向委派。三者完全一致时，申请核验并不困难；真正决定制度质量的，是它们不一致时谁来判断、依据什么判断，以及一个错误判断会造成什么后果。

草案提出修订 AFPUB-2005-v4-001。它把公共网络信息数据库描述为发布公共网络联系信息的工具，并引用旧政策第 9.5 节，把 AFRINIC Whois 数据库中的登记与分配有效性联系起来。草案还以“enforcement mechanism”形容自己的功能。这个自我描述可以准确说明起草者想用什么激励办法，却不能创造公法意义上的执法权。“执行一项私人流程中的登记前提”与“以国家权力处罚违法者”不是一回事；官方文件采用某个词，也不能让私人协调机构自动获得处罚、没收或裁判权。

Draft 1 的制度赌注在于：把下一次需要反向委派的时刻，变成促使资源持有者补齐下游登记的时刻。AFRINIC-16 的会议报告记载，提案作者把改善分配登记准确性作为动机，并把这项措施描述为一种激励——尤其是在运营者下一次需要更多地址空间之前。报告还将一组数字归于作者：超过 60% 的 ISP 登记了分配，接近 40% 没有登记任何分配。但这组数字没有随报告给出分母、查询日期、查询语句、样本构成或独立审计方法。它能证明的是会议上提出过怎样的担忧，不能证明每一个被系统判定为“无记录”的运营者都没有登记，更不能证明未登记等同于未使用或无权使用。

这正是为什么准确性目标与操作手段必须分别审查。公共责任记录有价值：事故响应者、网络对等方、客户、研究人员和其他运营者都可能需要知道一个地址段由谁实际管理，向哪里报告问题，怎样理解分配链条。登记长期缺失，会使账本偏离网络现实，也会削弱注册服务自身的可信度。但价值再高的账本仍然只是记录系统。它可以描述证据、留下时间线、关联经过认证的声明；它不能仅凭自身空白宣告现实不存在。

Draft 1 究竟拟做什么

草案的三个操作小节必须放在一起读，任何一个都不能被后来的版本替代。

第 3.1 节提出：对于 AFRINIC 管理的 IP 地址空间，如果该地址空间的分配或再分配没有在 AFRINIC 数据库中得到适当登记，AFRINIC 将不再批准反向委派。这里的直接后果是拒绝一个新的委派请求。Draft 1 没有规定后来版本出现的特定 /24 门槛，因此不能把后续文本的精度倒填进 2012 年 4 月的第一稿。“该地址空间”究竟按什么粒度与反向区域匹配，本身就是封存历史记录没有回答的重要问题。

第 3.2 节处理另一类对象：已经拥有反向 DNS 的分配，却没有登记下游分配或再分配的 LIR。草案设想通过 MyAFRINIC 和电子邮件联系这些 LIR，但把如何落实提醒留给秘书处工作人员。提醒本身可以是低风险的纠错工具；问题在于，Draft 1 没有定义通知应列出哪个对象、哪一个反向区域、哪一次查询、缺少哪条证据，也没有规定收件人应在多久内得到回应、如何对工作人员的匹配结果提出异议。

第 3.3 节是一道关键护栏。它明确说，草案若获批准，AFRINIC 不会移除批准前已经存在的 LIR 分配反向委派；只有之后的分配会受影响。也就是说，Draft 1 不是一个清除既有委派的通用授权。它采取前瞻性安排，限制了即刻影响范围，也避免把旧有工作状态突然改写成失效状态。这一克制值得肯定，因为连续性风险往往来自把新的记录规则追溯施加于正在运行的系统。

2012 年 5 月 18 日，AFRINIC-16 讨论了这份第一稿。官方报告记录了对实际效果、工作人员负担和可执行性的质疑，也记载有人指出互联网可以在没有反向 DNS 的情况下运行，并讨论了如果以端口扫描辅助判断，是否需要获得运营者同意。会议没有形成共识，提案回到邮件列表。2012 年 11 月 29 日的 AFRINIC-17 幻灯片仍把 Draft 1 列为当时版本，并重现其第 3.1 至 3.3 节；AFRINIC 2012 年年报则说，AFRINIC-17 讨论的提案没有取得共识。第二稿后来出现，但其十二个月或移除机制属于另一项研究，不能用来解释第一稿。

“没有共识”只是一项私人政策流程的记录结果。它既不说明草案已经实施，也不是法院对草案合法性的判决。反过来，假如某个文本曾得到会议共识，那也只能说明参与者在特定流程中形成了某种结果，不能凭空产生对所有运营者的主权管辖。过程记录应当被准确使用：官方材料证明谁在何时提交了什么、会议记录了什么发言、流程留下了什么结果；它们不能自证机构权力的合法来源、参与的代表性或方案的正确性。

反向委派的分量：重要，但不是路由开关

理解风险只需要很窄的 DNS 背景。IPv4 反向 DNS 使用 IN-ADDR.ARPA 下的委派区域，PTR 记录把地址映射到名称。普通的正向查询通常从名称寻找地址，反向查询则从地址寻找名称。为某一地址范围配置反向解析，往往需要地址层级上游为相应区域设置委派，然后由下游运营者维护区域内容。AFRINIC 所协调的父侧委派因此可能成为运营流程中的一个依赖点。

RFC 1035 定义了 PTR 与 IN-ADDR.ARPA 的基本机制。RFC 1912 讨论常见 DNS 错误，建议主机的 PTR 与 A 记录相互一致，并警告缺失或不匹配的反向映射可能带来访问或服务问题。这些材料支持一个克制而重要的判断：反向 DNS 有运行价值，一些系统会检查 PTR 是否存在，或检查正向与反向是否一致；不良记录可能增加邮件、访问控制、日志辨识、故障排查或信誉判断的摩擦。

但它们不支持把 PTR 说成 IP 路由的必要条件。路由器转发数据包并不以每个地址都有 PTR 为前提；没有反向委派也不意味着整个地址空间从互联网消失。不同服务对反向解析的依赖程度不同，封存的历史记录也没有列出任何因 Draft 1 被拒委派而发生的真实停机、邮件失败或客户损失。准确的措辞应当是“可能损害依赖地址到名称映射或一致性检查的服务”，而不是“会切断网络”。

这一区分不是替草案减轻责任，反而让审查更精确。若把反向 DNS 夸大成网络生死开关，容易用戏剧化后果替代证据；若把它贬低成可有可无，又会忽视拒绝委派可能给具体运营者带来的真实摩擦。制度设计应按实际依赖的性质控制风险：它不是路由没收，但也不是纯粹的文书退回。

私人账本可以核验事实，不能制造主权

AFRINIC 作为区域注册服务运营者，承担地址分配和登记方面的私人协调功能。这样的功能包括维护资源记录、认证账户请求、接收反向委派申请、核对申请所依据的地址范围、配置其负责的一侧 DNS 记录，以及保存审计轨迹。公共网络依赖这些工作稳定、准确地继续，并不意味着提供这些工作的一家公司拥有国家权力。

技术依赖常会产生一种危险的视觉错觉：谁控制了一个必要接口，谁就像有权决定接口两端参与者的权利。实际上，接口控制描述的是能力，不是权限来源。AFRINIC 能在自己运营的系统里批准或拒绝一项配置，是技术事实；它是否有正当理由这样做、需要遵守什么程序、能否据此判定资源权利，则是不同问题。官方出版物、邮件列表讨论、政策会议、被宣称的共识和运行依赖，都不能把私人记账员变成国家、立法机关、监管机关、警察、检察机关、处罚机构、没收者、法院或主权者。

因此，Draft 1 的“拒绝”只能在非常窄的意义上成立：注册服务运营者为完成一个新的父侧委派，可能要求申请人提供与该委派直接相关、足以认证和匹配的记录。若缺少构成配置所必需的事实，它可以暂停处理、说明缺口并邀请纠正。这与把反向 DNS 不可用包装为惩罚完全不同。前者服务于正确配置；后者把有价值的服务变成迫使对方履行另一项行政义务的杠杆。

区分两者的办法，不是看文件是否用了“政策”或“执行”这样的词，而是问五个操作问题：数据库究竟显示了什么；哪个具体反向区域或申请依赖这个事实；哪些证据可以证明记录滞后或匹配错误；在后果发生之前是否有明确通知、纠正、复核和回滚；若争议涉及法律权利，谁是独立且有管辖能力的裁判者。回答越含糊，所谓“前提”就越容易滑向无法核查的压力工具。

数据库空白不是权利判决

当查询没有返回预期的 assignment 或 sub-allocation 对象，系统得到的是一个有限命题：在特定时间、用特定规则、针对特定范围和粒度，没有找到预期记录。这个命题可以触发检查，却不能独自承担更多结论。

它不能证明地址没有在生产网络中使用。运营现实可能先于文书更新；也可能存在已认证但仍在处理的变更。它不能证明运营者放弃地址，数据库沉默更不能充当放弃声明。它不能证明违法或不当行为，因为记录缺失的原因尚未查明，私人登记条款也不是刑事法律。它不能证明资源权利已经消灭，更不能为没收资源提供依据。它也不能证明某一工作人员的匹配粒度正确，尤其当 Draft 1 没有定义“该地址空间”如何与反向区域一一对应时。

一个负面查询结果还容易受到“时间切片”影响。申请人在上午提交更正，数据库索引在稍后才反映；核验系统若只保存“未找到”，就可能遗漏更新已进入受理队列这一事实。一个对象也可能以不同粒度存在：申请对应的反向区域与下游登记边界不完全相同，机械等值比较会把可解释的层级关系误认为空白。认证信息、维护者对象或账户归属发生变化时，真实授权与当前可见字段也可能短暂脱节。工作人员还可能输入错误范围、选错对象类型，或把一个需要人工澄清的关系判成不存在。

这些不是对某次已知事故的描述；历史材料没有记录 Draft 1 造成过实际拒绝。它们是任何“数据库阴性即服务阴性”规则必须预先处理的失效类型。只有把假阴性路径写进制度，准确性要求才不会自相矛盾：一个声称要改善记录准确的机制，不应在自己的匹配错误发生时拒绝承认现实。

第 3.3 节为何重要，又为何仍不够

保留批准前既有反向委派，是 Draft 1 最清楚的连续性保护。它把旧状态与新申请分开，避免为了促使补登记而主动拆除已经工作的委派。对运营者而言，“不改变最后一个经过验证的工作状态”通常比事后道歉更有价值，因为 DNS 变更可能跨越多个缓存、管理团队和客户依赖，恢复并不总等于瞬间消除影响。

这项前瞻性限制也说明，起草者没有在第一稿中提出无差别清除。把 Draft 1 写成要在一段期限后普遍删除旧委派，会误读第 3.3 节，并把第二稿内容倒投回第一稿。历史精度在这里不仅是文献要求，还改变对风险的判断：第一稿的直接影响面是后续分配所涉的新委派请求，而非所有既有委派。

然而，祖父条款只解决“是否动旧状态”，没有解决“怎样对待新请求中的争议事实”。新分配、新客户或新反向区域同样可能承载正在运行的服务计划。若申请因为数据库假阴性而被拒，申请人仍需要知道准确原因、提交什么证据、多久得到答复、谁能复查工作人员结论、错误决定如何快速回滚。第 3.3 节缩小了冲击半径，却没有建立纠错架构。