Summary

  • RFC 3663 estimated that a direct, denormalized LDAP directory representation could turn a relational dataset of about 20 million objects into more than 115 million directory objects.
  • Referrals promised to preserve relationships and operational boundaries, but client inconsistency and referral loops pushed the pilot toward a normalized backend with a customized, denormalized view. The clients still needed to understand the particular directory tree.

A directory designed twice

The first design problem was not how to search for a domain. It was how to represent the relationships around one. A domain can have contacts and name servers; a name server can serve several domains; registries and registrars hold different parts of the administrative record. Put each relationship directly into a tree, and shared entities may be repeated many times.

In its December 2003 experimental memo, Andrew Newton described VeriSign’s Referral LDAP Service as a pilot in making domain-registration data available through LDAP and familiar LDAP types. The proposed non-normalized Directory Information Tree (DIT) would, the RFC estimated, expand a relational dataset of roughly 20 million objects to more than 115 million directory objects. That is not a measured deployment result. It is the scale estimate that made the directory model an operational question rather than a matter of naming style. RFC 3663

The project began from a historical sequence. The original InterNIC contract had called for an X.500 directory for administrative domain data. Problems with available X.500 server implementations led to a temporary NICNAME/WHOIS service. RWhois later sought to extend that model, but RFC 3663 says it did not gain wide acceptance for domain data. The memo’s own intervention was narrower: try LDAP as a more structured interface amid a split in registry and registrar responsibilities, concern about data mining, and the awkward machine readability of WHOIS output. RFC 954 RFC 2167 RFC 3663

Referrals moved complexity outward

The first DIT design used referrals between the top-level-domain tree and separate name-server and contact trees. That could avoid copying every shared record and offered a possible way to distribute data across servers. But an LDAP referral is not simply another row. A client must decide whether and how to follow it, carry the search’s intent to another server, and handle what comes back.

Testing with ldapsearch exposed inconsistent interpretations of referral behavior. Some clients could be caught in loops. The pilot then chose a customized backend that kept the data normalized while presenting a denormalized view to clients, avoiding the troublesome intra-server referrals. RFC 3663 says a large dataset would likely require such a tailored backend; a smaller dataset might fit an off-the-shelf server. The design did not make the links among records disappear. It changed where those links had to be assembled. RFC 3663

Referrals between registry and registrar servers served a different purpose. They represented an organizational division: the two services might be run by different organizations, machines or networks. Yet search results could fill with referrals that fell outside a supplied filter, up to a typical size limit of 50 entries. A query could therefore return a list of destinations rather than the records a user expected. The memo treats this as a distribution problem in the service model, not proof that LDAP as a protocol was defective. RFC 3663 RFC 2251

Generic protocol, specific map

The experiment also found a limit in the phrase “generic client.” LDAP supplied a common access protocol, but the clients needed algorithmic knowledge of the service’s DIT and schema. The graphical clients could not be pointed unchanged at a different LDAP directory and still use its data fully. A client that hid every structural difference would either expose less information or become too complex for ordinary use. RFC 3663

That gap appeared at the interface as well as in code. The web client led some users to believe it was the only way to reach the data, while the LDAP protocol and the registry–registrar–registrant structure remained hard to explain in search results. The C and Java clients could perform nested queries and referral chasing, but usability—not raw library capability—was a recurring difficulty. The RFC even cautions that popularity could not be measured accurately. These are pilot observations, not population research. RFC 3663

Nor did the service eliminate the control problem around public data. It allowed selected query shapes because arbitrary LDAP searches could be too costly; users nevertheless asked about recursively guessing names to evade those limits. The memo records that many WHOIS operators regarded such dictionary queries as data mining. Its security section is unusually plain: the demonstrated distinguished-name/password controls were not adequate as a production model. The experiment should not be read as a modern access-control recommendation. RFC 3663 RFC 2026

The lesson was about placement

RFC 3663’s most durable historical value is its engineering candor. A directory technology could provide familiar operations without providing a portable user experience. Data normalization reduced object multiplication, but a tailored backend had to recreate the view clients needed. Referrals preserved boundaries between servers, yet their usefulness depended on client behavior, query limits and the social division among registry, registrar and registrant.

The memo noted that searches still began at the registry tier, even when a user wanted a particular registrar or registrant, and that DNS SRV or NAPTR discovery had not been implemented. Its survey of LDAP servers was also bounded: four zone files, port-389 probes at domain names and ldap or dir hostnames, without SRV lookup. The reported estimate—about 0.5% of active domains in that sample had an LDAP server—cannot be treated as a present-day or Internet-wide census. RFC 3663

The trade-off was not “tree versus database.” It was who would carry the translation between a relational record, a directory view, a referral target and a user’s question. The pilot concentrated some of that work in a custom server and specialized clients rather than in millions of repeated objects or fragile referral chains. A common protocol made the pieces recognizable. It did not remove the need for a map.

Sources