摘要

  • RFC 2167为层级标签划定权威区域，查询不属本区时向父区转介，命中更细分区域时向下转介。
  • 文中把howard.md.us记录错放进va.us作为反例：记录可以躺在某台服务器里，却无法沿预定的RWhois树被发现。

问弗吉尼亚分支的服务器，马里兰分支的记录在哪里，它不能因为自己能回答网络请求就宣称有权给出否定结论。RFC 2167的例子规定，负责va.us的服务器遇到howard.md.us，应把查询向us或者根区域转介。这一步只是在承认管辖边界，并没有证明对象存在、联系人真实，或下一个地址一定可用。

再把那条howard.md.us记录实际存入va.us。记录的字节还在，路却不会走到那里。规范明确说它被放错位置，因而无法在RWhois树中找到。这不是“机器没存数据”的问题，而是标签指向的管理区域与实际存储区域不一致。规范也承认，把记录放在较高、较不具体的上级区域，在许多情况下仍可能找到；不能把所有偏离最细区域的存放都说成同样的故障。

1997年6月发布的《Referral Whois Protocol V1.5》试图缓解集中式Whois的规模与维护压力。域名的点分层级，以及以CIDR表达的网络前缀，都能从标签推导层级位置；单看一个人的姓名则不能。协议因此把“权威区域”与可解析的层级标签绑定，让区域之间形成树：父节点记录子区域的指针，子节点又知道怎样回到父节点。这是找保管人的办法，不是判断保管人写得对不对的办法。

向上走称为punt转介，向更具体的区域走称为link转介。转介给出下一台服务器的主机、端口和区域。下一站仍可能给出数据、报错，或继续转介；客户端收到多个指针时可以自行选择顺序。不带可用层级结构的搜索，还可能交给独立索引服务器寻找候选区域。因此，看到转介时只能说“有一条下一步路线”，不能说“已经查明全网事实”。

即使最终由对应区域回答“没有对象”，也必须把这个结论放回查询路径看。父子指针是否正确，记录是否按标签落在应有区域，读权限是否允许，副本是否及时更新，都会改变可见结果。走对路径而没找到错柜里的文件，不等于文件从来不存在。另一方面，区域有各自的数据库模式；RFC建议共享部分核心字段以便互通，却不要求子区域照搬父区域的全部定义。跨区域读到同名字段，也不能自动认定语义一致。

登记和答复的权限又是两回事。一个区域只能有一台master负责登记；slave可以从它复制数据并对该区域的查询作权威答复，却不得登记。完整或增量复制依靠SOA序列号、刷新与重试等参数，也允许只复制部分类型或属性。这里的“权威答复”说明服务器在这套目录中的职责，不等于记录已获独立核验，更不保证任意时刻的副本与主库完全同步。

RFC的guardian机制限制某些对象或区域的增加、修改、删除及私有数据读取，涉及密码与PGP。能通过写入权限检查的人，未必对现实中的资源拥有所声称的权利；限制阅读也不能让联系方式变得准确。RFC 2167是Informational文档，自称不制定互联网标准。它为我们提供设计上的证据，不提供某次实际查询、某个部署规模或今天WHOIS/RDAP服务行为的证据。最值得保留的是这条分层判断：找到保管位置、查到一条记录、验证现实主张，三者不能相互替代。

来源与证据边界

主要依据是RFC 2167第2、4节及其RFC Editor记录；RFC 1714是被其替代的旧版，RFC 954提供早期集中式Whois背景。这些文件不证明真实的错区事故、身份、分配有效性或查询结果。