idnits 2.17.1 draft-ietf-crisp-firs-dnsrr-00.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 7645 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) == Unused Reference: 'RFC2247' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 243, but no explicit reference was found in the text ** 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) == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' Summary: 6 errors (**), 0 flaws (~~), 14 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-dnsrr-00.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 Defining and Locating DNS Resource Records 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 resource records, in support of the Internet Resource Query 40 Service 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.............................3 48 5. Query Processing..........................................5 49 6. Security Considerations...................................6 50 7. IANA Considerations.......................................6 51 8. Author's Addresses........................................6 52 9. Normative References......................................6 53 10. Acknowledgments...........................................7 54 11. Changes from Previous Versions............................7 55 12. Full Copyright Statement..................................7 57 1. Introduction 58 This specification defines the naming syntax, object classes, 59 attributes, matching filters, and query processing rules for 60 storing and locating DNS resource records in the FIRS service. 61 Refer to [FIRS-ARCH] for information on the FIRS architecture and 62 [FIRS-CORE] for the schema definitions and rules which govern the 63 FIRS service as a whole. 65 Note that these rules and definitions only apply to DNS resource 66 records in FIRS, and do not apply to domainComponent entries or 67 any other domain name elements, unless explicity defined. 69 The definitions in this specification are intended to be used with 70 FIRS. Their usage outside of FIRS is not prohibited, but any such 71 usage is beyond this specification's scope of authority. 73 2. Prerequisites and Terminology 74 The complete set of specifications in the FIRS collection 75 cumulative define a structured and distributed information service 76 using LDAPv3 for the data-formatting and transport functions. This 77 specification should be read in the context of the complete set of 78 specifications, which currently include the following: 80 draft-ietf-crisp-firs-arch-00, "The Federated Internet 81 Registry Service: Architecture and Implementation" 82 [FIRS-ARCH] 83 draft-ietf-crisp-firs-core-00, "The Federated Internet 84 Registry Service: Core Elements" [FIRS-CORE] 86 draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS 87 Domains in the Federated Internet Registry Service" 88 [FIRS-DNS] 90 draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS 91 Resource Records in the Federated Internet Registry 92 Service" (this document) [FIRS-DNSRR] 94 draft-ietf-crisp-firs-contact-00, "Defining and Locating 95 Contact Persons in the Federated Internet Registry Service" 96 [FIRS-CONTCT] 98 draft-ietf-crisp-firs-asn-00, "Defining and Locating 99 Autonomous System Numbers in the Federated Internet 100 Registry Service" [FIRS-ASN] 102 draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 103 Address Blocks in the Federated Internet Registry Service" 104 [FIRS-IPV4] 106 draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 107 Address Blocks in the Federated Internet Registry Service" 108 [FIRS-IPV6] 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 111 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 112 in this document are to be interpreted as described in RFC 2119. 114 3. Naming syntax 115 This specification does not define new syntax rules. DNS resource 116 records are provided as supplemental data to DNS domain name 117 entries. As such, this data relies on pre-existing entries which 118 conform to the naming syntax defined in [FIRS-DNS]. 120 4. Object Classes and Attributes 121 DNS resource record entries in FIRS MUST use the inetDnsRR object 122 class, in addition to the inetDnsDomain object class defined in 123 [FIRS-DNS] and the mandatory object classes defined in 125 [FIRS-CORE]. If an entry exists as a referral source, the entry 126 MUST also be defined with the referral object class, in addition 127 to the above requirements. 129 The inetDnsRR object class is an auxiliary object class which is 130 subordinate to the inetDnsDomain object class. The inetDnsRR 131 object class has no mandatory attributes, and only has one 132 optional attribute which is inetDnsRRData. The inetDnsRR object 133 class also inherits the attributes defined in the inetDnsDomain 134 and inetResources object classes, including the "cn" naming 135 attribute. 137 The schema definition for the inetDnsRR object class is as 138 follows: 140 inetDnsRR 141 ( 1.3.6.1.4.1.7161.1.6.0 NAME 'inetDnsRR' DESC 'DNS record 142 records.' SUP inetDnsDomain AUXILIARY MAY inetDnsRRData ) 144 The inetDnsRRData attribute is described as follows: 146 inetDnsRRData 147 ( 1.3.6.1.4.1.7161.1.6.2 NAME 'inetDnsRRData' DESC 'Generic 148 DNS record record data.' EQUALITY caseIgnoreMatch SYNTAX 149 inetDnsRRDataSyntax ) 151 The inetDnsRRData attribute is a structured (SEQUENCE) attribute, 152 containing multiple subordinate attributes. The layout of the 153 subordinate attributes is identical to the layout of DNS resource 154 records in the domain name system data message. The inetDnsRRData 155 attribute is also multi-valued. This model allows multiple 156 resource records to be associated with each entry, with each 157 resource record having different types, classes, time-to-live 158 values, data values, and so forth. 160 The inetDnsRRDataSyntax syntax is defined in ASN.1 as follows: 162 inetDnsRRDataSyntax ::= SEQUENCE { 163 RRType INTEGER (0..65535), 164 RRClass INTEGER (0..65535), 165 RRTTL INTEGER (0..4294967295), 166 RRLen INTEGER (0..65535), 167 RRData OCTET STRING (SIZE (0..65535)) } 169 Note that data which is stored in the RRData element MUST NOT 170 represent compressed domain names. 172 An example of the inetDnsRR object class in use is shown in Figure 173 1 below. The example includes attributes from the inetDnsRR, 174 inetDnsDomain, inetResources, and inetAssociatedResources object 175 classes. 177 cn=ns1.example.com,cn=inetResources,dc=example,dc=com 178 [top object class] 179 [inetResources object class] 180 [inetDnsDomain object class] 181 [inetDnsRR object class] 182 [inetAssociatedResources object class] 183 | 184 +-attribute: description 185 | value: "The master DNS server for the example.com domain" 186 | 187 +-attribute: inetDnsContacts 188 | value: "hostmaster@example.com" 189 | 190 +-attribute: inetDnsRRData 191 | value: (1, 1, 3600, 4, 0xC0 0x00 0x02 0x0E) 192 | 193 +-attribute: inetAssociatedDnsDomain 194 value: "example.com" 196 Figure 1: The entry for the ns1.example.com DNS domain name and 197 its associated resource records. 199 In the example shown above, the ns1.example.com domain name has a 200 single inetDnsRRData attribute, which provides a single IPv4 201 address resource record. The subordinate elements of that 202 attribute indicate a RRType value of "1" (IPv4 Address), a RRClass 203 value of "1" (the Internet class), a RRTTL value of 3600 (a TTL of 204 one hour), a RRLen value of 4 (four octets of data), and four 205 single-octet data values which mirror the DNS format of IPv4 206 addresses (in this case, the IPv4 address of "192.0.2.14"). 208 5. Query Processing 209 This specification does not define new query processing rules. DNS 210 resource records are provided as supplemental data to DNS domain 211 name entries. As such, this data relies on the query processing 212 rules defined in [FIRS-DNS]. 214 Note that the use of bottom-up processing is more likely to 215 succeed when searching for DNS domain names with resource record 216 attributes, since these entries are more likely to exist. However, 217 the default usage of top-down processing is still preferred. 219 6. Security Considerations 220 Security considerations are discussed in [FIRS-ARCH]. 222 7. IANA Considerations 223 IANA considerations are discussed in [FIRS-ARCH]. 225 8. Author's Addresses 226 Eric A. Hall 227 ehall@ehsco.com 229 9. Normative References 230 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 231 and Sataluri, S. "Using Domains in LDAP/X.500 232 DNs", RFC 2247, January 1998. 234 [RFC2251] Wahl, M., Howes, T., and Kille, S. 235 "Lightweight Directory Access Protocol (v3)", 236 RFC 2251, December 1997. 238 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 239 S. "Lightweight Directory Access Protocol 240 (v3): Attribute Syntax Definitions", RFC 2252, 241 December 1997. 243 [RFC2254] Howes, T. "The String Representation of LDAP 244 Search Filters", RFC 2254, December 1997. 246 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 247 Service: Architecture and Implementation 248 Guide", draft-ietf-crisp-firs-arch-00, May 249 2003. 251 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 252 System Numbers in the Federated Internet 253 Registry Service", draft-ietf-crisp-firs-asn- 254 00, May 2003. 256 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 257 Persons in the Federated Internet Registry 258 Service", draft-ietf-crisp-firs-contact-00, 259 May 2003. 261 [FIRS-CORE] Hall, E. "The Federated Internet Registry 262 Service: Core Elements", draft-ietf-crisp- 263 firs-core-00, May 2003. 265 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 266 the Federated Internet Registry Service", 267 draft-ietf-crisp-firs-dns-00, May 2003. 269 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 270 Records in the Federated Internet Registry 271 Service", draft-ietf-crisp-firs-dnsrr-00, May 272 2003. 274 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 275 Blocks in the Federated Internet Registry 276 Service", draft-ietf-crisp-firs-ipv4-00, May 277 2003. 279 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 280 Blocks in the Federated Internet Registry 281 Service", draft-ietf-crisp-firs-ipv6-00, May 282 2003. 284 10. Acknowledgments 285 Funding for the RFC editor function is currently provided by the 286 Internet Society. 288 Portions of this document were funded by Verisign Labs. 290 Thanks to Stig Venaas for providing constructive feedback during 291 the early development of this specification. 293 11. Changes from Previous Versions 294 draft-ietf-crisp-fir-dnsrr-00: 296 * Restructured the document set. 298 12. Full Copyright Statement 299 Copyright (C) The Internet Society (2003). All Rights Reserved. 301 This document and translations of it may be copied and furnished 302 to others, and derivative works that comment on or otherwise 303 explain it or assist in its implementation may be prepared, 304 copied, published and distributed, in whole or in part, without 305 restriction of any kind, provided that the above copyright notice 306 and this paragraph are included on all such copies and derivative 307 works. However, this document itself may not be modified in any 308 way, such as by removing the copyright notice or references to the 309 Internet Society or other Internet organizations, except as needed 310 for the purpose of developing Internet standards in which case the 311 procedures for copyrights defined in the Internet Standards 312 process must be followed, or as required to translate it into 313 languages other than English. 315 The limited permissions granted above are perpetual and will not 316 be revoked by the Internet Society or its successors or assigns. 318 This document and the information contained herein is provided on 319 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 320 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 321 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.