idnits 2.17.1 draft-ietf-crisp-firs-dnsrr-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 7584 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: 'FIRS-DNSRR' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC2247' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 304, 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) 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-02.txt July 2003 4 Expires: February, 2004 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 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 4. Object Classes and Attributes.............................3 48 5. Query Processing..........................................6 49 6. Security Considerations...................................7 50 7. IANA Considerations.......................................7 51 8. Normative References......................................7 52 9. Changes from Previous Versions............................8 53 10. Author's Address..........................................8 54 11. Acknowledgments...........................................8 55 12. Full Copyright Statement..................................9 57 1. Introduction 59 This specification defines the naming syntax, object classes, 60 attributes, matching filters, and query processing rules for 61 storing and locating DNS resource records in the FIRS service. 62 Refer to [FIRS-ARCH] for information on the FIRS architecture and 63 [FIRS-CORE] for the schema definitions and rules which govern the 64 FIRS service as a whole. 66 DNS resource records are intended to be stored in FIRS whenever 67 the resource record data is useful or necessary. In the common 68 case, this data will provide the IP addresses which are associated 69 with a known "nameserver" host. In that scenario, the relative 70 distinguished name of the entry will be the fully-qualified domain 71 name of the host, with the multi-valued inetDnsRRData attribute 72 providing each of the "A" or "AAAA" resource records associated 73 with that host. 75 Although that specific information could be provided with narrow- 76 use attributes, this specification provides a generalized storage 77 format for DNS resource records so that other kinds of resource 78 record data may also be stored in FIRS, when desirable. For 79 example, it is feasible that another application of FIRS may need 80 to retrieve "MX" resource records or "SOA" resource records 81 associated with a domain name, and using a generalized format 82 facilitates these eventual application scenarios. Furthermore, 83 some DNS servers are known to store zone data in LDAP, and the use 84 of a generalized format facilitates interoperability. 86 Note that these rules and definitions only apply to DNS resource 87 records in FIRS, and do not apply to domainComponent entries or 88 any other domain name elements, unless explicitly defined. 90 The definitions in this specification are intended to be used with 91 FIRS. Their usage outside of FIRS is not prohibited, but any such 92 usage is beyond this specification's scope of authority. 94 2. Prerequisites and Terminology 96 The complete set of specifications in the FIRS collection 97 cumulative define a structured and distributed information service 98 using LDAPv3 for the data-formatting and transport functions. This 99 specification should be read in the context of that set, which 100 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS], 101 [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 104 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 105 in this document are to be interpreted as described in RFC 2119. 107 3. Naming syntax 109 This specification does not define new syntax rules. DNS resource 110 records are provided as supplemental data to DNS domain name 111 entries. As such, this data relies on pre-existing entries which 112 conform to the naming syntax defined in [FIRS-DNS]. 114 4. Object Classes and Attributes 116 DNS resource record entries in FIRS MUST use the inetDnsRR object 117 class, in addition to the inetDnsDomain object class defined in 118 [FIRS-DNS] and the mandatory object classes defined in 119 [FIRS-CORE]. If an entry exists as a referral source, the entry 120 MUST also be defined with the referral object class, in addition 121 to the above requirements. 123 The inetDnsRR object class is an auxiliary object class which is 124 subordinate to the inetDnsDomain object class. The inetDnsRR 125 object class has no mandatory attributes, and has two optional 126 attributes. The inetDnsRR object class also inherits the 127 attributes defined in the inetDnsDomain and inetResources object 128 classes, including the "cn" naming attribute. 130 The schema definition for the inetDnsRR object class is as 131 follows: 133 inetDnsRR 134 ( 1.3.6.1.4.1.7161.1.8.1 135 NAME 'inetDnsRR' 136 DESC 'DNS record records.' 137 SUP inetDnsDomain 138 AUXILIARY 139 MAY inetDnsRRData $ inetDnsRRDirective ) 141 The inetDnsRRData attribute is a structured (SEQUENCE) attribute, 142 containing multiple subordinate attributes. The layout of the 143 subordinate attributes is identical to the layout of DNS resource 144 records in the domain name system data message. The inetDnsRRData 145 attribute is also multi-valued. This model allows multiple 146 resource records to be associated with each entry, with each 147 resource record having different types, classes, time-to-live 148 values, data values, and so forth. 150 The inetDnsRRData attribute is described as follows: 152 inetDnsRRData 153 ( 1.3.6.1.4.1.7161.1.8.2 154 NAME 'inetDnsRRData' 155 DESC 'Generic DNS record record data.' 156 EQUALITY caseIgnoreMatch 157 SYNTAX inetDnsRRDataSyntax ) 159 The inetDnsRRDataSyntax syntax is defined in ASN.1 as follows: 161 inetDnsRRDataSyntax ::= SEQUENCE { 162 RRType INTEGER (0..65535), 163 RRClass INTEGER (0..65535), 164 RRTTL INTEGER (0..4294967295), 165 RRLen INTEGER (0..65535), 166 RRData OCTET STRING (SIZE (0..65535)) } 168 Note that the RRType and RRClass values are managed by IANA, and 169 are stored in the DNS parameter assignment registry. 171 Domain names which are stored in the RRData element MUST NOT use 172 the DNS compression mechanism. That compression mechanism relies 173 on the presence of existing domain names inside a DNS message, and 174 this storage system does not use DNS messages, so there would not 175 be any previous instances to reference. 177 The inetDnsRRDirective attribute provides a mechanism for storing 178 zone-file "directive" statements. Directives are textual sequences 179 which typically provide out-of-band data, such as default time-to- 180 live value for resource records in the zone. They are accommodated 181 here so that DNS systems which store and retrieve zone data in the 182 directory will be able also be able to store common directives. 183 Directives are not currently used with any FIRS applications. 185 The inetDnsRRDirective attribute stores a text string, and is 186 multi-valued. 188 inetDnsRRDirective 189 ( 1.3.6.1.4.1.7161.1.8.3 190 NAME 'inetDnsRRDirective' 191 DESC 'Zone-file directives for this domain name.' 192 EQUALITY caseIgnoreMatch 193 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) 195 An example of the inetDnsRR object class in use is shown in Figure 196 1 below. The example includes attributes from the inetDnsRR, 197 inetDnsDomain, inetResources, and inetAssociatedResources object 198 classes. 200 cn=ns1.example.com,cn=inetResources,dc=example,dc=com 201 [top object class] 202 [inetResources object class] 203 [inetDnsDomain object class] 204 [inetDnsRR object class] 205 [inetAssociatedResources object class] 206 | 207 +-attribute: description 208 | value: "The master DNS server for the example.com domain" 209 | 210 +-attribute: inetDnsContacts 211 | value: "hostmaster@example.com" 212 | 213 +-attribute: inetDnsRRData 214 | value: 1, 1, 3600, 4, (0xC0 0x00 0x02 0x0E) 215 | 216 +-attribute: inetAssociatedDnsDomain 217 value: "example.com" 219 Figure 1: The entry for the ns1.example.com DNS domain name and 220 its associated resource records. 222 In the example shown above, the ns1.example.com domain name has a 223 single inetDnsRRData attribute, which provides a single IPv4 224 address resource record. The subordinate elements of that 225 attribute indicate a RRType value of "1" (IPv4 Address), a RRClass 226 value of "1" (the Internet class), a RRTTL value of 3600 (a TTL of 227 one hour), a RRLen value of 4 (four octets of data), and four 228 single-octet data values which mirror the DNS format of IPv4 229 addresses (in this case, the IPv4 address of "192.0.2.14"). 231 5. Query Processing 233 This specification does not define new query processing rules. DNS 234 resource records are provided as supplemental data to DNS domain 235 name entries. As such, this data relies on the query processing 236 rules defined in [FIRS-DNS]. 238 Note that the use of bottom-up processing is more likely to 239 succeed when searching for DNS domain names with resource record 240 attributes, since these entries are more likely to exist. However, 241 the default usage of top-down processing is still preferred. 243 6. Security Considerations 245 Security considerations are discussed in [FIRS-ARCH]. 247 7. IANA Considerations 249 IANA considerations are discussed in [FIRS-ARCH]. 251 8. Normative References 253 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 254 Service: Architecture and Implementation 255 Guide", draft-ietf-crisp-firs-arch-02, July 256 2003. 258 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 259 System Numbers in the Federated Internet 260 Registry Service", draft-ietf-crisp-firs-asn- 261 02, July 2003. 263 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 264 Persons in the Federated Internet Registry 265 Service", draft-ietf-crisp-firs-contact-02, 266 July 2003. 268 [FIRS-CORE] Hall, E. "The Federated Internet Registry 269 Service: Core Elements", draft-ietf-crisp- 270 firs-core-02, July 2003. 272 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 273 the Federated Internet Registry Service", 274 draft-ietf-crisp-firs-dns-02, July 2003. 276 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 277 Records in the Federated Internet Registry 278 Service", draft-ietf-crisp-firs-dnsrr-02, July 279 2003. 281 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 282 Blocks in the Federated Internet Registry 283 Service", draft-ietf-crisp-firs-ipv4-02, July 284 2003. 286 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 287 Blocks in the Federated Internet Registry 288 Service", draft-ietf-crisp-firs-ipv6-02, July 289 2003. 291 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 292 and Sataluri, S. "Using Domains in LDAP/X.500 293 DNs", RFC 2247, January 1998. 295 [RFC2251] Wahl, M., Howes, T., and Kille, S. 296 "Lightweight Directory Access Protocol (v3)", 297 RFC 2251, December 1997. 299 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 300 S. "Lightweight Directory Access Protocol 301 (v3): Attribute Syntax Definitions", RFC 2252, 302 December 1997. 304 [RFC2254] Howes, T. "The String Representation of LDAP 305 Search Filters", RFC 2254, December 1997. 307 9. Changes from Previous Versions 309 draft-ietf-crisp-firs-dnsrr-02: 311 * Several clarifications and corrections have been made. 313 * Several attributes had their OIDs changed. NOTE THAT THIS 314 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 315 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 317 draft-ietf-crisp-firs-dnsrr-01: 319 * Added the inetDnsRRDirective attribute. 321 * Added explanatory text to the introduction. 323 * Several clarifications and corrections have been made. 325 draft-ietf-crisp-firs-dnsrr-00: 327 * Restructured the document set. 329 10. Author's Address 331 Eric A. Hall 332 ehall@ehsco.com 334 11. Acknowledgments 336 Funding for the RFC editor function is currently provided by the 337 Internet Society. 339 Portions of this document were funded by VeriSign Labs. 341 Thanks to Stig Venaas for providing constructive feedback during 342 the early development of this specification. 344 12. Full Copyright Statement 346 Copyright (C) The Internet Society (2003). All Rights Reserved. 348 This document and translations of it may be copied and furnished 349 to others, and derivative works that comment on or otherwise 350 explain it or assist in its implementation may be prepared, 351 copied, published and distributed, in whole or in part, without 352 restriction of any kind, provided that the above copyright notice 353 and this paragraph are included on all such copies and derivative 354 works. However, this document itself may not be modified in any 355 way, such as by removing the copyright notice or references to the 356 Internet Society or other Internet organizations, except as needed 357 for the purpose of developing Internet standards in which case the 358 procedures for copyrights defined in the Internet Standards 359 process must be followed, or as required to translate it into 360 languages other than English. 362 The limited permissions granted above are perpetual and will not 363 be revoked by the Internet Society or its successors or assigns. 365 This document and the information contained herein is provided on 366 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 367 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 368 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.