摘要

先看最无争议的一栏：地址边界。转移文件把起点和终点写得很清楚，是原 202.89.208.0/20 的最后四分之一。接收方那串 Indonesia Network Information Center/SCBD-ID 是日志里的名称，不负责交代交易对价、机构关系或路由切换。APNIC 的转移日志格式说明定义了资源、源方、接收方与日期字段。这里有一张登记收据，没有一份运营交接报告。

次日统计原始文件给出另一种切法。11 月 3 日版本以 202.89.208.0 为起点，记录 4,096 个地址，合成一个 /20。11 月 4 日版本将其换成三行：202.89.208.0/21 有 2,048 个地址；202.89.216.0/22 和 202.89.220.0/22 各有 1,024 个。三段无重叠，恰好填满旧 /20。最后一段与日志中的转移范围精确相合。

在 11 月 4 日同一文件内，前两段共用 A92AB1BD，第三段使用 A92B4C5C。扩展文件官方说明说同一 opaque ID 对应同一资源持有人，同时提醒代码不能保证跨版本保持稳定。因此，能说明持有人分开的，是 4 日文件内部的两种代码；不能仅凭 3 日与 4 日代码字符串去推断身份变动。代码不公开姓名，姓名要回到转移日志与精确登记对象找。

三条新行的日期仍是 20050419。这不是说 2026 年的转移没有发生。APNIC 的统计交换规范把每日文件定义为当前状态快照，不附交易沿革；日期记录原始分配时点。2005 年在管资源的出身，2026 年在管它的切分。把两者揉成一个日期，账就会错。

名字出现在 WHOIS。对左侧 /21和中间 /22的查询，第一条 inetnum 均为精确的 DNK-NET 子段；对转出 /22则为精确的 SCBD-NET。三个子对象都写 last-modified: 2026-11-02T23:38:47Z，比日志里的 23:38:39 晚八秒。它只量出两种记录时间的差，不是公开数据库传播速度。每份 WHOIS 答复还附上一个标为 source: IDNIC 的 DNK-NET /20 父对象，最后修改时间是 2011 年。新子段与旧父段同时待在答案里。

换成 RDAP，层级却塌回去。查左 /21、中 /22、转出 /22，得到的都是 202.89.208.0–202.89.223.255 的 DNK-NET 父对象。告知信息注明对象来自 IDNIC，APNIC 对其作了部分镜像。WHOIS 第一条里可见的 APNIC 来源精确子段，没有进入这三次 RDAP 答案。这说明查询结果的分辨率不同；谁在运营路由、投诉最后由谁处理，还需要另外的记录。

APNIC 自己在转移日志格式里建议通过 Whois Database 查询前缀，验证接收方持有状态。现在做这件事必须读懂 WHOIS 中子对象与父对象的次序。只拿 RDAP 第一张卡的人，看到的是旧 /20 的名字。制度保存了完整证据，却让最省力的查询走向较粗的一层。