RFC 3663
Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)
RFC 3663: Domain Administrative Data in LDAP 💖 (Part 1 of 4) ✨
okay bestie, let's get into it 🎀 this is RFC 3663, titled Domain Administrative Data in Lightweight Directory Access Protocol (LDAP). It was written by A. Newton from VeriSign, Inc. and dated December 2003. It's in the Experimental category 🧪 which means it's an experiment, not an Internet standard. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Status of This Memo 📝
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🌸
okay so domain registration data has basically always been shown to the public through Nicname/Whois for admin stuff 👀 this doc describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service that uses LDAP and well-known LDAP types to make domain admin data available. it's giving experiment era for sure 🧪
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Historical Directory Services for Domain Registration
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4
2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4
3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6
3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6
3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7
3.1.3. Access Control . . . . . . . . . . . . . . . . . 7
3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8
3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8
3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8
3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9
3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9
4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10
4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10
4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11
4.1.3. Access Control . . . . . . . . . . . . . . . . . 11
4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12
4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12
4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13
5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14
6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15
6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16
6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16
6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
8. Internationalization Considerations. . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 211. Introduction 🦋
this doc describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental project launched by VeriSign, Inc. 🏢 its whole goal is to explore using LDAP and LDAP-related technologies as a directory service for administrative domain registration info 🔍
1.1. Historical Directory Services for Domain Registration Data 🕰️
so the original National Science Foundation contract for the InterNIC called for an X.500 directory service for the admin needs of domain registration data and info 📜 but X.500 server software had problems with implementations, so a server based on the Nicname/Whois [1] protocol was temporarily set up instead 🫠
in 1994, the Rwhois [3] protocol came out to upgrade Nicname/Whois 🆙 it never really caught on for domain data though 😬
right now, ICANN requires registries and registrars of generic Top-Level Domains (TLD's) to run Nicname/Whois servers 🏛️
1.2. Motivations 💡
okay so the split in functional responsibilities between registries and registrars happened recently 👀 plus the constant misuse and data-mining of domain registration data, and the fact that Nicname/Whois output is hard for machines to read. that's why the Referral LDAP Service was created, with these motivations:
- Use a mechanism native to the directory protocol to refer clients from inquiries about specific domains made at a registry to the appropriate domain within the appropriate directory service at a registrar. 🔁
- Limit access to domain data based on authentication of the client. 🔐
- Provide structured queries and well-known and structured results. 📊
- Use a directory service technology already in general use. 🌍
given all that, LDAP [5] was picked as the protocol for this directory service 🫶 they also decided to restrict LDAP to features that are most readily available in common implementations, so the goal was to not define any new object classes, syntaxes, or matching rules. super practical, no notes 💅
the experiment worked. it showed how LDAP could be used in this context and how much customization an operational service would need 🎉 conclusions and observations are in Section 6 🧐
1.3. Abbreviations Used 🔤
these are the abbreviations used to describe the nature of this experiment:
TLD: Top-Level Domain. Refers to the domain names just beneath
the root in the Domain Name System. This experiment used the
TLD's .com, .net, .org, and .edu.
SLD: Second-Level Domain. Refers to the domain names just beneath
a TLD in the Domain Name System. An example of such a domain name
would be "example.com".
DIT: Directory Information Tree. One of many hierarchies of data
entries in an LDAP server.
DN: Distinguished Name. The unique name of an entry in a DIT.
cn: common name. See RFC 2256 [7].
dc: domain component. See RFC 2247 [4].
uid: user id. See RFC 2798 [9].2. Service Description 🧩
the service is made of three distinct server types: a registry LDAP server, registrar LDAP servers, and registrant LDAP servers 🖥️
the registry LDAP server has three Directory Information Trees (DIT's) 🌳
- The Top-Level Domain DIT's follow the DNS hierarchy for domains (e.g.,
dc=foo,dc=com). 🗂️ - The name server DIT allows a view of the name servers, many of which serve multiple domains. 🖧
- The registrar-referral DIT provides referrals from the registry into the respective TLD DIT of the registrars (on a TLD basis). ➡️
the registrar LDAP server has two types of DIT's 🌿
- The TLD DIT follows the DNS hierarchy for domains (e.g.,
dc=foo,dc=com) and parallels the TLD DIT of the registry. 🪞 - The name server and contact DIT allow a view of the name servers and contacts, many of which are associated and serve multiple domains. 👥
there's no specification on the DIT or schema for the registrant LDAP server 🤷♀️ referrals from the registrar server to the registrant server are provided solely so the registrant can directly control extra admin info related to a particular domain 🔑
access control for this service is merely a demo of using a Distinguished Name (DN) and password 🙈 if registries and registrars uniformly adopted LDAP to spread domain registration data, those DN's would need standardizing based on each type of user base 📋
3. Registry LDAP Service 🏰
3.1. TLD DIT 🌐
3.1.1. DIT Structure 🌲
the registry TLD DIT has this structural hierarchy:
TLD (e.g., dc=net)
|
|
-------------------------------------
| |
SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
| |
--------------------- ---------------------
| | | | | |
name server | | name server | |
(e.g., | | (e.g., | |
cn=nameserver1,| | cn=nameserver1, | |
dc=foo,dc=net ) | | dc=bar,dc=net ) | |
| | | |
name server | name server |
(e.g., | (e.g., |
cn=nameserver2, | cn=nameserver2, |
dc=foo,dc=net ) | dc=bar,dc=net ) |
| |
registrar referral registrar referral
(e.g., (e.g.,
cn=registrar, cn=registrar,
dc=foo,dc=net ) dc=bar,dc=net )
Figure 1: Registry DIT Overviewthe root of a TLD DIT is an entry of objectclass domain as specified by RFC 2247 [4], and it represents a top-level domain 🏷️
the second tier of the DIT represents second-level domains. each of these entries is of objectclass domain as specified by RFC 2247 [4] 🧁 the description attribute on these entries often has descriptive text giving the name of the registrar the domains were registered through 🏪
the third tier has entries specific to each second-level domain 🍰 name server entries are objectclass ipHost as specified by RFC 2307 [8] 🖥️ their distinguished names are algorithmically calculated: the first component is the word "nameserver" concatenated with an index number for the name server entry, and the remaining components are the appropriate domain names 🧮 there's no specification relating the value of the name server entry to the index it may be assigned, other than that it's unique and consistent with respect to the client session 🫧 this tier also holds the referral from the registry to the registrar. it's a direct referral to the entry in the appropriate registrar LDAP server that corresponds to the domain name the referral falls beneath in this DIT 💜
to be continued in Part 2, bestie 🎀
3.1.2. Allowed Searches ✨
okay bestie, this DIT is HUGE 🌸 like, so many entries that letting people run ANY LDAP search would be way too expensive for a public service 😭 so only certain searches are allowed. the vibe is very "you can look, but not like that" 💅
- One-level scoped searches based at the root of the DIT. Substring matching is allowed on
dcattributes, but the substring must be at least 3 characters in length. - Base search based at the root of the DIT.
- Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below.
3.1.3. Access Control 🔐
the registry TLD DIT only has ONE access control type 🫶 when a client binds with a DN of "cn=trademark" and password of "attorney", the second-level domain entries also get an objectclass of extensibleObject plus the added attributes "createddate" and "registrationexpirationdate". both are type Generalized Time, as specified by RFC 2252 [6] ⏰
3.2. Name Server DIT 🖥️
3.2.1. DIT Structure
the registry name server DIT has this structural hierarchy, and it's giving tree energy 🌳
(o=nsiregistry.com)
|
|
-------------------------------------
| | |
name server name server name server
(cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
Figure 2: Registry DIT Overviewthe root of a name server DIT is an entry of objectclass organization as specified by RFC 1617 [2] 🦋 it has no significance other than to serve as the root of the DIT. it's just the main character 👑 and that's all it does.
the second tier of this DIT represents name servers. each of these entries is of objectclass ipHost, as specified by RFC 2307 [8] 💜
3.2.2. Allowed Searches
again, the vast number of entries means only certain searches are allowed 🙈 because any LDAP search would lead to searches far too costly for a publicly available service. here's what's allowed:
- One-level and sub-tree scoped searches based at the root of the DIT if a filter on the cn attribute is provided.
- Base search based at the root of the DIT.
- Base, one-level, and sub-tree searches based at any name server entry.
3.3. Registrar Referral DIT 🎀
3.3.1. DIT Structure
the registry registrar-referral DIT has this structural hierarchy 🧚
(o=tlds)
|
|
-------------------------------
| | | |
tld tld tld tld
(dc=net) (dc=com) (dc=org) (dc=edu)
| | | |
: : | :
: : | :
|
---------------------------
| | |
referral to referral to referral to
registrar 1 registrar 2 registrar n
dc=org DIT dc=org DIT dc=org DIT
Figure 3: Registry Referral DIT Overviewthe root of the registrar referral DIT is an entry of objectclass organization, as specified by RFC 1617 [2] 🍓 again, no significance beyond being the root of this DIT. it's giving "I'm just here to hold everything together" 🫶
the second tier represents top-level domains. each of these entries is of objectclass domain, as specified by RFC 2247 [4] 🌈
underneath each TLD entry, the third tier has referrals to the appropriate TLD DIT of each registrar ✨
4. Registrar LDAP Service 💖
4.1. TLD DIT
4.1.1. DIT Structure
the registrar TLD DIT is kinda like the registry TLD DIT, and this is its structure 🦋
TLD (e.g., dc=net)
|
|
------------------------------------------------
| | |
SLD (e.g., dc=foo,dc=net) : :
| : :
---------------------------------------------
| | |
| | |
name server contact referral to
(e.g., cn=nameserver1, (e.g., cn=contact1, registrant
dc=foo,dc=net ) dc=foo,dc=net )
|
|
name server contact
(e.g., cn=contact,
cn=nameserver1,
dc=foo,dc=net )
Figure 4: Registrar DIT Overviewthe root of a TLD DIT is an entry of objectclass domain, as specified by RFC 2247 [4], and it represents a top-level domain 🌸
the second tier represents second-level domains. each of these entries is of objectclass domain, as specified by RFC 2247 [4] 💅
the third tier has entries specific to each second-level domain. here's what lives at this level:
- Name server entries are of objectclass ipHost, as specified by RFC 2307 [8]. their distinguished names are algorithmically calculated, where the first component is the word "nameserver" concatenated with an index number of the name server entry, and the remaining components are the appropriate domain names. there is no specification relating the value of the name server entry to the index it may be assigned, other than that it is unique and consistent with respect to the client session. 🖥️
- Contact entries are of objectclass inetOrgPerson, as specified by RFC 2798 [9]. their distinguished names are algorithmically calculated, where the first component is the word "contact" concatenated with an index number of the contact, and the remaining components are the appropriate domain names. there is no specification relating the value of the contact entry to the index it may be assigned, other than that it is unique and consistent with respect to the client session. the description attribute holds the role a contact plays for a domain. these roles are "Admin Contact", "Technical Contact", and "Billing Contact", and they may appear in any order. 🧑💻
- Finally, this third tier contains the referral from the registrar to the registrant. 👑
the fourth tier ONLY has name server contact entries 🙈 these are of objectclass inetOrgPerson, as specified by RFC 2798 [9].
4.1.2. Allowed Searches
yep, same energy: the DIT is massive, so only certain searches are allowed, because any LDAP search would be far too costly for a publicly available service 💀 here's the list:
- One-level scoped searches based at the root of the DIT. Substring matching is allowed on
dcandoattributes, but the substring must be at least 3 characters in length. - Base search based at the root of the DIT.
- Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below.
4.1.3. Access Control 🔑
the registrar TLD DIT has TWO access control types, so pay attention 👀 when binding anonymously, a client only sees the dc, o, and c attributes of second-level domain entries. when a client binds with a DN of "cn=trademark" and password of "attorney", all of the other attributes normally available on objectclass domain entries are visible, as long as they have values. and if a client binds with the DN of a contact and password of "password", all attributes for second-level domain entries that the bind DN has a relation to are visible 🦋
4.2. Name Server and Contact DIT 🌷
4.2.1. DIT Structure
the registrar name server and contact DIT has this structural hierarchy 🌈
(o=nsi.com)
|
|
--------------------------------------
| |
Contacts Name Servers
(ou=contacts) (ou=name servers)
| |
----------------- ------------------------
| | | | | |
Contact : : Name Server : :
(uid=handle) : : (cn=handle) : :
|
Name Server
Contact
(cn=contact1)
Figure 5: Registrar DIT Overviewthe first tier of the name server and contact DIT is an entry of objectclass organization, as specified by RFC 1617 [2] ✨
the second tier has TWO entries, and each one is of objectclass organizationalUnit, as specified by RFC 2256 [7] 🫶 one entry represents the part of the DIT with contacts, and the other represents the part with name servers. very organized, very slay 💅
entries underneath the contacts organizationalUnit entry are of objectclass inetOrgPerson and represent contacts registered with the registrar. their RDN is composed of the uid attribute. the uid attribute's value is a unique identifier or handle that is assigned by the registrar 🧚
entries underneath the name server organizationalUnit entry are of objectclass ipHost and represent name servers registered with the registrar. their RDN is composed of the cn attribute. the cn attribute's value is a unique identifier or handle that is assigned by the registrar. each name server entry may optionally have child entries of objectclass inetOrgPerson, and these represent the contacts of the name server they sit beneath 🍓
4.2.2. Allowed Searches
last one, and it's the same story: the DIT is huge, so only certain searches are allowed, because any LDAP search would be far too costly for a publicly available service 🙈 here's what you can do:
- One-level and base searches at the root of the DIT.
- Sub-tree searches at the root of the DIT using
cnanduidattributes as a filter. - Base searches at either entry of the second tier.
- One-level and sub-tree searches at either entry of the second tier, using
cnoruidattributes as a filter. - Base, one-level, and sub-tree searches based at any contact or name server entry and below.
5. Clients ✨
okay so early on, the whole project was scoped and analyzed using output from command line clients, specifically the ldapsearch command that ships with lots of LDAP server implementations 💻. When the team surveyed this tool (it's available from many vendors), referral chasing was hard to control or predict, and the behavior across implementations was inconsistent 😭.
Because command line tools can only express so much, searches with nested queries or advanced referral chasing were handed off to clients that use LDAP client libraries directly 🧚. Three of these were built: a web-based client, a cross-platform C-based client, and a Java client 🎀. No significant deficiencies or problems turned up in the LDAP client libraries while building them, and the control their programming interfaces offered was enough to write the searches needed 💖. The real problems were usability concerns 🙈.
The web-based client was lowkey confusing for users who didn't know LDAP or Nicname/Whois, especially about the underlying technology and the network model 💀. A lot of people thought the web client was the only interface to the data and didn't even notice the LDAP protocol in between 🫠. It was also hard to explain the registry-registrar-registrant service model clearly from search results, since the results had to render properly across the common web browsers 🌸.
The C-based and Java clients were both built to be graphical and cross-platform (for the C-based client, Linux and Windows were the chosen targets) 🦋. The LDAP client libraries used for both were super capable and gave the level of control needed for nested queries and advanced referral chasing 👑. Going in, the team assumed (based on past experience) that the C-based client would perform better than the Java one and look nicer too. That was not the tea 🍵. There was no perceivable difference in performance, and the Java client's look was often considered far superior ✨. The Java client also took much less time to create 🔥. Both clients are available under the terms of an open source license 🫶. Nobody can get accurate popularity numbers, but through monitoring and feedback it was perceived that the web-based client had way more use 💅.
6. Lessons Learned 🌈
ngl this part is the juiciest bit. The following items were noted based on piloting this experimental service, feedback from users of the service, and general comments and observations of current and common opinions 🧠.
6.1. Intra-Server Referrals
Okay so the original analysis of the data set revealed a high degree of relationships between name servers, contacts, and domains 🔗. Storing the data in non-normalized form according to the DIT outlined in this document would make an original relational dataset of roughly 20 million objects explode to over 115 million objects 😱.
To fix that, the first pass at defining the DITs made heavy use of referrals between the TLD DITs and the name server and contact DITs 🔁. The alias objectclass was considered but ruled out, because the plan was to use referrals for load balancing across servers (like placing each TLD DIT on a separate server, with separate servers for the name server and contact DITs) ⚖️. But initial testing with the ldapsearch command found inconsistencies in how the referrals were interpreted and managed 🤯. The results weren't consistent between implementations, and lots of clients would easily get caught in referral loops 🌀.
The final solution was a customized back-end data store holding the data in normalized form 🎉. This gave the client the appearance of a non-normalized data set that needed no intra-server referrals ✨. Aliases might have been a better solution, but the output from implementations of the ldapsearch tool wasn't satisfactory 🙃. It was also learned later that some LDAP server implementations place certain restrictions on aliases that would have conflicted with the overall DIT structure 🚫. In the end, it was felt that a customized back-end would be required by any server with a large data set, but smaller data sets for less populated domains could easily use off-the-shelf implementations 🧚♀️.
6.2. Inter-Server Referrals
The overall service was modeled to split operational responsibility between registry and registrar, and that required referrals 🎀. The two servers would not be operated by the same organization, so they would most likely not co-exist on the same physical machine or network 🏢. The chief problem with the LDAP referrals returned for this purpose came from the need to limit the data returned to the client and the priority given to referrals 😤. It was super easy to cause a sub-tree query at certain levels (a TLD level, for instance) to return nothing but referrals 💀. This happened because referrals would be returned outside the scope of the supplied search filter, so they'd fill the result set up to its limit, which was normally set to 50 entries 📉.
In certain use cases, a result set with nothing but referrals was actually desired (for example, o=tlds) 👑. Even then, some referrals could be dropped because of the size limit 🙈. The team felt that a result set of 50 referrals (the default size limit in most cases) was way too large for any practical use by a client, and that it was a failing of query distribution in general rather than a limitation of LDAP 🫠.
6.3. Common DIT
Because of how software development goes, the graphical and web clients were developed after the server software 💻. The ldapsearch client was used for testing and development while the server software was being created 🧪. It wasn't until more advanced clients were built that everyone realized uniform DIT naming should have been decided on from the start 😩. That would have allowed for slightly better software modularization and re-use 🧩. Also, using a company name in the DIT structure didn't allow for easy integration of another domain registry, which is what the registry-registrar model needs 🚧. Clients would have to be reconfigured for every new registry operator, and that would most likely have social implications too 🙃.
6.4. Universal Client
Building the clients revealed another misconception 🤓. Even though this project used a generic directory service technology, the clients needed a high degree of algorithmic knowledge about the DIT structure and schemas in use 🧠. The graphical clients couldn't be used against an LDAP service with a different DIT or schema 🚫. So a generic or universal client (one that could be used for all LDAP applications) would either not be able to make full use of the data the service provides, or it would be way too complex for the average user to operate 😵💫.
6.5. Targeting Searches by Tier
The network model for this service was split into three tiers: registry, registrar, and registrant 🌸. Even so, all searches had to start at the registry level, which caused overhead for searches that could have been targeted at a select tier 🐢. This service didn't implement a fix for that, such as using SRV and/or NAPTR records in DNS to let a client find a responsible LDAP server 🔍.
6.6. Data Mining
Sections 3.1.2 and 4.1.2 describe the searches allowed by this service 📜. But the most common question users asked was about getting around those restrictions 🙈. Browsing at the TLD level wasn't permitted, so lots of users asked whether recursive dictionary queries could be used to get around the search restrictions 🕵️♀️.
It should be noted that many operators of Nicname/Whois servers consider this practice to be data mining, and they often refer to it specifically as a dictionary attack 🚨.
7. IANA Considerations 📋
There are no applicable IANA considerations presented in this document.
8. Internationalization Considerations 🌍
The domain administrative data in this service did not cover Internationalized Domain Names (IDN's).
9. Security Considerations 🚨
This experiment did not endeavor to use security mechanisms beyond those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3 describe the various access controls used within the scope of the defined security mechanisms. While these mechanisms were adequate for this experimental deployment, they would not be adequate for a production environment, and they should not be taken as a model for those contemplating deployment on the Internet. 💀🔐
10. Intellectual Property Statement ⚖️
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
11. Normative References 📚
[1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots", RFC 1617, May 1994.
[3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.
[5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[8] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
Appendix A. Other Work 🧚
okay so VeriSign didn't just deploy servers and build clients, they ran two side projects alongside this experiment 💅
The first one was a Nicname/Whois-to-LDAP gateway 🌸 The goal was an LDAP server that registrars could put in front of their Nicname/Whois servers. The gateway took LDAP requests, translated them into Nicname/Whois requests, sent each one to a specific Nicname/Whois server on port 43, interpreted the response, and returned LDAP result sets. Nicname/Whois output has no fixed format, so the gateway only knew how to recognize the output of three distinct registrars 😭 It was useful enough for domain lookups and limited searches, but it couldn't do consistent contact lookups, nameserver lookups, or registrant referrals. The software was also released publicly under an open source license 🫶
The second one was an informal survey of registrants who had LDAP servers deployed 🔍 They used the com, net, org, and edu zone files and checked for an LDAP server on port 389 at three kinds of names: the domain itself, a host named "ldap" in the domain, and a host named "dir" in the domain (so "foo.com", "ldap.foo.com", and "dir.foo.com"). The survey did not try to find LDAP services through SRV records in DNS.
The results were kinda surprising 👀 Roughly 0.5% of active domains had an LDAP server. By profiling each server's root DSA-specific Entry (DSE), the survey found that about 90% were implementations from vendor A, 9% were from vendor B, and 1% were from other vendors. Of the vendor A servers that were queried, only about 10% contained public data, which led to the assumption that the other 90% weren't meant to be publicly queried 🙈 Nearly all of the vendor B servers that were queried did contain public data.
Appendix B. Acknowledgments 💜
Big thank-yous to Brad McMillen, David Blacka, Anna Zhang, and Michael Schiraldi 🎀 They did the significant analysis, design, and implementation for this project ✨ Mark Kosters and Leslie Daigle gave guidance by reviewing the project, its goals, and this document 🫶
Author's Address 📫
Andrew Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.netFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved.
Okay, the legal bit, but make it cute 💅 You can copy and share this document and translations of it, and you can make derivative works that comment on or explain it or help with implementing it. You can publish and distribute those copies and works, in whole or in part, without any restriction, as long as the copyright notice and this paragraph stay on every copy and derivative work 🦋
The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed, or when it's translated into languages other than English 🌈
The permissions above are perpetual, and the Internet Society or its successors or assignees won't revoke them 💖
This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society ✨ Thank you, Internet Society, you're literally the MVP 👑
📦 where this page comes from
- ietf: rfc3663 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms