idnits 2.17.1 draft-ietf-crisp-firs-dns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (May 2003) is 7652 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) == Missing Reference: 'RFC2253' is mentioned on line 157, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC2798' is mentioned on line 316, but not defined == Unused Reference: 'RFC2247' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 604, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 10 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-firs-dns-01.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 Defining and Locating DNS Domains 8 in the Federated Internet Registry 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 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines LDAP schema and searching rules for DNS 39 domain names, in support of the Federated Internet Registry 40 Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. 42 Table of Contents 44 1. Introduction...............................................2 45 2. Prerequisites and Terminology..............................2 46 3. Naming Syntax..............................................3 47 4. Object Classes and Attributes..............................6 48 5. Query Processing Rules.....................................8 49 5.1. Query Pre-Processing....................................8 50 5.2. Query Bootstrapping.....................................9 51 5.3. LDAP Matching...........................................9 52 5.4. Example Query..........................................11 53 6. Security Considerations...................................12 54 7. IANA Considerations.......................................12 55 8. Author's Addresses........................................12 56 9. Normative References......................................12 57 10. Acknowledgments...........................................14 58 11. Changes from Previous Versions............................14 59 12. Full Copyright Statement..................................15 61 1. Introduction 63 This specification defines the naming syntax, object classes, 64 attributes, matching filters, and query processing rules for 65 storing and locating DNS domain names in the FIRS service. Refer 66 to [FIRS-ARCH] for information on the FIRS architecture and 67 [FIRS-CORE] for the schema definitions and rules which govern the 68 FIRS service as a whole. 70 Note that these rules and definitions only apply to domain name 71 resources, and do not apply to domainComponent entries or any 72 other domain name elements, unless explicity defined. Also note 73 that this specification governs reverse-lookup DNS domains for 74 IPv4 and IPv6 address blocks, but that these entries are entirely 75 different from the entries which govern the actual IPv4 and IPv6 76 address blocks themselves. 78 The definitions in this specification are intended to be used with 79 FIRS. Their usage outside of FIRS is not prohibited, but any such 80 usage is beyond this specification's scope of authority. 82 2. Prerequisites and Terminology 84 The complete set of specifications in the FIRS collection 85 cumulative define a structured and distributed information service 86 using LDAPv3 for the data-formatting and transport functions. This 87 specification should be read in the context of the complete set of 88 specifications, which currently include the following: 90 draft-ietf-crisp-firs-arch-01, "The Federated Internet 91 Registry Service: Architecture and Implementation" 92 [FIRS-ARCH] 94 draft-ietf-crisp-firs-core-01, "The Federated Internet 95 Registry Service: Core Elements" [FIRS-CORE] 97 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 98 Domains in the Federated Internet Registry Service" (this 99 document) [FIRS-DNS] 101 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 102 Resource Records in the Federated Internet Registry 103 Service" [FIRS-DNSRR] 105 draft-ietf-crisp-firs-contact-01, "Defining and Locating 106 Contact Persons in the Federated Internet Registry Service" 107 [FIRS-CONTCT] 109 draft-ietf-crisp-firs-asn-01, "Defining and Locating 110 Autonomous System Numbers in the Federated Internet 111 Registry Service" [FIRS-ASN] 113 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 114 Address Blocks in the Federated Internet Registry Service" 115 [FIRS-IPV4] 117 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 118 Address Blocks in the Federated Internet Registry Service" 119 [FIRS-IPV6] 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 123 in this document are to be interpreted as described in RFC 2119. 125 3. Naming Syntax 127 The naming syntax for DNS domains in FIRS MUST follow the form of 128 "cn=,cn=inetResources,", where 129 is the DNS domain name resource, and where 130 is a sequence of domainComponent relative 131 distinguished names which identifies the scope of authority for 132 the selected directory partition. 134 The inetDnsDomainSyntax is relatively unstructured, in that it 135 uses standardized procedures to produce heavily-normalized DNS 136 domain names rather than using structured syntax rules. The 137 principle reason for this is due to conflicting syntax rules in 138 different canonical domain name rules, with these rules preventing 139 the use of a common syntax. 141 The normalization procedure produces UTF-8 [RFC2279] domain names 142 as output, with the resulting sequences being suitable for direct 143 comparisons, substring searches, and a broad range of other 144 matching operations. 146 This normalization procedure is as follows: 148 a. Any valid domain name MUST be accepted by FIRS-aware 149 applications. This specifically includes ASCII characters 150 outside of the traditional "hostname" subset, and also 151 includes non-printable eight-bit code-point values such as 152 Space, any of which are allowed by the domain name rules 153 specified in STD 13 [STD13] and RFC 2181 [RFC2181]. 155 These code-point values MUST be escaped into an ASCII-safe 156 form before they are stored and before they are used to 157 seed assertion values. [STD13] and [RFC2253] both use a 158 Reverse Solidus (Backslash) character followed by a three- 159 digit decimal number to represent the code-point value, and 160 this specification also requires FIRS implementations to 161 use this process for all code-point values which need to be 162 escaped. For example, "weird name.example.com" (where 163 "weird name" is a valid domain name label with an embedded 164 Space) MUST be stored as "weird\032name.example.com" in the 165 directory, and query input MUST use this sequence as the 166 basis of any resulting assertion value. 168 b. Domain names which explicitly specify the root domain MUST 169 use a single Full-Stop (".") character. Other domain names 170 MUST NOT have a trailing Full-Stop character, and any such 171 character MUST be stripped. 173 c. In order to ensure that internationalized domain names are 174 properly normalized and validated, all domain names MUST 175 also undergo a round-trip conversion process using the 176 mechanisms and rules specified in RFC 3490 [RFC3490]. 178 1. The first step in this process is to perform the 179 "ToASCII" conversion operation specified in [RFC3490], 180 with the "UseSTD3ASCIIRules" flag disabled. This step 181 will reduce the input domain name to its canonical 182 ASCII-compatible form, thus ensuring that the input 183 data can be properly normalized. 185 2. The second step in this process is to perform the 186 "ToUnicode" conversion operation specified in 187 [RFC3490], with the "UseSTD3ASCIIRules" flag disabled. 188 This step will convert the ASCII-compatible sequence 189 into a sequence of Unicode code-point values. 191 3. The Unicode code-point values returned in step 3.c.2 192 MUST be converted to UTF-8 before the domain name is 193 stored or transferred. 195 Once all of these steps have successfully completed, the domain 196 name can be stored in the directory or used as an assertion value. 197 Any fatal error conditions encountered during these conversions 198 MUST result in a local failure; FIRS-aware applications MUST NOT 199 store or transmit non-normalized domain names for any purposes. 201 The inetDnsDomainSyntax syntax is as follows: 203 inetDnsDomainSyntax 204 ( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A 205 fully-qualified DNS domain name.' ) 207 Note that the entry name of "cn=." encompasses the entire DNS 208 domain namespace. 210 Note that any Reverse Solidus characters in the domain name will 211 be further escaped when these sequences are transferred in LDAP 212 messages. For example, "weird\032name.example.com" will be further 213 escaped as "weird\\032name.example.com" when it is passed in an 214 LDAP message (this secondary escape will be stripped upon receipt, 215 leaving the escaped domain name in its original form). The use of 216 Reverse Solidus characters is also frequently illegal as data in 217 URLs, and these characters will probably be escaped before they 218 are stored in a URL as data. 220 Also note that UTF-8 characters use character codes which are 221 frequently illegal as data in URLs, and many of those octet values 222 will probably be escaped before they are stored in a URL as data. 224 4. Object Classes and Attributes 226 DNS domain name entries in FIRS MUST use the inetDnsDomain object 227 class, in addition to the mandatory object classes defined in 228 [FIRS-CORE]. DNS domain name entries MUST be treated as containers 229 capable of holding subordinate entries. If an entry exists as a 230 referral source, the entry MUST also be defined with the referral 231 object class, in addition to the above requirements. 233 The inetDnsDomain object class is a structural object class which 234 is subordinate to the inetResources object class. The 235 inetDnsDomain object class has no mandatory attributes, although 236 it does have several optional attributes. The inetDnsDomain object 237 class also inherits the attributes defined in the inetResources 238 object class, including the "cn" naming attribute. 240 The schema definition for the inetDnsDomain object class is as 241 follows: 243 inetDnsDomain 244 ( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS 245 domain attributes.' SUP inetResources STRUCTURAL MAY ( 246 inetDnsDelegationStatus $ inetDnsDelegationDate $ 247 inetDnsRegistrar $ inetDnsRegistry $ inetDnsContacts $ 248 inetDnsAuthServers ) ) 250 The attributes from the inetDnsDomain object class are described 251 below: 253 inetDnsAuthServers 254 ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC 255 'Authoritative DNS servers for this domain.' EQUALITY 256 caseExactMatch SYNTAX inetDnsDomainSyntax ) 258 The inetDnsAuthServers attribute provides a listing of the 259 authoritative DNS servers associated with the domain name 260 (assuming that that the domain name refers to a zone). The 261 attribute is defined as multi-valued, with each attribute 262 identifying the domain name of an authoritative nameserver. 264 inetDnsContacts 265 ( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContacts' DESC 266 'Contacts for general administrative issues concerning this 267 domain name.' EQUALITY caseIgnoreMatch SYNTAX 268 inetContactSyntax ) 269 inetDnsDelegationDate 270 ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsDelegationDate' DESC 271 'Date this DNS domain name was delegated.' EQUALITY 272 GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch 273 SYNTAX generalizedTime SINGLE-VALUE ) 275 inetDnsDelegationStatus 276 ( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsDelegationStatus' DESC 277 'Delegation status of this domain name.' EQUALITY 278 numericStringMatch SYNTAX numericString{2} SINGLE-VALUE ) 280 NOTE: In an effort to facilitate internationalization and 281 programmatic processing, the current status of a delegation 282 is identified by a 16-bit integer. The values and status 283 mapping is as follows: 285 0 Reserved delegation (permanently inactive) 286 1 Assigned and active (normal state) 287 2 Assigned but not yet active (new delegation) 288 3 Assigned but on hold (disputed) 289 4 Assignment revoked (database purge pending) 291 Additional values are reserved for future use, and are to 292 be administered by IANA. 294 Note that there is no status code for "unassigned"; 295 unassigned entries SHOULD NOT exist, and SHOULD NOT be 296 returned as answers. 298 inetDnsRegistrar 299 ( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsRegistrar' DESC 300 'Registrar who delegated this domain name.' EQUALITY 301 caseIgnoreMatch SYNTAX directoryString ) 303 NOTE: The inetIpv4Registrar attribute uses a URL to 304 indicate the registrar who delegated the domain name. The 305 attribute structure is identical to the labeledURI 306 attribute, as defined in [RFC2798], including the URL and 307 textual comments. The data can refer to any valid URL. 309 inetDnsRegistry 310 ( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsRegistry' DESC 311 'Registry where this domain name is managed.' EQUALITY 312 caseIgnoreMatch SYNTAX directoryString ) 313 NOTE: The inetIpv4Registry attribute uses a URL to indicate 314 the registry who is ultimately responsible for the domain 315 name. The attribute structure is identical to the 316 labeledURI attribute, as defined in [RFC2798], including 317 the URL and textual comments. The data can refer to any 318 valid URL. 320 An example of the inetDnsDomain object class in use is shown in 321 Figure 1 below. The example includes attributes from the 322 inetDnsDomain, inetResources, and inetAssociatedResources object 323 classes. 325 cn=example.com,cn=inetResources,dc=netsol,dc=com 326 [top object class] 327 [inetResources object class] 328 [inetDnsDomain object class] 329 [inetAssociatedResources object class] 330 | 331 +-attribute: description 332 | value: "The example.com DNS domain" 333 | 334 +-attribute: inetDnsContacts 335 | value: "hostmaster@example.com" 336 | 337 +-attribute: inetAuthServers 338 | value: "ns1.example.net" 339 | value: "ns2.example.net" 340 | 341 +-attribute: inetAssociatedIpv4Network 342 value: "192.0.2.0/24" 344 Figure 1: The entry for the example.com DNS domain name in the 345 dc=netsol,dc=com partition. 347 5. Query Processing Rules 349 Queries for DNS domain names have several special requirements, as 350 discussed in the following sections. 352 Refer to [FIRS-CORE] for general information about FIRS queries. 354 5.1. Query Pre-Processing 356 Clients MUST ensure that the query input is normalized according 357 to the rules specified in section 3 before the input is used as 358 the assertion value to the resulting LDAP query. 360 The authoritative partition for a DNS domain name is determined by 361 mapping the normalized domain name to a sequence of 362 domainComponent labels. 364 Since the domainComponent attribute is restricted to seven-bit 365 characters, the normalized DNS domain name MUST be converted to 366 its IDNA form using the "ToASCII" conversion operation specified 367 in [RFC3490], with the "UseSTD3ASCIIRules" flag disabled (FIRS 368 applications MAY reuse the output from the conversion performed in 369 step 3.c.1 if the entire conversion process is known to have 370 completed successfully). The resulting sequence of ASCII labels 371 are used to form the domainComponent sequence which represents the 372 authoritative partition for the DNS domain name. 374 As a simple example, "www.example.com" would be mapped to the 375 "dc=www,dc=example,dc=com" authoritative partition, with this 376 partition being used to seed the query process. As a slightly more 377 complex example, the domain name of "weird name.example.com" would 378 be mapped to "dc=weird\032name,dc=example,dc=com". 380 5.2. Query Bootstrapping 382 FIRS clients MUST use the top-down bootstrap model by default for 383 DNS domain name queries. As such, the search base for default 384 queries would be set to the right-most domainComponent relative 385 distinguished name of the authoritative partition, rather than 386 being set to the fully-qualified distinguished name of the 387 authoritative partition. 389 FIRS clients MAY use the targeted or bottom-up bootstrap models 390 for queries if necessary or desirable. However, it is not likely 391 that entries will be found for all DNS domain name resources using 392 these models. As such, the top-down bootstrap model will be the 393 most useful in most cases, and MUST be used by default. 395 5.3. LDAP Matching 397 FIRS clients MUST use the inetDnsDomainMatch extensible matching 398 filter in LDAP searches for DNS domain name entries. 400 The inetDnsDomainMatch filter provides an identifier and search 401 string format which collectively inform a queried server that a 402 specific DNS domain name should be searched for, and that any 403 matching inetDnsDomain object class entries should be returned. 405 The inetDnsDomainMatch extensibleMatch filter is defined as 406 follows: 408 inetDnsDomainMatch 409 ( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDomainMatch' SYNTAX 410 inetDnsDomainSyntax ) 412 The assertion value MUST be a normalized DNS domain name, using 413 the inetDnsDomainSyntax syntax rules defined in section 3. 415 A FIRS server MUST compare the assertion value against the RDN of 416 all entries in the inetResources container of the partition 417 specified in the search base which have an object class of 418 inetDnsDomain. Any entry with an object class of inetDnsDomain and 419 with a relative distinguished name which is in the delegation path 420 to the DNS domain name provided in the input string MUST be 421 returned to the client. Entries which are not in the delegation 422 path of the queried domain name MUST NOT be returned. Entries 423 which do not have an object class of inetDnsDomain MUST NOT be 424 returned. 426 In order to ensure that all of the relevant entries are found 427 (including any referrals), the search filters for these resources 428 MUST specify the inetDnsDomain object class along with the search 429 criteria. For example, "(&(objectclass=inetDnsDomain) 430 (1.3.6.1.4.1.7161.1.1.8:=example.com))" with a search base of 431 "cn=inetResources,dc=netsol,dc=com" would find all of the 432 inetDnsDomain object class entries in the delegation path to the 433 "example.com" domain in the "dc=netsol,dc=com" partition. 435 Domain names MUST be compared on label boundaries, and MUST NOT be 436 compared through simple character matching. Given two entries of 437 "cn=example.com" and "cn=an-example.com", only the first would 438 match an assertion value of "example.com". 440 Note that the entry name of "cn=." encompasses the entire DNS 441 domain namespace. When used in conjunction with referrals, this 442 entry MAY be used to redirect all inetDnsDomainMatch queries to 443 another partition for subsequent processing. 445 The matching filters defined in this specification MUST be 446 supported by FIRS clients and servers. FIRS servers MAY support 447 additional sub-string filters, soundex filters, or any other 448 filters they wish (these may be required to support generic LDAP 449 clients), although FIRS clients MUST NOT expect any additional 450 filters to be available. 452 5.4. Example Query 454 The following example assumes that the user has specified 455 "www.example.com" as the query value: 457 a. Normalize the input, which is "www.example.com" in this 458 case. 460 b. Determine the authoritative partition, which is 461 "dc=www,dc=example,dc=com" in this case. By default, 462 queries for DNS domain names use the top-down model, 463 meaning that the right-most relative distinguished name of 464 "dc=com" will be used. 466 c. Determine the search base for the query, which will be 467 "cn=inetResources,dc=com" if the defaults are used. 469 d. Initiate a DNS lookup for the SRV resource records 470 associated with "_ldap._tcp.com." For the purpose of this 471 example, assume that this lookup succeeds, with the DNS 472 response message indicating that "firs.iana.org" is the 473 preferred LDAP server. 475 e. Submit an LDAPv3 query to the specified server, using 476 "(&(objectclass=inetDnsDomain) 477 (1.3.6.1.4.1.7161.1.1.8:=www.example.com))" as the matching 478 filter, "cn=inetResources,dc=com" as the search base, and 479 the global query defaults defined in [FIRS-CORE]. 481 f. Assume that the queried server returns a continuation 482 reference referral which points to 483 "ldap://cn=inetResources,dc=netsol,dc=com". The 484 distinguished name element of 485 "cn=inetResources,dc=netsol,dc=com" will be used as the new 486 search base, while "dc=netsol,dc=com" will be used as the 487 new authoritative partition. 489 g. Initiate a DNS lookup for the SRV resource records 490 associated with "_ldap._tcp.netsol.com." For the purpose of 491 this example, assume that this lookup succeeds, with the 492 DNS response message indicating that "firs.netsol.org" is 493 the preferred LDAP server. 495 h. Submit an LDAPv3 query to the specified server, using 496 "(&(objectclass=inetDnsDomain) 497 (1.3.6.1.4.1.7161.1.1.8:=www.example.com))" as the matching 498 filter, "cn=inetResources,dc=netsol,dc=com" as the search 499 base, and the global query defaults defined in [FIRS-CORE]. 501 i. Assume that no other referrals are received. Display the 502 answer data which has been received and exit the query. 504 6. Security Considerations 506 Security considerations are discussed in [FIRS-ARCH]. 508 7. IANA Considerations 510 This specification assumes the existence of partitions for each of 511 the top-level domain names in the global DNS namespace, with the 512 expectation that FIRS-capable LDAP servers will be established for 513 each of these partitions, and with these partition containing 514 domain delegation entries which will provide referrals to the 515 appropriate registrar's partitions. It is expected that IANA will 516 encourage top-level domain registry operators to oversee the 517 creation and management of these resources. 519 It is further expected that IANA will oversee the creation and 520 management of the root domain's LDAP SRV resource records, the 521 "dc=." LDAP partition, and the necessary LDAP servers. 523 The inetDnsDelegationStatus attribute uses numeric code values. It 524 is expected that IANA will manage the assignment of these values. 526 Additional IANA considerations are discussed in [FIRS-ARCH]. 528 8. Author's Addresses 530 Eric A. Hall 531 ehall@ehsco.com 533 9. Normative References 535 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 536 Service: Architecture and Implementation 537 Guide", draft-ietf-crisp-firs-arch-01, May 538 2003. 540 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 541 System Numbers in the Federated Internet 542 Registry Service", draft-ietf-crisp-firs-asn- 543 01, May 2003. 545 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 546 Persons in the Federated Internet Registry 547 Service", draft-ietf-crisp-firs-contact-01, 548 May 2003. 550 [FIRS-CORE] Hall, E. "The Federated Internet Registry 551 Service: Core Elements", draft-ietf-crisp- 552 firs-core-01, May 2003. 554 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 555 the Federated Internet Registry Service", 556 draft-ietf-crisp-firs-dns-01, May 2003. 558 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 559 Records in the Federated Internet Registry 560 Service", draft-ietf-crisp-firs-dnsrr-01, May 561 2003. 563 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 564 Blocks in the Federated Internet Registry 565 Service", draft-ietf-crisp-firs-ipv4-01, May 566 2003. 568 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 569 Blocks in the Federated Internet Registry 570 Service", draft-ietf-crisp-firs-ipv6-01, May 571 2003. 573 [RFC2181] Elz, R., and Bush, R. "Clarifications to the 574 DNS Specification", RFC 2181, July 1997. 576 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 577 and Sataluri, S. "Using Domains in LDAP/X.500 578 DNs", RFC 2247, January 1998. 580 [RFC2251] Wahl, M., Howes, T., and Kille, S. 581 "Lightweight Directory Access Protocol (v3)", 582 RFC 2251, December 1997. 584 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 585 S. "Lightweight Directory Access Protocol 586 (v3): Attribute Syntax Definitions", RFC 2252, 587 December 1997. 589 [RFC2254] Howes, T. "The String Representation of LDAP 590 Search Filters", RFC 2254, December 1997. 592 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 593 ISO 10646", RFC 2279, January 1998. 595 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 596 "Internationalizing Domain Names in 597 Applications (IDNA)", RFC 3490, March 2003. 599 [STD13] Mockapetris, P. "Domain names - concepts and 600 facilities", STD 13, RFC 1034 and "Domain 601 names - implementation and specification", STD 602 13, RFC 1035, November 1987. 604 [US-ASCII] Cerf, V. "ASCII format for Network 605 Interchange", RFC 20, October 1969. 607 10. Acknowledgments 609 Funding for the RFC editor function is currently provided by the 610 Internet Society. 612 Portions of this document were funded by Verisign Labs. 614 The first version of this specification was co-authored by Andrew 615 Newton of Verisign Labs, and subsequent versions continue to be 616 developed with his active participation. 618 11. Changes from Previous Versions 620 draft-ietf-crisp-firs-dns-01: 622 * Several clarifications and corrections have been made. 624 draft-ietf-crisp-firs-dns-00: 626 * Restructured the document set. 628 * "Attribute references" have been eliminated from the 629 specification. All referential attributes now provide 630 actual data instead of URL pointers to data. Clients that 631 wish to retrieve these values will need to start new 632 queries using the data values instead of URLs. 634 * The various modified* operational attributes have been 635 eliminated as unnecessary. 637 * Several attributes had their OIDs changed. NOTE THAT THIS 638 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 639 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 641 draft-ietf-crisp-lw-dns-01: 643 * Added discussion for internationalized domain names. 645 * Moved attribute-specific security requirements to the 646 Security section. 648 12. Full Copyright Statement 650 Copyright (C) The Internet Society (2003). All Rights Reserved. 652 This document and translations of it may be copied and furnished 653 to others, and derivative works that comment on or otherwise 654 explain it or assist in its implementation may be prepared, 655 copied, published and distributed, in whole or in part, without 656 restriction of any kind, provided that the above copyright notice 657 and this paragraph are included on all such copies and derivative 658 works. However, this document itself may not be modified in any 659 way, such as by removing the copyright notice or references to the 660 Internet Society or other Internet organizations, except as needed 661 for the purpose of developing Internet standards in which case the 662 procedures for copyrights defined in the Internet Standards 663 process must be followed, or as required to translate it into 664 languages other than English. 666 The limited permissions granted above are perpetual and will not 667 be revoked by the Internet Society or its successors or assigns. 669 This document and the information contained herein is provided on 670 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 671 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 672 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 673 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.