idnits 2.17.1 draft-ietf-crisp-lw-dns-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 320 has weird spacing: '...ied the inetD...' == 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 7949 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 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-dns-00.txt July 2002 4 Expires: January, 2003 5 Category: Standards-Track 7 Defining and Locating DNS Domains 8 using the Internet Resource Query Service 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 defines LDAP schema and searching rules for DNS 35 domains, in support of the Internet Resource Query Service 36 described in [ldap-whois]. 38 2. Definitions and Terminology 40 This document unites, enhances and clarifies several pre-existing 41 technologies. Readers are expected to be familiar with the 42 following specifications: 44 RFC 2247 - Using Domains in LDAP/X.500 DNs 46 RFC 2251 - Lightweight Directory Access Protocol (v3) 48 RFC 2252 - Lightweight Directory Access Protocol (v3): 49 Attribute Syntax Definitions. 51 RFC 2254 - The String Representation of LDAP Search Filters 53 [ir-dir-req] - - 54 Internet Registry Directory Requirements 56 [ldap-whois] - - The 57 Internet Resource Query Service and the Internet Resource 58 Schema 60 The following abbreviations are used throughout this document: 62 DIT (Directory Information Tree) - A DIT is a contained 63 branch of the LDAP namespace, having a root of a particular 64 distinguished name. "dc=example,dc=com" is used throughout 65 this document as one DIT, with many example entries being 66 stored in this DIT. 68 DN (Distinguished Name) - A distinguished name provides a 69 unique identifier for an entry, through the use of a multi- 70 level naming syntax. Entries are named according to their 71 location relevant to the root of their containing DIT. For 72 example, "cn=inetResources,dc=example,dc=com" is a DN which 73 uniquely identifies the "inetResources" entry within the 74 "dc=example,dc=com" DIT. 76 RDN (Relative DN) - An RDN provides a locally-scoped unique 77 identifier for an entry. A complete, globally-unique DN is 78 formed by concatenating the RDNs of an entry together. For 79 example, "cn=admins,cn=inetResources,dc=example,dc=com" 80 consists of two RDNs ("cn=admins" and "cn=inetResources") 81 within the "dc=example,dc=com" DIT. RDNs are typically only 82 referenced within their local scope. 84 OID (Object Identifier) - An OID is a globally-unique, 85 concatenated set of integers which provide a kind of 86 "serial number" to attributes, object classes, syntaxes and 87 other schema elements. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 90 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 91 in this document are to be interpreted as described in RFC 2119. 93 3. The inetDnsDomain Object Class 95 The inetDnsDomain object class is a structural object class which 96 provides administrative information about a specific DNS domain 97 name resource, such as a zone, a well-known host, or some other 98 network resource which is primarily identified by a domain name. 100 3.1. Naming syntax 102 The naming syntax for DNS domain entries MUST follow the form of 103 "cn=,cn=inetResources,". Each DNS 104 domain name which is managed as a discrete LDAP-WHOIS resource 105 MUST have a dedicated entry in each of the DITs which provide 106 public LDAP-WHOIS data for that resource. 108 The inetDnsDomainSyntax component of an entry is subject to DN 109 rules, although the inetDnsDomainSyntax is also used for extended 110 search operations, and is therefore subject to specific syntax 111 rules. The basic rules for this format are that domain names MUST 112 be stored as sequences of labels, where each label consists of a 113 maximum of 63 characters, with each label being separated by a 114 full-stop (period) character, and with the entire domain name 115 sequence being a maximum of 255 characters. 117 For example, the "www.example.com" DNS domain name resource stored 118 in the "dc=example,dc=com" DIT would be represented as an entry 119 named "cn=www.example.com,cn=inetResources,dc=example,dc=com", 120 while the "2.0.192.in-addr.arpa" reverse-lookup domain which was 121 stored in the "dc=example,dc=com" DIT would be named 122 "cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com". 124 Note that the domain name syntax rules defined by STD 13 allow any 125 eight-bit character code to be used within any domain name, 126 although the host naming rules defined by RFC 952, STD 13 and STD 127 3 only allow a subset of the printable characters from US-ASCII to 128 be used for domain names which specify connection targets. 129 However, many domain names will need to be queried which will not 130 conform to the host naming rules ("_ldap._tcp.example.com" might 131 be specified in a search, for example), so any eight-bit character 132 MUST be considered valid for this service. 134 RFC 2253 defines several escaping mechanisms for use when handling 135 certain "special" characters, and these mechanisms MUST be used 136 whenever a character in a domain name needs to be escaped in order 137 for an assertion value to be parsed. However, STD 13 also allows 138 the use of special characters, and also provides several 139 mechanisms for escaping special characters in DNS domain names, 140 and these rules MUST also be accommodated if valid DNS names are 141 to be supported. 143 In order to facilitate this potential overlap while minimizing 144 confusion during handling, LDAP-WHOIS clients MUST allow DNS 145 domain name query strings to be entered as raw eight-bit data, but 146 if any of the characters need to be escaped for the assertion 147 value to be properly built, then the client MUST escape these 148 characters before the search is submitted. 150 Secondarily, if the user needs to search for a DNS domain name 151 which would normally require escaping or other special handling in 152 order for the domain name to be processed, then the user MUST 153 provide the domain name in its escaped form. By extension, this 154 also means that these DNS domain names MUST be stored as RDNs in 155 their escaped form. 157 STD 13 and RFC 2253 both use a common method of escaping special 158 characters with a reverse solidus (backslash) character, with 159 either the special character or a two-digit decimal code for that 160 character immediately following the reverse solidus. 162 For example, if a user needs to specify the domain name of 163 "weird name.example.com" (where "weird name" is a valid domain 164 name label with an embedded space), then the domain name would 165 have an RDN of "cn=weird\32name.example.com" in the directory, and 166 would have to be entered into the client as a search for 167 "weird\32name.example.com". The client would then perform a 168 secondary escape to form "weird\\32name.example.com" as the 169 assertion value, and this secondary escape would be removed by the 170 LDAP-WHOIS server upon receipt. Thus a match would be found. 172 NOTE: Remember that IPv4 addresses are also stored in DNS 173 for reverse-lookup purposes, and the associated zones and 174 PTR domain names may also require escaping, particularly 175 when used with site-specific CIDR notation. 177 The common reference to the root domain is a single full-stop 178 (".") character, and this usage is also endorsed by this document 179 when the root domain name needs to be explicitly queried. For any 180 domain name which contains a non-root label, the trailing period 181 which normally signifies the root domain MUST be omitted. The 182 maximum size of a valid DNS domain name is 255 characters (this 183 limit applies to the unescaped assertion value). Clients MUST 184 restrict input to this range, prior to submitting the LDAP query. 186 The domain name component of the DN MUST match the domain name of 187 the managed resource exactly as the domain name exists in the DNS 188 namespace. For example, if an organization wishes to provide 189 information about "www.example.com", then a RDN entry would need 190 to exist for "cn=www.example.com". If an organization wishes to 191 provide information about the "www.example.com" canonical target 192 "server1.example.net", then a RDN for "cn=server1.example.net" 193 would need to exist. If an organization wishes to provide 194 information about "server1.example.net" whenever a query is 195 received for "www.example.com", then the "cn=www.example.com" 196 entry would need to be defined as a subordinate reference 197 referral, with the ref attribute pointing to the 198 "cn=server1.example.net" entry. 200 This usage model also applies to reverse-lookup domains. If an 201 organization is the authority for the "2.0.192.in-addr.arpa" 202 reverse-lookup domain associated with an IPv4 network (this is 203 different from providing information about the network block in 204 particular, as is discussed separately in [ldap-whois-ipv4] and 205 [ldap-whois-ipv6], then that syntax would also be used to form the 206 RDN for the associated inetDnsDomain entry. 208 Note that reverse-lookup domain names are mapped directly as they 209 exist in the public DNS namespace. If a /24 IPv4 network block 210 such as 192.0.2.0 has been delegated to an organization, the 211 default controlling domain name of the reverse-lookup zone will be 212 2.0.192.in-addr.arpa, and the name of the associated LDAP-WHOIS 213 entry would be "cn=2.0.192.in-addr.arpa". However, if that network 214 had been delegated to an ISP who had in turn delegated the 215 192.0.2.0/29 address block and an associated reverse-lookup zone 216 of 29-0.2.0.192.in-addr.arpa to a user, then the associated LDAP- 217 WHOIS entry for that zone would be "cn=29-0.2.0.192.in-addr.arpa". 219 3.2. Schema definition 221 DNS domain name entries MUST exist with the top, inetResources and 222 inetDnsDomain object classes defined. If an entry exists as a 223 referral, the entry MUST also be defined with the referral object 224 class, in addition to the above requirements. 226 The inetDnsDomain object class is a structural object class which 227 is subordinate to the inetResources object class, and which MUST 228 be treated as a container class capable of holding additional 229 subordinate entries. The inetDnsDomain object class has no 230 mandatory attributes, although it does have several optional 231 attributes. 233 The inetDnsDomain object class defines attributes which are 234 specific to DNS domains, particularly as this relates to domain 235 delegation (DNS operational information is available through DNS 236 itself). This includes information such as the delegation date and 237 the status of the delegation. The inetDnsDomain object class is 238 subordinate to the inetResources object class, so it inherits 239 those attributes as well. 241 Some of the inetDnsDomain object class attributes define contact- 242 related referrals which provide LDAP URLs that refer to 243 inetOrgPerson entries, and these entries will need to be queried 244 separately if detailed information about a particular contact is 245 required. The contact attribute values follow the same rules as 246 the labeledURI attribute defined in RFC 2079, with additional 247 restrictions described in [ldap-whois]. 249 The various ModifiedBy and ModifiedDate attributes SHOULD be 250 treated as operational attributes. Their values SHOULD be filled 251 in automatically by the database management application, and 252 SHOULD NOT be returned except when explicitly requested. 254 The schema definition for the inetDnsDomain object class is as 255 follows: 257 inetDnsDomain 258 ( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS 259 domain attributes.' SUP inetResources STRUCTURAL MAY ( 260 inetDnsDelegationStatus $ inetDnsDelegationDate $ 261 inetDnsDelegationModifiedDate $ inetDnsDelegationModifiedBy 262 $ inetDnsContacts $ inetDnsContactsModifiedBy $ 263 inetDnsContactsModifiedDate $ inetDnsAuthServers ) ) 265 The attributes from the inetDnsDomain object class are described 266 below: 268 inetDnsAuthServers 269 ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC 270 'Authoritative DNS servers for this domain.' EQUALITY 271 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 273 The inetDnsAuthServers attribute provides a read-only 274 summary of the authoritative servers associated with the 275 zone. The attribute is defined as multi-valued, with each 276 attribute value currently (tentatively) being defined as: 278 domain.dom [address/prefix] 280 where "domain.dom" is the domain name of the authoritative 281 server, written as an inetDnsDomainSyntax string, and where 282 "address/prefix" is an IPv4 or IPv6 host-specific network 283 address, written as either an inetIpv4NetworkSyntax or 284 inetIpv6NetworkSyntax string. Clients that wish to obtain 285 additional information about the listed servers can issue 286 new queries for either the domain name or address syntax. 288 NOTE: THIS IS A TEMPORARY ATTRIBUTE WHICH WILL EVENTUALLY 289 BE REPLACED WITH GENERALIZED RESOURCE-RECORD ENTRIES AND 290 ATTRIBUTES. 292 inetDnsContacts 293 ( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContacts' DESC 294 'Contacts for reporting problems with this domain name.' 295 EQUALITY caseExactMatch SYNTAX 296 1.3.6.1.4.1.1466.115.121.1.15 ) 297 inetDnsContactsModifiedBy 298 ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedBy' 299 DESC 'Person who last modified the inetDnsContacts 300 attribute.' EQUALITY distinguishedNameMatch SYNTAX 301 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 302 distributedOperation ) 304 inetDnsContactsModifiedDate 305 ( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsContactsModifiedDate' 306 DESC 'Last modification date of the inetDnsContacts 307 attribute.' EQUALITY generalizedTimeMatch ORDERING 308 generalizedTimeOrderingMatch SYNTAX 309 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 310 distributedOperation ) 312 inetDnsDelegationDate 313 ( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsDelegationDate' DESC 314 'Date of original delegation.' EQUALITY 315 GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch 316 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 318 inetDnsDelegationModifiedBy 319 ( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsDelegationModifiedBy' 320 DESC 'Person who last modified the inetDnsDelegationStatus 321 attribute.' EQUALITY distinguishedNameMatch SYNTAX 322 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 323 distributedOperation ) 325 inetDnsDelegationModifiedDate 326 ( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDelegationModifiedDate' 327 DESC 'Last modification date of the inetDnsDelegationStatus 328 attribute.' EQUALITY generalizedTimeMatch ORDERING 329 generalizedTimeOrderingMatch SYNTAX 330 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 331 distributedOperation ) 333 inetDnsDelegationStatus 334 ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDelegationStatus' DESC 335 'Current delegation status code for this domain.' EQUALITY 336 numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} 337 SINGLE-VALUE ) 339 NOTE: In an effort to facilitate internationalization and 340 programmatic processing, the current status of a delegation 341 is identified by a 16-bit integer. The values and status 342 mapping is as follows: 344 0 Reserved delegation (permanently inactive) 345 1 Assigned and active (normal state) 346 2 Assigned but not yet active (new delegation) 347 3 Assigned but on hold (disputed) 348 4 Assignment revoked (database purge pending) 350 Additional values for the inetDnsDelegationStatus attribute 351 are reserved for future use, and are to be administered by 352 IANA. Note that there is no status code for "unassigned"; 353 unassigned entries SHOULD NOT exist, and SHOULD NOT be 354 returned as answers. 356 The inetDnsDomainSyntax syntax is as follows: 358 inetDnsDomainSyntax 359 ( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A 360 fully-qualified DNS domain name.' ) 362 3.3. Example 364 An example of the inetDnsDomain object class in use is shown in 365 Figure 1 below, with some additional attributes inherited from the 366 parent inetResources entry. This query is most likely being sent 367 to the LDAP servers responsible for operating the "example.com" 368 DNS domain. 370 cn=example.com,cn=inetResources,dc=example,dc=com 371 [top object class] 372 [inetResources object class] 373 [inetDnsDomain object class] 374 | 375 +-attribute: description 376 | value: "The example.com DNS domain" 377 | 378 +-attribute: inetDnsContacts 379 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 380 | dc=example,dc=com" 381 | 382 +-attribute: inetGeneralContacts 383 value: "ldap://ldap.example.com/cn=admins,ou=admins, 384 dc=example,dc=com" 386 Figure 1: The example.com inetDnsDomain entry. 388 4. The inetDnsDomainMatch Filter 390 The inetDnsDomainMatch filter provides an identifier and search 391 string format which collectively inform a queried server that a 392 specific DNS domain name should be searched for, and that any 393 matching inetDnsDomain object class entries should be returned. 395 The inetDnsDomainMatch extensibleMatch filter is defined as 396 follows: 398 inetDnsDomainMatch 399 ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDomainMatch' SYNTAX 400 inetDnsDomainSyntax ) 402 The assertion value MUST be a valid DNS domain name, using the 403 inetDnsDomainSyntax syntax rules defined in section 3. 405 The server MUST compare the assertion value against the RDN of all 406 entries in the inetResources container which have an object class 407 of inetDnsDomain. Any entry for a DNS domain resource which is 408 clearly superior to the DNS domain name provided in the input 409 string MUST be returned to the client. Entries which do not 410 encompass the queried domain name MUST NOT be returned. Entries 411 which do not have an object class of inetDnsDomain MUST NOT be 412 returned. 414 For example, assume that the client has issued a query with the 415 assertion value of "www.example.com". If the queried server has an 416 inetDnsDomain object class entry with a DN of 417 "cn=example.com,cn=inetResources,dc=com", then that entry would be 418 returned to the client. Similarly, a continuation reference 419 referral of "cn=cref1,cn=example.com,cn=inetResources,dc=com" 420 would also be returned, since it has a "cn" component that is 421 superior to the queried domain name, and has the inetDnsDomain 422 object class. 424 Domain names MUST be compared on label boundaries, and MUST NOT be 425 qualified through simple character matching. Given two entries of 426 "cn=example.com" and "cn=an-example.com", only the first would 427 match an assertion value of "example.com". 429 Using the notation format described in RFC 2254, the search filter 430 expression for the inetDnsDomainMatch query above would be written 431 as "(1.3.6.1.4.1.7161.1.1.9:=www.example.com)". 433 Response entries MAY be fully-developed inetDnsDomain entries, or 434 MAY be referrals generated from entries which have the 435 inetDnsDomain and referral object classes defined. Any attribute 436 values which are received MUST be displayed by the client. If a 437 subordinate reference referral is received, the client MUST 438 restart the query, using the provided data as the new search base. 439 If any continuation reference referrals are received, the client 440 SHOULD start new queries for each reference, and append the output 441 of those queries to the original query's output. 443 5. Security Considerations 445 This document describes an application of the LDAPv3 protocol, and 446 as such it inherits the security considerations associated with 447 LDAPv3, as described in section 7 of RFC 2251. 449 By nature, LDAP is a read-write protocol, while the legacy WHOIS 450 service has always been a read-only service. As such, there are 451 significant risks associated with allowing unintended updates by 452 unauthorized third-parties. Moreover, allowing the LDAP-WHOIS 453 service to update the underlying delegation databases could result 454 in network resources being stolen from their lawful operators. For 455 example, if the LDAP front-end had update access to a domain 456 delegation database, a malicious third-party could theoretically 457 take ownership of that domain by exploiting an authentication 458 weakness, thereby causing ownership of the domain to be changed to 459 another party. For this reason, it is imperative that the LDAP- 460 WHOIS service not be allowed to make critical modifications to 461 delegated resources without ensuring that all possible precautions 462 have been taken. 464 The query processing models described in this document make use of 465 DNS lookups in order to locate the LDAP servers associated with a 466 particular resource. DNS is susceptible to certain attacks and 467 forgeries which may be used to redirect clients to LDAP servers 468 which are not authoritative for the resource in question. 470 Some operators may choose to purposefully provide misleading or 471 erroneous information in an effort to avoid responsibility for bad 472 behavior. In addition, there are likely to be sporadic operator 473 errors which will result in confusing or erroneous answers. 475 This document provides multiple query models which will cause the 476 same query to be answered by different servers (one would be 477 processed by a delegation entity, while another would be processed 478 by an operational entity). As a result, each of the servers may 479 provide different information, depending upon the query type that 480 was originally selected. 482 For all of the reasons listed above, it is essential that 483 applications and end-users not make critical decisions based on 484 the information provided by the LDAP-WHOIS service without having 485 reason to believe the veracity of the information. Users should 486 limit unknown or untrusted information to routine purposes. 488 Finally, there are physical security issues associated with any 489 service which provides physical addressing and delivery 490 information. Although organizations are generally encouraged to 491 provide as much information as they feel comfortable with, no 492 information is required. 494 6. IANA Considerations 496 This document defines an application of the LDAPv3 protocol rather 497 than a new Internet application protocol. As such, there are no 498 protocol-related IANA considerations. 500 However, this document does define several LDAP schema elements, 501 including object classes, attributes, syntaxes and extensibleMatch 502 filters, and these elements should be assigned OID values from the 503 IANA branch, rather than being assigned from a particular 504 enterprise branch. 506 Finally, this document also describes several instances where 507 public DNS and LDAP servers are queried. It is expected that IANA 508 will establish and maintain these LDAP servers (and the necessary 509 DNS SRV domain names and resource records) required for this 510 service to operate. This includes providing SRV resource records 511 in the generic TLDs and the root domain, and also includes 512 administering the referenced LDAP servers. 514 7. Author's Addresses 516 Eric A. Hall 517 ehall@ehsco.com 519 8. References 521 RFC 2247 - Using Domains in LDAP/X.500 DNs 522 RFC 2251 - Lightweight Directory Access Protocol (v3) 524 RFC 2252 - Lightweight Directory Access Protocol (v3): 525 Attribute Syntax Definitions. 527 RFC 2254 - The String Representation of LDAP Search Filters 529 [ir-dir-req] - - 530 Internet Registry Directory Requirements 532 [ldap-whois] - - The 533 Internet Resource Query Service and the Internet Resource 534 Schema 536 [ldap-whois-ipv4] - - 537 Defining and Locating IPv4 Address Blocks using the 538 Internet Resource Query Service 540 [ldap-whois-ipv6] - - 541 Defining and Locating IPv6 Address Blocks using the 542 Internet Resource Query Service 544 9. Acknowledgments 546 Portions of this work were funded by Network Solutions, Inc.