]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3663.txt
Merge remote-tracking branch 'origin/mdb.RE/0.9'
[openldap] / doc / rfc / rfc3663.txt
1
2
3
4
5
6
7 Network Working Group                                          A. Newton
8 Request for Comments: 3663                                VeriSign, Inc.
9 Category: Experimental                                     December 2003
10
11
12                        Domain Administrative Data
13             in Lightweight Directory Access Protocol (LDAP)
14
15 Status of this Memo
16
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.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2003).  All Rights Reserved.
25
26 Abstract
27
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.
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Newton                        Experimental                      [Page 1]
59 \f
60 RFC 3663           Domain Administrative Data in LDAP      December 2003
61
62
63 Table of Contents
64
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
106
107
108
109
110
111
112
113
114 Newton                        Experimental                      [Page 2]
115 \f
116 RFC 3663           Domain Administrative Data in LDAP      December 2003
117
118
119 1.  Introduction
120
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.
126
127 1.1.  Historical Directory Services for Domain Registration Data
128
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.
135
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.
139
140    Presently, ICANN requires the operation of Nicname/Whois servers by
141    registries and registrars of generic Top-Level Domains (TLD's).
142
143 1.2.  Motivations
144
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:
150
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.
155
156    o  Limit access to domain data based on authentication of the client.
157
158    o  Provide structured queries and well-known and structured results.
159
160    o  Use a directory service technology already in general use.
161
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.
167
168
169
170 Newton                        Experimental                      [Page 3]
171 \f
172 RFC 3663           Domain Administrative Data in LDAP      December 2003
173
174
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.
179
180 1.3.  Abbreviations Used
181
182    The following abbreviations are used to describe the nature of this
183    experiment:
184
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.
188
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".
192
193       DIT: Directory Information Tree.  One of many hierarchies of data
194       entries in an LDAP server.
195
196       DN: Distinguished Name.  The unique name of an entry in a DIT.
197
198       cn: common name.  See RFC 2256 [7].
199
200       dc: domain component.  See RFC 2247 [4].
201
202       uid: user id.  See RFC 2798 [9].
203
204 2.  Service Description
205
206    The service is composed of three distinct server types: a registry
207    LDAP server, registrar LDAP servers, and registrant LDAP servers.
208
209    The registry LDAP server contains three Directory Information Trees
210    (DIT's).
211
212    o  The Top-Level Domain DIT's follow the DNS hierarchy for domains
213       (e.g., dc=foo,dc=com).
214
215    o  The name server DIT allows a view of the name servers, many of
216       which serve multiple domains.
217
218    o  The registrar-referral DIT provides referrals from the registry
219       into the respective TLD DIT of the registrars (on a TLD basis).
220
221
222
223
224
225
226 Newton                        Experimental                      [Page 4]
227 \f
228 RFC 3663           Domain Administrative Data in LDAP      December 2003
229
230
231    The registrar LDAP server contains two types of DIT's.
232
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.
235
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.
239
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.
245
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.
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Newton                        Experimental                      [Page 5]
283 \f
284 RFC 3663           Domain Administrative Data in LDAP      December 2003
285
286
287 3.  Registry LDAP Service
288
289 3.1.  TLD DIT
290
291 3.1.1.  DIT Structure
292
293    The registry TLD DIT has the following structural hierarchy:
294
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 )
318
319
320                     Figure 1: Registry DIT Overview
321
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.
324
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.
330
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
335
336
337
338 Newton                        Experimental                      [Page 6]
339 \f
340 RFC 3663           Domain Administrative Data in LDAP      December 2003
341
342
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.
352
353 3.1.2.  Allowed Searches
354
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:
360
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.
364
365    o  Base search based at the root of the DIT.
366
367    o  Base, one-level, and sub-tree searches based at any second level
368       domain name (the second tier) and below.
369
370 3.1.3.  Access Control
371
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].
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394 Newton                        Experimental                      [Page 7]
395 \f
396 RFC 3663           Domain Administrative Data in LDAP      December 2003
397
398
399 3.2.  Name Server DIT
400
401 3.2.1.  DIT Structure
402
403    The registry name server DIT has the following structural hierarchy:
404
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)
412
413
414                     Figure 2: Registry DIT Overview
415
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.
419
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].
422
423 3.2.2.  Allowed Searches
424
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:
429
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.
432
433    o  Base search based at the root of the DIT.
434
435    o  Base, one-level, and sub-tree searches based at any name server
436       entry.
437
438
439
440
441
442
443
444
445
446
447
448
449
450 Newton                        Experimental                      [Page 8]
451 \f
452 RFC 3663           Domain Administrative Data in LDAP      December 2003
453
454
455 3.3.  Registrar Referral DIT
456
457 3.3.1.  DIT Structure
458
459    The registry registrar-referral DIT has the following structural
460    hierarchy:
461
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
478
479
480                 Figure 3: Registry Referral DIT Overview
481
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.
485
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].
488
489    Underneath each TLD entry, the third tier contains referrals to the
490    appropriate TLD DIT of each registrar.
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506 Newton                        Experimental                      [Page 9]
507 \f
508 RFC 3663           Domain Administrative Data in LDAP      December 2003
509
510
511 4.  Registrar LDAP Service
512
513 4.1.  TLD DIT
514
515 4.1.1.  DIT Structure
516
517    The registrar TLD DIT, which is similar to the registry TLD DIT, has
518    the following structural hierarchy:
519
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     )
539
540                     Figure 4: Registrar DIT Overview
541
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.
544
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].
547
548    The third tier contains entries specific to each second-level domain.
549    The entries at this level are as follows:
550
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.
559
560
561
562 Newton                        Experimental                     [Page 10]
563 \f
564 RFC 3663           Domain Administrative Data in LDAP      December 2003
565
566
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.
579
580    o  Finally, this third tier contains the referral from the registrar
581       to the registrant.
582
583    The fourth tier only contains name server contact entries.  These
584    entries are of objectclass inetOrgPerson, as specified by RFC 2798
585    [9].
586
587 4.1.2.  Allowed Searches
588
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:
593
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.
597
598    o  Base search based at the root of the DIT.
599
600    o  Base, one-level, and sub-tree searches based at any second level
601       domain name (the second tier) and below.
602
603 4.1.3.  Access Control
604
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.
614
615
616
617
618 Newton                        Experimental                     [Page 11]
619 \f
620 RFC 3663           Domain Administrative Data in LDAP      December 2003
621
622
623 4.2.  Name Server and Contact DIT
624
625 4.2.1.  DIT Structure
626
627    The registrar name server and contact DIT has the following
628    structural hierarchy:
629
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)
646
647                     Figure 5: Registrar DIT Overview
648
649    The first tier of the name server and contact DIT is an entry of
650    objectclass organization, as specified by RFC 1617 [2].
651
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.
656
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.
662
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.
670
671
672
673
674 Newton                        Experimental                     [Page 12]
675 \f
676 RFC 3663           Domain Administrative Data in LDAP      December 2003
677
678
679 4.2.2.  Allowed Searches
680
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:
685
686    o  One-level and base searches at the root of the DIT.
687
688    o  Sub-tree searches at the root of the DIT using cn and uid
689       attributes as a filter.
690
691    o  Base searches at either entry of the second tier.
692
693    o  One-level and sub-tree searches at either entry of the second
694       tier, using cn or uid attributes as a filter.
695
696    o  Base, one-level, and sub-tree searches based at any contact or
697       name server entry and below.
698
699 5.  Clients
700
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.
708
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.
720
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
727
728
729
730 Newton                        Experimental                     [Page 13]
731 \f
732 RFC 3663           Domain Administrative Data in LDAP      December 2003
733
734
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.
738
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.
755
756 6.  Lessons Learned
757
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.
762
763 6.1.  Intra-Server Referrals
764
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.
770
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.
781
782
783
784
785
786 Newton                        Experimental                     [Page 14]
787 \f
788 RFC 3663           Domain Administrative Data in LDAP      December 2003
789
790
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.
803
804 6.2.  Inter-Server Referrals
805
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.
818
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.
826
827 6.3.  Common DIT
828
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
839
840
841
842 Newton                        Experimental                     [Page 15]
843 \f
844 RFC 3663           Domain Administrative Data in LDAP      December 2003
845
846
847    reconfigured for each new registry operator, but this would most
848    likely have social implications as well.
849
850 6.4.  Universal Client
851
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.
861
862 6.5.  Targeting Searches by Tier
863
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.
870
871 6.6.  Data Mining
872
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.
879
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.
883
884 7.  IANA Considerations
885
886    There are no applicable IANA considerations presented in this
887    document.
888
889 8.  Internationalization Considerations
890
891    The domain administrative data in this service did not cover
892    Internationalized Domain Names (IDN's).
893
894
895
896
897
898 Newton                        Experimental                     [Page 16]
899 \f
900 RFC 3663           Domain Administrative Data in LDAP      December 2003
901
902
903 9.  Security Considerations
904
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.
912
913 10.  Intellectual Property Statement
914
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.
928
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.
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954 Newton                        Experimental                     [Page 17]
955 \f
956 RFC 3663           Domain Administrative Data in LDAP      December 2003
957
958
959 11.  Normative References
960
961    [1]  Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
962         954, October 1985.
963
964    [2]  Barker, P., Kille, S. and T. Lenggenhager, "Naming and
965         Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
966         May 1994.
967
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.
971
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.
975
976    [5]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
977         Protocol (v3)", RFC 2251, December 1997.
978
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.
982
983    [7]  Wahl, M., "A Summary of the X.500(96) User Schema for use with
984         LDAPv3", RFC 2256, December 1997.
985
986    [8]  Howard, L., "An Approach for Using LDAP as a Network Information
987         Service", RFC 2307, March 1998.
988
989    [9]  Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
990         RFC 2798, April 2000.
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Newton                        Experimental                     [Page 18]
1011 \f
1012 RFC 3663           Domain Administrative Data in LDAP      December 2003
1013
1014
1015 Appendix A.  Other Work
1016
1017    In addition to the deployment of servers and development of clients,
1018    VeriSign conducted two sub-projects related to this experiment.
1019
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.
1033
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.
1041
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.
1054
1055 Appendix B.  Acknowledgments
1056
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.
1061
1062
1063
1064
1065
1066 Newton                        Experimental                     [Page 19]
1067 \f
1068 RFC 3663           Domain Administrative Data in LDAP      December 2003
1069
1070
1071 Author's Address
1072
1073    Andrew Newton
1074    VeriSign, Inc.
1075    21345 Ridgetop Circle
1076    Sterling, VA  20166
1077    USA
1078
1079    Phone: +1 703 948 3382
1080    EMail: anewton@verisignlabs.com; anewton@ecotroph.net
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Newton                        Experimental                     [Page 20]
1123 \f
1124 RFC 3663           Domain Administrative Data in LDAP      December 2003
1125
1126
1127 Full Copyright Statement
1128
1129    Copyright (C) The Internet Society (2003).  All Rights Reserved.
1130
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.
1144
1145    The limited permissions granted above are perpetual and will not be
1146    revoked by the Internet Society or its successors or assignees.
1147
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.
1154
1155 Acknowledgement
1156
1157    Funding for the RFC Editor function is currently provided by the
1158    Internet Society.
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Newton                        Experimental                     [Page 21]
1179 \f