Summary

  • RFC 3088 turned an eligible domain-component suffix in an LDAP distinguished name into a DNS domain, queried _ldap._tcp SRV records and returned LDAP URLs as referrals.
  • The root service was a bootstrap point, not a global directory database: the RFC urged clients to use local services and consult the root only when referred.

The server at the top of a directory path did not need to store the directory. In April 2001, the OpenLDAP Project described an experimental “root service” that helped LDAP clients discover which server might own a domain-based name. Its result was a referral: a set of possible next addresses, not the person or organization record being sought.

The distinction mattered because LDAP names could follow a hierarchy that had no reliable registration and service-location mechanism. RFC 2247's domain-based naming let a distinguished name carry DC components corresponding to DNS labels. RFC 3088 used that structure as a bridge. It examined the name, derived a domain where its rules allowed, and asked DNS for LDAP service-location records.

That parse was narrower than “strip the username and use the rest.” The RFC's algorithm walked relative distinguished names from left to right and accumulated eligible single-valued domain-component RDNs. A non-domain component reset the candidate. Its examples show why shape mattered: some names yield a usable suffix, some produce no domain, and the special DC=. notation handles a proposed mapping for the domain-tree root. A referral service therefore depended on the exact naming form, not just on a human intuition about which part looked like a domain.

For a domain such as example.net, the service queried _ldap._tcp.example.net. RFC 2782 supplies the DNS SRV mechanism: records identify a target host and port and can carry priority and weight. RFC 3088 then constructed LDAP URLs from the returned targets and handed them back in a referral. But the implementation described in the RFC returned records in resolver order; it did not itself apply SRV priority or weight. DNS data shape and service behavior were separate facts.

The root service did not follow every referral on the client's behalf, merge results or vouch for the data at the other end. Basic LDAP operations returned a referral when the target or search base could be mapped to service URLs. The client or referring server still had to continue the operation, and the referred server had to process it. A successful first exchange could establish a route to ask the next question. It could not establish that the final entry existed, was current, was complete or came from an authority the client should trust.

That is why RFC 3088 recommended a local-first path. LDAP servers could be configured to refer superior requests to the OpenLDAP Root Service; clients could contact it directly, but the RFC discouraged doing so. Clients should use a local service and reach the root only when referred. This kept the central service in a coordination role: it helped connect separate directory islands without becoming the universal store or an obligatory first hop for every lookup.

The proposal was explicitly experimental. The RFC said its mechanisms were not definitive and that a later Standards Track document would be needed. The example service spoke LDAPv3 and LDAPv2+ over TCP/IPv4; LDAPv2 could not represent referrals at all, and LDAPv2+ used a different representation. Those compatibility details are period-specific, not a claim about every later LDAP client.

Security boundaries were equally visible. The described service accepted anonymous binds, refused other bind attempts and did not provide encryption or information integrity. It disclosed data derived from public DNS, but the RFC warned that the design remained exposed to DNS spoofing and denial of service. It also cautioned that LDAP-session integrity alone could create false confidence about the integrity of DNS-derived information. A referral protocol hop was not a proof of the name-to-server mapping that produced it.

The RFC's own “lessons learned” section reported a single host and the authors' belief that ordinary load balancing could scale the service if needed. That is evidence of what the document said about its experiment, not a capacity test, service guarantee or adoption census. The article's historical claim stops there: RFC 3088 showed how DNS could provide glue for domain-based LDAP discovery, while leaving the final record, local policy and client continuation elsewhere.

Sources