idnits 2.17.1 draft-newton-ldap-whois-00.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 a Security Considerations section. ** 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 295 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 (July 12, 2001) is 8324 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: 11 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.L. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: January 10, 2002 July 12, 2001 6 Whois Domain Data in LDAP 7 draft-newton-ldap-whois-00 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 20 months and may be updated, replaced, or obsoleted by other documents 21 at any 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 25 http://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 January 10, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 Domain registration data has typically been exposed to the general 39 public via whois for administrative purposes. This document 40 discusses the application of LDAP and well-known LDAP types to make 41 available Domain registration data. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Historical Directory Services for Domain Registration Data . 3 47 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Service Description . . . . . . . . . . . . . . . . . . . . 4 49 3. Registry LDAP Service . . . . . . . . . . . . . . . . . . . 5 50 3.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.2 Name Server DIT . . . . . . . . . . . . . . . . . . . . . . 6 55 3.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 7 57 3.3 Registrar Referral DIT . . . . . . . . . . . . . . . . . . . 7 58 3.3.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . 9 60 4.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.2 Name Server and Contact DIT . . . . . . . . . . . . . . . . 11 65 4.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 12 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 68 6. Internationalization Considerations . . . . . . . . . . . . 14 69 7. Security Consideratons . . . . . . . . . . . . . . . . . . . 15 70 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 This document describes the Referral LDAP Service, a pilot project 77 launched by VeriSign, Inc., to explore the use of LDAP and 78 LDAP-related technologies for use as a directory service of 79 administrative domain registration information. 81 1.1 Historical Directory Services for Domain Registration Data 83 The original National Science Foundation contract for the InterNIC 84 called for the creation of an X.500 directory service to allow for 85 administrative needs of the domain registration data and 86 information. Due to problems with implementations of X.500 server 87 software, a server based on the whois[1] protocol was temporarily 88 erected. 90 In 1994, the rwhois[3] protocol was introduced to enhance the whois 91 protocol. This directory service never gained wide acceptance. 93 At present, ICANN requires the operation of whois servers by 94 registries and registrars of generic top-level domains. 96 1.2 Motivations 98 With the recent split in functional responsibilities between 99 registries and registrars, the constant miss-use and data-mining of 100 domain registration data, and the difficulties with 101 machine-readability of whois output, the creation of the Referral 102 LDAP Service had the following motivations: 104 o Use a mechanism native to the directory protocol to refer clients 105 from inquiries about specific domains made at a registry to the 106 appropriate domain within the appropriate directory service at a 107 registrar. 109 o Limit access to domain data based on authentication of the client. 111 o Provide for structured queries and well-defined structured 112 results. 114 o Use a directory service technology already in general use. 116 Given these general criteria, LDAP[5] was selected as the protocol 117 for this directory service. 119 2. Service Description 121 The service is composed of three distinct server types: a registry 122 LDAP server, registrar LDAP servers, and registrant LDAP servers. 124 The registry LDAP server contains three Directory Information Tree's 125 (DIT). 127 o The Top-Level Domain (TLD) DIT's follows the DNS hierarchy for 128 domains (i.e. dc=foo,dc=com). 130 o The name server DIT allows a view of the name servers, many of 131 which serve multiple domains. 133 o The registrar-referral DIT provides referrals from the registry 134 into the respective TLD DIT of the registrars (on a TLD basis). 136 The registrar LDAP server contains two types of DIT's. 138 o The TLD DIT follows the DNS hierarchy for domains (i.e. 139 dc=foo,dc=com) and parallels the TLD DIT of the registry. 141 o The name server and contact DIT allow a view of the name servers 142 and contacts, many of which are associated and serve multiple 143 domains. 145 There is no specification on the DIT or schema for the registrant 146 LDAP server. Referrals from the registrar server to the registrant 147 server are provided solely for the purpose of allowing the 148 registrant direct control over extra administrative information as 149 it relates to a particular domain. 151 Access control for this service is merely a demonstration of using 152 simple bind DN and password authentication. Should registries and 153 registrars uniformly adopt LDAP as a means to disseminate domain 154 registration data, standardization of the bind DN's would need to be 155 undertaken based on each type of user base. 157 3. Registry LDAP Service 159 3.1 TLD DIT 161 3.1.1 DIT Structure 163 The registry TLD DIT has the following structural hierarchy. 165 TLD (i.e. dc=net) 166 | 167 | 168 ------------------------------------- 169 | | 170 SLD (i.e. dc=foo,dc=net) SLD (i.e. dc=bar,dc=net) 171 | | 172 --------------------- --------------------- 173 | | | | | | 174 name server | | name server | | 175 (i.e. | | (i.e. | | 176 cn=nameserver1, | | cn=nameserver1, | | 177 dc=foo,dc=net ) | | dc=bar,dc=net ) | | 178 | | | | 179 name server | name server | 180 (i.e. | (i.e. | 181 cn=nameserver2, | cn=nameserver2, | 182 dc=foo,dc=net ) | dc=bar,dc=net ) | 183 | | 184 registrar referral registrar referral 185 (i.e. (i.e. 186 cn=registrar, cn=registrar, 187 dc=foo,dc=net ) dc=bar,dc=net ) 189 The root of a TLD DIT is an entry of objectclass domain as specified 190 by RFC2247[4] and represents a top-level domain. 192 The second tier of the DIT represents second-level domains. Each of 193 these entries is of objectclass domain as specified by RFC2247[4]. 194 The description attribute on these entries often contains 195 descriptive text giving the name of the registrar through which 196 these domains have been registered. 198 The third tier contains entries specific to each second-level domain 199 for which they fall under. Name server entries are of objectclass 200 ipHost as specified by RFC2307[8]. The distinguished names of these 201 name server entries are algorithmicly calculated where the first 202 component is the word "nameserver" concatenated with an index number 203 of the name server entry and the remaining components being the 204 appropriate domain names. There is no specification relating the 205 value of the name server entry to the index it may be assigned other 206 than it is unique and consistent with respect to the client session. 207 This tier also contains the referral from the registry to the 208 registrar. This referral is a direct referral to the entry in the 209 appropriate registrar LDAP server corresponding to the domain name 210 which the referral falls beneath in this DIT. 212 3.1.2 Allowed Searches 214 Because of the vast amount of entries contained within this DIT, 215 only certain types of searches are allowed. Allowing any search 216 expressible via LDAP would lead to expensive searches that would be 217 far too costly for a publicly available service. The searches 218 allowed are as follows. 220 o One-level scoped searches based at the root of the DIT. Substring 221 matching is allowed on dc attributes, but the substring must be 222 at least be 3 characters in length. 224 o Base search based at the root of the DIT. 226 o Base, one-level, and sub-tree searches based at any second level 227 domain name (the second tier) and below. 229 3.1.3 Access Control 231 The registry TLD DIT only has one access control type. When a client 232 binds with a DN of "cn=trademark" and password of "attorney", the 233 second-level domain entries also take on an objectclass of 234 extensibleObject with the added attributes of "createddate" and 235 "registrationexpirationdate", which are of type Generalized Time as 236 specified by RFC2252[6]. 238 3.2 Name Server DIT 240 3.2.1 DIT Structure 242 The registry name server DIT has the following structural hierarchy. 244 (o=nsiregistry.com) 245 | 246 | 247 ------------------------------------- 248 | | | 249 name server name server name server 250 (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org) 252 The root of a name server DIT is an entry of objectclass 253 organization as specified by RFC1617[2]. It has no significance 254 other than to serve as the root of the DIT. 256 The second tier of this DIT represents name servers. Each of these 257 entries is of objectclass ipHost as specified by RFC2307[8]. 259 3.2.2 Allowed Searches 261 Because of the vast amount of entries contained within this DIT, 262 only 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 and sub-tree scoped searches based at the root of the 268 DIT if a filter on the cn attribute is provided. 270 o Base search based at the root of the DIT. 272 o Base, one-level, and sub-tree searches based at any name server 273 entry. 275 3.3 Registrar Referral DIT 277 3.3.1 DIT Structure 279 The registry registrar-referral DIT has the following structural 280 hierarchy. 282 (o=tlds) 283 | 284 | 285 ------------------------------- 286 | | | | 287 tld tld tld tld 288 (dc=net) (dc=com) (dc=org) (dc=edu) 289 | | | | 290 : : | : 291 : : | : 292 | 293 --------------------------- 294 | | | 295 referral to referral to referral to 296 registrar 1 registrar 2 registrar n 297 dc=org DIT dc=org DIT dc=org DIT 299 The root of the registrar referral DIT is an entry of objectclass 300 organization as specified by RFC1617[2]. It has no significance 301 other than to serve as the root of this DIT. 303 The second tier of this DIT represents top-level domains. Each of 304 these entries is of objectclass domain as specified by RFC2247[4]. 306 Underneath each TLD entry, the third tier contains referrals to the 307 appropriate TLD DIT of each registrar. 309 4. Registrar LDAP Service 311 4.1 TLD DIT 313 4.1.1 DIT Structure 315 The registrar TLD DIT's, which is similar to the registry TLD DIT's, 316 has the following structural hierarchy. 318 TLD (i.e. dc=net) 319 | 320 | 321 ------------------------------------------------ 322 | | | 323 SLD (i.e. dc=foo,dc=net) : : 324 | : : 325 --------------------------------------------- 326 | | | 327 | | | 328 name server contact referral to 329 (i.e. cn=nameserver1, (i.e. cn=contact1, registrant 330 dc=foo,dc=net ) dc=foo,dc=net ) 331 | 332 | 333 name server contact 334 (i.e. cn=contact, 335 cn=nameserver1, 336 dc=foo,dc=net ) 338 The root of a TLD DIT is an entry of objectclass domain as specified 339 by RFC2247[4] and represents a top-level domain. 341 The second tier of the DIT represents second-level domains. Each of 342 these entries is of objectclass domain as specified by RFC2247[4]. 344 The third tier contains entries specific to each second-level domain 345 for which they fall under. The entries at this level are as follows: 347 o Name server entries are of objectclass ipHost as specified by 348 RFC2307[8]. The distinguished names of these name server entries 349 are algorithmicly calculated where the first component is the 350 word "nameserver" concatenated with an index number of the name 351 server entry and the remaining components being the appropriate 352 domain names. There is no specification relating the value of the 353 name server entry to the index it may be assigned other than it 354 is unique and consistent with respect to the client session. 356 o Contact entries are of objectclass inetOrgPerson as specified by 357 RFC2798[9]. The distinguished names of these contact entries are 358 algorithmicly calculated where the first component is the word 359 "contact" concatenated with an index number of the contact and 360 the remaining components being the appropriate domain names. 361 There is no specification relating the value of the contact entry 362 to the index it may be assigned other than it is unique and 363 consistent with respect to the client session. The description 364 attribute of the entry contains the role for which a contact is 365 related to a domain. These roles are identified as "Admin 366 Contact", "Technical Contact", and "Billing Contact", and may 367 appear in any order. 369 o Finally, this third tier contains the referral from the registrar 370 to the registrant. 372 The fourth tier only contains name server contact entries. These 373 entries are of objectclass inetOrgPerson as specified by RFC2798[9]. 375 4.1.2 Allowed Searches 377 Because of the vast amount of entries contained within this DIT, 378 only certain types of searches are allowed. Allowing any search 379 expressible via LDAP would lead to expensive searches that would be 380 far too costly for a publicly available service. The searches 381 allowed are as follows. 383 o One-level scoped searches based at the root of the DIT. Substring 384 matching is allowed on dc and o attributes, but the substring 385 must be at least be 3 characters in length. 387 o Base search based at the root of the DIT. 389 o Base, one-level, and sub-tree searches based at any second level 390 domain name (the second tier) and below. 392 4.1.3 Access Control 394 The registrar TLD DIT's have two access control types. When binding 395 anonymously, a client only sees dc, o, and c attributes of the 396 second-level domain entries. When a client binds with a DN of 397 "cn=trademark" and password of "attorney", all of the other 398 attributes normally available on entries of objectclass domain are 399 visible if they have values. In addition, if a client binds with the 400 DN of a contact and password of "password", all attributes for 401 second-level domain entries for which the bind DN has a relation are 402 visible. 404 4.2 Name Server and Contact DIT 406 4.2.1 DIT Structure 408 The registrar name server and contact DIT has the following 409 structural hierarchy. 411 (o=nsi.com) 412 | 413 | 414 -------------------------------------- 415 | | 416 Contacts Name Servers 417 (ou=contacts) (ou=name servers) 418 | | 419 ----------------- ------------------------ 420 | | | | | | 421 Contact : : Name Server : : 422 (uid=handle) : : (cn=handle) : : 423 | 424 Name Server 425 Contact 426 (cn=contact1) 428 The first tier of the name server and contact DIT is an entry of 429 objectclass organization as specified by RFC1617[2]. 431 The second tier of the DIT contains two entries, each of which is of 432 objectclass organizationalUnit as specified by RFC2256[7]. One entry 433 represents the part of the DIT containing contacts and the other 434 entry represents the part of the DIT containing name servers. 436 Entries underneath the contacts organizationalUnit entry are of 437 objectclass inetOrgPerson and represent contacts registered with the 438 registrar. Their RDN is composed of the uid attribute. The uid 439 attribute's value is a unique identifier or handle that is registrar 440 assigned. 442 Entries underneath the name server organizationalUnit entry are of 443 objectclass ipHost and represent name servers registered with the 444 registrar. Their RDN is composed of the cn attribute. The cn 445 attribute's value is a unique identifier or handle that is registrar 446 assigned. Each name server entry may optionally have children 447 entries of objectclass inetOrgPerson. These entries represent the 448 contacts of the name server they fall beneath. 450 4.2.2 Allowed Searches 452 Because of the vast amount of entries contained within this DIT, 453 only certain types of searches are allowed. Allowing any search 454 expressible via LDAP would lead to expensive searches that would be 455 far too costly for a publicly available service. The searches 456 allowed are as follows. 458 o One-level and base searches at the root of the DIT. 460 o Sub-tree searches at the root of the DIT using cn and uid 461 attributes as a filter. 463 o Base searches at the either entry of the second tier. 465 o One-level and sub-tree searches at either entry of the second 466 tier using cn or uid attributes as a filter. 468 o Base, one-level, and sub-tree searches based at any contact or 469 name server entry and below. 471 5. IANA Considerations 473 There are no IANA considerations beyond those need by LDAP[5]. 475 6. Internationalization Considerations 477 There are no internationalization considerations beyond those needed 478 by LDAP[5]. 480 7. Security Consideratons 482 There are no security considerations beyond those need by LDAP[5]. 484 References 486 [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 487 954, October 1985. 489 [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and 490 Structuring Guidelines for X.500 Directory Pilots", RFC 1617, 491 May 1994. 493 [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. 494 Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, 495 June 1997. 497 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, 498 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, 499 January 1998. 501 [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 502 Protocol (v3)", RFC 2251, December 1997. 504 [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight 505 Directory Access Protocol (v3): Attribute Syntax Definitions", 506 RFC 2252, December 1997. 508 [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with 509 LDAPv3", RFC 2256, December 1997. 511 [8] Howard, L., "An Approach for Using LDAP as a Network 512 Information Service", RFC 2307, March 1998. 514 [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", 515 RFC 2798, April 2000. 517 Author's Address 519 Andrew L. Newton 520 VeriSign, Inc. 521 21345 Ridgetop Circle 522 Sterling, VA 20166 523 USA 525 Phone: +1 703 948 3382 526 EMail: anewton@research.netsol.com 527 URI: http://www.research.netsol.com/ 529 Full Copyright Statement 531 Copyright (C) The Internet Society (2001). All Rights Reserved. 533 This document and translations of it may be copied and furnished to 534 others, and derivative works that comment on or otherwise explain it 535 or assist in its implementation may be prepared, copied, published 536 and distributed, in whole or in part, without restriction of any 537 kind, provided that the above copyright notice and this paragraph 538 are included on all such copies and derivative works. However, this 539 document itself may not be modified in any way, such as by removing 540 the copyright notice or references to the Internet Society or other 541 Internet organizations, except as needed for the purpose of 542 developing Internet standards in which case the procedures for 543 copyrights defined in the Internet Standards process must be 544 followed, or as required to translate it into languages other than 545 English. 547 The limited permissions granted above are perpetual and will not be 548 revoked by the Internet Society or its successors or assigns. 550 This document and the information contained herein is provided on an 551 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 552 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 553 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 554 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 555 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Acknowledgement 559 Funding for the RFC editor function is currently provided by the 560 Internet Society.