1 2 3 4 5 6 7Network Working Group A. Newton 8Request for Comments: 3663 VeriSign, Inc. 9Category: Experimental December 2003 10 11 12 Domain Administrative Data 13 in Lightweight Directory Access Protocol (LDAP) 14 15Status 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 22Copyright Notice 23 24 Copyright (C) The Internet Society (2003). All Rights Reserved. 25 26Abstract 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 58Newton Experimental [Page 1] 59 60RFC 3663 Domain Administrative Data in LDAP December 2003 61 62 63Table 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 114Newton Experimental [Page 2] 115 116RFC 3663 Domain Administrative Data in LDAP December 2003 117 118 1191. 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 1271.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 1431.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 170Newton Experimental [Page 3] 171 172RFC 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 1801.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 2042. 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 226Newton Experimental [Page 4] 227 228RFC 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 282Newton Experimental [Page 5] 283 284RFC 3663 Domain Administrative Data in LDAP December 2003 285 286 2873. Registry LDAP Service 288 2893.1. TLD DIT 290 2913.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 338Newton Experimental [Page 6] 339 340RFC 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 3533.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 3703.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 394Newton Experimental [Page 7] 395 396RFC 3663 Domain Administrative Data in LDAP December 2003 397 398 3993.2. Name Server DIT 400 4013.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 4233.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 450Newton Experimental [Page 8] 451 452RFC 3663 Domain Administrative Data in LDAP December 2003 453 454 4553.3. Registrar Referral DIT 456 4573.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 506Newton Experimental [Page 9] 507 508RFC 3663 Domain Administrative Data in LDAP December 2003 509 510 5114. Registrar LDAP Service 512 5134.1. TLD DIT 514 5154.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 562Newton Experimental [Page 10] 563 564RFC 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 5874.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 6034.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 618Newton Experimental [Page 11] 619 620RFC 3663 Domain Administrative Data in LDAP December 2003 621 622 6234.2. Name Server and Contact DIT 624 6254.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 674Newton Experimental [Page 12] 675 676RFC 3663 Domain Administrative Data in LDAP December 2003 677 678 6794.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 6995. 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 730Newton Experimental [Page 13] 731 732RFC 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 7566. 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 7636.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 786Newton Experimental [Page 14] 787 788RFC 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 8046.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 8276.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 842Newton Experimental [Page 15] 843 844RFC 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 8506.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 8626.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 8716.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 8847. IANA Considerations 885 886 There are no applicable IANA considerations presented in this 887 document. 888 8898. 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 898Newton Experimental [Page 16] 899 900RFC 3663 Domain Administrative Data in LDAP December 2003 901 902 9039. 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 91310. 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 954Newton Experimental [Page 17] 955 956RFC 3663 Domain Administrative Data in LDAP December 2003 957 958 95911. 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 1010Newton Experimental [Page 18] 1011 1012RFC 3663 Domain Administrative Data in LDAP December 2003 1013 1014 1015Appendix 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 1055Appendix 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 1066Newton Experimental [Page 19] 1067 1068RFC 3663 Domain Administrative Data in LDAP December 2003 1069 1070 1071Author'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 1122Newton Experimental [Page 20] 1123 1124RFC 3663 Domain Administrative Data in LDAP December 2003 1125 1126 1127Full 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 1155Acknowledgement 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 1178Newton Experimental [Page 21] 1179 1180