idnits 2.17.1 draft-ietf-crisp-firs-dns-02.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 (July 2003) is 7591 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 128, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC2798' is mentioned on line 304, but not defined == Unused Reference: 'FIRS-DNS' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC2247' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-02 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-02 -- 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-02.txt July 2003 4 Expires: February, 2004 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..............................5 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. Variant Domain Names......................................12 54 7. Security Considerations...................................13 55 8. IANA Considerations.......................................13 56 9. Normative References......................................13 57 10. Changes from Previous Versions............................15 58 11. Author's Address..........................................16 59 12. Acknowledgments...........................................16 60 13. Full Copyright Statement..................................16 62 1. Introduction 64 This specification defines the naming syntax, object classes, 65 attributes, matching filters, and query processing rules for 66 storing and locating DNS domain names in the FIRS service. Refer 67 to [FIRS-ARCH] for information on the FIRS architecture and 68 [FIRS-CORE] for the schema definitions and rules which govern the 69 FIRS service as a whole. 71 Note that these rules and definitions only apply to domain name 72 resources, and do not apply to domainComponent entries or any 73 other domain name elements, unless explicitly defined. Also note 74 that this specification governs reverse-lookup DNS domains for 75 IPv4 and IPv6 address blocks, but that these entries are entirely 76 different from the entries which govern the actual IPv4 and IPv6 77 address blocks themselves. 79 The definitions in this specification are intended to be used with 80 FIRS. Their usage outside of FIRS is not prohibited, but any such 81 usage is beyond this specification's scope of authority. 83 2. Prerequisites and Terminology 85 The complete set of specifications in the FIRS collection 86 cumulative define a structured and distributed information service 87 using LDAPv3 for the data-formatting and transport functions. This 88 specification should be read in the context of that set, which 89 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNSRR], 90 [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 93 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 94 in this document are to be interpreted as described in RFC 2119. 96 3. Naming Syntax 98 The naming syntax for DNS domains in FIRS MUST follow the form of 99 "cn=,cn=inetResources,", where 100 is the DNS domain name resource, and where 101 is a sequence of domainComponent relative 102 distinguished names which identifies the scope of authority for 103 the selected directory partition. 105 The inetDnsDomainSyntax is relatively unstructured, in that it 106 uses standardized procedures to produce heavily-normalized DNS 107 domain names rather than using structured syntax rules. This is 108 partly necessary due to conflicting syntax rules in different 109 specifications, but is also necessary to support existing LDAP 110 systems which do not know the syntax rules. 112 The normalization procedure produces UTF-8 [RFC2279] domain names 113 as output, with the resulting sequences being suitable for direct 114 comparisons, substring searches, and a broad range of other 115 matching operations. 117 This normalization procedure is as follows: 119 a. Any valid domain name MUST be accepted by FIRS-aware 120 applications. This specifically includes ASCII characters 121 outside of the traditional "hostname" subset, and also 122 includes non-printable eight-bit code-point values such as 123 Space, any of which are allowed by the domain name rules 124 specified in STD 13 [STD13] and RFC 2181 [RFC2181]. 126 These code-point values MUST be escaped into an ASCII-safe 127 form before they are stored and before they are used to 128 seed assertion values. [STD13] and [RFC2253] both use a 129 Reverse Solidus (Backslash) character followed by a three- 130 digit decimal number to represent the code-point value, and 131 this specification also requires FIRS implementations to 132 use this process for all code-point values which need to be 133 escaped. For example, "weird name.example.com" (where 134 "weird name" is a valid domain name label with an embedded 135 Space) MUST be stored as "weird\032name.example.com" in the 136 directory, and query input MUST use this sequence as the 137 basis of any resulting assertion value. 139 b. Domain names which explicitly specify the root domain MUST 140 use a single Full-Stop (".") character. Other domain names 141 MUST NOT have a trailing Full-Stop character, and any such 142 character MUST be stripped. 144 c. In order to ensure that internationalized domain names are 145 properly normalized and validated, all domain names MUST 146 also undergo a round-trip conversion process using the 147 mechanisms and rules specified in RFC 3490 [RFC3490]. 149 1. The first step in this process is to perform the 150 "ToASCII" conversion operation specified in [RFC3490], 151 with the "UseSTD3ASCIIRules" flag disabled. This step 152 will reduce the input domain name to its canonical 153 ASCII-compatible form, thus ensuring that the input 154 data can be properly normalized. 156 2. The second step in this process is to perform the 157 "ToUnicode" conversion operation specified in 158 [RFC3490], with the "UseSTD3ASCIIRules" flag disabled. 159 This step will convert the ASCII-compatible sequence 160 into a sequence of Unicode code-point values. 162 3. The Unicode code-point values returned in step 3.c.2 163 MUST be converted to UTF-8 before the domain name is 164 stored or transferred. 166 Once all of these steps have successfully completed, the domain 167 name can be stored in the directory or used as an assertion value. 168 Any fatal error conditions encountered during these conversions 169 MUST result in a local failure; FIRS-aware applications MUST NOT 170 store or transmit non-normalized domain names for any purposes. 172 The inetDnsDomainSyntax syntax is as follows: 174 inetDnsDomainSyntax 175 ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetDnsDomainSyntax' DESC 'A 176 DNS domain name.' ) 177 Note that the entry name of "cn=." encompasses the entire DNS 178 domain namespace. 180 Note that any Reverse Solidus characters in the domain name will 181 be further escaped when these sequences are transferred in LDAP 182 messages. For example, "weird\032name.example.com" will be further 183 escaped as "weird\\032name.example.com" when it is passed in an 184 LDAP message (this secondary escape will be stripped upon receipt, 185 leaving the escaped domain name in its original form). The use of 186 Reverse Solidus characters is also frequently illegal as data in 187 URLs, and these characters will probably be escaped before they 188 are stored in a URL as data. 190 Also note that UTF-8 characters use character codes which are 191 frequently illegal as data in URLs, and many of those octet values 192 will probably be escaped before they are stored in a URL as data. 194 4. Object Classes and Attributes 196 DNS domain name entries in FIRS MUST use the inetDnsDomain object 197 class, in addition to the mandatory object classes defined in 198 [FIRS-CORE]. DNS domain name entries MUST be treated as containers 199 capable of holding subordinate entries. If an entry exists as a 200 referral source, the entry MUST also be defined with the referral 201 object class, in addition to the above requirements. 203 The inetDnsDomain object class is a structural object class which 204 is subordinate to the inetResources object class. The 205 inetDnsDomain object class has no mandatory attributes, although 206 it does have several optional attributes. The inetDnsDomain object 207 class also inherits the attributes defined in the inetResources 208 object class, including the "cn" naming attribute. 210 The schema definition for the inetDnsDomain object class is as 211 follows: 213 inetDnsDomain 214 ( 1.3.6.1.4.1.7161.1.3.1 215 NAME 'inetDnsDomain' 216 DESC 'DNS domain attributes.' 217 SUP inetResources 218 STRUCTURAL 219 MAY ( inetDnsDelegationStatus $ inetDnsDelegationDate $ 220 inetDnsRegistrar $ inetDnsRegistry $ inetDnsContacts $ 221 inetDnsAuthServers ) ) 222 The attributes from the inetDnsDomain object class are described 223 below: 225 inetDnsAuthServers 226 ( 1.3.6.1.4.1.7161.1.3.2 227 NAME 'inetDnsAuthServers' 228 DESC 'Authoritative DNS servers for this domain.' 229 EQUALITY caseExactMatch 230 SYNTAX 1.3.6.1.4.1.7161.1.3.1 ) 232 The inetDnsAuthServers attribute provides a listing of the 233 authoritative DNS servers associated with the domain name. 234 The attribute is defined as multi-valued, with each 235 attribute identifying the domain name of an authoritative 236 nameserver. 238 inetDnsContacts 239 ( 1.3.6.1.4.1.7161.1.3.3 240 NAME 'inetDnsContacts' 241 DESC 'Contacts for general administrative issues concerning 242 this domain name.' 243 EQUALITY caseIgnoreMatch 244 SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) 246 inetDnsDelegationDate 247 ( 1.3.6.1.4.1.7161.1.3.4 248 NAME 'inetDnsDelegationDate' 249 DESC 'Date this DNS domain name was delegated.' 250 EQUALITY generalizedTimeMatch 251 ORDERING generalizedTimeOrderingMatch 252 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 253 SINGLE-VALUE ) 255 inetDnsDelegationStatus 256 ( 1.3.6.1.4.1.7161.1.3.5 257 NAME 'inetDnsDelegationStatus' 258 DESC 'Delegation status of this domain name.' 259 EQUALITY numericStringMatch 260 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} 261 SINGLE-VALUE ) 262 NOTE: In an effort to facilitate internationalization and 263 programmatic processing, the current status of a delegation 264 is identified by a 16-bit integer. The values and status 265 mapping is as follows: 267 0 Reserved delegation (permanently inactive) 268 1 Assigned and active (normal state) 269 2 Assigned but not yet active (new delegation) 270 3 Assigned but on hold (disputed) 271 4 Assignment revoked (database purge pending) 272 5 Variant registration (alias for canonical domain) 274 Additional values are reserved for future use, and are to 275 be administered by IANA. 277 Note that there is no status code for "unassigned"; 278 unassigned entries SHOULD NOT exist, and SHOULD NOT be 279 returned as answers. 281 inetDnsRegistrar 282 ( 1.3.6.1.4.1.7161.1.3.6 283 NAME 'inetDnsRegistrar' 284 DESC 'Registrar who delegated this domain name.' 285 EQUALITY caseExactMatch 286 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 288 NOTE: The inetDnsRegistrar attribute uses a URL to indicate 289 the registrar who delegated the domain name. The attribute 290 structure is identical to the labeledURI attribute, as 291 defined in [RFC2798], including the URL and textual 292 comments. The data can refer to any valid URL. 294 inetDnsRegistry 295 ( 1.3.6.1.4.1.7161.1.3.7 296 NAME 'inetDnsRegistry' 297 DESC 'Registry where this domain name is managed.' 298 EQUALITY caseExactMatch 299 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 301 NOTE: The inetDnsRegistry attribute uses a URL to indicate 302 the registry who is ultimately responsible for the domain 303 name. The attribute structure is identical to the 304 labeledURI attribute, as defined in [RFC2798], including 305 the URL and textual comments. The data can refer to any 306 valid URL. 308 An example of the inetDnsDomain object class in use is shown in 309 Figure 1 below. The example includes attributes from the 310 inetDnsDomain, inetResources, and inetAssociatedResources object 311 classes. 313 cn=example.com,cn=inetResources,dc=netsol,dc=com 314 [top object class] 315 [inetResources object class] 316 [inetDnsDomain object class] 317 [inetAssociatedResources object class] 318 | 319 +-attribute: description 320 | value: "The example.com DNS domain" 321 | 322 +-attribute: inetDnsContacts 323 | value: "hostmaster@example.com" 324 | 325 +-attribute: inetAuthServers 326 | value: "ns1.example.net" 327 | value: "ns2.example.net" 328 | 329 +-attribute: inetAssociatedIpv4Network 330 value: "192.0.2.0/24" 332 Figure 1: The entry for the example.com DNS domain name in the 333 dc=netsol,dc=com partition. 335 5. Query Processing Rules 337 Queries for DNS domain names have several special requirements, as 338 discussed in the following sections. 340 Refer to [FIRS-CORE] for general information about FIRS queries. 342 5.1. Query Pre-Processing 344 Clients MUST ensure that the query input is normalized according 345 to the rules specified in section 3 before the input is used as 346 the assertion value to the resulting LDAP query. 348 The authoritative partition for a DNS domain name is determined by 349 mapping the normalized domain name to a sequence of 350 domainComponent labels. 352 Since the domainComponent attribute is restricted to seven-bit 353 characters, the normalized DNS domain name MUST be converted to 354 its IDNA form using the "ToASCII" conversion operation specified 355 in [RFC3490], with the "UseSTD3ASCIIRules" flag disabled (FIRS 356 applications MAY reuse the output from the conversion performed in 357 step 3.c.1 if the entire conversion process is known to have 358 completed successfully). The resulting sequence of ASCII labels 359 are used to form the domainComponent sequence which represents the 360 authoritative partition for the DNS domain name. 362 As a simple example, "www.example.com" would be mapped to the 363 "dc=www,dc=example,dc=com" authoritative partition, with this 364 partition being used to seed the query process. As a slightly more 365 complex example, the domain name of "weird name.example.com" would 366 be mapped to "dc=weird\032name,dc=example,dc=com". 368 5.2. Query Bootstrapping 370 FIRS clients MUST use the top-down bootstrap model by default for 371 DNS domain name queries. As such, the search base for default 372 queries would be set to the right-most domainComponent relative 373 distinguished name of the authoritative partition, rather than 374 being set to the fully-qualified distinguished name of the 375 authoritative partition. 377 FIRS clients MAY use the targeted or bottom-up bootstrap models 378 for queries if necessary or desirable. However, it is not likely 379 that entries will be found for all DNS domain name resources using 380 these models. As such, the top-down bootstrap model will be the 381 most useful in most cases, and MUST be used by default. 383 5.3. LDAP Matching 385 If the server advertises the inetDnsDomain object class in the 386 firsVersion server control, FIRS clients MUST use the 387 inetDnsDomainMatch extensible matching filter in LDAP searches for 388 DNS domain name entries. 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 inetDnsDomain object class entries which either match or are 394 delegation parents to the assertion value should be returned. 396 The inetDnsDomainMatch extensibleMatch filter is defined as 397 follows: 399 inetDnsDomainMatch 400 ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetDnsDomainMatch' SYNTAX 401 inetDnsDomainSyntax ) 403 The assertion value MUST be a normalized DNS domain name, using 404 the inetDnsDomainSyntax syntax rules defined in section 3. 406 A FIRS server MUST compare the assertion value against the RDN of 407 all entries in the inetResources container of the partition 408 specified in the search base which have an object class of 409 inetDnsDomain. Any entry with an object class of inetDnsDomain and 410 with a relative distinguished name which is either equal to or is 411 a delegation parent of the domain name provided in the assertion 412 value MUST be returned to the client. Entries which are child 413 delegations of the queried domain name MUST NOT be returned. 414 Entries in other delegation hierarchies MUST NOT be returned. 415 Entries which do not have an object class of inetDnsDomain MUST 416 NOT be returned. 418 In order to ensure that all of the relevant entries are found 419 (including any referrals), the search filters for these resources 420 MUST specify the inetDnsDomain object class along with the search 421 criteria. For example, "(&(objectclass=inetDnsDomain) 422 (1.3.6.1.4.1.7161.1.0.3:=example.com))" with a search base of 423 "cn=inetResources,dc=netsol,dc=com" would find all of the 424 inetDnsDomain object class entries in the delegation path to the 425 "example.com" domain in the "dc=netsol,dc=com" partition. 427 Domain names MUST be compared on label boundaries, and MUST NOT be 428 compared through simple character matching. Given two entries of 429 "cn=example.com" and "cn=an-example.com", only the first would 430 match an assertion value of "example.com". 432 Note that the entry name of "cn=." encompasses the entire DNS 433 domain namespace. When used in conjunction with referrals, this 434 entry MAY be used to redirect all inetDnsDomainMatch queries to 435 another partition for subsequent processing. 437 The matching filters defined in this specification MUST be 438 supported by FIRS clients and servers. FIRS servers MAY support 439 additional sub-string filters, soundex filters, or any other 440 filters they wish (these may be required to support generic LDAP 441 clients), although FIRS clients MUST NOT expect any additional 442 filters to be available. 444 If the server does not advertise support for the inetDnsDomain 445 object class in the firsVersion server control, the client MAY 446 choose to emulate this matching process through the use of 447 locally-constructed filters. Since the inetDnsDomainMatch filter 448 simply locates all of the entries in the delegation path to the 449 named domain, it is possible that a client could emulate this 450 query by generating distinct queries for any entries associated 451 with the parent domains. 453 For example, if the user asked for information about the 454 "www.example.com" domain name resource but the server does not 455 advertise support for the inetDnsDomain object class, the client 456 could theoretically issue distinct queries for inetDnsDomain 457 entries named "cn=com", "cn=example.com" and "cn=www.example.com". 459 As stated earlier, however, if the server advertises support for 460 the inetDnsDomain object class in the firsVersion control, then 461 the client MUST use the inetDnsDomainMatch filter defined above. 463 5.4. Example Query 465 The following example assumes that the user has specified 466 "www.example.com" as the query value: 468 a. Normalize the input, which is "www.example.com" in this 469 case. 471 b. Determine the authoritative partition, which is 472 "dc=www,dc=example,dc=com" in this case. By default, 473 queries for DNS domain names use the top-down model, 474 meaning that the right-most relative distinguished name of 475 "dc=com" will be used. 477 c. Determine the search base for the query, which will be 478 "cn=inetResources,dc=com" if the defaults are used. 480 d. Initiate a DNS lookup for the SRV resource records 481 associated with "_ldap._tcp.com." For the purpose of this 482 example, assume that this lookup succeeds, with the DNS 483 response message indicating that "firs.iana.org" is the 484 preferred LDAP server. 486 e. Submit an LDAPv3 query to the specified server, using 487 "(&(objectclass=inetDnsDomain) 488 (1.3.6.1.4.1.7161.1.3.8:=www.example.com))" as the matching 489 filter, "cn=inetResources,dc=com" as the search base, and 490 the global query defaults defined in [FIRS-CORE]. 492 f. Assume that the queried server returns a continuation 493 reference referral which points to 494 "ldap://cn=inetResources,dc=netsol,dc=com". The 495 distinguished name element of 496 "cn=inetResources,dc=netsol,dc=com" will be used as the new 497 search base, while "dc=netsol,dc=com" will be used as the 498 new authoritative partition. 500 g. Initiate a DNS lookup for the SRV resource records 501 associated with "_ldap._tcp.netsol.com." For the purpose of 502 this example, assume that this lookup succeeds, with the 503 DNS response message indicating that "firs.netsol.org" is 504 the preferred LDAP server. 506 h. Submit an LDAPv3 query to the specified server, using 507 "(&(objectclass=inetDnsDomain) 508 (1.3.6.1.4.1.7161.1.3.8:=www.example.com))" as the matching 509 filter, "cn=inetResources,dc=netsol,dc=com" as the search 510 base, and the global query defaults defined in [FIRS-CORE]. 512 i. Assume that no other referrals are received. Display the 513 answer data which has been received and exit the query. 515 6. Variant Domain Names 517 Some domain operators have policies which require that variant 518 forms of a domain name be assigned or reserved whenever the 519 underlying domain name is registered. For example, a domain 520 operator may choose to reserve look-alike forms of "foo" 521 (including "f00" and "fo0" and so forth), thereby preventing other 522 entities from registering the look-alike domain name. 524 This document reserves the inetDnsDelegationStatus attribute value 525 of "5" specifically for use with the look-alike domains. In this 526 model, the canonical domain name would have a typical entry, while 527 all of the look-alike domains would have entries with the 528 inetDnsDelegationStatus attribute value of "5", and would only 529 exist as referrals to the canonical domain name's entry. Searches 530 and lookups for the variant domain names would return referrals 531 which point to the canonical domain name entry. 533 An entry for the canonical domain name MUST exist in the 534 appropriate partition(s). These entries MAY include the variant 535 domain names as values of the optional inetAssociatedDnsDomains 536 attribute, if desired. 538 7. Security Considerations 540 Security considerations are discussed in [FIRS-ARCH]. 542 8. IANA Considerations 544 This specification assumes the existence of partitions for each of 545 the top-level domain names in the global DNS namespace, with the 546 expectation that FIRS-capable LDAP servers will be established for 547 each of these partitions, and with these partition containing 548 domain delegation entries which will provide referrals to the 549 appropriate registrar's partitions. It is expected that IANA will 550 encourage top-level domain registry operators to oversee the 551 creation and management of these resources. 553 It is further expected that IANA will oversee the creation and 554 management of the root domain's LDAP SRV resource records, the 555 "dc=." LDAP partition, and the necessary LDAP servers. 557 The inetDnsDelegationStatus attribute uses numeric code values. It 558 is expected that IANA will manage the assignment of these values. 560 Additional IANA considerations are discussed in [FIRS-ARCH]. 562 9. Normative References 564 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 565 Service: Architecture and Implementation 566 Guide", draft-ietf-crisp-firs-arch-02, July 567 2003. 569 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 570 System Numbers in the Federated Internet 571 Registry Service", draft-ietf-crisp-firs-asn- 572 02, July 2003. 574 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 575 Persons in the Federated Internet Registry 576 Service", draft-ietf-crisp-firs-contact-02, 577 July 2003. 579 [FIRS-CORE] Hall, E. "The Federated Internet Registry 580 Service: Core Elements", draft-ietf-crisp- 581 firs-core-02, July 2003. 583 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 584 the Federated Internet Registry Service", 585 draft-ietf-crisp-firs-dns-02, July 2003. 587 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 588 Records in the Federated Internet Registry 589 Service", draft-ietf-crisp-firs-dnsrr-02, July 590 2003. 592 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 593 Blocks in the Federated Internet Registry 594 Service", draft-ietf-crisp-firs-ipv4-02, July 595 2003. 597 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 598 Blocks in the Federated Internet Registry 599 Service", draft-ietf-crisp-firs-ipv6-02, July 600 2003. 602 [RFC2181] Elz, R., and Bush, R. "Clarifications to the 603 DNS Specification", RFC 2181, July 1997. 605 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 606 and Sataluri, S. "Using Domains in LDAP/X.500 607 DNs", RFC 2247, January 1998. 609 [RFC2251] Wahl, M., Howes, T., and Kille, S. 610 "Lightweight Directory Access Protocol (v3)", 611 RFC 2251, December 1997. 613 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 614 S. "Lightweight Directory Access Protocol 615 (v3): Attribute Syntax Definitions", RFC 2252, 616 December 1997. 618 [RFC2254] Howes, T. "The String Representation of LDAP 619 Search Filters", RFC 2254, December 1997. 621 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 622 ISO 10646", RFC 2279, January 1998. 624 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 625 "Internationalizing Domain Names in 626 Applications (IDNA)", RFC 3490, March 2003. 628 [STD13] Mockapetris, P. "Domain names - concepts and 629 facilities", STD 13, RFC 1034 and "Domain 630 names - implementation and specification", STD 631 13, RFC 1035, November 1987. 633 [US-ASCII] Cerf, V. "ASCII format for Network 634 Interchange", RFC 20, October 1969. 636 10. Changes from Previous Versions 638 draft-ietf-crisp-firs-dns-02: 640 * Several clarifications and corrections have been made. 642 * Several attributes had their OIDs changed. NOTE THAT THIS 643 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 644 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 646 draft-ietf-crisp-firs-dns-01: 648 * Several clarifications and corrections have been made. 650 draft-ietf-crisp-firs-dns-00: 652 * Restructured the document set. 654 * "Attribute references" have been eliminated from the 655 specification. All referential attributes now provide 656 actual data instead of URL pointers to data. Clients that 657 wish to retrieve these values will need to start new 658 queries using the data values instead of URLs. 660 * The various modified* operational attributes have been 661 eliminated as unnecessary. 663 * Several attributes had their OIDs changed. NOTE THAT THIS 664 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 665 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 667 draft-ietf-crisp-lw-dns-01: 669 * Added discussion for internationalized domain names. 671 * Moved attribute-specific security requirements to the 672 Security section. 674 11. Author's Address 676 Eric A. Hall 677 ehall@ehsco.com 679 12. Acknowledgments 681 Funding for the RFC editor function is currently provided by the 682 Internet Society. 684 Portions of this document were funded by Verisign Labs. 686 The first version of this specification was co-authored by Andrew 687 Newton of Verisign Labs, and subsequent versions continue to be 688 developed with his active participation. 690 13. Full Copyright Statement 692 Copyright (C) The Internet Society (2003). All Rights Reserved. 694 This document and translations of it may be copied and furnished 695 to others, and derivative works that comment on or otherwise 696 explain it or assist in its implementation may be prepared, 697 copied, published and distributed, in whole or in part, without 698 restriction of any kind, provided that the above copyright notice 699 and this paragraph are included on all such copies and derivative 700 works. However, this document itself may not be modified in any 701 way, such as by removing the copyright notice or references to the 702 Internet Society or other Internet organizations, except as needed 703 for the purpose of developing Internet standards in which case the 704 procedures for copyrights defined in the Internet Standards 705 process must be followed, or as required to translate it into 706 languages other than English. 708 The limited permissions granted above are perpetual and will not 709 be revoked by the Internet Society or its successors or assigns. 711 This document and the information contained herein is provided on 712 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 713 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 714 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 715 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.