idnits 2.17.1 draft-ietf-crisp-lw-core-00.txt: ** The Abstract section seems to be numbered -(2598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 415 has weird spacing: '...in-addr dc=i...' == Line 718 has weird spacing: '...ny/path descr...' == Line 2004 has weird spacing: '...ny/path descr...' == Unrecognized Status in ' Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 2002) is 7957 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-ietf-crisp-lw-core-00.txt July 2002 4 Expires: January, 2003 5 Category: Standards-Track 7 The Internet Resource Query Service 8 and the Internet Resource Schema 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 1. Abstract 34 This document describes an architectural framework for locating 35 and retrieving information about network resources, using LDAPv3 36 for the data-formatting and query-processing services. This 37 document also defines LDAP schema and searching rules for four 38 Internet resource types: DNS domains, IPv4 addresses, IPv6 39 address, and AS numbers. The framework specified in this document 40 also allows additional documents to define additional Internet 41 resource types and their handling rules. 43 Table of Contents 45 1. Abstract..................................................1 46 2. Definitions and Terminology...............................3 47 3. Background, Objectives and Overview.......................4 48 3.1. Background.............................................4 49 3.2. Overview...............................................5 50 4. The LDAP-WHOIS Namespace..................................7 51 4.1. Namespace Example......................................7 52 4.2. The domainComponent LDAP Hierarchy....................10 53 4.3. The inetResources Container...........................11 54 4.4. Resource-Specific Entries.............................12 55 4.5. Redirects and Referrals...............................13 56 5. The LDAP-WHOIS Object Classes and Attributes.............18 57 5.1. The inetResources Object Class........................19 58 5.2. The inetAssociatedResources Object Class..............25 59 5.3. The referral Object Class.............................29 60 5.4. Object Class and Attribute Permissions................30 61 6. Search and Match Filters.................................31 62 6.1. Search Filter Expressions.............................31 63 6.2. Matching Filter Definitions...........................33 64 7. Query Processing Models..................................35 65 7.1. Top-Down Processing...................................35 66 7.2. Bottom-Up Processing..................................39 67 7.3. Targeted Search Processing............................44 68 7.4. Supplemental Query Processing Mechanisms..............46 69 8. Internationalization and Localization....................53 70 9. DIT Replication..........................................53 71 10. Transition Issues........................................54 72 10.1. NIC Handles...........................................54 73 10.2. Change-Logs...........................................55 74 10.3. Open Issues...........................................56 75 11. Security Considerations..................................56 76 12. IANA Considerations......................................57 77 13. Author's Addresses.......................................58 78 14. References...............................................58 79 15. Acknowledgments..........................................60 80 16. Changes from Previous Versions...........................60 81 2. Definitions and Terminology 83 This document unites, enhances and clarifies several pre-existing 84 technologies. Readers are expected to be familiar with the 85 following specifications: 87 RFC 2247 - Using Domains in LDAP/X.500 DNs 89 RFC 2251 - Lightweight Directory Access Protocol (v3) 91 RFC 2252 - Lightweight Directory Access Protocol (v3): 92 Attribute Syntax Definitions. 94 RFC 2254 - The String Representation of LDAP Search Filters 96 RFC 2256 - A Summary of the X.500(96) User Schema for use 97 with LDAPv3 99 RFC 2798 - Definition of the inetOrgPerson LDAP Object 100 Class 102 [namedref] - - Named 103 Subordinate References in LDAP Directories 105 [ir-dir-req] - - 106 Internet Registry Directory Requirements 108 The following abbreviations are used throughout this document: 110 DIT (Directory Information Tree) - A DIT is a contained 111 branch of the LDAP namespace, having a root of a particular 112 distinguished name. "dc=example,dc=com" is used throughout 113 this document as one DIT, with many example entries being 114 stored in this DIT. 116 DN (Distinguished Name) - A distinguished name provides a 117 unique identifier for an entry, through the use of a multi- 118 level naming syntax. Entries are named according to their 119 location relevant to the root of their containing DIT. For 120 example, "cn=inetResources,dc=example,dc=com" is a DN which 121 uniquely identifies the "inetResources" entry within the 122 "dc=example,dc=com" DIT. 124 RDN (Relative DN) - An RDN provides a locally-scoped unique 125 identifier for an entry. A complete, globally-unique DN is 126 formed by concatenating the RDNs of an entry together. For 127 example, "cn=admins,cn=inetResources,dc=example,dc=com" 128 consists of two RDNs ("cn=admins" and "cn=inetResources") 129 within the "dc=example,dc=com" DIT. RDNs are typically only 130 referenced within their local scope. 132 OID (Object Identifier) - An OID is a globally-unique, 133 concatenated set of integers which provide a kind of 134 "serial number" to attributes, object classes, syntaxes and 135 other schema elements. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 138 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 139 in this document are to be interpreted as described in RFC 2119. 141 3. Background, Objectives and Overview 143 3.1. Background 145 The WHOIS service was originally provided as a front-end to a 146 centralized repository of ARPANET resources and users. Over time, 147 multiple WHOIS information servers have been deployed which 148 provide other kinds of information for various types of Internet 149 resources. 151 For example, there are scores of WHOIS servers which serve one or 152 more of the top-level domains ("com", "jp", etc.), with each 153 server providing information about the sub-domains that have been 154 delegated beneath each of the managed TLDs, and which also provide 155 information about the human operators of those domains, among 156 other details. Similarly, there are WHOIS servers which provide 157 information about different portions of the IPv4 address space. 158 Similarly, there are WHOIS servers which are operated by service 159 providers which provide information about the resources in use by 160 that organization and its customers. All told, there are hundreds 161 of WHOIS servers available on the public Internet, with each 162 server providing general information about the particular network 163 resources under the control of each organization. 165 Unfortunately, the WHOIS specification does not define a strict 166 set of data-typing or formatting requirements, and as a result, 167 each of the different implementations provide information in 168 slightly different ways. Some servers provide limited amounts of 169 unstructured information, while others provide information in a 170 highly-detailed and highly-structured form. Similarly, some 171 servers provide information in only one language and charset, 172 while others support multiple languages and charsets, and use 173 input switches to control the output format. Essentially, every 174 WHOIS server has its own data formats and syntaxes, with little 175 consistency between them, which has made programmatic processing 176 of the data difficult. 178 Furthermore, each WHOIS server operates as a self-contained 179 entity, with no knowledge or linkage between the different 180 servers, meaning that WHOIS servers cannot redirect clients to 181 other servers for additional information. 183 Another concern is that the WHOIS services which are being 184 operated today offer no means of client authentication, requiring 185 that server operators essentially publish all data with a single 186 "world-readable" permission. However, this single permission 187 conflicts with the privacy and security policies of specific 188 jurisdictions. A more flexible mechanism for controlling the 189 release of physical and personal information is required in order 190 to meet the requirements of the varying constituencies. 192 There are many other secondary issues with the WHOIS service as it 193 exists in current form. However, the largest problems are a lack 194 of standardized data formats, a lack of widely-supported referral 195 mechanisms, and lack of privacy and security controls, as 196 described in the preceding text. 198 This document attempts to address these issues by defining 199 operational and protocol guidelines for a distributed and highly- 200 structured WHOIS-like service, using the LDAP protocol for the 201 query/response transfer service, and using LDAP schema for the 202 search inputs, answer data, and redirection mechanisms. In short, 203 the intention of this approach is to provide an extensible and 204 scalable WHOIS service, leveraging the capabilities of LDAP. 206 3.2. Overview 208 This document defines four basic service components and their 209 interaction as part of a distributed resource-locator service. 210 Each of these components work together to provide a structured and 211 distributed resource-locator service. 213 Specifically, this document only defines the elements which govern 214 the core service. Separate documents define the individual 215 resource types, their schema and matching filters, and so forth. 217 As such, the architecture and protocols defined in this 218 specification are purposefully designed to be capable of 219 accommodating a variety of different data-types and usage models, 220 including future uses which are not defined here. 222 The four components of the core service model are: 224 * Structured Namespace. This document makes use of an LDAP 225 namespace which is built upon the existing DNS delegation 226 hierarchy, and which is supplemented by a layered namespace 227 consisting of service-specific containers and resource- 228 specific entries. This namespace and the associated naming 229 rules facilitate the programmatic formation of queries, 230 structured data, and referrals. 232 * Schema Definitions. This document reuses many existing LDAP 233 schema definitions, but also introduces several new object 234 classes, attributes, syntaxes and matching filters. Some of 235 these definitions apply to the overall architecture, while 236 others are concerned with specific resource types. 238 * Searching Rules. This document defines several rules for 239 forming queries which are designed to facilitate consistent 240 answer sets, and to improve interoperability between 241 compliant clients and servers. 243 * Query Processing Models. This document defines three 244 distinct query-processing models which may be used for 245 locating the authoritative servers associated with a named 246 resource. These include a "top-down" model which is 247 designed for querying centrally-managed Internet resources, 248 a "bottom-up" model which is designed for querying user- 249 managed resources, and a "targeted search" model which is 250 designed for querying known servers for information about 251 known resources. This document also specifies protocol 252 behavior for following subordinate reference referrals, 253 continuation reference referrals, and attribute references. 255 As stated above, this document defines core schema and matching 256 rules, while external (related) documents define schema and 257 matching rules for specific resource types. Among the resource 258 types already defined (and partially reused herein) are: 260 * [ldap-whois-dns] - - 261 Defining and Locating DNS Domains using the Internet 262 Resource Query Service 263 * [ldap-whois-ipv4] - - 264 Defining and Locating IPv4 Address Blocks using the 265 Internet Resource Query Service 267 * [ldap-whois-ipv6] - - 268 Defining and Locating IPv6 Address Blocks using the 269 Internet Resource Query Service 271 * [ldap-whois-asn] - - 272 Defining and Locating Autonomous System Numbers using the 273 Internet Resource Query Service 275 * [ldap-whois-user] - - 276 Defining and Locating Contact Persons using the Internet 277 Resource Query Service 279 It is the intention of the author that additional resource types 280 will be added to this framework over time. 282 4. The LDAP-WHOIS Namespace 284 A critical aspect of this service is the use of a predictable 285 naming syntax, both for the automatic creation of programmatic 286 searches for data, and for publishing structured data and 287 referrals. In order to ensure this predictability, this document 288 defines a multi-layered syntax which MUST be used by all compliant 289 implementations. 291 The LDAP-WHOIS service also makes provisions for the use of 292 multiple referral services for the purpose of redirecting LDAP 293 clients to foreign directory information trees (DITs). This allows 294 organizations to redirect queries to external service providers, 295 consolidate DITs within a single server, maintain foreign objects 296 within a private DIT (such as allowing a third-party router to 297 exist as a separately managed resource within an end-user DIT), 298 and allows answer sets to contain responses from multiple servers. 300 4.1. Namespace Example 302 Figure 1 below shows a subset example of the LDAP-WHOIS namespace. 303 This namespace will be used throughout this document to illustrate 304 many of the concepts from this specification. 306 DIT: dc=example,dc=com 307 | 308 +-cn=inetResources,dc=example,dc=com 309 [top object class] 310 [inetResources object class] 311 | 312 +-attribute: o 313 | value: "Example Widgets, Inc. public network resources" 314 | 315 +-cn=example.com,cn=inetResources,dc=example,dc=com 316 | [top object class] 317 | [inetResources object class] 318 | [inetDnsDomain object class] 319 | | 320 | +-attribute: inetDnsContacts 321 | value: "ldap://ldap.example.com/cn=hostmaster, 322 | ou=admins,dc=example,dc=com" 323 | 324 +-cn=2.0.192.in-addr.arpa, 325 cn=inetResources,dc=example,dc=com 326 | [top object class] 327 | [inetResources object class] 328 | [inetDnsDomain object class] 329 | | 330 | +-attribute: description 331 | | value: "Example Widgets' reverse-lookup domain" 332 | | 333 | +-cn=cref1,cn=2.0.192.in-addr.arpa, 334 | cn=inetResources,dc=example,dc=com 335 | [top object class] 336 | [inetResources object class] 337 | [inetDnsDomain object class] 338 | [referral object class] 339 | | 340 | +-attribute: ref 341 | value: "ldap://ldap.example.com/cn=example.com, 342 | cn=inetResources,dc=example,dc=com" 343 | 344 +-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 345 [inetResources object class] 346 [inetIpv4Network object class] 347 | 348 +-attribute: inetIpv4Contacts 349 value: "ldap://ldap.example.com/cn=hostmaster, 350 ou=admins,dc=example,dc=com" 352 DIT: dc=2,dc=0,dc=192,dc=in-addr,dc=arpa 353 | 354 +-cn=inetResources 355 [top object class] 356 [inetResources object class] 357 [referral object class] 358 | 359 +-attribute: ref 360 value: "ldap://ldap.example.com/cn=inetResources, 361 dc=example,dc=com" 363 Figure 1: Namespace for Example Widgets' domain and network. 365 Figure 1 shows different DITs, both of which are managed by the 366 Example Widgets company. The "dc=example,dc=com" DIT is 367 authoritative for the DNS domain of "example.com", while the 368 "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for the 369 reverse-lookup DNS domain of 2.0.192.in-addr.arpa and the IPv4 370 network of "192.0.2.0/24". 372 Both DITs have container entries called "cn=inetResources". This 373 container entry is responsible for holding all of the entries 374 which are associated with the Internet resources that are being 375 managed by the LDAP-WHOIS service. For example, the 376 "cn=inetResources,dc=example,dc=com" entry contains a subordinate 377 entry for "cn=example.com", which is a DNS domain that is being 378 managed through the LDAP-WHOIS service, and also contains entries 379 for the 2.0.192.in-addr.arpa reverse-lookup DNS domain and the 380 192.0.2.0/24 IPv4 network. 382 The "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entry 383 only exists as a referral which will cause queries to be 384 redirected to the "cn=inetResources,dc=example,dc=com" hierarchy. 386 The naming syntax and rules are described throughout the remainder 387 of this section 4.1. Figure 1 is only provided as an example a 388 relatively complete namespace, for illustration and subsequent 389 discussion purposes. 391 4.2. The domainComponent LDAP Hierarchy 393 The top-level of the namespace defined for use with this service 394 uses the domainComponent naming syntax specified in RFC 2247, 395 which maps DNS domain names to domainComponent ("dc=") labels to 396 form a DIT. Each DIT represents a primary identifier for the 397 management body that is offering an LDAP server, and as such, 398 provides a primary identifier for the Internet resources under the 399 control of that organization. The DITs will be used to build LDAP 400 queries for specific resources, and will also be used to locate 401 the LDAP servers associated with the controlling organization. 403 Examples of the RFC 2247 syntax are shown in Figure 2 below. 405 Figure 2: The LDAP-WHOIS domainComponent Namespace. 407 dc=. 408 | 409 +----------------+---------------+ 410 / | \ 411 dc=arpa dc=com dc=[...] 412 | | 413 +--+--+ dc=example 414 / \ 415 dc=in-addr dc=ip6 417 A complete sequence of domainComponent DNs represents the scope of 418 the DIT. For example, a DIT with the distinguished name (DN) of 419 "dc=com" is authoritative for all of the LDAP resources within the 420 "com" DNS domain (for many LDAP-WHOIS queries, this will also 421 include any sub-domains under the "com" domain). Meanwhile, a DIT 422 with the DN of "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is 423 authoritative for domain name resources within the reverse-lookup 424 "2.0.192.in-addr.arpa" DNS domain, as well as the IPv4 network 425 addresses within the 192.0.2.0/24 network. At the other extreme, 426 the dc="." DIT is responsible for all Internet resources (although 427 this DIT is rarely used). 429 Since the DIT determines the scope of control over a set of 430 resources, DITs that overlap also have overlapping scopes of 431 control. For example, the "dc=com" and "dc=example,dc=com" DITs 432 can both provide information about the "www.example.com" domain 433 name resource. In order to allow end-users to specify which scope 434 they wish to work with for any given query, this document defines 435 three different query models (these are described in section 7). 437 When the LDAP servers associated with the chosen DIT need to be 438 located, the domainComponent DNs from the DIT are mapped to a DNS 439 domain name, and a query is issued for the LDAP servers associated 440 with that domain name (this process is also described in section 441 7). This means that the authority to process LDAP searches for a 442 DIT comes directly from the portion of the DNS namespace already 443 under the control of that management body. For example, the LDAP 444 servers which are used to process queries for the "dc=com" DIT 445 will be located by querying the DNS zone responsible for the "com" 446 portion of the DNS namespace, and so forth. 448 4.3. The inetResources Container 450 This specification requires the use of a mandatory LDAP container 451 entry with the well-known relative distinguished name (RDN) of 452 "cn=inetResources", which MUST exist in the root of every DIT that 453 provides LDAP-WHOIS services. All resource-specific entries which 454 are provided on public LDAP-WHOIS servers MUST be stored in the 455 cn=inetResources container entry. 457 The primary motivation for this naming is for predictability, in 458 that it allows searches to be formed programmatically (a search 459 base for resources in the "dc=example,dc=com" DIT can be 460 programmatically formed as "cn=inetResources,dc=example,dc=com", 461 for example). However, there are several other motivating factors 462 for this naming syntax. 464 For example, it is easier to apply a single anonymous read-only 465 permission to the inetResources container than it is to apply the 466 same permission to multiple discrete entries, which in turn means 467 that it is more likely that the appropriate restrictions will be 468 defined. Furthermore, the use of a single container entry for all 469 of an organization's Internet resources allows that branch of the 470 DIT to be redirected to another DIT through the use of a single 471 referral operation (this will be particularly important when the 472 LDAP servers that are located by DNS lookups are not the same 473 servers that provide LDAP-WHOIS services). Another reason to use 474 this naming syntax is that it shelters clients from server-side 475 vagaries with DIT entries (where different vendors use different 476 object classes to define the DITs). 478 All told, the use of the "cn=inetResources" RDN facilitates smooth 479 operations, and is important enough to justify the MANDATORY usage 480 of this naming syntax. 482 4.4. Resource-Specific Entries 484 This document defines four Internet resource types, each of which 485 have their own naming rules. However, each resource type has a 486 consistent naming principle, in that the specific managed resource 487 has an RDN which uniquely identifies that resource, with the RDN 488 residing within the inetResources container entry. 490 For example, an entry for the "www.example.com" domain name 491 resource stored in the "dc=example,dc=com" DIT would have a DN of 492 "cn=www.example.com,cn=inetResources,dc=example,dc=com", while an 493 entry for the "192.0.2.0/24" IPv4 network resource would have a DN 494 of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although 495 the relative naming syntax is different for each resource type, 496 the resource naming is consistent for each type, and the position 497 of the RDN within the DN is also predictable. 499 Most resource types cannot be located through simple LDAP browsing 500 and equality matches. Instead, resource-specific entries use 501 structured naming rules in order to facilitate the extensible 502 match search operations which are specific to each of the defined 503 resource types. For example, there is not likely to be a specific 504 entry for every possible IPv4 address. In order to allow the 505 appropriate entry to be located, however, the client can use the 506 inetIpv4NetworkMatch extensible matching search operation, which 507 locates the appropriate entry based on the search input. 509 The naming rules associated with each resource type are provided 510 in section 5, along with the schema definitions for each of the 511 resource types. The extensible matching filters associated with 512 each resource type are described in section 6. 514 4.5. Redirects and Referrals 516 A critical objective behind this service is for servers to be able 517 to redirect clients to other servers, entries, or DITs, when this 518 is necessary or desirable. Towards this end, this document 519 specifies three methods for generating and processing redirects 520 and referrals: subordinate reference referrals, continuation 521 reference referrals, and attribute references. 523 Subordinate reference referrals indicate that the queried entry is 524 an alias for some other entry, and that the query has to be 525 restarted in order for the current operation to be completed. 526 Meanwhile, continuation references indicate that the search was 527 successfully initiated, but that additional queries are required 528 for the original query to be completely exhausted. Finally, 529 attribute references simply indicate that supplemental data is 530 available at some other location, but that no additional queries 531 are required to satisfy the current operation. 533 NOTE: RFC 2251 defines a superior reference referral which 534 is used as a "default referral" for out-of-scope searches. 535 However, this application specifically excludes support for 536 superior reference referrals. Any superior reference 537 referrals which are encountered as a part of this service 538 are to be treated as errors. 540 Subordinate references and continuation references use the ref 541 attribute and referral object class defined in [namedref]. 542 Attribute references use a superset of the formatting rules 543 associated with the labeledURI attribute, as defined in RFC 2079. 544 All of these mechanisms use LDAP URLs as their input data, 545 although these URLs have service-specific restrictions that are 546 somewhat tighter than the source specifications allow. 548 Among these rules: 550 * All referenced entries MUST comply with the naming syntax 551 rules specified in this document. This means that all 552 entries MUST use the domainComponent ("dc=") naming syntax 553 for their DITs, resource-specific entries MUST reside in 554 the inetResources container entry, and resource-specific 555 entries MUST comply with the naming rules for the resource 556 type in question. 558 * Referral sources and targets MUST have the same resource- 559 specific object classes defined (for example, the referral 560 source and target for a DNS domain resource would both have 561 the inetDnsDomain object class defined). This is a 562 prerequisite for the proper handling of the search filters 563 specified in this document. Attribute references are not 564 referrals, so they are exempt from this requirement. 566 * Referenced entries MAY exist as referrals to other entries, 567 but recursive referrals are discouraged. 569 * Except where otherwise noted, the protocol identifier of a 570 URL MUST specify the LDAP service type. Although general- 571 purpose LDAP referrals are allowed to specify any URL, 572 LDAP-WHOIS referrals and references are intended to be used 573 for automated queries, so the use of other protocols or 574 services is expressly forbidden. 576 * The host identifier of a URL MUST specify either an IP 577 address or a domain name. URLs which do not provide host 578 identifiers are invalid in all cases. 580 * URLs MUST be provided and stored in a URL-safe format. For 581 example, the IPv4 and IPv6 network address syntaxes defined 582 in this document make use of the forward-slash ("/") 583 character to indicate a subnet prefix, and if this 584 character needs to be provided in a URL, it must be 585 provided in the escaped form ("%2F" in this example). 586 Furthermore, some of the matching rules described in this 587 document require that the URLs also be stored in this 588 format in order for the searches to succeed. 590 * Implementations MUST NOT restrict URL values to verifiable 591 entries from local partitions. Implementations MAY validate 592 targets when the partition is known and accessible, but a 593 lack of knowledge regarding a target MUST NOT be cause to 594 prevent the entry from being specified. 596 Clients MAY implement support for additional protocol identifiers 597 if they wish to act upon URLs which are provided in conflict with 598 the requirements above. However, clients MUST NOT violate any 599 other mandates in this document while doing so (in particular, 600 clients MUST NOT break the query-processing procedures defined in 601 section 7 of this document). 603 Each of the supported redirection mechanisms are discussed in more 604 detail below. 606 4.5.1. Subordinate reference referrals 608 Subordinate reference referrals are returned when the search base 609 specified in a query names an entry which exists as a referral 610 object class that points to some other entry. 612 Any of the named entries specified in section 4 of this document 613 MAY be defined as subordinate reference referrals which point to 614 other entries. However, almost all of the search functions defined 615 for use by this service use the inetResources container entry as 616 the search base (the exceptions to this rule are targeted searches 617 for explicit entries), so subordinate reference referrals will 618 most commonly be seen when an inetResources container entry has 619 been redirected to an inetResources container in another DIT. 621 For example, the namespace shown in Figure 1 has an entry of 622 "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" defined 623 with the referral object class, with the ref attribute value 624 pointing to the LDAP server of "ldap.example.com" and the DN of 625 "cn=inetResources,dc=example,dc=com". Any queries for resources 626 within "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" 627 would be answered with that subordinate reference referral, and 628 these queries would have to be restarted using the specified 629 search base and server before they would be processed. 631 Servers MUST support the use of subordinate reference referrals 632 for this purpose, and clients MUST be prepared to accept and 633 process any subordinate reference referrals in answer sets. 635 When subordinate reference referrals are used for this purpose, 636 the referral source MUST be defined with the referral object 637 class, and MUST also be defined with the appropriate object class 638 for that resource type. For example, a "cn=inetResources" entry 639 which provided a subordinate reference referral would need to have 640 both the referral and inetResources object classes defined, while 641 a DNS domain resource such as "dc=example.com" would need to have 642 both the referral and inetDnsDomain object classes defined (among 643 the other object class definitions which were required for that 644 entry). Referral targets need to use whatever object classes are 645 appropriate for the resource in question, and MAY also be 646 referrals to other entries. 648 Client rules for processing subordinate reference referrals are 649 given in section 7.4.1. 651 4.5.2. Continuation reference referrals 653 Continuation reference referrals are returned when a search 654 operation has been successfully processed by the queried server, 655 but the answer data also includes referrals to other entries. 656 These referrals are often provided as supplemental data to an 657 answer set, although this is not required (a continuation 658 reference referral can be the only response, but it won't be the 659 only response in the common case). 661 For example, the namespace shown in Figure 1 has an entry of 662 "cn=cref1,cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example, 663 dc=com" defined with the referral object class, with the ref 664 attribute value pointing to the LDAP server of "ldap.example.com" 665 and the DN of "cn=example.com,cn=inetResources,dc=example,dc=com". 666 Any answers to any queries about "cn=2.0.192.in-addr.arpa" would 667 also include the continuation reference referral, and new queries 668 for the referral target would have to be issued before the 669 original queries were completely processed. 671 Servers MUST support the use of continuation reference referrals 672 for this purpose, and clients MUST be prepared to accept and 673 process any subordinate reference referrals in answer sets. 675 When continuation reference referrals are used for this purpose, 676 entries MAY exist for the queried resource, but one or more 677 entries MUST exist with the referral object class defined, and 678 which provide LDAP URLs that point to other entries which have 679 additional information about the resource in question. 681 Continuation reference referrals are returned in response to 682 specific extensible match queries, and have specific naming 683 requirements which are necessary for the matching functions to 684 work properly. These considerations are described in 7.4.3. 686 Client rules for processing continuation reference referrals are 687 also given in section 7.4.3. 689 4.5.3. Attribute references 691 This document defines attribute references as attribute values 692 which provide LDAP URLs, for the purpose of providing pointers to 693 contextually-related information regarding the entry currently 694 being viewed. Attribute references use the same basic syntax as 695 the labeledURI attribute defined in RFC 2079, although there are 696 additional restrictions, as described above. 698 The contact attributes defined in this document use the attribute 699 reference rules and formats to provide role-specific pointers to 700 inetOrgPerson entries. Whenever one of these attributes is 701 encountered, it is up to the client to deconstruct the provided 702 URLs in order to locate and read the inetOrgPerson entries, 703 although such actions are secondary to the original query process, 704 and will typically only be performed at the user's request. 706 For example, the namespace shown in Figure 1 has an entry of 707 "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" defined with 708 the inetIpv4Network object class, with the inetIpv4Contacts 709 attribute value pointing to the LDAP server of "ldap.example.com" 710 and the DN of "cn=hostmaster,ou=admins,dc=example,dc=com". When 711 this attribute is provided as part of an answer to a query, a 712 client MAY choose to follow this URL for information about that 713 contact, although this would be considered a new and separate 714 query, and would not be required to satisfy the original query. 716 Note that the attribute reference URLs are similar to the URLs 717 defined in RFC 2079, and use a two-part notation of 718 "url://any.host:port/any/path description", with the 719 "description" string providing a free-text description of the 720 target specified by the URL. When the descriptive text is provided 721 in an attribute reference, it SHOULD be displayed to the user as 722 potentially informative data. 724 Client rules for processing attribute references are given in 725 section 7.4.4. 727 4.5.4. labeledURI references 729 Some of the object classes defined in this document make use of 730 the labeledURI attribute, as defined by RFC 2079. These attributes 731 (and their values) are not governed by this document, but instead 732 are governed by RFC 2079. As such, the rules set forth in RFC 2079 733 always apply to those attributes. In particular, this means that 734 those attribute values may reference any protocol (such as 735 http://) and are not restricted to LDAP protocol targets. 737 5. The LDAP-WHOIS Object Classes and Attributes 739 This document defines a general framework for locating information 740 about public network resources in a distributed environment, and a 741 critical element of this definition are schema definitions for the 742 object classes and attributes that provide this information. 744 Towards that end, this document defines a schema for the global 745 inetResources object class which is inherited by all of the 746 resource-specific types, defines four resource-specific object 747 classes, and defines a generalized object class for cross- 748 referencing resources. This document also takes advantage of some 749 pre-existing schema definitions (in particular, the inetOrgPerson 750 object class), where suitable schema were available. Each of the 751 schema definitions provided in this document include attribute 752 definitions, naming rules, and other definitions which are 753 designed to facilitate searching and browsing Internet resources. 755 The following resource definitions are provided in this section: 757 * Organizational and summary data. The inetResources object 758 class defines a variety of general-purpose attributes for 759 describing an organization and its resources. For example, 760 there is a free-text attribute which may be used to provide 761 general comments about the organization or the resources 762 under its control, attributes for providing general-use 763 postal and email addresses, and so forth. The inetResources 764 object class also defines several attributes which may be 765 used to provide attribute references for a variety of 766 administrative roles. 768 * Associated objects. Internet resources are typically 769 assigned by independent entities, although there is often 770 an extensive amount of cross-pollination. For example, AS 771 Numbers are typically associated with IPv4 and IPv6 address 772 blocks, with this association being considered as a 773 mandatory linkage. However, less-formal associations also 774 often exist, such as a private organization associating an 775 IP address block with a specific DNS domain, or where a 776 regional authority is responsible for all domain name and 777 IP address delegations. Due to this flexibility, the LDAP- 778 WHOIS service provides an auxiliary object class for 779 associated objects which may be used with any of the 780 resource-specific object classes defined in this document. 782 Each of the attributes and object classes listed above represent 783 the Internet-wide network resources which MAY be offered by an 784 LDAP-WHOIS server. 786 It is expected that additional network resource definitions will 787 be provided by other documents. 789 5.1. The inetResources Object Class 791 The inetResources object class is a structural object class which 792 defines the attributes associated with a "cn=inetResources" 793 container entry, and which provides general information about the 794 network resources associated with the current DIT. 796 5.1.1. Naming syntax 798 This document requires the presence of an entry named 799 "cn=inetResources" in the root of every DIT which provides LDAP- 800 WHOIS services. 802 5.1.2. Schema definition 804 Every DIT which provides public LDAP-WHOIS data MUST have a 805 "cn=inetResources" entry in the root of the DIT. The inetResources 806 entry MUST exist with the top and inetResources object classes 807 defined. If the entry exists as a referral, the entry MUST also be 808 defined with the referral object class, in addition to the above 809 requirements. 811 The inetResources object class is a structural object class which 812 is subordinate to the top abstract class, and which MUST be 813 treated as a container class capable of holding additional 814 subordinate entries. The inetResources object class has one 815 mandatory attribute which is "cn" (the naming attribute), and also 816 has several optional attributes. Each of the other object classes 817 defined by this document are subordinate to the inetResources 818 object class and inherit the attributes defined for the 819 inetResources object class. 821 The inetResources object class is intended to provide summary 822 information about a collection of resources under the control of a 823 single organization or management body. For example, the mail 824 attribute is intended to be used as a general-purpose email 825 address for the organization as a whole (such as 826 "info@example.com"), rather than being used as an email address 827 for a particular administrative role. Because this object class is 828 also inherited by the resource-specific object classes, these 829 attributes can be defined at each of the subordinate entries if a 830 global set of values is undesirable or unfeasible. 832 The inetResources object class provides several multi-valued 833 contact-related attributes for a variety of well-known 834 administrative roles. This model allows the inetResources entry 835 and each of the subordinate managed resources to share a common 836 set of administrative roles, or to have unique roles for each 837 resource, as seen fit by the managing entity. The contact 838 attribute values follow the same rules as the labeledURI attribute 839 defined in RFC 2079, with additional restrictions as described in 840 section 4.5 of this document. 842 The various ModifiedBy and ModifiedDate attributes SHOULD be 843 treated as operational attributes. Their values SHOULD be filled 844 in automatically by the database management application, and 845 SHOULD NOT be returned except when explicitly requested. 847 Since multiple directory trees can share a single inetResources 848 entry (through the use of subordinate reference referrals), it is 849 important for the associated data to be applicable for all of the 850 objects which refer to it. For example, it would be effective for 851 a small private company to use a shared set of inetResources 852 attributes for their DNS domain names and IP network blocks, but 853 it would probably be counter-productive for a global ISP to share 854 contact data across all of their hosted domains and routed 855 networks. If separate contacts are required for each resource, the 856 contact data should be specified within each entry, rather than 857 being linked to the inetResources entry. 859 The schema definition for the inetResources object class is as 860 follows: 862 inetResources 863 ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The 864 inetResources container for the LDAP-WHOIS service' SUP top 865 STRUCTURAL MUST cn MAY ( o $ ou $ description $ 866 inetResourceComments $ businessCategory $ telephoneNumber $ 867 facsimileTelephoneNumber $ mail $ labeledURI $ 868 preferredDeliveryMethod $ physicalDeliveryOfficeName $ 869 postOfficeBox $ postalAddress $ postalCode $ street $ l $ 870 st $ c $ inetAbuseContacts $ inetAbuseContactsModifiedBy $ 871 inetAbuseContactsModifiedDate $ inetGeneralContacts $ 872 inetGeneralContactsModifiedBy $ 873 inetGeneralContactsModifiedDate $ inetSecurityContacts $ 874 inetSecurityContactsModifiedBy $ 875 inetSecurityContactsModifiedDate $ inetTechContacts $ 876 inetTechContactsModifiedBy $ inetTechContactsModifiedDate $ 877 inetGeneralDisclaimer ) ) 879 The attributes from the inetResources object class are described 880 below: 882 businessCategory, see RFC 2256, section 5.16 884 c (country), see RFC 2256, section 5.7 886 cn (commonName), see RFC 2256, section 5.4 888 description, see RFC 2256, section 5.14 890 facsimileTelephoneNumber, see RFC 2256, section 5.24 892 inetAbuseContacts 893 ( 1.3.6.1.4.1.7161.1.0.1 NAME 'inetAbuseContacts' DESC 894 'Contacts for reporting abusive behavior or acceptable-use 895 policy violations.' EQUALITY caseExactMatch SYNTAX 896 1.3.6.1.4.1.1466.115.121.1.15 ) 898 inetAbuseContactsModifiedBy 899 ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContactsModifiedBy' 900 DESC 'Person who last modified the inetAbuseContacts 901 attribute.' EQUALITY distinguishedNameMatch SYNTAX 902 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 903 distributedOperation ) 904 inetAbuseContactsModifiedDate 905 ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetAbuseContactsModifiedDate' 906 DESC 'Last modification date of the inetAbuseContacts 907 attribute.' EQUALITY generalizedTimeMatch ORDERING 908 generalizedTimeOrderingMatch SYNTAX 909 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 910 distributedOperation ) 912 inetGeneralContacts 913 ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetGeneralContacts' DESC 914 'Contacts for general administrative issues.' EQUALITY 915 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 917 inetGeneralContactsModifiedBy 918 ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetGeneralContactsModifiedBy' 919 DESC 'Person who last modified the inetGeneralContacts 920 attribute.' EQUALITY distinguishedNameMatch SYNTAX 921 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 922 distributedOperation ) 924 inetGeneralContactsModifiedDate 925 ( 1.3.6.1.4.1.7161.1.0.6 NAME 926 'inetGeneralContactsModifiedDate' DESC 'Last modification 927 date of the inetGeneralContacts attribute.' EQUALITY 928 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 929 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 930 distributedOperation ) 932 inetGeneralDisclaimer 933 ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC 934 'General disclaimer text regarding this data' EQUALITY 935 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 936 ) 938 inetResourceComments 939 ( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetResourceComments' DESC 940 'General comments about this entry' EQUALITY 941 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 942 ) 944 inetSecurityContacts 945 ( 1.3.6.1.4.1.7161.1.0.9 NAME 'inetSecurityContacts' DESC 946 'Contacts for general security issues.' EQUALITY 947 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 948 inetSecurityContactsModifiedBy 949 ( 1.3.6.1.4.1.7161.1.0.10 NAME 950 'inetSecurityContactsModifiedBy' DESC 'Person who last 951 modified the inetSecurityContacts attribute.' EQUALITY 952 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 953 SINGLE-VALUE USAGE distributedOperation ) 955 inetSecurityContactsModifiedDate 956 ( 1.3.6.1.4.1.7161.1.0.11 NAME 957 'inetSecurityContactsModifiedDate' DESC 'Last modification 958 date of the inetSecurityContacts attribute.' EQUALITY 959 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 960 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 961 distributedOperation ) 963 inetTechContacts 964 ( 1.3.6.1.4.1.7161.1.0.12 NAME 'inetTechContacts' DESC 965 'Contacts for general technical issues.' EQUALITY 966 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 968 inetTechContactsModifiedBy 969 ( 1.3.6.1.4.1.7161.1.0.13 NAME 'inetTechContactsModifiedBy' 970 DESC 'Person who last modified the inetTechContacts 971 attribute.' EQUALITY distinguishedNameMatch SYNTAX 972 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 973 distributedOperation ) 975 inetTechContactsModifiedDate 976 ( 1.3.6.1.4.1.7161.1.0.14 NAME 'inetTechContactsModifiedDate' 977 DESC 'Last modification date of the inetTechContacts 978 attribute.' EQUALITY generalizedTimeMatch ORDERING 979 generalizedTimeOrderingMatch SYNTAX 980 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 981 distributedOperation ) 983 l (locality), see RFC 2256, section 5.8 985 labeledURI, see RFC 2079 987 mail, see RFC 2798, section 9.1.3 989 o (organization), see RFC 2256, section 5.11 991 ou (organizational unit), see RFC 2256, section 5.12 992 physicalDeliveryOfficeName, see RFC 2256, section 5.20 994 postalAddress, see RFC 2256, section 5.17 996 postalCode, see RFC 2256, section 5.18 998 postOfficeBox, see RFC 2256, section 5.19 1000 preferredDeliveryMethod, see RFC 2256, section 5.29 1002 st (stateOrProvinceName), see RFC 2256, section 5.9 1004 street (streetAddress), see RFC 2256, section 5.10 1006 telephoneNumber, see RFC 2256, section 5.21 1008 5.1.3. Example 1010 An example of the inetResources object class in use is shown in 1011 Figure 3 below. 1013 cn=inetResources,dc=example,dc=com 1014 [top object class] 1015 [inetResources object class] 1016 | 1017 +-attribute: o 1018 | value: "Example Widgets' network resources" 1019 | 1020 +-attribute: inetGeneralContacts 1021 | value: "ldap://ldap.example.com/cn=admins,ou=admins, 1022 | dc=example,dc=com" 1023 | 1024 +-attribute: telephoneNumber 1025 | value: "1-800-555-1212" 1026 | 1027 +-attribute: mail 1028 | value: "info@example.com" 1029 | 1030 +-attribute: inetResourceComments 1031 value: "Please don't send complaints to the 1032 postmaster@example.com mailbox." 1034 Figure 3: The Example Widgets inetResources container entry. 1036 5.2. The inetAssociatedResources Object Class 1038 The inetAssociatedResources object class defines cross-reference 1039 attributes which may be used with any of the object classes 1040 defined in this document. For example, it allows inetDnsDomain 1041 object class entries to be associated with IPv4 networks, or even 1042 to other DNS domains, if that information is known (this 1043 information may be useful if a single organization has multiple 1044 DNS domains registered). Furthermore, it allows inetOrgPerson 1045 object classes to be associated with managed resources such as IP 1046 networks or DNS domains. In short, any resource can be associated 1047 with any other resource through the use of this object class. 1049 The inetAssociatedResources object class MUST NOT be associated 1050 with an entry that only exists as a referral source. 1052 5.2.1. Naming syntax 1054 The inetAssociatedResources object class is an auxiliary object 1055 class, and not a structural object class. Entries which use this 1056 object class definition are primarily defined under the rules 1057 associated with the structural object class that defines the 1058 Internet resource in question. As such, the naming rules 1059 associated with the structural object class in use with that entry 1060 take precedence. Therefore, the inetAssociatedResources object 1061 class does not define a naming syntax. 1063 5.2.2. Schema definition 1065 The inetAssociatedResources object class is an auxiliary object 1066 class which is subordinate to the top object class. The 1067 inetAssociatedResources object class has no mandatory attributes, 1068 although it does have several optional attributes. 1070 Although the inetAssociatedResources object class is subordinate 1071 to the top object class, it is intended to only be associated with 1072 the resource-specific structural object classes defined in this 1073 document. For example, the inetAssociatedResources object class is 1074 not likely to provide much value when it is associated with the 1075 inetResources object class, since the inetResources object class 1076 does not specifically define any resources (and since it does not 1077 define resources, it cannot define any associated resources). On 1078 the other hand, it is reasonable for the inetAssociatedResources 1079 object class to be associated with an inetOrgPerson object class 1080 entry, particularly if the referenced person (or role) is 1081 responsible for the management of multiple resources. 1083 Each of the associated resource attributes provide multi-valued 1084 data, using the syntax notations which are specific to the 1085 resource in question. For example, the inetAssociatedDnsDomain 1086 attribute provides associated DNS domain name resources using a 1087 multi-valued array, with each DNS domain name using the 1088 inetDnsDomainSyntax naming rules. 1090 The various ModifiedBy and ModifiedDate attributes SHOULD be 1091 treated as operational attributes. Their values SHOULD be filled 1092 in automatically by the database management application, and 1093 SHOULD NOT be returned except when explicitly requested. 1095 The schema definition for the inetAssociatedResources object class 1096 is as follows: 1098 inetAssociatedResources 1099 ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC 1100 'Network resources associated with this entry.' SUP top 1101 AUXILIARY MAY ( inetAssociatedDnsDomains $ 1102 inetAssociatedDnsDomainsModifiedBy $ 1103 inetAssociatedDnsDomainsModifiedDate $ 1104 inetAssociatedIpv4Networks $ 1105 inetAssociatedIpv4NetworksModifiedBy $ 1106 inetAssociatedIpv4NetworksModifiedDate $ 1107 inetAssociatedIpv6Networks $ 1108 inetAssociatedIpv6NetworksModifiedBy $ 1109 inetAssociatedIpv6NetworksModifiedDate $ 1110 inetAssociatedAsNumbers $ 1111 inetAssociatedAsNumbersModifiedBy $ 1112 inetAssociatedAsNumbersModifiedDate ) ) 1114 The attributes from the inetAssociatedResources object class are 1115 described below: 1117 inetAssociatedAsNumbers 1118 ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC 1119 'The autonomous system numbers associated with this entry.' 1120 EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax ) 1121 inetAssociatedAsNumbersModifiedBy 1122 ( 1.3.6.1.4.1.7161.1.5.3 NAME 1123 'inetAssociatedAsNumbersModifiedBy' DESC 'Person who last 1124 modified the inetAssociatedAsNumbers attribute.' EQUALITY 1125 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1126 SINGLE-VALUE USAGE distributedOperation ) 1128 inetAssociatedAsNumbersModifiedDate 1129 ( 1.3.6.1.4.1.7161.1.5.4 NAME 1130 'inetAssociatedAsNumbersModifiedBy' DESC 'Last modification 1131 date of the inetAssociatedAsNumbers attribute.' EQUALITY 1132 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1133 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1134 distributedOperation ) 1136 inetAssociatedDnsDomains 1137 ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedDnsDomains' DESC 1138 'The DNS domains associated with this entry.' EQUALITY 1139 caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) 1141 inetAssociatedDnsDomainsModifiedBy 1142 ( 1.3.6.1.4.1.7161.1.5.6 NAME 1143 'inetAssociatedDnsDomainsModifiedBy' DESC 'Person who last 1144 modified the inetAssociatedDnsDomains attribute.' EQUALITY 1145 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1146 SINGLE-VALUE USAGE distributedOperation ) 1148 inetAssociatedDnsDomainsModifiedDate 1149 ( 1.3.6.1.4.1.7161.1.5.7 NAME 1150 'inetAssociatedDnsDomainsModifiedBy' DESC 'Last 1151 modification date of the inetAssociatedDnsDomains 1152 attribute.' EQUALITY generalizedTimeMatch ORDERING 1153 generalizedTimeOrderingMatch SYNTAX 1154 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1155 distributedOperation ) 1157 inetAssociatedIpv4Networks 1158 ( 1.3.6.1.4.1.7161.1.5.8 NAME 'inetAssociatedIpv4Networks' 1159 DESC 'The IPv4 networks associated with this entry.' 1160 EQUALITY caseIgnoreMatch SYNTAX inetIpv4NetworkSyntax ) 1161 inetAssociatedIpv4NetworksModifiedBy 1162 ( 1.3.6.1.4.1.7161.1.5.9 NAME 1163 'inetAssociatedIpv4NetworksModifiedBy' DESC 'Person who 1164 last modified the inetAssociatedIpv4Networks attribute.' 1165 EQUALITY distinguishedNameMatch SYNTAX 1166 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1167 distributedOperation ) 1169 inetAssociatedIpv4NetworksModifiedDate 1170 ( 1.3.6.1.4.1.7161.1.5.10 NAME 1171 'inetAssociatedIpv4NetworksModifiedDate' DESC 'Last 1172 modification date of the inetAssociatedIpv4Networks 1173 attribute.' EQUALITY generalizedTimeMatch ORDERING 1174 generalizedTimeOrderingMatch SYNTAX 1175 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1176 distributedOperation ) 1178 inetAssociatedIpv6Networks 1179 ( 1.3.6.1.4.1.7161.1.5.11 NAME 'inetAssociatedIpv6Networks' 1180 DESC 'The IPv6 networks associated with this entry.' 1181 EQUALITY caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) 1183 inetAssociatedIpv6NetworksModifiedBy 1184 ( 1.3.6.1.4.1.7161.1.5.12 NAME 1185 'inetAssociatedIpv6NetworksModifiedBy' DESC 'Person who 1186 last modified the inetAssociatedIpv6Networks attribute.' 1187 EQUALITY distinguishedNameMatch SYNTAX 1188 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1189 distributedOperation ) 1191 inetAssociatedIpv6NetworksModifiedDate 1192 ( 1.3.6.1.4.1.7161.1.5.13 NAME 1193 'inetAssociatedIpv6NetworksModifiedDate' DESC 'Last 1194 modification date of the inetAssociatedIpv6Networks 1195 attribute.' EQUALITY generalizedTimeMatch ORDERING 1196 generalizedTimeOrderingMatch SYNTAX 1197 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1198 distributedOperation ) 1199 5.2.3. Example 1201 An example of the inetAssociatedResources object class is shown in 1202 Figure 4 below. 1204 cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 1205 [top object class] 1206 [inetResources object class] 1207 [inetIpv4Network object class] 1208 [inetAssociatedResources object class] 1209 | 1210 +-attribute: description 1211 | value: "The example.com network" 1212 | 1213 +-attribute: inetAssociatedAsNumbers 1214 | value: "65535" 1215 | 1216 +-attribute: inetAssociatedDnsDomains 1217 value: "example.com" 1219 Figure 4: The inetAssociatedResources attributes associated with 1220 the 192.0.2.0/24 IPv4 network entry. 1222 5.3. The referral Object Class 1224 This document allows the use of the referral object class to 1225 define subordinate reference referrals and continuation reference 1226 referrals for inetResources container entries and all of the 1227 resource-specific entries. 1229 Referral entries MUST conform to the schema specification defined 1230 in [namedref]. In particular, referral entries MUST NOT contain 1231 any user-definable attributes other than the mandatory "cn" naming 1232 attribute and the mandatory "ref" operational attribute. By 1233 extension, referral entries MUST be leaf nodes, and MUST NOT have 1234 any subordinate entries defined at the referral source. 1236 Furthermore, in order to facilitate programmatic access to this 1237 data, LDAP URLs provided in ref attributes MUST refer to entries 1238 which use the same object classes as the source entry, MUST refer 1239 to an entry in a DIT which uses the domainComponent object class 1240 syntax ("dc="), and MUST specify the LDAP protocol-type. 1242 5.4. Object Class and Attribute Permissions 1244 The information presented through the LDAP-WHOIS service will be 1245 used for many operational and problem-resolution purposes. In 1246 order for this information to be suitable for this purpose, it 1247 must be accurate. In order to ensure the veracity of the 1248 information, a minimal set of operational guidelines are provided 1249 in this section. For the most part, these rules are designed to 1250 prevent unauthorized modifications to the data. 1252 Note that these rules only apply to data which is willingly 1253 provided; no data is required to be entered, but where the data is 1254 provided, it MUST be accurate, and it MUST be secured against 1255 unauthorized modifications. 1257 * The inetResources container entry and all of the resource- 1258 specific subordinate entries within every public DIT that 1259 provides LDAP-WHOIS resources SHOULD have anonymous read- 1260 only access permissions, and SHOULD NOT have anonymous add, 1261 delete or modify permissions. 1263 * With the exception of contact-related attributes from the 1264 inetOrgPerson object class, each attribute MAY have 1265 whatever restrictions are necessary in order to suit local 1266 security policies, government regulations or personal 1267 privacy concerns. When the inetOrgPerson object class is 1268 used to provide contact details, the mail attribute MUST be 1269 defined, SHOULD be valid, SHOULD have read-only anonymous 1270 access, and SHOULD NOT have anonymous add, delete or modify 1271 permissions. 1273 By using the inetOrgPerson object class, it is expected 1274 that existing contact-related entries can be reused. If 1275 reusing these entries is undesirable or unfeasible, entries 1276 with the necessary access SHOULD be made available. 1278 Note that contact pointers are entirely optional and are 1279 not required to exist. However, where they exist, they MUST 1280 comply with the above requirements. 1282 * End-users and implementers SHOULD provide anonymous access 1283 to the creatorsName, createTimestamp, modifiersName and 1284 modifyTimestamp operational attributes associated with each 1285 entry in the inetResources branch, since this information 1286 is useful for determining the age of the information. 1288 * Server administrators MAY define additional add, delete or 1289 modify permissions for authenticated users, using any 1290 LDAPv3 authentication mechanisms they wish. In particular, 1291 delegation entities MAY provide for the remote management 1292 of delegated resources (such as assigning modification 1293 privileges to the managers of a particular delegated domain 1294 or address block), although this is entirely optional, and 1295 is within the sole discretion of the delegation body. 1297 External applications SHOULD NOT make critical decisions based on 1298 the information provided through this service without having 1299 reason to trust the veracity of the information. Clients and users 1300 SHOULD limit the use of unknown or untrusted information to 1301 routine purposes. 1303 6. Search and Match Filters 1305 LDAP search filters are fairly flexible, in that they allow for a 1306 wide variety of configurable elements, such as the maximum number 1307 of entries which are returned, the type of comparison operation 1308 that needs to be performed, and other details. In order to promote 1309 interoperability, default values are defined here for many of 1310 these elements, although these defaults are only applicable when 1311 they are used with the LDAP-WHOIS service. 1313 In particular, this document defines several suggested and 1314 mandatory search filter qualifiers, which are described in detail 1315 in section 6.1. This document also defines extensibleMatch filter 1316 definitions which MUST be implemented whenever the associated 1317 resource types defined in this document are implemented by an 1318 LDAP-WHOIS client or server. These filter definitions are provided 1319 in section 6.2 below. 1321 6.1. Search Filter Expressions 1323 Section 4.5.1 of RFC 2251 defines the LDAP search request 1324 specification, although it does not provide guidelines or 1325 recommended values for the filter settings. In an effort to 1326 promote interoperability among LDAP-WHOIS clients and servers, 1327 this document defines some recommended and mandatory values for 1328 searches within the LDAP-WHOIS service. 1330 NOTE: These rules ONLY apply to the LDAP-WHOIS search 1331 operations in particular. Any queries for other resources 1332 (such as requests for inetOrgPerson contact entries) MUST 1333 NOT impose these restrictions. Also note that other 1334 documents which define additional resource types can also 1335 define different restrictions, and those definitions will 1336 take preference over these guidelines. 1338 Generic LDAP clients may be used to browse and search for data, 1339 and in those cases, these rules are not likely to be followed. As 1340 such, servers MUST be prepared to enforce these rules 1341 independently of the client settings. 1343 The values of an LDAP search filter should be as follows: 1345 * Search base. The DIT to be used in a search will vary for 1346 each query operation. The methodology for determining the 1347 current search base for a query is defined by the query- 1348 processing protocols described in section 7, although LDAP- 1349 WHOIS searches are normally constrained to the 1350 "cn=inetResources" container of a particular DIT. 1352 * Scope. In order to support continuation reference referrals 1353 (which are defined as referral entries beneath a resource- 1354 specific entry), clients MUST use a sub-tree scope for 1355 LDAP-WHOIS searches. Servers MUST NOT arbitrarily limit the 1356 scope of search operations. 1358 * Dereference aliases. Although the LDAP-WHOIS service does 1359 not make direct use of alias entries, they are not 1360 prohibited. Clients SHOULD set the Dereference Aliases 1361 option to "Always" for LDAP-WHOIS searches. Servers SHOULD 1362 dereference any aliases which are encountered, where this 1363 is feasible (in particular, where the alias refers to 1364 another DIT on the same server). 1366 * Size limit. The size limit field specifies the maximum 1367 number of entries that a server should return. For the 1368 LDAP-WHOIS service, this setting SHOULD be set to a value 1369 between 25 and 100. This range ensures that the client is 1370 capable of receiving a sufficient number of entries and 1371 continuation references in a single response, but also 1372 works to prevent runaway queries that match everything 1373 (such as searches for "com", which can match every 1374 inetDnsDomain entry in the "cn=inetResources,dc=com" 1375 container). Servers MAY truncate answer sets to 100 1376 responses if the client specifies a larger value. 1378 * Time limit. The time limit field specifies the maximum 1379 number of seconds that a server should process the search. 1380 For the LDAP-WHOIS service, this setting SHOULD be set to a 1381 value between 10 and 60 seconds. This range ensures that 1382 the server is able to process a sufficient number of 1383 entries, but also works to prevent runaway queries that 1384 match everything. Servers MAY stop processing queries after 1385 60 seconds if the client specifies a larger value. 1387 * Types-only. The types-only setting is a Boolean flag which 1388 controls whether or not attribute values are returned in 1389 the answer sets. Since excessive queries are likely to be 1390 more burdensome than larger answer sets, this setting 1391 SHOULD be set to FALSE. Resource-constrained clients (such 1392 as PDAs) MAY set this value to TRUE, but these clients MUST 1393 be prepared to issue the necessary subsequent queries. 1395 * Filter. The search operation will depend on the type of 1396 data being queried. For LDAP-WHOIS queries, the filter MUST 1397 use the matching rules defined in section 6.2 for the 1398 relevant resource type. Other resource-specific documents 1399 may define their own handling rules. 1401 Note that the extensible match filters defined in this 1402 document MUST be supported by LDAP-WHOIS clients and 1403 servers. LDAP-WHOIS servers MAY also support additional 1404 sub-string filters, soundex filters, or any other filters 1405 they wish (these may be required for generic LDAP clients), 1406 although LDAP-WHOIS clients MUST NOT expect any additional 1407 filters to be available. 1409 * Attribute list. Clients MAY restrict the list of attributes 1410 which are returned in searches, but are discouraged from 1411 doing so without cause. 1413 6.2. Matching Filter Definitions 1415 Each of the object classes defined in this document have their own 1416 search criteria which MUST be used whenever a collection of 1417 resource pools need to be searched. In this model, resource types 1418 are specified during the search operation, and most of the 1419 resource types have extensibleMatch definition which are used 1420 whenever the available resources need to be searched. 1422 For example, if a user wishes to find the inetIPv4network object 1423 class entry associated with a specific IPv4 address, then the 1424 inetIpv4NetworkMatch extensibleMatch filter MUST be specified by 1425 the client, and MUST be used by the server when attempting to 1426 locate the relevant inetIpv4Network entry. 1428 The inetResources object class can be searched with simple 1429 equalityMatch filters, and do not require dedicated 1430 extensibleMatch filters, although they do have specific handling 1431 rules. 1433 In order to ensure that all of the relevant entries (including any 1434 referrals) are found, the search filters for these resources MUST 1435 specify two distinct elements: the object class of the resource 1436 being queried, and the naming element of the resource specified as 1437 a distinguished name attribute. 1439 For example, using the notation format described in RFC 2254, the 1440 search filter expression for the inetOrgPerson entry associated 1441 with "cn=admins,ou=admins,dc=example,dc=com" would be structured 1442 as "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", using 1443 "ou=admins,dc=example,dc=com" as the search base. This would find 1444 all entries with the object class of inetOrgPerson (including all 1445 of the referral entries for inetOrgPerson entries) where the 1446 distinguished name contained the "cn" attribute of "admins". 1448 The input source and search base for these matches will vary 1449 according to the query being processed, but whenever an 1450 equalityMatch is called for during query processing, the above 1451 methods MUST be used in order to ensure that all of the related 1452 entries are located. 1454 Response entries MAY be fully-developed entries, or MAY be 1455 referrals generated from entries which have the referral object 1456 class defined. Any attribute values which are received MUST be 1457 displayed by the client. If a subordinate reference referral is 1458 received, the client MUST restart the query, using the provided 1459 data as the new search base. If any continuation reference 1460 referrals are received, the client SHOULD start new queries for 1461 each reference, and append the output of those queries to the 1462 original query's output. 1464 7. Query Processing Models 1466 The LDAP-WHOIS service uses three different query-processing 1467 models. These are the "top-down" model which initiates the query 1468 process at the top-level of a DNS delegation hierarchy, a "bottom- 1469 up" model which directs queries to user-managed servers, and a 1470 "targeted" search model which is functionally identical to 1471 traditional LDAP searches. Furthermore, any of these mechanisms 1472 may be redirected to other servers, either through simple DNS 1473 query processing, or by way of LDAP redirections (including 1474 subordinate reference referrals, continuation reference referrals, 1475 attribute references, or labeledURI attributes). 1477 Each of the three query models are appropriate to different usage 1478 environments. For example, the top-down model is best suited for 1479 searches about global resources which are centrally managed and 1480 delegated (such as IP addresses and DNS domains), and where 1481 delegation information is a critical element of the resource data. 1482 Meanwhile, the bottom-up model is most appropriate for those 1483 resources which are managed by the end-users directly, and which 1484 are not managed from a centralized delegation authority (this 1485 includes information such as private keys, mail servers, and other 1486 leaf-node resources). Finally, the targeted model is best suited 1487 for explicit queries where a particular resource is supposed to 1488 exist with a known DN (such as with contact pointers). 1490 LDAP-WHOIS clients and servers MUST implement all three models. 1491 Clients MUST default to using the top-down model, but clients MUST 1492 also provide a user-selectable option for the disposition of 1493 individual queries. 1495 7.1. Top-Down Processing 1497 The top-down model is primarily suited for locating Internet 1498 resources which are centrally managed and delegated. The top-down 1499 model is similar to other distributed WHOIS protocols in this 1500 regard, with the principle difference being the use of LDAP for 1501 standardized syntaxes, data and referrals, rather than using a 1502 specialized protocol specifically for this application. 1504 The top-down model uses an input string to construct an LDAP 1505 assertion value and search base, with DNS queries being used to 1506 locate the LDAP servers associated with the appropriate top-level 1507 delegation entity. Once this process completes, an extensible 1508 match query is issued to the specified servers. The query may also 1509 be redirected through the use of LDAP referrals, if additional 1510 data is known to exist elsewhere. 1512 For example, a top-down search for the domain name of 1513 "www.example.com" would result in the client building an 1514 inetDnsDomainMatch extensible match query with the search base of 1515 "cn=inetResources,dc=com", and with the client issuing a DNS query 1516 for the LDAP servers associated with "com" domain. If the queried 1517 server had information about the "www.example.com" resource, it 1518 would be returned as answer data. If the server knew of other 1519 sources of information about the resource (such as the registrar 1520 for the domain, or the entity operating the domain, or both), 1521 continuation reference referrals could be returned. Any of the 1522 subsequent queries could return additional answers and/or 1523 referrals, according to the data they had. 1525 IP address blocks and AS numbers are processed in a similar 1526 fashion. If a client needed to locate information about the 1527 "192.0.2.14/32" IPv4 address, it would begin the process by 1528 building a reverse-lookup DNS domain name from the input string, 1529 and then issuing a DNS query for the LDAP servers associated with 1530 the "arpa" top-level domain. Once a server had been located, an 1531 LDAP query with the assertion value of "192.0.2.14/32" would be 1532 submitted with a search base of "cn=inetResources,dc=arpa". The 1533 server would return data and/or referrals, with this process 1534 repeating until the query string had been completely processed. 1536 Note that entries for the inetResources and inetOrgPerson object 1537 classes are not searchable with this model, since they do not have 1538 centralized delegation authorities. One of the other search models 1539 MUST be used for those resource types. 1541 7.1.1. Processing steps 1543 The steps for processing top-down queries are described below: 1545 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 1547 b. Determine the authoritative domain name for the query. 1549 1. Separate the input string into discrete elements where 1550 this is possible. For a DNS domain name of 1551 "www.example.com", this would be "www", "example" and 1552 "com". For the IPv4 network number of "192.0.2.14", 1553 this would be "192", "0", "2" and "14". AS numbers 1554 only have a single value and require no separation. Do 1555 not discard the original query string. 1557 2. IP addresses and AS numbers require additional 1558 conversion. For IPv4 addresses, strip off the prefix 1559 and convert the input string into a reverse-lookup DNS 1560 domain name by reversing the order of the octets and 1561 appending "in-addr.arpa" to the right of the domain 1562 name. For IPv6 addresses, strip off the prefix and 1563 reverse the nibble order of the address (where each 1564 nibble is represented by a single hexadecimal 1565 character), and append "ip6.arpa". For AS numbers, 1566 append only the "arpa" domain name. 1568 c. Form the LDAP search base for the query. 1570 1. Convert the right-most element from the domain name 1571 formed in step 7.1.1.b above into a domainComponent DN 1572 (such as "dc=com" or "dc=arpa"). This represents the 1573 DIT for the current query. 1575 2. Append the "cn=inetResources" RDN to the front of the 1576 domainComponent syntax ("cn=inetResources,dc=com"). 1577 This will form the fully-qualified search base for the 1578 LDAP query. 1580 d. Locate the LDAP servers associated with the resource by 1581 processing the domain name formed in step 7.1.1.b above 1582 through the SRV query steps provided in section 7.4.5. 1584 e. If the SRV lookup succeeds: 1586 1. Choose the best LDAP server, using the weighting 1587 formula described in RFC 2782. 1589 2. Construct the LDAP search filter according to the 1590 rules specified in section 6.1, using the appropriate 1591 matching rule from section 6.2. 1593 3. Formulate the LDAP search using the search base and 1594 search filter constructed above. For example, if the 1595 input query string was for "www.example.com", then the 1596 client would begin the process by submitting an 1597 inetDnsDomainMatch extensibleMatch search with the 1598 assertion value of "www.example.com", and with a 1599 search base of "dc=inetResources,dc=com". Similarly, 1600 if the input query string was "192.0.2.14", then the 1601 client would begin the process by submitting an 1602 inetIpv4NetworkMatch extensibleMatch search with the 1603 assertion value of "192.0.2.14/32", and with the 1604 search base of "cn=inetResources,dc=arpa". 1606 4. Submit the search operation to the chosen server and 1607 port number. If the operation fails, report the 1608 failure to the user and exit. Otherwise, display any 1609 answer data which is returned. 1611 5. If the answer data contains a subordinate reference 1612 referral or a continuation reference referral, new 1613 query processes MUST be spawned. 1615 For subordinate reference referrals, process the URLs 1616 according to the rules described in section 7.4.1 and 1617 restart the query process at step 7.1.1.e.2. For each 1618 continuation reference referral, display the answer 1619 data received so far, process the LDAP URLs according 1620 to the rules described in section 7.4.3 and start new 1621 query processes for each referral at step 7.1.1.e.2, 1622 appending the output from these searches to the 1623 current output. 1625 Any additional subordinate reference referrals or 1626 continuation reference referrals which are encountered 1627 from any subsequent searches will need to be processed 1628 in the same manner as specified above, until no 1629 additional referrals are received. 1631 f. If the SRV lookup fails (where failure is defined as any 1632 DNS response message other than an answer), report the 1633 failure to the user and exit the current search operation. 1635 7.1.2. Top-Down example 1637 In the example below, the user has entered a search string of 1638 "www.example.com" and has indicated that the query is for a DNS 1639 domain name. 1641 a. The input string is broken into the discrete label 1642 components ("www", "example" and "com"). 1644 b. The right-most label ("com") is used to form the DNS SRV 1645 lookup ("_ldap._tcp.com"), in order to find the LDAP 1646 servers authoritative for the delegation hierarchy. 1648 c. One of the LDAP servers is contacted, and an 1649 inetDnsDomainMatch search filter is submitted with the 1650 assertion value of "www.example.com" and a search base of 1651 "cn=inetResources,dc=com". 1653 d. The server responds with a continuation reference referral 1654 URL of "ldap://ldap.netsol.com/cn=example.com, 1655 cn=inetResources,dc=netsol,dc=com", indicating that the 1656 domain delegation is managed under the "dc=netsol,dc=com" 1657 DIT, and is hosted at the "ldap.netsol.com" server. The 1658 client uses this information to start a new query. No 1659 additional data was provided for the client to display. 1661 e. An inetDnsDomainMatch extensibleMatch search is submitted 1662 to "ldap.netsol.com", using the search base of 1663 "cn=example.com,cn=inetResources,dc=netsol,dc=com". 1665 f. The queried server returns the information that it has. No 1666 additional referrals are provided. The client displays the 1667 data and exits the query. 1669 7.2. Bottom-Up Processing 1671 The bottom-up model is best used when a leaf-node resource needs 1672 to be queried, and where an LDAP-WHOIS server is expected to be 1673 able to answer the query. In this case, navigating down through a 1674 delegation hierarchy would be either fruitless or inefficient. For 1675 example, information about a mail domain would be more efficient 1676 in the bottom-up model, since there is no global delegation body 1677 for Internet mail (the DNS domains are delegated, but the message 1678 routing is specific to the operational entities responsible for 1679 the domain name). The bottom-up model can also be used for DNS 1680 domain names, IPv4 addresses, and IPv6 addresses, although this 1681 will generally prove to be less useful than top-down queries, 1682 given the limited number of user-managed servers deployed. 1684 The bottom-up model uses an input string to construct an LDAP 1685 assertion value and search base, with DNS queries being used to 1686 locate the LDAP servers which are associated with the management 1687 entity that is directly responsible for the resource in question. 1688 Once this process completes, an extensible match query is issued 1689 to the specified servers. The query may also be redirected through 1690 the use of LDAP referrals, if additional data is known to exist 1691 elsewhere. 1693 For example, a bottom-up search for the domain name of 1694 "www.example.com" would result in the client building an 1695 inetDnsDomainMatch extensible match query with the search base of 1696 "cn=inetResources,dc=www,dc=example,dc=com", and with the client 1697 issuing a DNS query for the LDAP servers associated with 1698 "www.example.com" domain. If the DNS lookup failed, the client 1699 would issue a subsequent query for the LDAP servers associated 1700 with the "example.com" domain, and so forth, until a server had 1701 been located. If the queried server had information about the 1702 "www.example.com" resource, it would be returned as answer data. 1703 If the server knew of other sources of information about the 1704 resource (such as the registrar for the domain, or the entity 1705 operating the domain, or both), continuation reference referrals 1706 could be returned. Any of the subsequent queries could return 1707 additional answers and/or referrals, according to the data they 1708 had. 1710 IP address blocks are processed in a similar fashion. If a client 1711 needed to locate information about the "192.0.2.14" IPv4 address, 1712 it would begin by issuing a DNS query for the LDAP servers 1713 responsible for the "14.2.0.192.in-addr.arpa" domain name, with 1714 the left-most labels being truncated as the search for an 1715 authoritative server was broadened. Once a server had been 1716 located, an inetIpv4NetworkMatch extensibleMatch search with the 1717 assertion value of "192.0.2.14/32" would be submitted. If the 1718 server knew of any information about that resource, it would 1719 return data or a referral, with this process repeating until the 1720 query string had been processed as completely as possible. 1722 Note that entries for inetAsNumber and inetOrgPerson object 1723 classes are not searchable with this model, since they are not 1724 represented in the DNS delegation hierarchy. One of the other 1725 search models MUST be used for those resource types. 1727 7.2.1. Processing steps 1729 The steps for processing bottom-up queries are described below: 1731 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 1733 b. Determine the authoritative DNS domain for the resource. 1735 1. Separate the input string into discrete elements where 1736 this is possible. For a DNS domain name of 1737 "www.example.com", this would be "www", "example" and 1738 "com". For the IPv4 network number of "192.0.2.14", 1739 this would be "192", "0", "2" and "14". Do not discard 1740 the original query string. 1742 2. IP addresses require additional conversion. For IPv4 1743 addresses, strip off the prefix and convert the input 1744 string into a reverse-lookup DNS domain name by 1745 reversing the order of the octets and appending 1746 "in-addr.arpa" to the right of the resulting sequence. 1747 For IPv6 addresses, strip off the prefix and reverse 1748 the nibble order of the address (where each nibble is 1749 represented by a single hexadecimal character), and 1750 append "ip6.arpa" to the right of the resulting 1751 sequence. 1753 c. Form the LDAP search base for the query. 1755 1. Convert the domain name formed in step 7.2.1.b above 1756 into a domainComponent DN (such as 1757 "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, 1758 dc=in-addr,dc=arpa"). This represents the DIT for the 1759 current query. 1761 2. Append the "cn=inetResources" RDN to the left of the 1762 domainComponent syntax (perhaps resulting in 1763 "cn=inetResources,dc=www,dc=example,dc=com"). This 1764 will become the search base for the LDAP query. 1766 d. Locate the LDAP servers associated with the resource by 1767 processing the domain name formed in step 7.2.1.b above 1768 through the SRV query steps provided in section 7.4.5. 1770 e. If the SRV lookup fails with an NXDOMAIN response code (as 1771 described in RFC 2308), then the domain name used for the 1772 SRV lookup does not exist, and a substitute LDAP server and 1773 search base must be identified. This process involves 1774 determining the parent zone for the domain name in 1775 question, issuing an SRV lookup for that zone, and using 1776 the domain name of the zone as the new LDAP search base, 1777 with this process repeating until a search base can be 1778 located, or until a critical failure forces an exit. 1780 1. Remove the left-most label from the domain name formed 1781 in step 7.2.1.b. 1783 2. If this process has already resulted in a query domain 1784 name at a top-level domain such as "com" or "arpa", 1785 convert the query domain name to "." (to signify the 1786 root domain). 1788 3. If the queried domain name is already set to ".", the 1789 query can go no higher (this most likely indicates a 1790 malformed DNS configuration, a connectivity problem, 1791 or a typo in the query). Exit and report the failure 1792 to the user. 1794 4. Restart the process at step 7.1.1.c, using the domain 1795 name formed above. Repeat until a server is located or 1796 a critical failure forces an exit. 1798 For example, if the original input string of 1799 "www.example.com" resulted in a failed SRV lookup for 1800 "_ldap._tcp.www.example.com", then the first fallback 1801 SRV query would be for "_ldap._tcp.example.com", and 1802 the next fallback query would be for "_ldap._tcp.com", 1803 possibly being followed by "_ldap._tcp.", and possibly 1804 resulting in failure after that. 1806 f. If the SRV lookup succeeds: 1808 1. Choose the best LDAP server, using the weighting 1809 formula described in RFC 2782. 1811 2. Construct the LDAP search filter according to the 1812 rules specified in section 6.1, and choose the 1813 appropriate matching rule from section 6.2. 1815 3. Formulate the LDAP search using the search base and 1816 search filter constructed above. For example, if the 1817 input query string was for "www.example.com", then the 1818 client would begin the process by submitting an 1819 inetDnsDomainMatch extensibleMatch search with the 1820 assertion value of "www.example.com", with the search 1821 base of "cn=inetResources,dc=www,dc=example,dc=com". 1823 4. Submit the search operation to the chosen server and 1824 port number. If the operation fails, report the 1825 failure to the user and exit. Otherwise, display any 1826 answer data which is returned. 1828 5. If the answer data contains a subordinate reference 1829 referral or a continuation reference referral, new 1830 query processes MUST be spawned. 1832 For subordinate reference referrals, process the URLs 1833 according to the rules described in section 7.4.1 and 1834 restart the query process at step 7.2.1.f.2. For each 1835 continuation reference referral, display the answer 1836 data received so far, process the LDAP URLs according 1837 to the rules described in section 7.4.3 and start new 1838 query processes for each referral at step 7.2.1.f.2, 1839 appending the output from these searches to the 1840 current output. 1842 Any additional subordinate reference referrals or 1843 continuation reference referrals which are encountered 1844 from any subsequent queries will need to be processed 1845 in the same manner as specified above, until no 1846 additional referrals are received. 1848 g. If a fatal DNS error condition occurs, report the error to 1849 the user and stop processing the current query. A fatal DNS 1850 error is any response message with an RCODE of FORMERR, 1851 SERVFAIL, NOTIMPL, or REFUSED, or where a query results in 1852 NODATA (implying that an "_ldap._tcp" domain name exists 1853 but it doesn't have an SRV resource record associated with 1854 it, which is most likely a configuration error). 1856 7.2.2. Bottom-Up example 1858 In the example below, the user has entered a search string of 1859 "www.example.com" and has indicated that the query is for a DNS 1860 Domain Name. 1862 a. The query string is used to form the DNS SRV lookup 1863 ("_ldap._tcp.www.example.com"), in order to find the LDAP 1864 servers authoritative for that domain name. 1866 b. The SRV lookup fails with NXDOMAIN, indicating that the 1867 queried domain name does not exist. 1869 c. The client creates a new query for the parent domain 1870 ("_ldap._tcp.example.com"), which succeeds. 1872 d. The client contacts one of the servers, and issues an 1873 inetDnsDomainMatch extensibleMatch search with the 1874 assertion value of "www.example.com", and with the search 1875 base of "cn=inetResources,dc=example,dc=com". 1877 e. The server returns a continuation reference referral of 1878 "ldap://ldap.example.net/cn=server1.example.net, 1879 cn=inetResources,dc=example,dc=net", indicating that the 1880 queried resource is a referral for a web hosting server at 1881 Example Networks. The client uses this information to start 1882 a new query. No additional data was provided for the client 1883 to display. 1885 f. An inetDnsDomainMatch extensibleMatch search is submitted 1886 to the "ldap.example.net" server, using the search base of 1887 "cn=server1.example.net,cn=inetResources,dc=example,dc=net" 1889 g. The queried server returns the information that it has. No 1890 additional referrals are provided. The client displays the 1891 data and exits the query. 1893 7.3. Targeted Search Processing 1895 The targeted search model is similar to the bottom-up query model 1896 described in the preceding section, except that it does not 1897 provide fallback processing of DNS domain names. In this regard, 1898 the targeted search model is closely similar to the traditional 1899 LDAP searching model, in that a client queries a specified LDAP 1900 server for a specific entry, under the assumption that the 1901 resource exists at that location. If the server or resource does 1902 not exist, the entire query fails. 1904 For this reason, the targeted search model is not suitable for 1905 search operations against generic Internet resources, but instead 1906 is mostly suitable for searches against known entries which are 1907 presumed to exist at a known location. In terms of the LDAP-WHOIS 1908 service in particular, this includes inetOrgPerson entries which 1909 are provided in contact-related attributes. However, the targeted 1910 search model can be used for any resource type, and it can be 1911 useful for diagnosing problems with resource types. For this 1912 reason, clients SHOULD support this model for use with all known 1913 resource types. 1915 The targeted search takes an LDAP URL as the query input (along 1916 with the resource-type identifier), and uses the URL to determine 1917 the query server, the search base, and the assertion value. 1919 7.3.1. Processing steps 1921 The steps for processing targeted search queries are described 1922 below: 1924 a. Process the LDAP URLs according to the continuation 1925 reference referral handling rules described in section 1926 7.4.3. This process will determine the servers, search base 1927 and assertion value of the query. 1929 b. If this process succeeds: 1931 1. Construct the LDAP search filter according to the 1932 rules specified in section 6.1, and choose the 1933 appropriate matching rule from section 6.2. 1935 2. Submit the search operation to the chosen server and 1936 port number. If the operation fails, report the 1937 failure to the user and exit. Otherwise, display any 1938 answer data which is returned. 1940 3. If the answer data contains a subordinate reference 1941 referral or a continuation reference referral, new 1942 query processes MUST be spawned. 1944 For subordinate reference referrals, process the URLs 1945 according to the rules described in section 7.4.1 and 1946 restart the query process at step 7.3.1.b. For each 1947 continuation reference referral, display the answer 1948 data received so far, process the LDAP URLs according 1949 to the rules described in section 7.4.3 and start new 1950 query processes for each referral at step 7.3.1.b. 1952 Any additional subordinate reference referrals or 1953 continuation reference referrals which are encountered 1954 from any subsequent queries will need to be processed 1955 in the same manner as specified above, until no 1956 additional referrals are received. 1958 c. If this process fails, report the failure to the user and 1959 exit the current search operation. 1961 7.3.2. Targeted search example 1963 In the example below, the user has provided an LDAP URL of 1964 "ldap://ldap.example.com/cn=admins,ou=admins,dc=example,dc=com", 1965 and has indicated that the query is for an inetOrgPerson entry. 1967 a. The query string is used to form a DNS lookup of the 1968 specified server ("ldap.example.com"). 1970 b. The client contacts the servers, and issues a search for 1971 "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", with a 1972 search base of "ou=admins,dc=example,dc=com". 1974 c. The queried server returns the information that it has. No 1975 additional referrals are provided. The client displays the 1976 data and exits the query. 1978 7.4. Supplemental Query Processing Mechanisms 1980 During the course of normal query processing, an LDAP-WHOIS client 1981 may need to use additional mechanisms to complete an operation, 1982 such as processing a URL received from a redirect operation, or 1983 issuing DNS SRV lookups against a provided domain name. 1985 7.4.1. URL processing 1987 URL processing in this specification is a function of both content 1988 and context. Different attributes and result codes provide 1989 different types of URLs, and the disposition of these URLs will 1990 depend on the query-resolution process currently being executed. 1992 On the content front, this specification allows three different 1993 forms of URLs to appear throughout this service: labeledURI 1994 attribute values, attribute references, and referral messages. 1995 Each of these usage scenarios have slightly different restrictions 1996 and formats. 1998 * The labeledURI attribute is included with the inetResources 1999 object class for the purpose of informing end-users of a 2000 generic resource associated with an entry (such as an 2001 organization's home page). The labeledURI attribute is 2002 defined in RFC 2079 for the purpose of storing generic URLs 2003 as attribute values, and uses a two-part syntax of 2004 "url://any.host:port/any/path description", with the 2005 "description" string providing a free-text description of 2006 the target specified by the URL. 2008 * Attribute references also use the two-part format of the 2009 labeledURI attribute, but with some additional restrictions 2010 as described in section 4.5 of this document. 2012 * Subordinate and continuation reference referrals use URLs 2013 for the purpose of providing referral targets. The URL 2014 format specified in [namedref] is also an explicit subset 2015 of the labeledURI format, but without the "description" 2016 free-text block. When used with the LDAP-WHOIS service, 2017 subordinate and continuation referrals are subject to some 2018 additional rules as described in section 4.5 of this 2019 document. 2021 Non-compliance with the requirements provided in section 4.5 2022 amounts to an error, and is sufficient cause for a client to stop 2023 processing a query. 2025 7.4.2. Subordinate reference referrals 2027 Subordinate reference referrals and their schema are defined in 2028 [namedref]. Subordinate reference referrals use the 2029 SearchResultDone response with a Referral result code, which is 2030 defined and described in section 4.1.11 of RFC 2251. Subordinate 2031 reference referrals use a subset of the labeledURI syntax as 2032 defined in RFC 2079, and use the syntax definitions from RFC 2255 2033 when LDAP URLs in particular are provided, although section 4.5 of 2034 this document also defines additional restrictions on the 2035 allowable URL syntax. 2037 In the context of the LDAP-WHOIS service, subordinate reference 2038 referrals are returned when the search base specified in a search 2039 operation exists as a referral object class with the ref attribute 2040 pointing to some other entry, resulting in queries with that 2041 search base being answered with a SearchResultDone referral 2042 response. This condition means that the current search operation 2043 cannot proceed past this point, and the search MUST be restarted. 2044 This will most often occur when the inetResources entry for a DIT 2045 has been redirected to another DIT, but it can also happen after 2046 continuation reference referrals have been followed or after 2047 targeted searches have been issued, and where the queried entry 2048 exists as a referral to some other entry. 2050 The procedure for processing URLs returned in a subordinate 2051 reference referral is as follows: 2053 a. RFC 2251 allows multiple URLs to be provided, although the 2054 URLs are not provided with any "preference" or "weighting" 2055 values. If a set of URLs are provided, only one of the URLs 2056 need to be tried (implementations MAY perform additional 2057 queries in an attempt to recover from temporary failures, 2058 although this is not required). Select one of the URLs at 2059 random ("round-robin"), and continue to the next step in 2060 the process. 2062 b. Extract and discard any description text which may have 2063 been provided with the URL. 2065 c. Validate the protocol label. This specification only 2066 supports the use of the LDAP service type. URLs with other 2067 protocol identifiers are to be treated as malformed. 2069 d. Extract the host identifier element and perform any DNS 2070 lookups which may be required. URLs without host 2071 identifiers are to be treated as malformed. 2073 e. Extract the port number provided with the URL, and set it 2074 aside for use with the subsequent connection attempt. If no 2075 port number has been provided in the URL, use the default 2076 port numbers associated with the protocol, as discovered in 2077 step 7.4.2.c. 2079 f. Extract the path element from the URL for use as the search 2080 base of the subsequent search operation. URLs without path 2081 elements are to be treated as malformed. 2083 g. Restart the current search operation, using the LDAP server 2084 from step 7.4.2.d, the port number from step 7.4.2.e, and 2085 the search base formed in step 7.4.2.f. 2087 7.4.3. Continuation reference referrals 2089 Continuation reference referrals and their schema are defined in 2090 [namedref]. Continuation reference referrals use the 2091 SearchResultReference response, which is defined and described in 2092 section 4.5.3 of RFC 2251. Continuation reference referrals use a 2093 subset of the labeledURI syntax as defined in RFC 2079, and use 2094 the syntax definitions from RFC 2255 when LDAP URLs in particular 2095 are to be provided, although section 4.5 of this document also 2096 defines additional restrictions on the allowable URL syntax. 2098 For this service, continuation reference referrals are returned 2099 when the search base specified in a search operation exists, but 2100 one or more of the answer elements exist as referral object 2101 classes, resulting in one or more SearchResultReference responses. 2102 This condition means that the current search operation has 2103 partially succeeded, but that additional searches SHOULD be 2104 started in order for all of the answer data to be retrieved (in 2105 many cases, no answer data will be provided, and in those 2106 situations, new queries will be required for any data to be 2107 retrieved). This will occur whenever the assertion value of a 2108 search has matched a resource entry which is being managed by 2109 another DIT, and can occur with any of the search operations 2110 described in this document. 2112 Multiple continuation reference referrals MAY be returned in 2113 response to a search, and each of them MUST be processed in order 2114 for all of the answer data to be retrieved. 2116 The procedure for processing the URLs returned in a continuation 2117 reference referral is as follows: 2119 a. RFC 2251 allows multiple URLs to be provided, although the 2120 URLs are not provided with any "preference" or "weighting" 2121 values. If a set of URLs are provided, only one of the URLs 2122 need to be tried (implementations MAY perform additional 2123 queries in an attempt to recover from temporary failures, 2124 although this is not required). Select one of the URLs at 2125 random ("round-robin"), and continue to the next step in 2126 the process. 2128 b. Extract and discard any description text which may have 2129 been provided with the URL. 2131 c. Validate the protocol label. This specification only 2132 supports the use of the LDAP service types. URLs with other 2133 protocol identifiers are to be treated as malformed. 2135 d. Extract the host identifier element and perform any DNS 2136 lookups which may be required. URLs without host 2137 identifiers are to be treated as malformed. 2139 e. Extract the port number provided with the URL, and set it 2140 aside for use with the subsequent connection attempt. If no 2141 port number has been provided in the URL, use the default 2142 port numbers associated with the protocol, as discovered in 2143 step 7.4.3.c. 2145 f. Extract the path element from the URL for use as the search 2146 base of the subsequent search operation. URLs without path 2147 elements are to be treated as malformed. 2149 g. Extract the left-most RDN from the search base constructed 2150 in step 7.4.3.e, and delete the naming attribute label. The 2151 resulting string will be used as the assertion value for 2152 the subsequent search operation. For example, if the path 2153 element from a URL provided a distinguished name of 2154 "cn=example.com,cn=inetResources,dc=example,dc=com", then 2155 the "cn=example.com" RDN would be used to form an assertion 2156 value of "example.com". 2158 h. Start a new search operation, using the LDAP server from 2159 step 7.4.3.d, the port number from step 7.4.3.e, the search 2160 base formed in step 7.4.3.f, and the assertion value formed 2161 in step 7.4.3.g. 2163 7.4.4. Attribute references 2165 Attribute references are defined in this document as attributes 2166 which provide URLs as pointers to contextually related 2167 information. These are not referrals, but instead are simple URLs 2168 returned as attribute values. In particular, this document defines 2169 multiple contact-related attributes which provide these URLs. 2170 Other documents may also define attributes which reuse the URL 2171 format defined here, or may define their own URL rules, as needed. 2173 For this service, attribute reference URLs are returned when an 2174 entry has an attribute defined which uses them. Attribute 2175 references are not referrals, and do not require additional 2176 processing. Clients MAY automatically start new search operations 2177 when an attribute reference is encountered, or they MAY delay 2178 processing until a user requests the action. 2180 The procedure for processing the URLs returned in an attribute 2181 reference is as follows: 2183 a. RFC 2251 allows multiple URLs to be provided, although the 2184 URLs are not provided with any "preference" or "weighting" 2185 values. If a set of URLs are provided, only one of the URLs 2186 need to be tried (implementations MAY perform additional 2187 queries in an attempt to recover from temporary failures, 2188 although this is not required). Select one of the URLs at 2189 random ("round-robin"), and continue to the next step in 2190 the process. 2192 b. Extract and discard any description text which may have 2193 been provided with the URL. 2195 c. Validate the protocol label. This specification only 2196 supports the use of LDAP service types. URLs with other 2197 protocol identifiers are to be treated as malformed. 2199 d. Extract the host identifier element and perform any DNS 2200 lookups which may be required. URLs without host 2201 identifiers are to be treated as malformed. 2203 e. Extract the port number provided with the URL, and set it 2204 aside for use with the subsequent connection attempt. If no 2205 port number has been provided in the URL, use the default 2206 port numbers associated with the protocol, as discovered in 2207 step 7.4.4.c. 2209 f. Extract the path element from the URL for use as the search 2210 base of the subsequent search operation. URLs without path 2211 elements are to be treated as malformed. 2213 g. Extract the left-most RDN from the search base constructed 2214 in step 7.4.4.e, and delete the naming attribute label. The 2215 resulting string will be used as the assertion value for 2216 the subsequent search operation. For example, if the path 2217 element from a URL provided a distinguished name of 2218 "cn=example.com,cn=inetResources,dc=example,dc=com", then 2219 the "cn=example.com" RDN would be used to form an assertion 2220 value of "example.com". 2222 h. Determine the object class filter to be used with the 2223 assertion value. This will depend on the attribute which 2224 provided the attribute reference. The contact-related 2225 attributes defined in this document refer to inetOrgPerson 2226 object class entries. 2228 i. Start a new search operation, using the LDAP server from 2229 step 7.4.4.d, the port number from step 7.4.4.e, the search 2230 base formed in step 7.4.4.f, the assertion value formed in 2231 step 7.4.4.g, and the new object class filter formed in 2232 step 7.4.4.h. 2234 7.4.5. SRV processing 2236 The query models described in this document make use of DNS SRV 2237 resource records whenever a new query process is started, as a way 2238 to locate the LDAP servers associated with a DIT. 2240 The procedure for constructing this SRV lookup is as follows: 2242 a. Construct an SRV-specific label pair for the service type. 2243 For LDAP queries, this will be "_ldap._tcp". 2245 b. Append the SRV label pair to the left of the input domain 2246 name. In the case of an LDAP query for "example.com", this 2247 would result in an SRV-specific domain name of 2248 "_ldap._tcp.example.com". 2250 c. Issue a DNS query for the SRV resource records associated 2251 with the domain name formed in step 7.4.5.b. 2253 Multiple SRV resource records may be returned in response to a 2254 query. Each resource record identifies a different connection 2255 target, including the domain name of a server, and a port number 2256 for that server. The port number specified in a SRV resource 2257 record MUST be used for any subsequent bind and search operations. 2259 SRV resource records provide "priority" and "weight" values which 2260 MUST be used to determine the preferred server. If a server is 2261 unavailable or unreachable, a connection attempt must be made to 2262 the next-best server in the answer set. 2264 Refer to RFC 2782 for a detailed explanation of SRV resource 2265 records and their handling. 2267 8. Internationalization and Localization 2269 The LDAP-WHOIS model uses the internationalization and 2270 localization services provided by LDAPv3. In this regard, LDAP- 2271 WHOIS clients do not need to implement any special services in 2272 order to process and display internationalized attribute data, 2273 since the attribute types already provide direct support for 2274 internationalized data. 2276 LDAP-WHOIS clients may have some localization or language-specific 2277 presentation issues with regards to attribute names, in that the 2278 names of the attributes may need to be localized for specific 2279 markets. However, these services are outside the scope of the 2280 protocol operations. Any such requirements must be dealt with 2281 according to the services available on the client platform. 2283 In the case of legacy WHOIS servers which gateway requests between 2284 TCP port 43 and the LDAP-WHOIS service, the input and output 2285 language and/or locale codes MAY be specified by server-specific 2286 options, although these mechanisms must be defined as part of the 2287 WHOIS protocol for any widespread consistency to be possible, and 2288 are therefore beyond the scope of this document. 2290 9. DIT Replication 2292 All DITs which provide data for global Internet resources SHOULD 2293 be replicated across two or more servers. Each of the 2294 authoritative LDAP servers for the managed resource MUST be 2295 specified with a unique DNS SRV resource record for the domain 2296 name associated with the top-level resource assignment space. 2298 For example, the top-level "com" delegation space SHOULD have two 2299 or more SRV resource records associated with the "_ldap._tcp.com" 2300 domain name, with each entry referring to separate LDAP servers, 2301 and with each of those servers maintaining accurate copies of the 2302 "dc=com" DIT (within reasonable timeliness). Similarly, the top- 2303 level " arpa" domain which is used by the IPv4 and IPv6 delegation 2304 trees SHOULD provide two or more SRV resource records for the 2305 "_ldap._tcp.arpa" domain name, as should the "in-addr.arpa" and 2306 "ip6.arpa" domain hierarchies. 2308 DITs which serve multiple organizations SHOULD also be replicated. 2309 For example, an ISP which provides LDAP-WHOIS services for their 2310 customers SHOULD also follow these same rules, since outages of 2311 those servers will affect multiple parties. Leaf-node DITs 2312 associated with an user-managed resource MAY be replicated, and 2313 are encouraged to do so. 2315 Similarly, any referrals which present URLs as answer data SHOULD 2316 provide multiple URLs, each of which reference different hosts on 2317 different networks. For leaf-node referrals, attribute references, 2318 and labeledURI references, this behavior MAY be relaxed, although 2319 it is still encouraged. 2321 Note that the most effective replication strategy will be for 2322 entities to replicate their DITs with the delegation parents, as 2323 this will allow queries for those resources to be processed by the 2324 parent servers (thereby eliminating the need for referral 2325 queries). In many cases, this will not be feasible (the servers 2326 for the "dc=com" DIT cannot be expected to host replicas of every 2327 subordinate DIT), but it is encouraged where practical. 2329 10. Transition Issues 2331 There are a handful of areas where the proposed service does not 2332 fully match with all of the existing WHOIS service offerings. 2333 These areas are discussed in more detail below. 2335 10.1. NIC Handles 2337 NIC handles represent a historical method of WHOIS lookups, tying 2338 unique identifiers to a specific record in a specific database. 2339 Given that the model proposed in this document uses a distributed 2340 lookup system rather than isolated databases, the NIC handle model 2341 is no longer necessary. Furthermore, given the limited global 2342 usability of NIC handles, they should be deprecated. 2344 However, NIC handles are an important part of the legacy service, 2345 and their continued usage is likely to be desired in at least some 2346 instances. There are two possible workarounds for this problem: 2348 * NIC handle output in legacy WHOIS systems SHOULD be replaced 2349 with an LDAP URL for the contact entries. This option 2350 facilitates faster coalescence around the LDAP-WHOIS system. 2352 * Referral entries MAY be defined for each existing NIC handle 2353 if the explicit NIC handle is still required for an 2354 application or usage, and queries for NIC handles MAY be 2355 processed through these referral entries. For example, the 2356 NIC handle of EH26 on Network Solutions' WHOIS server can be 2357 represented as "cn=EH26,cn=inetResources,dc=netsol,dc=com", 2358 with the inetOrgPerson and referral object classes defined, 2359 and with the ref attribute value pointing to an entry named 2360 "cn=Eric A. Hall,cn=inetResources,dc=ntrg,dc=com". 2362 Of the two mechanisms described above, the former is preferred. 2364 10.2. Change-Logs 2366 Several WHOIS services provide pseudo change-logs in their 2367 response data, listing each unique modification event which has 2368 occurred for a particular resource. For example, RIPE and some of 2369 its member ccTLDs provide WHOIS output which includes a series of 2370 "changed" fields that itemize every modification event ("updated", 2371 "added", etc.), the modifier, and the modification date, which 2372 cumulatively act as a change-log for the resource in question. 2374 While this service is useful and informative to the delegating 2375 bodies, this information is not as useful to external entities. 2376 Furthermore, the principle use of this information is for the 2377 purpose of internal audits, rather than external information. 2378 Finally, a subset of this kind of information is already provided 2379 in the *modified* operational attributes, which are always 2380 available for public review. 2382 Organizations are certainly free to maintain this information on 2383 their internal systems (and are even encouraged to do so). 2384 However, this information is not necessary for public view of the 2385 data in the LDAP-WHOIS service. Where the auditing information 2386 will be required, a format which is more suitable to legal review 2387 will be required and more appropriate. 2389 For these reasons, this service is not supported in the LDAP-WHOIS 2390 service. However, if this information is absolutely required, 2391 implementers MAY provide it as additional unstructured data via 2392 the inetGeneralComments attribute (perhaps using an 2393 "event:modifier:date" format). 2395 10.3. Open Issues 2397 The following issues require additional analysis: 2399 * inetIpv6Network and other entries will likely benefit from 2400 certificate-related data, although the extent and nature of 2401 this information (minimum requirements, preferred 2402 attributes, pre-existing schema, etcetera) is currently 2403 unknown. 2405 * The RIPE database v3 has several additional attributes: 2406 domain: [mandatory] [single] [primary/look-up key] 2407 descr: [mandatory] [multiple] [ ] 2408 admin-c: [mandatory] [multiple] [inverse key] 2409 tech-c: [mandatory] [multiple] [inverse key] 2410 zone-c: [mandatory] [multiple] [inverse key] 2411 nserver: [optional] [multiple] [inverse key] 2412 sub-dom: [optional] [multiple] [inverse key] 2413 dom-net: [optional] [multiple] [ ] 2414 remarks: [optional] [multiple] [ ] 2415 notify: [optional] [multiple] [inverse key] 2416 mnt-by: [optional] [multiple] [inverse key] 2417 mnt-lower: [optional] [multiple] [inverse key] 2418 refer: [optional] [single] [ ] 2419 changed: [mandatory] [multiple] [ ] 2420 source: [mandatory] [single] [ ] 2421 see http://www.ripe.net/ripe/docs/databaseref-manual.html 2423 11. Security Considerations 2425 This document describes an application of the LDAPv3 protocol, and 2426 as such it inherits the security considerations associated with 2427 LDAPv3, as described in section 7 of RFC 2251. 2429 By nature, LDAP is a read-write protocol, while the legacy WHOIS 2430 service has always been a read-only service. As such, there are 2431 significant risks associated with allowing unintended updates by 2432 unauthorized third-parties. Moreover, allowing the LDAP-WHOIS 2433 service to update the underlying delegation databases could result 2434 in network resources being stolen from their lawful operators. For 2435 example, if the LDAP front-end had update access to a domain 2436 delegation database, a malicious third-party could theoretically 2437 take ownership of that domain by exploiting an authentication 2438 weakness, thereby causing ownership of the domain to be changed to 2439 another party. For this reason, it is imperative that the LDAP- 2440 WHOIS service not be allowed to make critical modifications to 2441 delegated resources without ensuring that all possible precautions 2442 have been taken. 2444 The query processing models described in this document make use of 2445 DNS lookups in order to locate the LDAP servers associated with a 2446 particular resource. DNS is susceptible to certain attacks and 2447 forgeries which may be used to redirect clients to LDAP servers 2448 which are not authoritative for the resource in question. 2450 Some operators may choose to purposefully provide misleading or 2451 erroneous information in an effort to avoid responsibility for bad 2452 behavior. In addition, there are likely to be sporadic operator 2453 errors which will result in confusing or erroneous answers. 2455 This document provides multiple query models which will cause the 2456 same query to be answered by different servers (one would be 2457 processed by a delegation entity, while another would be processed 2458 by an operational entity). As a result, each of the servers may 2459 provide different information, depending upon the query type that 2460 was originally selected. 2462 For all of the reasons listed above, it is essential that 2463 applications and end-users not make critical decisions based on 2464 the information provided by the LDAP-WHOIS service without having 2465 reason to believe the veracity of the information. Users should 2466 limit unknown or untrusted information to routine purposes. 2468 Finally, there are physical security issues associated with any 2469 service which provides physical addressing and delivery 2470 information. Although organizations are generally encouraged to 2471 provide as much information as they feel comfortable with, no 2472 information is required. 2474 12. IANA Considerations 2476 This document defines an application of the LDAPv3 protocol rather 2477 than a new Internet application protocol. As such, there are no 2478 protocol-related IANA considerations. 2480 However, this document does define several LDAP schema elements, 2481 including object classes, attributes, syntaxes and extensibleMatch 2482 filters, and these elements should be assigned OID values from the 2483 IANA branch, rather than being assigned from a particular 2484 enterprise branch. 2486 Furthermore, this document defines delegation status codes for 2487 four of the resource types described herein, and IANA is expected 2488 to maintain the code-point mapping values associated with these 2489 attribute values. Each resource type may develop its own peculiar 2490 status codes, so each of the mapping tables will need to be 2491 maintained independently. 2493 Finally, this document also describes several instances where 2494 public DNS and LDAP servers are queried. It is expected that IANA 2495 will establish and maintain these LDAP servers (and the necessary 2496 DNS SRV domain names and resource records) required for this 2497 service to operate. This includes providing SRV resource records 2498 in the generic TLDs and the root domain, and also includes 2499 administering the referenced LDAP servers. 2501 13. Author's Addresses 2503 Eric A. Hall 2504 ehall@ehsco.com 2506 14. References 2508 RFC 1274 - The COSINE and Internet X.500 Schema 2510 RFC 2079 - Definition of an X.500 Attribute Type and an 2511 Object Class to Hold Uniform Resource Identifiers (URIs) 2513 RFC 2247 - Using Domains in LDAP/X.500 DNs 2515 RFC 2251 - Lightweight Directory Access Protocol (v3) 2517 RFC 2252 - Lightweight Directory Access Protocol (v3): 2518 Attribute Syntax Definitions. 2520 RFC 2253 - Lightweight Directory Access Protocol (v3): 2521 UTF-8 String Representation of DNs 2523 RFC 2254 - The String Representation of LDAP Search Filters 2525 RFC 2255 - The LDAP URL Format 2526 RFC 2256 - A Summary of the X.500(96) User Schema for use 2527 with LDAPv3 2529 RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) 2531 RFC 2782 - A DNS RR for specifying the location of services 2532 (DNS SRV) 2534 RFC 2798 - Definition of the inetOrgPerson LDAP Object 2535 Class 2537 RFC 2849 - The LDAP Data Interchange Format (LDIF) - 2538 Technical Specification 2540 [namedref] - - Named 2541 Subordinate References in LDAP Directories 2543 [ir-dir-req] - - 2544 Internet Registry Directory Requirements 2546 [ldap-whois-dns] - - 2547 Defining and Locating DNS Domains using the Internet 2548 Resource Query Service 2550 [ldap-whois-ipv4] - - 2551 Defining and Locating IPv4 Address Blocks using the 2552 Internet Resource Query Service 2554 [ldap-whois-ipv6] - - 2555 Defining and Locating IPv6 Address Blocks using the 2556 Internet Resource Query Service 2558 [ldap-whois-asn] - - 2559 Defining and Locating Autonomous System Numbers using the 2560 Internet Resource Query Service 2562 [ldap-whois-user] - - 2563 Defining and Locating Contact Persons using the Internet 2564 Resource Query Service 2566 On a related note, VeriSign has been working on an RLDAP project 2567 [described in draft-newton-ldap-whois-00.txt (Whois Domain Data in 2568 LDAP)] that uses a query model very similar to the one described 2569 in this document, and which illustrates many of the points 2570 described in this document. The current RLDAP implementation has 2571 three client implementations, multiple distributed servers, and 2572 contains more than 32 million DNS domain entries, and 115 million 2573 resource-specific entries. In many regards, this document is an 2574 extension of RLDAP. 2576 15. Acknowledgments 2578 Portions of this work were funded by Network Solutions, Inc. 2580 16. Changes from Previous Versions 2582 draft-ietf-crisp-lw-core-00: 2584 * As a result of the formation of the CRISP working group, 2585 the original monolithic document has been broken into 2586 multiple documents, with draft-ietf-crisp-lw-core 2587 describing the core service, while related documents 2588 describe the per-resource schema and access mechanisms. 2590 * References to the ldaps: URL scheme have been removed, 2591 since there is no standards-track specification for the 2592 ldaps: scheme. 2594 * An acknowledgements section was added. 2596 draft-hall-ldap-whois-01: 2598 * The �Objectives� section has been removed. [ir-dir-req] is 2599 now being used as the guiding document for this service. 2601 * Several typographical errors have been fixed. 2603 * Some unnecessary text has been removed. 2605 * Figures changed to show complete sets of object classes, to 2606 improve inheritance visibility. 2608 * Clarified the handling of reverse-lookup domains (zones 2609 within the in-addr.arpa portion of the DNS hierarchy) in 2610 the inetDnsDomain object class reference text. 2612 * Referrals now use regular LDAP URLs (multiple responses 2613 with explicit hostnames and port numbers). Prior editions 2614 of this specification used LDAP SRV resource records for 2615 all referrals. 2617 * The delegation status codes used by the 2618 inetDnsDelegationStatus, inetIpv4DelegationStatus, 2619 inetIpv6DelegationStatus and inetAsnDelegationStatus 2620 attributes have been condensed to a more logical set. 2622 * Added an inetDnsAuthServers attribute for publishing the 2623 authoritative DNS servers associated with a domain. NOTE 2624 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 2625 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 2626 ATTRIBUTES. 2628 * Added an inetGeneralDisclaimer attribute for publishing 2629 generalized disclaimers. 2631 * Added the inetAssociatedResources auxiliary object class 2632 for defining associated resources, and moved some of the IP 2633 addressing and ASN attributes to the new object class. 2635 * Several attributes had their OIDs changed. NOTE THAT THIS 2636 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 2637 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.