idnits 2.17.1 draft-newton-ldap-whois-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 344 has weird spacing: '...rral to refer...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 2003) is 7515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 954 (ref. '1') (Obsoleted by RFC 3912) ** Downref: Normative reference to an Informational RFC: RFC 1617 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2167 (ref. '3') ** Obsolete normative reference: RFC 2251 (ref. '5') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (ref. '6') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2256 (ref. '7') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Downref: Normative reference to an Experimental RFC: RFC 2307 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 2798 (ref. '9') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: March 29, 2004 September 29, 2003 6 Domain Administrative Data in LDAP 7 draft-newton-ldap-whois-04 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 29, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Domain registration data has typically been exposed to the general 39 public via Nicname/Whois for administrative purposes. This document 40 describes an experimental service using the Lightweight Directory 41 Access Protocol (LDAP) and well-known LDAP types to make available 42 domain administrative data. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Historical Directory Services for Domain Registration 48 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.3 Abbreviations Used . . . . . . . . . . . . . . . . . . . . . 4 51 2. Service Description . . . . . . . . . . . . . . . . . . . . 5 52 3. Registry LDAP Service . . . . . . . . . . . . . . . . . . . 6 53 3.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.2 Name Server DIT . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 8 60 3.3 Registrar Referral DIT . . . . . . . . . . . . . . . . . . . 8 61 3.3.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . 10 63 4.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.2 Name Server and Contact DIT . . . . . . . . . . . . . . . . 12 68 4.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 13 70 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 6. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . 15 72 6.1 Intra-Server Referrals . . . . . . . . . . . . . . . . . . . 15 73 6.2 Inter-Server Referrals . . . . . . . . . . . . . . . . . . . 15 74 6.3 Common DIT . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.4 Universal Client . . . . . . . . . . . . . . . . . . . . . . 16 76 6.5 Targeting Searches by Tier . . . . . . . . . . . . . . . . . 16 77 6.6 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 79 8. Internationalization Considerations . . . . . . . . . . . . 19 80 9. Security Considerations . . . . . . . . . . . . . . . . . . 20 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21 83 A. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . 24 87 1. Introduction 89 This document describes the Referral LDAP Service, an experimental 90 project launched by VeriSign, Inc., to explore the use of LDAP and 91 LDAP-related technologies for use as a directory service of 92 administrative domain registration information. 94 1.1 Historical Directory Services for Domain Registration Data 96 The original National Science Foundation contract for the InterNIC 97 called for the creation of an X.500 directory service for 98 administrative needs of the domain registration data and information. 99 Due to problems with implementations of X.500 server software, a 100 server based on the Nicname/Whois [1] protocol was temporarily 101 erected. 103 In 1994, the Rwhois [3] protocol was introduced to enhance the 104 Nicname/Whois protocol. This directory service never gained wide 105 acceptance for use with domain data. 107 At present, ICANN requires the operation of Nicname/Whois servers by 108 registries and registrars of generic Top-Level Domains (TLD's). 110 1.2 Motivations 112 With the recent split in functional responsibilities between 113 registries and registrars, the constant misuse and data-mining of 114 domain registration data, and the difficulties with 115 machine-readability of Nicname/Whois output, the creation of the 116 Referral LDAP Service had the following motivations: 118 o Use a mechanism native to the directory protocol to refer clients 119 from inquiries about specific domains made at a registry to the 120 appropriate domain within the appropriate directory service at a 121 registrar. 123 o Limit access to domain data based on authentication of the client. 125 o Provide structured queries and well-known and structured results. 127 o Use a directory service technology already in general use. 129 Given these general criteria, LDAP [5] was selected as the protocol 130 for this directory service. The decision was also made to restrict 131 the use of LDAP to features most readily available in common 132 implementations. Therefore, a goal was set to not define any new 133 object classes, syntaxes, or matching rules. 135 The experiment was successful in exploring how LDAP might be used in 136 this context and demonstrating the level of customization required 137 for an operational service.. Conclusions and observations about this 138 experiment are outlined in Section 6. 140 1.3 Abbreviations Used 142 The following abbreviations are used to describe the nature of this 143 experiment: 145 TLD: Top-Level Domain. Refers to the domain names just beneath 146 the root in the Domain Name System. This experiment used the 147 TLD's .com, .net, .org, and .edu. 149 SLD: Second-Level Domain. Refers to the domain names just beneath 150 a TLD in the Domain Name System. An example of such a domain name 151 would be "example.com". 153 DIT: Directory Information Tree. One of many hierarchies of data 154 entries in an LDAP server. 156 DN: Distinguished Name. The unique name of an entry in a DIT. 158 cn: common name. See RFC2256 [7]. 160 dc: domain component. See RFC2247 [4]. 162 uid: user id. See RFC2798 [9]. 164 2. Service Description 166 The service is composed of three distinct server types: a registry 167 LDAP server, registrar LDAP servers, and registrant LDAP servers. 169 The registry LDAP server contains three Directory Information Trees 170 (DIT's). 172 o The Top-Level Domain DIT's follow the DNS hierarchy for domains 173 (e.g. dc=foo,dc=com). 175 o The name server DIT allows a view of the name servers, many of 176 which serve multiple domains. 178 o The registrar-referral DIT provides referrals from the registry 179 into the respective TLD DIT of the registrars (on a TLD basis). 181 The registrar LDAP server contains two types of DIT's. 183 o The TLD DIT follows the DNS hierarchy for domains (e.g. 184 dc=foo,dc=com) and parallels the TLD DIT of the registry. 186 o The name server and contact DIT allow a view of the name servers 187 and contacts, many of which are associated and serve multiple 188 domains. 190 There is no specification on the DIT or schema for the registrant 191 LDAP server. Referrals from the registrar server to the registrant 192 server are provided solely for the purpose of allowing the registrant 193 direct control over extra administrative information as it relates to 194 a particular domain. 196 Access control for this service is merely a demonstration of using a 197 Distinguished Name (DN) and password. Should registries and 198 registrars uniformly adopt LDAP as a means to disseminate domain 199 registration data, standardization of these DN's would need to be 200 undertaken based on each type of user base. 202 3. Registry LDAP Service 204 3.1 TLD DIT 206 3.1.1 DIT Structure 208 The registry TLD DIT has the following structural hierarchy. 210 TLD (e.g. dc=net) 211 | 212 | 213 ------------------------------------- 214 | | 215 SLD (e.g. dc=foo,dc=net) SLD (e.g. dc=bar,dc=net) 216 | | 217 --------------------- --------------------- 218 | | | | | | 219 name server | | name server | | 220 (e.g. | | (e.g. | | 221 cn=nameserver1, | | cn=nameserver1, | | 222 dc=foo,dc=net ) | | dc=bar,dc=net ) | | 223 | | | | 224 name server | name server | 225 (e.g. | (e.g. | 226 cn=nameserver2, | cn=nameserver2, | 227 dc=foo,dc=net ) | dc=bar,dc=net ) | 228 | | 229 registrar referral registrar referral 230 (e.g. (e.g. 231 cn=registrar, cn=registrar, 232 dc=foo,dc=net ) dc=bar,dc=net ) 234 Figure 1: Registry DIT Overview 236 The root of a TLD DIT is an entry of objectclass domain as specified 237 by RFC2247 [4] and represents a top-level domain. 239 The second tier of the DIT represents second-level domains. Each of 240 these entries is of objectclass domain as specified by RFC2247 [4]. 241 The description attribute on these entries often contains descriptive 242 text giving the name of the registrar through which these domains 243 have been registered. 245 The third tier contains entries specific to each second-level domain. 246 Name server entries are of objectclass ipHost as specified by RFC2307 247 [8]. The distinguished names of these name server entries are 248 algorithmically calculated where the first component is the word 249 "nameserver" concatenated with an index number of the name server 250 entry and the remaining components are the appropriate domain names. 251 There is no specification relating the value of the name server entry 252 to the index it may be assigned other than it is unique and 253 consistent with respect to the client session. This tier also 254 contains the referral from the registry to the registrar. This 255 referral is a direct referral to the entry in the appropriate 256 registrar LDAP server corresponding to the domain name which the 257 referral falls beneath in this DIT. 259 3.1.2 Allowed Searches 261 Because of the vast number of entries contained within this DIT, only 262 certain types of searches are allowed. Allowing any search 263 expressible via LDAP would lead to expensive searches that would be 264 far too costly for a publicly available service. The searches 265 allowed are as follows. 267 o One-level scoped searches based at the root of the DIT. Substring 268 matching is allowed on dc attributes, but the substring must be at 269 least be 3 characters in length. 271 o Base search based at the root of the DIT. 273 o Base, one-level, and sub-tree searches based at any second level 274 domain name (the second tier) and below. 276 3.1.3 Access Control 278 The registry TLD DIT only has one access control type. When a client 279 binds with a DN of "cn=trademark" and password of "attorney", the 280 second-level domain entries also take on an objectclass of 281 extensibleObject with the added attributes of "createddate" and 282 "registrationexpirationdate", which are of type Generalized Time as 283 specified by RFC2252 [6]. 285 3.2 Name Server DIT 287 3.2.1 DIT Structure 289 The registry name server DIT has the following structural hierarchy. 291 (o=nsiregistry.com) 292 | 293 | 294 ------------------------------------- 295 | | | 296 name server name server name server 297 (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org) 299 Figure 2: Registry DIT Overview 301 The root of a name server DIT is an entry of objectclass organization 302 as specified by RFC1617 [2]. It has no significance other than to 303 serve as the root of the DIT. 305 The second tier of this DIT represents name servers. Each of these 306 entries is of objectclass ipHost as specified by RFC2307 [8]. 308 3.2.2 Allowed Searches 310 Because of the vast number of entries contained within this DIT, only 311 certain types of searches are allowed. Allowing any search 312 expressible via LDAP would lead to expensive searches that would be 313 far too costly for a publicly available service. The searches 314 allowed are as follows. 316 o One-level and sub-tree scoped searches based at the root of the 317 DIT if a filter on the cn attribute is provided. 319 o Base search based at the root of the DIT. 321 o Base, one-level, and sub-tree searches based at any name server 322 entry. 324 3.3 Registrar Referral DIT 326 3.3.1 DIT Structure 328 The registry registrar-referral DIT has the following structural 329 hierarchy. 331 (o=tlds) 332 | 333 | 334 ------------------------------- 335 | | | | 336 tld tld tld tld 337 (dc=net) (dc=com) (dc=org) (dc=edu) 338 | | | | 339 : : | : 340 : : | : 341 | 342 --------------------------- 343 | | | 344 referral to referral to referral to 345 registrar 1 registrar 2 registrar n 346 dc=org DIT dc=org DIT dc=org DIT 348 Figure 3: Registry Referral DIT Overview 350 The root of the registrar referral DIT is an entry of objectclass 351 organization as specified by RFC1617 [2]. It has no significance 352 other than to serve as the root of this DIT. 354 The second tier of this DIT represents top-level domains. Each of 355 these entries is of objectclass domain as specified by RFC2247 [4]. 357 Underneath each TLD entry, the third tier contains referrals to the 358 appropriate TLD DIT of each registrar. 360 4. Registrar LDAP Service 362 4.1 TLD DIT 364 4.1.1 DIT Structure 366 The registrar TLD DIT's, which is similar to the registry TLD DIT's, 367 has the following structural hierarchy. 369 TLD (e.g. dc=net) 370 | 371 | 372 ------------------------------------------------ 373 | | | 374 SLD (e.g. dc=foo,dc=net) : : 375 | : : 376 --------------------------------------------- 377 | | | 378 | | | 379 name server contact referral to 380 (e.g. cn=nameserver1, (e.g. cn=contact1, registrant 381 dc=foo,dc=net ) dc=foo,dc=net ) 382 | 383 | 384 name server contact 385 (e.g. cn=contact, 386 cn=nameserver1, 387 dc=foo,dc=net ) 389 Figure 4: Registrar DIT Overview 391 The root of a TLD DIT is an entry of objectclass domain as specified 392 by RFC2247 [4] and represents a top-level domain. 394 The second tier of the DIT represents second-level domains. Each of 395 these entries is of objectclass domain as specified by RFC2247 [4]. 397 The third tier contains entries specific to each second-level domain. 398 The entries at this level are as follows: 400 o Name server entries are of objectclass ipHost as specified by 401 RFC2307 [8]. The distinguished names of these name server entries 402 are algorithmically calculated where the first component is the 403 word "nameserver" concatenated with an index number of the name 404 server entry and the remaining components are the appropriate 405 domain names. There is no specification relating the value of the 406 name server entry to the index it may be assigned other than it is 407 unique and consistent with respect to the client session. 409 o Contact entries are of objectclass inetOrgPerson as specified by 410 RFC2798 [9]. The distinguished names of these contact entries are 411 algorithmically calculated where the first component is the word 412 "contact" concatenated with an index number of the contact and the 413 remaining components are the appropriate domain names. There is 414 no specification relating the value of the contact entry to the 415 index it may be assigned other than it is unique and consistent 416 with respect to the client session. The description attribute of 417 the entry contains the role for which a contact is related to a 418 domain. These roles are identified as "Admin Contact", "Technical 419 Contact", and "Billing Contact", and may appear in any order. 421 o Finally, this third tier contains the referral from the registrar 422 to the registrant. 424 The fourth tier only contains name server contact entries. These 425 entries are of objectclass inetOrgPerson as specified by RFC2798 [9]. 427 4.1.2 Allowed Searches 429 Because of the vast number of entries contained within this DIT, only 430 certain types of searches are allowed. Allowing any search 431 expressible via LDAP would lead to expensive searches that would be 432 far too costly for a publicly available service. The searches 433 allowed are as follows. 435 o One-level scoped searches based at the root of the DIT. Substring 436 matching is allowed on dc and o attributes, but the substring must 437 be at least be 3 characters in length. 439 o Base search based at the root of the DIT. 441 o Base, one-level, and sub-tree searches based at any second level 442 domain name (the second tier) and below. 444 4.1.3 Access Control 446 The registrar TLD DIT's have two access control types. When binding 447 anonymously, a client only sees dc, o, and c attributes of the 448 second-level domain entries. When a client binds with a DN of 449 "cn=trademark" and password of "attorney", all of the other 450 attributes normally available on entries of objectclass domain are 451 visible if they have values. In addition, if a client binds with the 452 DN of a contact and password of "password", all attributes for 453 second-level domain entries for which the bind DN has a relation are 454 visible. 456 4.2 Name Server and Contact DIT 458 4.2.1 DIT Structure 460 The registrar name server and contact DIT has the following 461 structural hierarchy. 463 (o=nsi.com) 464 | 465 | 466 -------------------------------------- 467 | | 468 Contacts Name Servers 469 (ou=contacts) (ou=name servers) 470 | | 471 ----------------- ------------------------ 472 | | | | | | 473 Contact : : Name Server : : 474 (uid=handle) : : (cn=handle) : : 475 | 476 Name Server 477 Contact 478 (cn=contact1) 480 Figure 5: Registrar DIT Overview 482 The first tier of the name server and contact DIT is an entry of 483 objectclass organization as specified by RFC1617 [2]. 485 The second tier of the DIT contains two entries, each of which is of 486 objectclass organizationalUnit as specified by RFC2256 [7]. One 487 entry represents the part of the DIT containing contacts and the 488 other entry represents the part of the DIT containing name servers. 490 Entries underneath the contacts organizationalUnit entry are of 491 objectclass inetOrgPerson and represent contacts registered with the 492 registrar. Their RDN is composed of the uid attribute. The uid 493 attribute's value is a unique identifier or handle that is registrar 494 assigned. 496 Entries underneath the name server organizationalUnit entry are of 497 objectclass ipHost and represent name servers registered with the 498 registrar. Their RDN is composed of the cn attribute. The cn 499 attribute's value is a unique identifier or handle that is registrar 500 assigned. Each name server entry may optionally have children 501 entries of objectclass inetOrgPerson. These entries represent the 502 contacts of the name server they fall beneath. 504 4.2.2 Allowed Searches 506 Because of the vast number of entries contained within this DIT, only 507 certain types of searches are allowed. Allowing any search 508 expressible via LDAP would lead to expensive searches that would be 509 far too costly for a publicly available service. The searches 510 allowed are as follows. 512 o One-level and base searches at the root of the DIT. 514 o Sub-tree searches at the root of the DIT using cn and uid 515 attributes as a filter. 517 o Base searches at either entry of the second tier. 519 o One-level and sub-tree searches at either entry of the second tier 520 using cn or uid attributes as a filter. 522 o Base, one-level, and sub-tree searches based at any contact or 523 name server entry and below. 525 5. Clients 527 Early scoping and analysis of this project were based on the use of 528 output from command line clients, specifically the "ldapsearch" 529 command present with many implementations of LDAP servers. Our 530 survey of this tool available from many vendors showed that referral 531 chasing was difficult to control or predict, and the behavior between 532 these implementations with respect to referral chasing was 533 inconsistent. 535 Based on the limited nature of the expressive capabilities present 536 with just command line tools, searches involving nested queries or 537 advanced referral chasing were deemed the domain of clients making 538 direct use of LDAP client libraries. Three of these types of clients 539 were produced: a web-based client, a cross-platform C-based client, 540 and a Java client. No significant deficiencies or problems were 541 found with the LDAP client libraries in the construction of these 542 clients, and the level of control provided by their programming 543 interfaces was adequate to create the necessary searches. Instead, 544 most of the problems encountered with these clients were based on 545 usability concerns. 547 It was found that the web-based client caused a great amount of 548 confusion for users not familiar with LDAP or Nicname/Whois with 549 respect to the underlying technology and the network model. Thus 550 many users believed the web-based client to be the only interface to 551 the data and were unaware or confused by the intermediate LDAP 552 protocol. In addition, it was difficult to express to users the 553 registry-registrar-registrant service model in adequate terms from 554 search results where the results could be rendered properly among the 555 various common web browsers. 557 Both the C and Java based clients were built to be both graphical and 558 cross-platform (in the case of the C-based client, the Linux and 559 Windows platforms were chosen as targets). The LDAP client libraries 560 chosen for both clients proved to be quite capable and offered the 561 necessary levels of control for conducting nested queries and 562 advanced referral chasing. Expectations at the outset for 563 construction of both clients, based on past experience, were that the 564 C-based client would not only perform better than the Java client but 565 also have a better appearance. In reality, these assumptions were 566 incorrect as there was no perceivable difference in performance and 567 the look of the Java client was often considered to be far superior 568 to its counter-part. In addition, the Java client required much less 569 time to create. Both clients are available under the terms of an 570 open source license. Though it is impossible to have accurate 571 measurements of their popularity, through monitoring and feedback it 572 was perceived that the web-based client had far greater use. 574 6. Lessons Learned 576 Based on the experience of piloting this experimental service, 577 feedback from users of the service, and general comments and 578 observations of current and common opinions, the following items have 579 been noted. 581 6.1 Intra-Server Referrals 583 Original analysis of the data set to be used revealed a high degree 584 of relationships between name servers, contacts, and domains. To 585 store the data in non-normalized form according to the DIT outlined 586 in this document would make an original relational dataset of roughly 587 20 million objects explode to over 115 million objects. 589 To combat this problem, the first pass at defining the DIT's made 590 heavy use of referrals between the TLD DIT's and the name server and 591 contact DIT's. The use of the 'alias' objectclass was considered but 592 ruled out in hopes of using referrals for load balancing across 593 servers (i.e. placing each TLD DIT on a separate server, and 594 separate servers for the name server and contact DIT's). However, 595 initial testing with the 'ldapsearch' command found inconsistencies 596 with the interpretation of the referrals and how they were managed. 597 Not only were the results inconsistent between implementations, but 598 many of these clients would easily get caught in referral loops. 600 The final solution to the problem was to create a customized back-end 601 data store containing the data in a normalized form. This gave the 602 appearance to the client of having a non-normalized data set which 603 required no intra-server referrals. Aliases may have been a better 604 solution, however our interpretation of their output with 605 implementations of the 'ldapsearch' tool was not satisfactory. It 606 was also later learned that some LDAP server implementations place 607 certain restrictions on aliases that would have conflicted with our 608 overall DIT structure. In the end, it was felt that a customized 609 back-end would be required by any server with a large data-set, but 610 smaller data-sets for less populated domains could easily use 611 off-the-shelf implementations. 613 6.2 Inter-Server Referrals 615 The modeling of the overall service to provide the split in 616 operational responsibility between registry and registrar required 617 the use of referrals (i.e. the two servers would not be operated by 618 the same organization, therefore would most likely not co-exist on 619 the same physical machine or network). The chief problem with LDAP 620 referrals returned for this purpose grew out of the need to limit 621 data returned to the client and the priority given to referrals. It 622 was quite easy to cause a sub-tree query at certain levels, for 623 instance a TLD level, to return nothing but referrals. This was true 624 because referrals would be returned out of scope of the supplied 625 search filter and therefore would fill the result set to its limit, 626 normally set to 50 entries. 628 In certain use cases, a result set with nothing but referrals was 629 desired (e.g. o=tlds). However, even in these cases it was possible 630 for some referrals not be returned due to the size limit. In this 631 case, it was felt that a result set of 50 referrals, the default for 632 the size limit in most cases, was too large for any practical use by 633 a client and was a failing of query distribution in general rather 634 than a limitation of LDAP. 636 6.3 Common DIT 638 Because of the nature of software development, the graphical and web 639 clients were developed after the development of the server software. 640 The 'ldapsearch' client was used for testing and development during 641 server software creation. It was not until the creation of more 642 advanced clients that it was discovered the design decision of 643 uniform DIT naming should have been made. Technically, this would 644 have allowed for slightly better software modularization and re-use. 645 In addition, the use of a company name in the DIT structure did not 646 allow the easy integration of another domain registry, as in the 647 registry-registrar model. Not only would clients have to be 648 reconfigured for each new registry operator, but this would most 649 likely have social implications as well. 651 6.4 Universal Client 653 The construction of the clients revealed yet another misconception. 654 Though this project used a generic directory service technology, the 655 clients required a high-degree of algorithmic knowledge about the DIT 656 structure and schemas being used. The graphical clients could not be 657 used against an LDAP service with another DIT or schema. Therefore a 658 generic or universal client, one that could be used for all LDAP 659 applications, would either not be able to make full use of the data 660 provided by the service or would be far too complex for operation by 661 the average user. 663 6.5 Targeting Searches by Tier 665 The network model for this service was divided up into three tiers: 666 registry, registrar, and registrant. Despite this, all searches 667 needed to start at the registry level causing overhead for searches 668 that could be targeted at a select tier. This service did not 669 implement a solution to this problem, such as using SRV and/or NAPTR 670 records in DNS to allow a client to find a responsible LDAP server. 672 6.6 Data Mining 674 Section 3.1.2 and Section 4.1.2 describe the searches allowed by this 675 service. However, the most common question asked by users of the 676 service revolved around getting around these restrictions. Because 677 browsing at the TLD level was not permitted, many users asked about 678 the feasibility of using recursive dictionary queries to circumvent 679 the search restrictions. 681 It should be noted that many operators of Nicname/Whois server 682 consider this practice to be data mining and often refer to it 683 specifically as a dictionary attack. 685 7. IANA Considerations 687 There are no applicable IANA considerations presented in this 688 document. 690 8. Internationalization Considerations 692 The domain administrative data in this service did not cover 693 Internationalized Domain Names (IDN's). 695 9. Security Considerations 697 This experiment did not endeavor to use security mechanisms beyond 698 those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3 699 describe the various access controls used within the scope of the 700 defined security mechanisms. 702 References 704 [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 705 954, October 1985. 707 [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and 708 Structuring Guidelines for X.500 Directory Pilots", RFC 1617, 709 May 1994. 711 [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. 712 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, 713 June 1997. 715 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, 716 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, 717 January 1998. 719 [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 720 Protocol (v3)", RFC 2251, December 1997. 722 [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight 723 Directory Access Protocol (v3): Attribute Syntax Definitions", 724 RFC 2252, December 1997. 726 [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with 727 LDAPv3", RFC 2256, December 1997. 729 [8] Howard, L., "An Approach for Using LDAP as a Network Information 730 Service", RFC 2307, March 1998. 732 [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", 733 RFC 2798, April 2000. 735 Author's Address 737 Andrew Newton 738 VeriSign, Inc. 739 21345 Ridgetop Circle 740 Sterling, VA 20166 741 USA 743 Phone: +1 703 948 3382 744 EMail: anewton@verisignlabs.com; anewton@ecotroph.net 746 Appendix A. Other Work 748 In addition to the deployment of servers and development of clients, 749 VeriSign conducted two sub-projects related to this experiment. 751 The first project was a Nicname/Whois-to-LDAP gateway. The goal of 752 the project was to create an LDAP server for use by registrars to 753 deploy in front of their Nicname/Whois servers. This gateway would 754 take LDAP requests, translate them to Nicname/Whois requests, issue 755 the request to a specific Nicname/Whois server deployed on port 43, 756 interpret the response, and return LDAP result sets. Because of the 757 unspecified nature of Nicname/Whois result sets, the gateway was 758 programmed specifically to recognize only the output of three 759 distinct registrars. While this gateway proved valuable enough to 760 allow domain lookups and limited searches, it was unable to provide 761 consistent contact lookups, nameserver lookups, or registrant 762 referrals. This software was also made publicly available under the 763 terms of an open source license. 765 The second project was an informal survey of registrants with 766 deployed LDAP servers. This was conducted by using the com, net, 767 org, and edu zone files and testing for the existence of an LDAP 768 server on port 389 using the name of the domain, a host named "ldap" 769 in the domain, and a host named "dir" in the domain (e.g. "foo.com", 770 "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to 771 resolve LDAP services using SRV records in DNS. 773 The result of this survey found that roughly 0.5% of active domains 774 had an LDAP server. By profiling a server's root DSA-specific Entry 775 (DSE), the survey found that about 90% of the servers were 776 implementations provided by vendor A, 9% of the servers were 777 implementations provided by vendor B, and 1% of the servers were 778 implementations provided by other vendors. Of the servers queried 779 that were determined to be implementations provided by vendor A, it 780 appeared that about only 10% contained public data (this also led to 781 the assumption that the other 90% were not intended to be publicly 782 queried). Of the servers queried that were determined to be 783 implementations provided by vendor B, it appears that nearly all 784 contained public data. 786 Appendix B. Acknowledgments 788 Significant analysis, design, and implementation for this project 789 were conducted by Brad McMillen, David Blacka, Anna Zhang, and 790 Michael Schiraldi. Guidance and review of this project, the 791 project's goals, and this document have been given by Mark Kosters 792 and Leslie Daigle. 794 Intellectual Property Statement 796 The IETF takes no position regarding the validity or scope of any 797 intellectual property or other rights that might be claimed to 798 pertain to the implementation or use of the technology described in 799 this document or the extent to which any license under such rights 800 might or might not be available; neither does it represent that it 801 has made any effort to identify any such rights. Information on the 802 IETF's procedures with respect to rights in standards-track and 803 standards-related documentation can be found in BCP-11. Copies of 804 claims of rights made available for publication and any assurances of 805 licenses to be made available, or the result of an attempt made to 806 obtain a general license or permission for the use of such 807 proprietary rights by implementors or users of this specification can 808 be obtained from the IETF Secretariat. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights which may cover technology that may be required to practice 813 this standard. Please address the information to the IETF Executive 814 Director. 816 Full Copyright Statement 818 Copyright (C) The Internet Society (2003). All Rights Reserved. 820 This document and translations of it may be copied and furnished to 821 others, and derivative works that comment on or otherwise explain it 822 or assist in its implementation may be prepared, copied, published 823 and distributed, in whole or in part, without restriction of any 824 kind, provided that the above copyright notice and this paragraph are 825 included on all such copies and derivative works. However, this 826 document itself may not be modified in any way, such as by removing 827 the copyright notice or references to the Internet Society or other 828 Internet organizations, except as needed for the purpose of 829 developing Internet standards in which case the procedures for 830 copyrights defined in the Internet Standards process must be 831 followed, or as required to translate it into languages other than 832 English. 834 The limited permissions granted above are perpetual and will not be 835 revoked by the Internet Society or its successors or assignees. 837 This document and the information contained herein is provided on an 838 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 839 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 840 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 841 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 842 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 844 Acknowledgement 846 Funding for the RFC Editor function is currently provided by the 847 Internet Society.