摘要

  • RFC 3663 估算，把一份约有 2000 万个对象的关系型数据集按未归一化方式映射进 LDAP 目录，目录对象可能超过 1.15 亿个。
  • 引用原本要保留对象关系并支持跨组织分工，但客户端解释不一、甚至陷入循环。实验转而采用归一化后端和面向客户端的非归一化视图；客户端仍需理解这套目录树。

先变的是数据形状

域名登记并不是一条孤立记录。一个域名可能关联多个联系人和名称服务器；同一台名称服务器又可能服务很多域名。注册局与注册商所持有的行政信息也分属不同环节。如果把每一条关系都摊开写进一棵目录树，共用的人和服务器就可能在许多位置重复出现。

2003 年 12 月，Andrew Newton 以实验备忘录形式写下 VeriSign 推出的 Referral LDAP Service。RFC 3663 的目标，是检验 LDAP 与已有 LDAP 类型能否用于域名行政资料目录。它的设计估算很醒目：一个约 2000 万对象的关系型数据集，若按提案中的非归一化目录信息树（DIT）表示，可能膨胀到超过 1.15 亿个目录对象。这个数字是原文用于权衡设计的估算，并非已经建成同等规模部署后的实测结果。它把目录建模从命名习惯变成了存储与运营问题。RFC 3663

这次实验也接续了一段更早的目录史。最初 InterNIC 合同曾要求用 X.500 目录服务承载域名行政资料；由于当时服务器软件实现存在困难，先搭起了临时 NICNAME/WHOIS 服务。RWhois 后来希望扩展原有方式，但 RFC 3663 称它没有在域名数据场景广泛普及。Referral LDAP 的目标更有限：提供结构化查询与结果，让机器更容易读取，并在注册局和注册商分开承担职能后，从前者引导查询走向合适的后者。它还回应了对 WHOIS 输出难以机读和资料被采集的担忧。RFC 954 RFC 2167 RFC 3663

引用把复杂度移到了客户端

第一版 DIT 在顶级域名树与名称服务器、联系人树之间大量使用服务器内部引用。这样可以避免复制每个关联，也为把不同数据放到不同服务器上留下了可能性。但 LDAP 引用不是多加一行记录而已。客户端必须判断是否继续跟随、怎样把原搜索条件带到下一台服务器，以及如何处理返回的内容。

使用 ldapsearch 的测试显示，不同实现对引用的解释和跟进方式并不一致，一些客户端很容易陷入引用循环。实验最终选择定制后端：底层数据保持归一化，却向客户端呈现非归一化视图，从而不再依赖服务器内部引用。RFC 3663 认为，大型数据集很可能需要定制服务器后端；较小的域名空间则可能用现成实现解决。关系没有消失，只是由不同组件负责重建。原文同时说明，这种经验来自该项目的测试，而不是对所有 LDAP 客户端的普遍判决。RFC 3663

服务器之间的引用承担另一种任务：表达注册局与注册商在组织、设备和网络上的分离。可是搜索结果中可能出现不符合指定过滤条件的引用，并很快占满通常为 50 条的结果上限。用户想找记录，收到的却可能是一串下一站。RFC 把它描述为查询分发与返回数量的问题，不是 LDAP 协议整体失效的证据。RFC 3663 RFC 2251

通用协议没有带来通用客户端

LDAP 提供了共同的访问协议，但图形客户端仍得掌握服务具体采用的 DIT 和 schema。项目发现，这些应用无法原样连接另一个结构不同的 LDAP 服务，同时继续完整利用其中的数据。若所谓通用客户端把所有结构差异都藏起来，它可能只能呈现部分信息；若要全部处理，界面和算法又会复杂到普通用户难以操作。可复用的是协议接口，不一定是客户端所依赖的数据模型。RFC 3663

困难也发生在用户看得见的地方。RFC 记录说，部分人以为网页就是数据的唯一入口，不清楚后面还有 LDAP 协议，也难以从搜索结果理解注册局、注册商和注册人之间的关系。C 和 Java 客户端使用的程序库足以完成嵌套查询与高级引用跟进，但更多问题来自可用性，而不是程序库能力。作者也承认，无法准确衡量各类客户端的流行程度。这是试点中的观察，不能包装成全行业用户调查。RFC 3663

查询成本与资料采集同样没有因结构化而消失。RFC 说，允许任意 LDAP 搜索会使公共服务负担过重，因此实验只开放有限的查询形态。用户仍会询问能否通过递归字典查询绕开限制；许多 WHOIS 运营者把这种做法视为数据挖掘。更重要的是，安全章节明确写道，实验所演示的 DN 加密码访问控制不足以作为生产环境的范本。这是项目自己的限制说明，而非今天可直接复用的安全设计。RFC 3663 RFC 2026

设计选择是在决定谁来做转换

RFC 3663 的历史价值，在于它没有把通用目录协议写成免维护的解决方案。数据归一化减少了对象膨胀，却要求定制后端重建客户端期望的视图；服务器间引用保存了组织边界，却把一部分查找成功与否交给不同客户端的实现和各级运营政策。

原文指出，即使目标是某一家注册商或注册人，搜索仍要从注册局这一层开始。实验没有实现 DNS SRV 或 NAPTR 服务发现。它对 LDAP 服务器的探测范围也很明确：使用 .com、.net、.org 和 .edu 四份区文件，在域名及 ldap、dir 主机名上检查 389 端口，没有尝试 SRV 查询。文中“约 0.5% 的活动域名有 LDAP 服务器”只适用于它所述的抽样方法，不能当成全网普查，也不能代表现在的服务状态。RFC 3663

所以真正的选择不只是树结构还是关系数据库，而是谁负责把关系型登记记录转成目录视图、把引用变成下一站，再把技术响应变回用户要找的信息。这个试点把一部分工作放进定制服务器和了解特定目录的客户端，避免了大量重复对象和容易失控的内部引用链。共同协议让零件看起来相似，却没有替使用者画出那张地图。

来源