idnits 2.17.1 draft-ietf-crisp-firs-dns-03.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 (August 2003) is 7559 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: 'RFC2798' is mentioned on line 390, but not defined == Unused Reference: 'RFC2181' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC2247' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'STD13' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 699, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' -- 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: 8 errors (**), 0 flaws (~~), 10 warnings (==), 9 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-03.txt August 2003 4 Expires: March, 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..............................3 46 3. Naming Syntax..............................................3 47 3.1. Normalization and Conversion............................4 48 3.2. Escape Syntax...........................................6 49 4. Object Classes and Attributes..............................7 50 5. Query Processing Rules....................................10 51 5.1. Query Pre-Processing...................................10 52 5.2. LDAP Matching..........................................11 53 5.3. Example Query..........................................13 54 6. Variant Domain Names......................................14 55 7. Security Considerations...................................14 56 8. IANA Considerations.......................................14 57 9. Normative References......................................15 58 10. Changes from Previous Versions............................16 59 11. Author's Address..........................................17 60 12. Acknowledgments...........................................18 61 13. Full Copyright Statement..................................18 63 1. Introduction 65 This specification defines the naming syntax, object classes, 66 attributes, matching filters, and query processing rules for 67 storing and locating DNS domain names in the FIRS service. Refer 68 to [FIRS-ARCH] for information on the FIRS architecture and 69 [FIRS-CORE] for the schema definitions and rules which govern the 70 FIRS service as a whole. 72 Note that these rules and definitions only apply to domain name 73 resources, and do not apply to domainComponent entries or any 74 other domain name elements, unless explicitly defined. Also note 75 that this specification governs reverse-lookup DNS domains for 76 IPv4 and IPv6 address blocks, but that these entries are entirely 77 different from the entries which govern the actual IPv4 and IPv6 78 address blocks themselves. 80 The definitions in this specification are intended to be used with 81 FIRS. Their usage outside of FIRS is not prohibited, but any such 82 usage is beyond this specification's scope of authority. 84 2. Prerequisites and Terminology 86 The complete set of specifications in the FIRS collection 87 cumulative define a structured and distributed information service 88 using LDAPv3 for the data-formatting and transport functions. This 89 specification should be read in the context of that set, which 90 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNSRR], 91 [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 94 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 95 in this document are to be interpreted as described in RFC 2119. 97 3. Naming Syntax 99 The naming syntax for DNS domains in FIRS MUST follow the form of 100 "cn=,cn=inetResources,", where 101 is the DNS domain name resource, and where 102 is a sequence of domainComponent relative 103 distinguished names which identifies the scope of authority for 104 the selected directory partition. 106 The inetDnsDomainSyntax syntax is as follows: 108 inetDnsDomainSyntax 109 ( 1.3.6.1.4.1.7161.1.3.0 110 NAME 'inetDnsDomainSyntax' 111 DESC 'A fully-qualified DNS domain name.' ) 113 The inetDnsDomainSyntax uses relatively unstructured UTF-8 114 strings, using standardized procedures to produce heavily- 115 normalized DNS domain names rather than using formal domain name 116 syntax rules. This is partly necessary due to conflicting syntax 117 rules in the different base specifications, but is also necessary 118 in order to support existing LDAP systems which do not know the 119 syntax rules. 121 Section 3.1 defines the normalization and conversion process which 122 is used to produce the standardized output. All systems which 123 generate DNS domain names for use with FIRS MUST use these 124 normalization and conversion process on those domain names. 126 3.1. Normalization and Conversion 128 The normalization and conversion routine described herein produce 129 UTF-8 [RFC2279] encoded domain names as output, with the resulting 130 sequences being suitable for equality matches, sub-string matches, 131 and a broad range of other matching operations. Once all of these 132 steps have successfully completed, the domain name can be stored 133 in the directory or used as an assertion value. Any fatal error 134 conditions encountered during these conversions MUST result in a 135 local failure; FIRS-aware applications MUST NOT store or transmit 136 non-normalized domain names for any purposes. 138 NOTE: The use of UTF-8 encoded domain names is ONLY required 139 for protocol-level exchanges of domain name resources. 140 Clients MAY use any encoding or transformation formats that 141 they wish for local presentation services. Specifically, 142 these requirements are intended to ensure interoperability 143 between clients and servers, and do not mandate any 144 presentation format at the client. 146 In general terms, the validation process requires that every 147 domain name which is to be stored in an internationalized domain 148 name element undergo a two-part conversion, with the input first 149 being reduced to its canonical IDNA-encoded form, and then being 150 expanded into its UTF-8 encoded UCS form. This process ensures 151 that the domain name has been validated as a semantically correct 152 IDNA sequence, and that the resulting internationalized domain 153 name has been properly normalized into its canonical form. 155 The full process is as follows: 157 a. Unless otherwise explicitly defined, disable the 158 UseSTD3ASCIIRules IDNA flag and enable the AllowUnassigned 159 IDNA flag, thereby permitting the broadest range of 160 character codes to be used. 162 b. If the input domain name terminates with a Full-Stop 163 character (0x2E), an Ideographic Full-Stop (U+3002), Full- 164 Width Full-Stop (U+FF0E) character, or a Half-Width 165 Ideographic Full-Stop (U+FF61), but does not consist of 166 that single character alone, remove the trailing character 167 from the input. 169 c. If the input domain name contains any octet values which 170 need to be protected from normalization, use the escape 171 syntax described in section 3.2 to protect those octets. 173 d. Perform the "ToASCII" conversion operation specified in 174 [RFC3490]. This step will reduce the input domain name to 175 the canonical IDNA-compatible form, thus ensuring that the 176 input data can be properly normalized when it is 177 reconstructed, and also ensuring that any subsequent 178 conversions back into the ASCII-compatible form will result 179 in predictable and legitimate domain names. 181 e. Perform the "ToUnicode" conversion operation specified in 182 [RFC3490] against the output from step 3.1.d above. This 183 step will convert the ASCII-compatible sequence into a 184 sequence of UCS code-point values. 186 f. Encode the output from step 3.1.e into UTF-8. 188 Note that the UseSTD3ASCIIRules and AllowUnassigned IDNA flags 189 MUST be set to their most liberal settings by default, and are not 190 to be used unless the underlying application-specific usage of a 191 domain name is known to require usage to the contrary. 193 By following these rules, internationalized domain names will 194 always be valid, and will always be usable by applications which 195 specifically make use of the elements, while those systems which 196 do not make explicit use of these elements but which may 197 inadvertently pass the internationalized domain names to other 198 applications will not be exposed to any potential risks which 199 could have been caused by malformed data. 201 Also note that these requirements are significantly more stringent 202 than the requirements for validating legacy domain names in the 203 legacy elements, and also apply to legacy-compatible domain names 204 which are stored in the internationalized elements. For example, 205 the existing domainComponent and mail attributes do not require 206 data to be validated against the known syntax rules for domain 207 names and email addresses, but instead simply limit the range of 208 character codes to a relatively small subset, while the rules 209 defined above will result in the same canonical input having a 210 stricter actual syntax. 212 Also note that UTF-8 character codes are frequently illegal as 213 data in URLs, and many of those octet values will probably be 214 escaped before they are stored in a URL as data. 216 3.2. Escape Syntax 218 Certain applications allow for the use of "unusual" characters or 219 octet values which are not typically associated with traditional 220 domain names, but which must be preserved in order for the 221 associated applications to function properly. For example, an 222 application-specific domain name may contain an Underscore 223 character (0x5F) or a Space character (0x20), or may contain a 224 "raw" octet value such as 0xC0 which cannot be treated as a UCS 225 character code during normalization routines (otherwise the 226 corresponding UCS character code value would be interpreted and 227 lowercased, thus destroying the actual octet value). 229 In order to ensure that these kinds of values are properly 230 preserved, a formal escape syntax is defined for their use. In 231 general terms, this syntax requires problematic eight-bit values 232 to be replaced with a Reverse-Solidus character (0x5C, "\"), 233 followed by a three-digit decimal value (in the range of "000" 234 through "255") that corresponds to the canonical octet value. 236 This escape syntax MUST be applied to any octet value which does 237 not explicitly represent a printable character (0x00 through 0x20, 238 0x7F through 0x9F, and 0xA0, inclusive), or which represents an 239 embedded Reverse-Solidus character (0x5C, "\"). In those cases 240 where a valid escape sequence already exists, that sequence 241 (including its leading Reverse-Solidus character) MUST NOT be 242 escaped again. 244 This escape syntax MAY be applied to any other character code or 245 octet value, although the unnecessary usage of this mechanism is 246 strongly DISCOURAGED. Furthermore, the availability of this 247 mechanism MUST NOT be interpreted to mean that this mechanism can 248 be used with any domain name; instead, it is only to be used with 249 application-specific domain names which explicitly allow the 250 presence of these problematic characters. 252 For example, if an application-specific domain name contains 253 "weird name.example.com", the "weird name" portion of that domain 254 name MUST be escaped as "weird\032name". Meanwhile, if an 255 application-specific domain name contains "local\046postmaster", 256 this sequence would be unmodified since the Reverse-Solidus 257 character is already part of a valid escape sequence. 259 This escape syntax MUST be applied to an input domain name before 260 that domain name undergoes the conversion process described in 261 section 3.1. Furthermore, the leaf-node applications which 262 generate and use these domain names SHOULD escape the data before 263 it is passed to an LDAP agent, since those agents cannot be 264 expected to know all of the application-specific usages of a 265 domain name. For example, an application which uses a domain name 266 with an embedded Full-Stop character (0x2E, ".") SHOULD escape 267 that character before storing or passing the domain name to an 268 LDAP agent, thus eliminating the possibility of having that agent 269 interpret the embedded Full-Stop character as a label separator. 271 Note that any Reverse Solidus characters in the resulting domain 272 name will be further escaped when these sequences are transferred 273 in LDAP messages. For example, "weird\032name" will be further 274 escaped as "weird\\032name" when it is passed in an LDAP message 275 (this secondary escape will be stripped upon receipt, leaving the 276 escaped domain name in its original form). 278 Also note that Reverse-Solidus characters are frequently illegal 279 as data in URIs, and these characters will probably end up being 280 percent-escaped whenever they are provided in a URI as data. 282 4. Object Classes and Attributes 284 DNS domain name entries in FIRS MUST use the inetDnsDomain object 285 class, in addition to the mandatory object classes defined in 286 [FIRS-CORE]. DNS domain name entries MUST be treated as containers 287 capable of holding subordinate entries. 289 If an entry exists as a referral source, the entry MUST be defined 290 with the referral object class, in addition to the other object 291 classes defined above. Referral sources MUST NOT contain 292 subordinate entries. Refer to section 3.5 of [FIRS-CORE] for more 293 information on referral entries in FIRS. 295 The inetDnsDomain object class is a structural object class which 296 is subordinate to the inetResources object class. The 297 inetDnsDomain object class has no mandatory attributes, although 298 it does have several optional attributes. The inetDnsDomain object 299 class also inherits the attributes defined in the inetResources 300 object class, including the "cn" naming attribute. 302 Domain name entries MAY also be defined with the inetDnsRR 303 auxiliary object class (as described in [FIRS-DNSRR]), which 304 provides DNS resource records as attributes. For example, if a 305 domain name entry needs to publish a list of authoritative DNS 306 servers for the associated domain name, those values would be 307 provided through the use of the inetDnsRR object class and its 308 related attributes. 310 The schema definition for the inetDnsDomain object class is as 311 follows: 313 inetDnsDomain 314 ( 1.3.6.1.4.1.7161.1.3.1 315 NAME 'inetDnsDomain' 316 DESC 'DNS domain attributes.' 317 SUP inetResources 318 STRUCTURAL 319 MAY ( inetDnsDelegationStatus $ inetDnsDelegationDate $ 320 inetDnsRegistrar $ inetDnsRegistry $ inetDnsContacts ) ) 322 The attributes from the inetDnsDomain object class are described 323 below: 325 inetDnsContacts 326 ( 1.3.6.1.4.1.7161.1.3.2 327 NAME 'inetDnsContacts' 328 DESC 'Contacts for general administrative issues concerning 329 this domain name.' 330 EQUALITY caseIgnoreMatch 331 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 333 inetDnsDelegationDate 334 ( 1.3.6.1.4.1.7161.1.3.3 335 NAME 'inetDnsDelegationDate' 336 DESC 'Date this DNS domain name was delegated.' 337 EQUALITY generalizedTimeMatch 338 ORDERING generalizedTimeOrderingMatch 339 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 340 SINGLE-VALUE ) 342 inetDnsDelegationStatus 343 ( 1.3.6.1.4.1.7161.1.3.4 344 NAME 'inetDnsDelegationStatus' 345 DESC 'Delegation status of this domain name.' 346 EQUALITY numericStringMatch 347 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} 348 SINGLE-VALUE ) 349 NOTE: In an effort to facilitate internationalization and 350 programmatic processing, the current status of a delegation 351 is identified by a 16-bit integer. The values and status 352 mapping is as follows: 354 0 Reserved delegation (permanently inactive) 355 1 Assigned and active (normal state) 356 2 Assigned but not yet active (new delegation) 357 3 Assigned but on hold (disputed) 358 4 Assignment revoked (database purge pending) 360 Additional values are reserved for future use, and are to 361 be administered by IANA. 363 Note that there is no status code for "unassigned"; 364 unassigned entries SHOULD NOT exist, and SHOULD NOT be 365 returned as answers. 367 inetDnsRegistrar 368 ( 1.3.6.1.4.1.7161.1.3.5 369 NAME 'inetDnsRegistrar' 370 DESC 'Registrar who delegated this domain name.' 371 EQUALITY caseExactMatch 372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 374 NOTE: The inetDnsRegistrar attribute uses a URL to indicate 375 the registrar who delegated the domain name. The attribute 376 structure is identical to the labeledURI attribute, as 377 defined in [RFC2798], including the URL and textual 378 comments. The data can refer to any valid URL. 380 inetDnsRegistry 381 ( 1.3.6.1.4.1.7161.1.3.6 382 NAME 'inetDnsRegistry' 383 DESC 'Registry where this domain name is managed.' 384 EQUALITY caseExactMatch 385 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 387 NOTE: The inetDnsRegistry attribute uses a URL to indicate 388 the registry who is ultimately responsible for the domain 389 name. The attribute structure is identical to the 390 labeledURI attribute, as defined in [RFC2798], including 391 the URL and textual comments. The data can refer to any 392 valid URL. 394 Two examples of the inetDnsDomain object class are shown below. 395 The examples also include attributes from the inetResources and 396 referral object classes. 398 cn=example.com,cn=inetResources,dc=com 399 [top object class] 400 [inetResources object class] 401 [inetDnsDomain object class] 402 | 403 +-attribute: description 404 | value: "The example.com DNS domain" 405 | 406 +-attribute: inetDnsContacts 407 | value: "hostmaster@example.com" 408 | 409 +-cn=ref1,cn=example.com,cn=inetResources,dc=com 410 [top object class] 411 [inetResources object class] 412 [inetDnsDomain object class] 413 [referral object class] 414 | 415 +-attribute: ref 416 value: "ldap:///dc=registrar,dc=com??? 417 (1.3.6.1.4.1.7161.1.3.0.1:=example.com)" 419 Figure 1: The entry for the example.com DNS domain name in the 420 dc=com partition, and a referral child entry. 422 5. Query Processing Rules 424 Queries for DNS domain names have several special requirements, as 425 discussed in the following sections. 427 Refer to [FIRS-CORE] for general information about FIRS queries. 429 5.1. Query Pre-Processing 431 FIRS clients MUST use the top-down bootstrap model by default for 432 DNS domain name queries. As such, the search base for default 433 queries would be set to the right-most domainComponent relative 434 distinguished name of the authoritative partition, rather than 435 being set to the fully-qualified distinguished name of the 436 authoritative partition. 438 FIRS clients MAY use the targeted or bottom-up bootstrap models 439 for queries if necessary or desirable. However, it is not likely 440 that entries will be found for all DNS domain name resources using 441 these models. As such, the top-down bootstrap model will be the 442 most useful in most cases, and MUST be used by default. 444 When the bottom-up bootstrap model is used, the authoritative 445 partition for a DNS domain name is determined by mapping the 446 normalized domain name to a sequence of domainComponent labels. 448 As a simple example, "www.example.com" would be mapped to the 449 "dc=www,dc=example,dc=com" authoritative partition, with this 450 partition being used to seed the query process. As a slightly more 451 complex example, the domain name of "weird name.example.com" would 452 be mapped to "dc=weird\032name,dc=example,dc=com". 454 Since the domainComponent attribute is restricted to seven-bit 455 characters, the normalized DNS domain name MUST be converted to 456 its IDNA form using the "ToASCII" conversion operation specified 457 in [RFC3490] before these lookups are performed, with the 458 "UseSTD3ASCIIRules" flag disabled (FIRS applications MAY reuse the 459 output from the conversion performed in step 3.1.d if the entire 460 conversion process is known to have completed successfully). The 461 resulting sequence of ASCII labels are used to form the 462 domainComponent sequence which represents the authoritative 463 partition for the DNS domain name. 465 5.2. LDAP Matching 467 If the server advertises the inetDnsDomain object class and the 468 inetDnsDomainMatch matching filter in the inetResourcesControl 469 server control, FIRS clients MUST use the inetDnsDomainMatch 470 matching filter in LDAP searches for DNS domain name entries. 472 The inetDnsDomainMatch filter provides an identifier and search 473 string format which collectively inform a queried server that a 474 specific DNS domain name should be searched for, and that any 475 inetDnsDomain object class entries which either match or are 476 delegation parents to the assertion value should be returned. 478 The inetDnsDomainMatch filter is defined as follows: 480 inetDnsDomainMatch 481 ( 1.3.6.1.4.1.7161.1.3.0.1 482 NAME 'inetDnsDomainMatch' 483 SYNTAX 1.3.6.1.4.1.7161.1.3.0 ) 484 Clients MUST ensure that the query input is normalized according 485 to the rules specified in section 3 before the input is used as 486 the assertion value to the resulting LDAP query. 488 A FIRS server MUST compare the assertion value against the 489 distinguished name of all entries within and beneath the container 490 specified by the search base of the query. Any entry in that 491 hierarchy with an object class of inetDnsDomain and a 492 distinguished name component that is either equal to or is a 493 delegation parent of the domain name provided in the assertion 494 value MUST be returned to the client (this specifically includes 495 any child entries, such as referral stubs). Entries which do not 496 have an object class of inetDnsDomain MUST NOT be returned. 497 Entries with distinguished name for other delegation hierarchies 498 MUST NOT be returned. Entries with distinguished names for child 499 domains MUST NOT be returned. 501 An example of this matching logic is illustrated below, using the 502 assertion value of "example.com" and the search base of 503 "cn=inetResources,dc=com": 505 set searchBase "cn=inetResources,dc=com" 506 find ( ( objectClass equals inetDnsDomain) and 507 ( ( nameComponent equals "cn=com" ) or 508 ( nameComponent equals "cn=example.com") ) 510 Domain names MUST be compared on label boundaries, and MUST NOT be 511 compared through simple character matching. Given two entries of 512 "cn=example.com" and "cn=an-example.com", only the first would 513 match an assertion value of "example.com". 515 Note that the entry name of "cn=." encompasses the entire DNS 516 domain namespace. When used in conjunction with referrals, this 517 entry MAY be used to redirect all inetDnsDomainMatch queries to 518 another partition for subsequent processing. 520 The matching filters defined in this specification MUST be 521 supported by FIRS clients and servers. FIRS servers MAY support 522 additional matching filters, although FIRS clients MUST NOT expect 523 any additional filters to be available. 525 If the server does not advertise support for the 526 inetDnsDomainMatch matching filter in the inetResourcesControl 527 server control, the client MAY choose to emulate the matching 528 filter through the use of locally-constructed equalityMatch 529 filters. However, this process can result in incomplete answers in 530 some cases, so if the server advertises support for the 531 inetDnsDomainMatch matching filter in the inetResourcesControl 532 control, the client MUST use it. 534 5.3. Example Query 536 The following example assumes that the user has specified 537 "www.example.com" as the query value: 539 a. Normalize the input, which is "www.example.com" in this 540 case. 542 b. Determine the authoritative partition, which is 543 "dc=www,dc=example,dc=com" in this case. By default, 544 queries for DNS domain names use the top-down model, 545 meaning that the right-most relative distinguished name of 546 "dc=com" will be used. 548 c. Determine the search base for the query, which will be 549 "cn=inetResources,dc=com" if the defaults are used. 551 d. Initiate a DNS lookup for the SRV resource records 552 associated with "_ldap._tcp.com." For the purpose of this 553 example, assume that this lookup succeeds, with the DNS 554 response message indicating that "firs.iana.org" is the 555 preferred LDAP server. 557 e. Submit an LDAPv3 query to the specified server, using 558 "(1.3.6.1.4.1.7161.1.3.0.1:=www.example.com)" as the 559 matching filter, "cn=inetResources,dc=com" as the search 560 base, and the global query defaults defined in [FIRS-CORE]. 562 f. Assume that the queried server returns a continuation 563 reference referral which points to 564 "ldap:///cn=inetResources,dc=netsol,dc=com". The 565 distinguished name element of 566 "cn=inetResources,dc=netsol,dc=com" will be used as the new 567 search base, while "dc=netsol,dc=com" will be used as the 568 new authoritative partition. 570 g. Initiate a DNS lookup for the SRV resource records 571 associated with "_ldap._tcp.netsol.com." For the purpose of 572 this example, assume that this lookup succeeds, with the 573 DNS response message indicating that "firs.netsol.org" is 574 the preferred LDAP server. 576 h. Submit an LDAPv3 query to the specified server, using 577 "(1.3.6.1.4.1.7161.1.3.0.1:=www.example.com)" as the 578 matching filter, "cn=inetResources,dc=netsol,dc=com" as the 579 search base, and the global query defaults defined in 580 [FIRS-CORE]. 582 i. Assume that no other referrals are received. Display the 583 answer data which has been received and exit the query. 585 6. Variant Domain Names 587 Some domain operators have policies which require that variant 588 forms of a domain name be assigned or reserved whenever the 589 underlying domain name is registered. For example, a domain 590 operator may choose to reserve look-alike forms of "foo" 591 (including "f00" and "fo0" and so forth), thereby preventing other 592 entities from registering the look-alike domain name. 594 This document reserves the inetDnsDelegationStatus attribute value 595 of "5" specifically for use with the look-alike domains. In this 596 model, the canonical domain name would have a typical entry, while 597 all of the look-alike domains would have entries with the 598 inetDnsDelegationStatus attribute value of "5", and would only 599 exist as referrals to the canonical domain name's entry. Searches 600 and lookups for the variant domain names would return referrals 601 which point to the canonical domain name entry. 603 An entry for the canonical domain name MUST exist in the 604 appropriate partition(s). These entries MAY include the variant 605 domain names as values of the optional inetAssociatedDnsDomains 606 attribute, if desired. 608 7. Security Considerations 610 Security considerations are discussed in [FIRS-ARCH]. 612 8. IANA Considerations 614 This specification assumes the existence of partitions for each of 615 the top-level domain names in the global DNS namespace, with the 616 expectation that FIRS-capable LDAP servers will be established for 617 each of these partitions, and with these partition containing 618 domain delegation entries which will provide referrals to the 619 appropriate registrar's partitions. It is expected that IANA will 620 encourage top-level domain registry operators to oversee the 621 creation and management of these resources. 623 It is further expected that IANA will oversee the creation and 624 management of the root domain's LDAP SRV resource records, the 625 "dc=." LDAP partition, and the necessary LDAP servers. 627 The inetDnsDelegationStatus attribute uses numeric code values. It 628 is expected that IANA will manage the assignment of these values. 630 Additional IANA considerations are discussed in [FIRS-ARCH]. 632 9. Normative References 634 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 635 Service: Architecture and Implementation 636 Guide", draft-ietf-crisp-firs-arch-03, August 637 2003. 639 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 640 System Numbers in the Federated Internet 641 Registry Service", draft-ietf-crisp-firs-asn- 642 03, August 2003. 644 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 645 Persons in the Federated Internet Registry 646 Service", draft-ietf-crisp-firs-contact-03, 647 August 2003. 649 [FIRS-CORE] Hall, E. "The Federated Internet Registry 650 Service: Core Elements", draft-ietf-crisp- 651 firs-core-03, August 2003. 653 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 654 Records in the Federated Internet Registry 655 Service", draft-ietf-crisp-firs-dnsrr-02, July 656 2003. 658 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 659 Blocks in the Federated Internet Registry 660 Service", draft-ietf-crisp-firs-ipv4-03, 661 August 2003. 663 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 664 Blocks in the Federated Internet Registry 665 Service", draft-ietf-crisp-firs-ipv6-03, 666 August 2003. 668 [RFC2181] Elz, R., and Bush, R. "Clarifications to the 669 DNS Specification", RFC 2181, July 1997. 671 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 672 and Sataluri, S. "Using Domains in LDAP/X.500 673 DNs", RFC 2247, January 1998. 675 [RFC2251] Wahl, M., Howes, T., and Kille, S. 676 "Lightweight Directory Access Protocol (v3)", 677 RFC 2251, December 1997. 679 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 680 S. "Lightweight Directory Access Protocol 681 (v3): Attribute Syntax Definitions", RFC 2252, 682 December 1997. 684 [RFC2254] Howes, T. "The String Representation of LDAP 685 Search Filters", RFC 2254, December 1997. 687 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 688 ISO 10646", RFC 2279, January 1998. 690 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 691 "Internationalizing Domain Names in 692 Applications (IDNA)", RFC 3490, March 2003. 694 [STD13] Mockapetris, P. "Domain names - concepts and 695 facilities", STD 13, RFC 1034 and "Domain 696 names - implementation and specification", STD 697 13, RFC 1035, November 1987. 699 [US-ASCII] Cerf, V. "ASCII format for Network 700 Interchange", RFC 20, October 1969. 702 10. Changes from Previous Versions 704 draft-ietf-crisp-firs-dns-03: 706 * Several clarifications and corrections have been made. 708 * The normalization rules were rewritten to be more exacting 709 and precise. 711 * Clarified the matching behavior, and added sample logic 712 that demonstrates efficient matching behavior. 714 * The inetDnsAuthServers attribute was removed. Name servers 715 for a domain resource should be listed using the inetDnsRR 716 object class instead. 718 * Several attributes had their OIDs changed. NOTE THAT THIS 719 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 720 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 722 draft-ietf-crisp-firs-dns-02: 724 * Several clarifications and corrections have been made. 726 * Several attributes had their OIDs changed. NOTE THAT THIS 727 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 728 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 730 draft-ietf-crisp-firs-dns-01: 732 * Several clarifications and corrections have been made. 734 draft-ietf-crisp-firs-dns-00: 736 * Restructured the document set. 738 * "Attribute references" have been eliminated from the 739 specification. All referential attributes now provide 740 actual data instead of URL pointers to data. Clients that 741 wish to retrieve these values will need to start new 742 queries using the data values instead of URLs. 744 * The various modified* operational attributes have been 745 eliminated as unnecessary. 747 * Several attributes had their OIDs changed. NOTE THAT THIS 748 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 749 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 751 draft-ietf-crisp-lw-dns-01: 753 * Added discussion for internationalized domain names. 755 * Moved attribute-specific security requirements to the 756 Security section. 758 11. Author's Address 760 Eric A. Hall 761 ehall@ehsco.com 762 12. Acknowledgments 764 Funding for the RFC editor function is currently provided by the 765 Internet Society. 767 Portions of this document were funded by Verisign Labs. 769 The first version of this specification was co-authored by Andrew 770 Newton of Verisign Labs, and subsequent versions continue to be 771 developed with his active participation. 773 13. Full Copyright Statement 775 Copyright (C) The Internet Society (2003). All Rights Reserved. 777 This document and translations of it may be copied and furnished 778 to others, and derivative works that comment on or otherwise 779 explain it or assist in its implementation may be prepared, 780 copied, published and distributed, in whole or in part, without 781 restriction of any kind, provided that the above copyright notice 782 and this paragraph are included on all such copies and derivative 783 works. However, this document itself may not be modified in any 784 way, such as by removing the copyright notice or references to the 785 Internet Society or other Internet organizations, except as needed 786 for the purpose of developing Internet standards in which case the 787 procedures for copyrights defined in the Internet Standards 788 process must be followed, or as required to translate it into 789 languages other than English. 791 The limited permissions granted above are perpetual and will not 792 be revoked by the Internet Society or its successors or assigns. 794 This document and the information contained herein is provided on 795 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 796 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 797 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 798 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.