摘要

  • APNIC 11 月 3 日原始文件把 103.7.4.0/23 和 163.227.238.0/23 分别列为孟加拉国代码 BD 下、各含 512 个地址的 allocated 资源。
  • 11 月 4 日文件把每段拆成两个 /24：前半仍为 allocated，103.7.5.0/24 和 163.227.239.0/24 则列为 reserved。原先合计 1,024 个已分配地址，如今这两组行中有 512 个仍为已分配、512 个为保留。

第一组数字值得逐格看。旧行从 103.7.4.0 开始，数量 512，日期 2022 年 9 月 16 日，持有者标识 A914661C。新文件里，同一起点只剩 256 个；日期和标识照旧。紧邻的 103.7.5.0 另起一行，数量 256，状态为保留，国家、日期和持有者栏都空了。第二组旧行从 163.227.238.0 开始，同样是 512 个地址，但日期是 2025 年 5 月 5 日，标识 A918E269。新文件保留它的前 256 个，将 163.227.239.0/24 列为保留。这是两个不同标识的记录，不能把同一天出现在文件里当成同一宗处置。

APNIC 的精确 RDAP 查询给前半段补上一张当前名片。103.7.4.0/24 对应 HPLINKINTERNET-BD，当前对象的登记及更新事件是 11 月 3 日 05:04:01 UTC；163.227.238.0/24 对应 SERVER-BD，事件时间是 04:55:44 UTC。两个对象都精确覆盖各自继续分配的 /24。把问题改成后半段，答案就变了：查询 103.7.5.0/24 返回覆盖整个 103.0.0.0/8 的 APNIC 管理对象；查询 163.227.239.0/24 返回 163.0.0.0/8 的上级管理对象。那不是这两个保留 /24 的精确持有者卡片。

APNIC 自己的地址状态说明把 allocated 定义为交给账户持有组织的资源，把 reserved 放在另一个资源池状态中；隔离待处理地址是保留状态的一种用途。两组记录各缺一份注明原因和生效范围的资源处置记录；取得记录即可判断为何切半。

这份账还有两个时钟。名为 11 月 3 日的文件收录截至 2 日的数据，名为 4 日的文件收录截至 3 日的数据。2022 年和 2025 年的日期继续印在各自幸存的 /24 上，只说明那部分记录的历史。若审查者拿旧 /23 的登记日期当作今天仍能代表整个 /23 的凭据，恰好会漏掉这次改变。