摘要

  • RFC 3088 从符合条件的 DC 命名分段提取域名，查询 _ldap._tcp SRV 记录，并把结果构造成 LDAP referral。
  • 根服务只是引导点，不是全球目录数据库；RFC 建议客户端先使用本地服务，只有在收到转介时才继续访问根服务。

一次目录查询的第一条回复，可能只是“下一步去哪里”。2001 年 4 月，OpenLDAP 项目描述了一个实验性 Root Service：它利用 DNS 服务定位记录，帮助找到与域名式 LDAP 名称对应的服务器。它没有把所有目录条目收集到一个根节点里。

处理从 Distinguished Name（DN）开始。RFC 2247 允许用 DC 分段表达 DNS 域组件；RFC 3088 则规定了如何从 DN 中解析域名。算法按从左到右的顺序检查相对名称分段，累积符合条件的单值 DC；遇到不符合条件的分段时，候选序列会重置。因此，是否能生成域名取决于 DN 的具体形状，而不是简单删去最左侧的用户名就万事大吉。

得到 example.net 后，服务查询 _ldap._tcp.example.net。DNS SRV 记录会列出目标主机和端口。Root Service 将每个目标组成 LDAP URL，再以 referral 的形式返回。这个实验实现按解析器提供的顺序回传记录，没有自行执行 RFC 2782 中的优先级和权重选择；记录里写了权重，不等于该服务实际使用了权重。

返回 referral 后，查询链还没结束。客户端或中间服务器必须继续访问 URL，由目标 LDAP 服务执行操作。根服务不会替所有目标汇总查询结果，也不保证最终条目存在、最新、完整或可信。它证明的是一个候选下一跳被指出，而不是搜索已经成功。

RFC 3088 还明确推荐“本地优先”：目录服务器可以把更高层级的请求转给 OpenLDAP Root Service；客户端可以直接使用它，但通常不鼓励这样做。客户端应先查询本地服务，只有被转介时才访问根服务。这样，DNS 为彼此独立的目录提供连接胶水，却不必把每次查询集中到一个全球数据仓库。

该方案被 RFC 明确标为 Experimental，机制尚不具备最终规范性。它描述的服务支持 LDAPv3 与 LDAPv2+，通过 TCP/IPv4 提供；LDAPv2 无法表达 referral。服务只接受 anonymous bind，拒绝其他绑定方式，不提供加密或信息完整性保护。RFC 还指出 DNS 欺骗与拒绝服务风险，并提醒：保护 LDAP 会话本身，并不能证明用于生成转介的 DNS 信息真实无误。

文末经验部分称，当时服务运行在一台主机上；作者认为若需求增长，普通负载均衡即可扩展。这只是 RFC 对当时实验的陈述，不是容量测试、可用性承诺或广泛采用的统计证据。

来源