| blob | 7ae70f61b9c1498b28054a1dcf57e2a4518be523 |
7 Network Working Group A. Newton
8 Request for Comments: 3663 VeriSign, Inc.
9 Category: Experimental December 2003
12 Domain Administrative Data
13 in Lightweight Directory Access Protocol (LDAP)
15 Status of this Memo
17 This memo defines an Experimental Protocol for the Internet
18 community. It does not specify an Internet standard of any kind.
19 Discussion and suggestions for improvement are requested.
20 Distribution of this memo is unlimited.
22 Copyright Notice
24 Copyright (C) The Internet Society (2003). All Rights Reserved.
26 Abstract
28 Domain registration data has typically been exposed to the general
29 public via Nicname/Whois for administrative purposes. This document
30 describes the Referral Lightweight Directory Access Protocol (LDAP)
31 Service, an experimental service using LDAP and well-known LDAP types
32 to make domain administrative data available.
58 Newton Experimental [Page 1]
59 \f
60 RFC 3663 Domain Administrative Data in LDAP December 2003
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Historical Directory Services for Domain Registration
67 Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3
69 1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4
70 2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4
71 3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6
72 3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6
73 3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6
74 3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7
75 3.1.3. Access Control . . . . . . . . . . . . . . . . . 7
76 3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8
77 3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8
78 3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8
79 3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9
80 3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9
81 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10
82 4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10
83 4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10
84 4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11
85 4.1.3. Access Control . . . . . . . . . . . . . . . . . 11
86 4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12
87 4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12
88 4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13
89 5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
90 6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14
91 6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14
92 6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15
93 6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15
94 6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16
95 6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16
96 6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16
97 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
98 8. Internationalization Considerations. . . . . . . . . . . . . . 16
99 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
100 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17
101 11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
102 Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19
103 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
105 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
114 Newton Experimental [Page 2]
115 \f
116 RFC 3663 Domain Administrative Data in LDAP December 2003
119 1. Introduction
121 This document describes the Referral Lightweight Directory Access
122 Protocol (LDAP) Service, an experimental project launched by
123 VeriSign, Inc., to explore the use of LDAP and LDAP-related
124 technologies for use as a directory service of administrative domain
125 registration information.
127 1.1. Historical Directory Services for Domain Registration Data
129 The original National Science Foundation contract for the InterNIC
130 called for the creation of an X.500 directory service for the
131 administrative needs of the domain registration data and information.
132 Due to problems with implementations of X.500 server software, a
133 server based on the Nicname/Whois [1] protocol was temporarily
134 erected.
136 In 1994, the Rwhois [3] protocol was introduced to enhance the
137 Nicname/Whois protocol. This directory service never gained wide
138 acceptance for use with domain data.
140 Presently, ICANN requires the operation of Nicname/Whois servers by
141 registries and registrars of generic Top-Level Domains (TLD's).
143 1.2. Motivations
145 With the recent split in functional responsibilities between
146 registries and registrars, the constant misuse and data-mining of
147 domain registration data, and the difficulties with machine-
148 readability of Nicname/Whois output, the creation of the Referral
149 LDAP Service had the following motivations:
151 o Use a mechanism native to the directory protocol to refer clients
152 from inquiries about specific domains made at a registry to the
153 appropriate domain within the appropriate directory service at a
154 registrar.
156 o Limit access to domain data based on authentication of the client.
158 o Provide structured queries and well-known and structured results.
160 o Use a directory service technology already in general use.
162 Given these general criteria, LDAP [5] was selected as the protocol
163 for this directory service. The decision was also made to restrict
164 the use of LDAP to features most readily available in common
165 implementations. Therefore, a goal was set to not define any new
166 object classes, syntaxes, or matching rules.
170 Newton Experimental [Page 3]
171 \f
172 RFC 3663 Domain Administrative Data in LDAP December 2003
175 The experiment was successful in exploring how LDAP might be used in
176 this context and demonstrating the level of customization required
177 for an operational service. Conclusions and observations about this
178 experiment are outlined in Section 6.
180 1.3. Abbreviations Used
182 The following abbreviations are used to describe the nature of this
183 experiment:
185 TLD: Top-Level Domain. Refers to the domain names just beneath
186 the root in the Domain Name System. This experiment used the
187 TLD's .com, .net, .org, and .edu.
189 SLD: Second-Level Domain. Refers to the domain names just beneath
190 a TLD in the Domain Name System. An example of such a domain name
191 would be "example.com".
193 DIT: Directory Information Tree. One of many hierarchies of data
194 entries in an LDAP server.
196 DN: Distinguished Name. The unique name of an entry in a DIT.
198 cn: common name. See RFC 2256 [7].
200 dc: domain component. See RFC 2247 [4].
202 uid: user id. See RFC 2798 [9].
204 2. Service Description
206 The service is composed of three distinct server types: a registry
207 LDAP server, registrar LDAP servers, and registrant LDAP servers.
209 The registry LDAP server contains three Directory Information Trees
210 (DIT's).
212 o The Top-Level Domain DIT's follow the DNS hierarchy for domains
213 (e.g., dc=foo,dc=com).
215 o The name server DIT allows a view of the name servers, many of
216 which serve multiple domains.
218 o The registrar-referral DIT provides referrals from the registry
219 into the respective TLD DIT of the registrars (on a TLD basis).
226 Newton Experimental [Page 4]
227 \f
228 RFC 3663 Domain Administrative Data in LDAP December 2003
231 The registrar LDAP server contains two types of DIT's.
233 o The TLD DIT follows the DNS hierarchy for domains (e.g.,
234 dc=foo,dc=com) and parallels the TLD DIT of the registry.
236 o The name server and contact DIT allow a view of the name servers
237 and contacts, many of which are associated and serve multiple
238 domains.
240 There is no specification on the DIT or schema for the registrant
241 LDAP server. Referrals from the registrar server to the registrant
242 server are provided solely for the purpose of allowing the registrant
243 direct control over extra administrative information as it relates to
244 a particular domain.
246 Access control for this service is merely a demonstration of using a
247 Distinguished Name (DN) and password. Should registries and
248 registrars uniformly adopt LDAP as a means to disseminate domain
249 registration data, standardization of these DN's would need to be
250 undertaken based on each type of user base.
282 Newton Experimental [Page 5]
283 \f
284 RFC 3663 Domain Administrative Data in LDAP December 2003
287 3. Registry LDAP Service
289 3.1. TLD DIT
291 3.1.1. DIT Structure
293 The registry TLD DIT has the following structural hierarchy:
295 TLD (e.g., dc=net)
296 |
297 |
298 -------------------------------------
299 | |
300 SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
301 | |
302 --------------------- ---------------------
303 | | | | | |
304 name server | | name server | |
305 (e.g., | | (e.g., | |
306 cn=nameserver1, | | cn=nameserver1, | |
307 dc=foo,dc=net ) | | dc=bar,dc=net ) | |
308 | | | |
309 name server | name server |
310 (e.g., | (e.g., |
311 cn=nameserver2, | cn=nameserver2, |
312 dc=foo,dc=net ) | dc=bar,dc=net ) |
313 | |
314 registrar referral registrar referral
315 (e.g., (e.g.,
316 cn=registrar, cn=registrar,
317 dc=foo,dc=net ) dc=bar,dc=net )
320 Figure 1: Registry DIT Overview
322 The root of a TLD DIT is an entry of objectclass domain as specified
323 by RFC 2247 [4] and represents a top-level domain.
325 The second tier of the DIT represents second-level domains. Each of
326 these entries is of objectclass domain as specified by RFC 2247 [4].
327 The description attribute on these entries often contains descriptive
328 text giving the name of the registrar through which these domains
329 have been registered.
331 The third tier contains entries specific to each second-level domain.
332 Name server entries are of objectclass ipHost as specified by RFC
333 2307 [8]. The distinguished names of these name server entries are
334 algorithmically calculated, where the first component is the word
338 Newton Experimental [Page 6]
339 \f
340 RFC 3663 Domain Administrative Data in LDAP December 2003
343 "nameserver" concatenated with an index number of the name server
344 entry and the remaining components are the appropriate domain names.
345 There is no specification relating the value of the name server entry
346 to the index it may be assigned other than it is unique and
347 consistent with respect to the client session. This tier also
348 contains the referral from the registry to the registrar. This
349 referral is a direct referral to the entry in the appropriate
350 registrar LDAP server corresponding to the domain name that the
351 referral falls beneath in this DIT.
353 3.1.2. Allowed Searches
355 Because of the vast number of entries contained within this DIT, only
356 certain types of searches are allowed. Allowing any search
357 expressible via LDAP would lead to expensive searches that would be
358 far too costly for a publicly available service. The searches
359 allowed are as follows:
361 o One-level scoped searches based at the root of the DIT. Substring
362 matching is allowed on dc attributes, but the substring must be at
363 least be 3 characters in length.
365 o Base search based at the root of the DIT.
367 o Base, one-level, and sub-tree searches based at any second level
368 domain name (the second tier) and below.
370 3.1.3. Access Control
372 The registry TLD DIT only has one access control type. When a client
373 binds with a DN of "cn=trademark" and password of "attorney", the
374 second-level domain entries also take on an objectclass of
375 extensibleObject with the added attributes of "createddate" and
376 "registrationexpirationdate", which are of type Generalized Time, as
377 specified by RFC 2252 [6].
394 Newton Experimental [Page 7]
395 \f
396 RFC 3663 Domain Administrative Data in LDAP December 2003
399 3.2. Name Server DIT
401 3.2.1. DIT Structure
403 The registry name server DIT has the following structural hierarchy:
405 (o=nsiregistry.com)
406 |
407 |
408 -------------------------------------
409 | | |
410 name server name server name server
411 (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
414 Figure 2: Registry DIT Overview
416 The root of a name server DIT is an entry of objectclass organization
417 as specified by RFC 1617 [2]. It has no significance other than to
418 serve as the root of the DIT.
420 The second tier of this DIT represents name servers. Each of these
421 entries is of objectclass ipHost, as specified by RFC 2307 [8].
423 3.2.2. Allowed Searches
425 Because of the vast number of entries contained within this DIT, only
426 certain types of searches are allowed. Allowing any search
427 expressible via LDAP would lead to searches far too costly for a
428 publicly available service. The searches allowed are as follows:
430 o One-level and sub-tree scoped searches based at the root of the
431 DIT if a filter on the cn attribute is provided.
433 o Base search based at the root of the DIT.
435 o Base, one-level, and sub-tree searches based at any name server
436 entry.
450 Newton Experimental [Page 8]
451 \f
452 RFC 3663 Domain Administrative Data in LDAP December 2003
455 3.3. Registrar Referral DIT
457 3.3.1. DIT Structure
459 The registry registrar-referral DIT has the following structural
460 hierarchy:
462 (o=tlds)
463 |
464 |
465 -------------------------------
466 | | | |
467 tld tld tld tld
468 (dc=net) (dc=com) (dc=org) (dc=edu)
469 | | | |
470 : : | :
471 : : | :
472 |
473 ---------------------------
474 | | |
475 referral to referral to referral to
476 registrar 1 registrar 2 registrar n
477 dc=org DIT dc=org DIT dc=org DIT
480 Figure 3: Registry Referral DIT Overview
482 The root of the registrar referral DIT is an entry of objectclass
483 organization, as specified by RFC 1617 [2]. It has no significance
484 other than to serve as the root of this DIT.
486 The second tier of this DIT represents top-level domains. Each of
487 these entries is of objectclass domain, as specified by RFC 2247 [4].
489 Underneath each TLD entry, the third tier contains referrals to the
490 appropriate TLD DIT of each registrar.
506 Newton Experimental [Page 9]
507 \f
508 RFC 3663 Domain Administrative Data in LDAP December 2003
511 4. Registrar LDAP Service
513 4.1. TLD DIT
515 4.1.1. DIT Structure
517 The registrar TLD DIT, which is similar to the registry TLD DIT, has
518 the following structural hierarchy:
520 TLD (e.g., dc=net)
521 |
522 |
523 ------------------------------------------------
524 | | |
525 SLD (e.g., dc=foo,dc=net) : :
526 | : :
527 ---------------------------------------------
528 | | |
529 | | |
530 name server contact referral to
531 (e.g., cn=nameserver1, (e.g., cn=contact1, registrant
532 dc=foo,dc=net ) dc=foo,dc=net )
533 |
534 |
535 name server contact
536 (e.g., cn=contact,
537 cn=nameserver1,
538 dc=foo,dc=net )
540 Figure 4: Registrar DIT Overview
542 The root of a TLD DIT is an entry of objectclass domain, as specified
543 by RFC 2247 [4] and represents a top-level domain.
545 The second tier of the DIT represents second-level domains. Each of
546 these entries is of objectclass domain, as specified by RFC 2247 [4].
548 The third tier contains entries specific to each second-level domain.
549 The entries at this level are as follows:
551 o Name server entries are of objectclass ipHost, as specified by RFC
552 2307 [8]. The distinguished names of these name server entries
553 are algorithmically calculated where the first component is the
554 word "nameserver" concatenated with an index number of the name
555 server entry and the remaining components are the appropriate
556 domain names. There is no specification relating the value of the
557 name server entry to the index it may be assigned other than it is
558 unique and consistent with respect to the client session.
562 Newton Experimental [Page 10]
563 \f
564 RFC 3663 Domain Administrative Data in LDAP December 2003
567 o Contact entries are of objectclass inetOrgPerson, as specified by
568 RFC 2798 [9]. The distinguished names of these contact entries
569 are algorithmically calculated, where the first component is the
570 word "contact" concatenated with an index number of the contact
571 and the remaining components are the appropriate domain names.
572 There is no specification relating the value of the contact entry
573 to the index it may be assigned other than it is unique and
574 consistent with respect to the client session. The description
575 attribute of the entry contains the role for which a contact is
576 related to a domain. These roles are identified as "Admin
577 Contact", "Technical Contact", and "Billing Contact", and may
578 appear in any order.
580 o Finally, this third tier contains the referral from the registrar
581 to the registrant.
583 The fourth tier only contains name server contact entries. These
584 entries are of objectclass inetOrgPerson, as specified by RFC 2798
585 [9].
587 4.1.2. Allowed Searches
589 Because of the vast number of entries contained within this DIT, only
590 certain types of searches are allowed. Allowing any search
591 expressible via LDAP would lead to searches far too costly for a
592 publicly available service. The searches allowed are as follows:
594 o One-level scoped searches based at the root of the DIT. Substring
595 matching is allowed on dc and o attributes, but the substring must
596 be at least 3 characters in length.
598 o Base search based at the root of the DIT.
600 o Base, one-level, and sub-tree searches based at any second level
601 domain name (the second tier) and below.
603 4.1.3. Access Control
605 The registrar TLD DIT has two access control types. When binding
606 anonymously, a client only sees dc, o, and c attributes of the
607 second-level domain entries. When a client binds with a DN of
608 "cn=trademark" and password of "attorney", all of the other
609 attributes normally available on entries of objectclass domain are
610 visible if they have values. In addition, if a client binds with the
611 DN of a contact and password of "password", all attributes for
612 second-level domain entries for which the bind DN has a relation are
613 visible.
618 Newton Experimental [Page 11]
619 \f
620 RFC 3663 Domain Administrative Data in LDAP December 2003
623 4.2. Name Server and Contact DIT
625 4.2.1. DIT Structure
627 The registrar name server and contact DIT has the following
628 structural hierarchy:
630 (o=nsi.com)
631 |
632 |
633 --------------------------------------
634 | |
635 Contacts Name Servers
636 (ou=contacts) (ou=name servers)
637 | |
638 ----------------- ------------------------
639 | | | | | |
640 Contact : : Name Server : :
641 (uid=handle) : : (cn=handle) : :
642 |
643 Name Server
644 Contact
645 (cn=contact1)
647 Figure 5: Registrar DIT Overview
649 The first tier of the name server and contact DIT is an entry of
650 objectclass organization, as specified by RFC 1617 [2].
652 The second tier of the DIT contains two entries, each of which is of
653 objectclass organizationalUnit, as specified by RFC 2256 [7]. One
654 entry represents the part of the DIT containing contacts and the
655 other entry represents the part of the DIT containing name servers.
657 Entries underneath the contacts organizationalUnit entry are of
658 objectclass inetOrgPerson and represent contacts registered with the
659 registrar. Their RDN is composed of the uid attribute. The uid
660 attribute's value is a unique identifier or handle that is registrar
661 assigned.
663 Entries underneath the name server organizationalUnit entry are of
664 objectclass ipHost and represent name servers registered with the
665 registrar. Their RDN is composed of the cn attribute. The cn
666 attribute's value is a unique identifier or handle that is registrar
667 assigned. Each name server entry may optionally have children
668 entries of objectclass inetOrgPerson. These entries represent the
669 contacts of the name server they fall beneath.
674 Newton Experimental [Page 12]
675 \f
676 RFC 3663 Domain Administrative Data in LDAP December 2003
679 4.2.2. Allowed Searches
681 Because of the vast number of entries contained within this DIT, only
682 certain types of searches are allowed. Allowing any search
683 expressible via LDAP would lead to searches far too costly for a
684 publicly available service. The searches allowed are as follows:
686 o One-level and base searches at the root of the DIT.
688 o Sub-tree searches at the root of the DIT using cn and uid
689 attributes as a filter.
691 o Base searches at either entry of the second tier.
693 o One-level and sub-tree searches at either entry of the second
694 tier, using cn or uid attributes as a filter.
696 o Base, one-level, and sub-tree searches based at any contact or
697 name server entry and below.
699 5. Clients
701 Early scoping and analysis of this project were based on the use of
702 output from command line clients, specifically the "ldapsearch"
703 command present with many implementations of LDAP servers. Our
704 survey of this tool, available from many vendors, showed that
705 referral chasing was difficult to control or predict, and the
706 behavior between these implementations with respect to referral
707 chasing was inconsistent.
709 Based on the limited nature of the expressive capabilities present
710 with just command line tools, searches involving nested queries or
711 advanced referral chasing were deemed the domain of clients making
712 direct use of LDAP client libraries. Three of these types of clients
713 were produced: a web-based client, a cross-platform C-based client,
714 and a Java client. No significant deficiencies or problems were
715 found with the LDAP client libraries in the construction of these
716 clients, and the level of control provided by their programming
717 interfaces was adequate to create the necessary searches. Instead,
718 most of the problems encountered with these clients were based on
719 usability concerns.
721 It was found that the web-based client caused a great amount of
722 confusion for users not familiar with LDAP or Nicname/Whois with
723 respect to the underlying technology and the network model. Thus,
724 many users believed the web-based client to be the only interface to
725 the data and were unaware or confused by the intermediate LDAP
726 protocol. In addition, it was difficult to express to users the
730 Newton Experimental [Page 13]
731 \f
732 RFC 3663 Domain Administrative Data in LDAP December 2003
735 registry-registrar-registrant service model in adequate terms from
736 search results where the results could be rendered properly among the
737 various common web browsers.
739 Both the C and Java based clients were built to be both graphical and
740 cross-platform (in the case of the C-based client, the Linux and
741 Windows platforms were chosen as targets). The LDAP client libraries
742 chosen for both clients proved to be quite capable and offered the
743 necessary levels of control for conducting nested queries and
744 advanced referral chasing. Expectations at the outset for
745 construction of both clients, based on past experience, were that the
746 C-based client would not only perform better than the Java client but
747 also have a better appearance. In reality, these assumptions were
748 incorrect as there was no perceivable difference in performance and
749 the look of the Java client was often considered to be far superior
750 to its counter-part. In addition, the Java client required much less
751 time to create. Both clients are available under the terms of an
752 open source license. Though it is impossible to have accurate
753 measurements of their popularity, through monitoring and feedback it
754 was perceived that the web-based client had far greater use.
756 6. Lessons Learned
758 Based on the experience of piloting this experimental service,
759 feedback from users of the service, and general comments and
760 observations of current and common opinions, the following items have
761 been noted.
763 6.1. Intra-Server Referrals
765 Original analysis of the data set to be used revealed a high degree
766 of relationships between name servers, contacts, and domains.
767 Storing the data in non-normalized form according to the DIT outlined
768 in this document would make an original relational dataset of roughly
769 20 million objects explode to over 115 million objects.
771 To combat this problem, the first pass at defining the DIT's made
772 heavy use of referrals between the TLD DIT's and the name server and
773 contact DIT's. The use of the 'alias' objectclass was considered but
774 ruled out in hopes of using referrals for load balancing across
775 servers (i.e., placing each TLD DIT on a separate server, and
776 separate servers for the name server and contact DIT's). However,
777 initial testing with the 'ldapsearch' command found inconsistencies
778 with the interpretation of the referrals and how they were managed.
779 Not only were the results inconsistent between implementations, but
780 many of these clients would easily get caught in referral loops.
786 Newton Experimental [Page 14]
787 \f
788 RFC 3663 Domain Administrative Data in LDAP December 2003
791 The final solution to the problem was to create a customized back-end
792 data store containing the data in a normalized form. This gave the
793 client the appearance of having a non-normalized data set which
794 required no intra-server referrals. Aliases may have been a better
795 solution, however our interpretation of their output with
796 implementations of the 'ldapsearch' tool was not satisfactory. It
797 was also later learned that some LDAP server implementations place
798 certain restrictions on aliases that would have conflicted with our
799 overall DIT structure. In the end, it was felt that a customized
800 back-end would be required by any server with a large data-set, but
801 smaller data-sets for less populated domains could easily use off-
802 the-shelf implementations.
804 6.2. Inter-Server Referrals
806 The modeling of the overall service to provide the split in
807 operational responsibility between registry and registrar required
808 the use of referrals (i.e., the two servers would not be operated by
809 the same organization, therefore would most likely not co-exist on
810 the same physical machine or network). The chief problem with LDAP
811 referrals returned for this purpose grew out of the need to limit
812 data returned to the client and the priority given to referrals. It
813 was quite easy to cause a sub-tree query at certain levels, for
814 instance a TLD level, to return nothing but referrals. This was true
815 because referrals would be returned out of the scope of the supplied
816 search filter and therefore would fill the result set to its limit,
817 normally set to 50 entries.
819 In certain use cases, a result set with nothing but referrals was
820 desired (e.g., o=tlds). However, even in these cases it was possible
821 for some referrals to not be returned due to the size limit. In this
822 case, it was felt that a result set of 50 referrals, the default for
823 the size limit in most cases, was too large for any practical use by
824 a client and was a failing of query distribution in general rather
825 than a limitation of LDAP.
827 6.3. Common DIT
829 Because of the nature of software development, the graphical and web
830 clients were developed after the development of the server software.
831 The 'ldapsearch' client was used for testing and development during
832 server software creation. It was not until the creation of more
833 advanced clients that it was discovered that the design decision of
834 uniform DIT naming should have been made. Technically, this would
835 have allowed for slightly better software modularization and re-use.
836 In addition, the use of a company name in the DIT structure did not
837 allow the easy integration of another domain registry, as in the
838 registry-registrar model. Not only would clients have to be
842 Newton Experimental [Page 15]
843 \f
844 RFC 3663 Domain Administrative Data in LDAP December 2003
847 reconfigured for each new registry operator, but this would most
848 likely have social implications as well.
850 6.4. Universal Client
852 The construction of the clients revealed yet another misconception.
853 Though this project used a generic directory service technology, the
854 clients required a high-degree of algorithmic knowledge about the DIT
855 structure and schemas being used. The graphical clients could not be
856 used against an LDAP service with another DIT or schema. Therefore,
857 a generic or universal client, one that could be used for all LDAP
858 applications, would either not be able to make full use of the data
859 provided by the service or would be far too complex for operation by
860 the average user.
862 6.5. Targeting Searches by Tier
864 The network model for this service was divided into three tiers:
865 registry, registrar, and registrant. Despite this, all searches
866 needed to start at the registry level causing overhead for searches
867 that could be targeted at a select tier. This service did not
868 implement a solution to this problem, such as using SRV and/or NAPTR
869 records in DNS to allow a client to find a responsible LDAP server.
871 6.6. Data Mining
873 Section 3.1.2 and Section 4.1.2 describe the searches allowed by this
874 service. However, the most common question asked by users of the
875 service revolved around getting around these restrictions. Because
876 browsing at the TLD level was not permitted, many users asked about
877 the feasibility of using recursive dictionary queries to circumvent
878 the search restrictions.
880 It should be noted that many operators of Nicname/Whois server
881 consider this practice to be data mining and often refer to it
882 specifically as a dictionary attack.
884 7. IANA Considerations
886 There are no applicable IANA considerations presented in this
887 document.
889 8. Internationalization Considerations
891 The domain administrative data in this service did not cover
892 Internationalized Domain Names (IDN's).
898 Newton Experimental [Page 16]
899 \f
900 RFC 3663 Domain Administrative Data in LDAP December 2003
903 9. Security Considerations
905 This experiment did not endeavor to use security mechanisms beyond
906 those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3
907 describe the various access controls used within the scope of the
908 defined security mechanisms. While these mechanisms were adequate
909 for this experimental deployment, they would not be adequate for a
910 production environment, and they should not be taken as a model for
911 those contemplating deployment on the Internet.
913 10. Intellectual Property Statement
915 The IETF takes no position regarding the validity or scope of any
916 intellectual property or other rights that might be claimed to
917 pertain to the implementation or use of the technology described in
918 this document or the extent to which any license under such rights
919 might or might not be available; neither does it represent that it
920 has made any effort to identify any such rights. Information on the
921 IETF's procedures with respect to rights in standards-track and
922 standards-related documentation can be found in BCP-11. Copies of
923 claims of rights made available for publication and any assurances of
924 licenses to be made available, or the result of an attempt made to
925 obtain a general license or permission for the use of such
926 proprietary rights by implementors or users of this specification can
927 be obtained from the IETF Secretariat.
929 The IETF invites any interested party to bring to its attention any
930 copyrights, patents or patent applications, or other proprietary
931 rights which may cover technology that may be required to practice
932 this standard. Please address the information to the IETF Executive
933 Director.
954 Newton Experimental [Page 17]
955 \f
956 RFC 3663 Domain Administrative Data in LDAP December 2003
959 11. Normative References
961 [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
962 954, October 1985.
964 [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
965 Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
966 May 1994.
968 [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
969 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
970 June 1997.
972 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
973 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
974 January 1998.
976 [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
977 Protocol (v3)", RFC 2251, December 1997.
979 [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
980 Directory Access Protocol (v3): Attribute Syntax Definitions",
981 RFC 2252, December 1997.
983 [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
984 LDAPv3", RFC 2256, December 1997.
986 [8] Howard, L., "An Approach for Using LDAP as a Network Information
987 Service", RFC 2307, March 1998.
989 [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
990 RFC 2798, April 2000.
1010 Newton Experimental [Page 18]
1011 \f
1012 RFC 3663 Domain Administrative Data in LDAP December 2003
1015 Appendix A. Other Work
1017 In addition to the deployment of servers and development of clients,
1018 VeriSign conducted two sub-projects related to this experiment.
1020 The first project was a Nicname/Whois-to-LDAP gateway. The goal of
1021 the project was to create an LDAP server for use by registrars to
1022 deploy in front of their Nicname/Whois servers. This gateway would
1023 take LDAP requests, translate them to Nicname/Whois requests, issue
1024 the request to a specific Nicname/Whois server deployed on port 43,
1025 interpret the response, and return LDAP result sets. Because of the
1026 unspecified nature of Nicname/Whois result sets, the gateway was
1027 programmed to specifically recognize only the output of three
1028 distinct registrars. While this gateway proved valuable enough to
1029 allow domain lookups and limited searches, it was unable to provide
1030 consistent contact lookups, nameserver lookups, or registrant
1031 referrals. This software was also made publicly available under the
1032 terms of an open source license.
1034 The second project was an informal survey of registrants with
1035 deployed LDAP servers. This was conducted by using the com, net,
1036 org, and edu zone files and testing for the existence of an LDAP
1037 server on port 389 using the name of the domain, a host named "ldap"
1038 in the domain, and a host named "dir" in the domain (e.g., "foo.com",
1039 "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to
1040 resolve LDAP services using SRV records in DNS.
1042 The result of this survey found that roughly 0.5% of active domains
1043 had an LDAP server. By profiling a server's root DSA-specific Entry
1044 (DSE), the survey found that about 90% of the servers were
1045 implementations provided by vendor A, 9% of the servers were
1046 implementations provided by vendor B, and 1% of the servers were
1047 implementations provided by other vendors. Of the servers queried
1048 that were determined to be implementations provided by vendor A, it
1049 appeared that about only 10% contained public data (this also led to
1050 the assumption that the other 90% were not intended to be publicly
1051 queried). Of the servers queried that were determined to be
1052 implementations provided by vendor B, it appears that nearly all
1053 contained public data.
1055 Appendix B. Acknowledgments
1057 Significant analysis, design, and implementation for this project
1058 were conducted by Brad McMillen, David Blacka, Anna Zhang, and
1059 Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance
1060 by reviewing this project, the project's goals, and this document.
1066 Newton Experimental [Page 19]
1067 \f
1068 RFC 3663 Domain Administrative Data in LDAP December 2003
1071 Author's Address
1073 Andrew Newton
1074 VeriSign, Inc.
1075 21345 Ridgetop Circle
1076 Sterling, VA 20166
1077 USA
1079 Phone: +1 703 948 3382
1080 EMail: anewton@verisignlabs.com; anewton@ecotroph.net
1122 Newton Experimental [Page 20]
1123 \f
1124 RFC 3663 Domain Administrative Data in LDAP December 2003
1127 Full Copyright Statement
1129 Copyright (C) The Internet Society (2003). All Rights Reserved.
1131 This document and translations of it may be copied and furnished to
1132 others, and derivative works that comment on or otherwise explain it
1133 or assist in its implementation may be prepared, copied, published
1134 and distributed, in whole or in part, without restriction of any
1135 kind, provided that the above copyright notice and this paragraph are
1136 included on all such copies and derivative works. However, this
1137 document itself may not be modified in any way, such as by removing
1138 the copyright notice or references to the Internet Society or other
1139 Internet organizations, except as needed for the purpose of
1140 developing Internet standards in which case the procedures for
1141 copyrights defined in the Internet Standards process must be
1142 followed, or as required to translate it into languages other than
1143 English.
1145 The limited permissions granted above are perpetual and will not be
1146 revoked by the Internet Society or its successors or assignees.
1148 This document and the information contained herein is provided on an
1149 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1150 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1151 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1152 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1153 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1155 Acknowledgement
1157 Funding for the RFC Editor function is currently provided by the
1158 Internet Society.
1178 Newton Experimental [Page 21]
1179 \f