摘要

  • 2013 年 2 月的 RFC 6761 设立 IANA 特殊用途域名登记表。此后若要新增特殊名字，规范必须分别回答七类参与者该如何对待它。
  • 第一批条目既有此前保留的名字，也有私有地址反向解析区。localhost 的地址查询应回本机环回地址，invalid 应快速返回不存在；私有反向区可能在本地网络获得回答。同在一张表，不等于执行同一条规则。
  • 2017 年的 RFC 8244 指出了制度上的裂缝：IETF 与 ICANN 没有正式的特殊用途分配协调程序，“技术用途”的边界也没有共识。登记记录能证明名字被指定，不能证明一台现实中的解析器做了什么。

盖章的人不回答 DNS 查询

想象一位开发者把一个测试域名交给程序。程序可能调用系统解析库；解析库可能把问题送到递归解析器；后者可能再去找权威服务器。另一边，域名注册商决定这个名字能否出售。相同的一串字符经过几处不同的决策点。IANA 在列表上写一个“特殊”，并不会让所有节点同步改口。

1999 年的 RFC 2606 已为测试、示例、预期失败和本地主机保留名称。它解决的是虚构名字误撞真实域名的问题。2013 年的 RFC 6761 换了一个更棘手的问题：既然名字已经保留，究竟由谁识别、在哪里拦截、返回什么？这个问题落在实际运行的软件上，而不只是登记环节。

RFC 6761 建立的 IANA 登记表 最初收录既有保留名称以及私有地址反向解析区。每行附一个定义行为的规范出处。它像索引，不像每个解析器执行时都会读取的远程指令。表格整理了约定；网络中的进程、缓存和配置才把约定变成一次回答。

七张办公桌，七道题

要新增一个特殊用途名字，RFC 6761 要求 IETF 标准行动或 IESG 批准的规范。规范必须界定哪一组名称需要特殊处理，并在“域名保留考虑”中回答七类问题：普通用户要不要识别？应用程序要不要识别？名称解析 API 和程序库呢？缓存 DNS 服务器、权威 DNS 服务器呢？服务器运营者要知道什么？注册局与注册商又该如何处理申请？

这不是让七方一起按同一个按钮。七个问题要把责任放到正确的位置。以 10.in-addr.arpa 等私有地址反向解析区为例，RFC 6761 说应用程序和解析 API 不应把它当成需要特殊截断的名字，应正常向已配置的缓存服务器发问。缓存服务器默认应在本地回答，避免把问题继续送向外部权威服务器；在有本地权威服务的私有网络，它还应提供相应配置选项。看到应用发出 DNS 请求，并不能宣判规则失败。要看下一站怎样处理。

localhost 又是另一种安排。针对它的地址查询，解析 API 与缓存服务器应给出环回地址，避免向公网绕一圈。invalid 则应迅速得到 NXDOMAIN。一个“保留”标签背后有不同的返回值、不同的阻断点。只检查域名是否出现在 IANA 表里，无法说明本机发生了什么；只检查一个公共递归解析器，也无法说明某个程序库是否提前答复。

如今 IANA 表 还列出 local、onion、home.arpa 等名字，各自指向自己的规范。这个类别既容纳在 DNS 中有特殊递归处理的名称，也容纳依赖本地解析或不同应用上下文的名称。RFC 6761 从未要求所有条目都是顶级域，也没有要求它们一律绕开 DNS。共同点是必须说清谁在何处作出判断。

名字出门，语境留在原地

本地名称最容易在复制粘贴时露馅。一个人把内部名字发给另一网络中的同事。字母一模一样，对方的解析环境却不同：它可能通向别处，也可能根本没有目的地。RFC 8244 后来用此类跨语境问题说明，特殊用途不是单纯“占一个名额”。名称可以传播，赋予它意义的配置却未必一起走。

2017 年 10 月，RFC 8244 发布问题清单。IETF 与 ICANN 有联络关系，却没有正式程序协调特殊用途名称的分配；“技术用途”的范围缺乏明确界定和共识。两家机构在名称空间里各有角色，但都无法禁止外部开发者先拿一个字符串去用。文件没有给出完成版修补方案，它把运行中的冲突摊在桌上。

清单还提到几条现实路径：本地名称泄漏到外部；未经正式登记的用法后来撞上正规分配；设计者不知道程序存在，或者预计申请会被拒绝。谁因为哪一种原因做过什么，需要具体产品的历史配置和查询记录才能判断。IANA 表证明指定状态；带日期的配置、解析调用与抓包，才说明指定状态是否抵达机器。

这里有一个扎心的机构笑话：登记机关终于给“特殊”设了正规座位，却发现座位背后连着七张分属不同人的办公桌。2013 年的七道题试图在占名之前把每张桌子的工作写出来。2017 年的问题清单表明，连谁来协调开新桌这件事也没有完全谈拢。