idnits 2.17.00 (12 Aug 2021) /tmp/idnits36410/draft-hardie-out-rr-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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 361 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1035], [BCP42]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'RFC 1035' on line 89 looks like a reference -- Missing reference section? 'BCP 42' on line 42 looks like a reference -- Missing reference section? 'RFC 2119' on line 84 looks like a reference -- Missing reference section? 'BCP42' on line 179 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Ted Hardie 3 Expires: December 2002 Nominum, Inc. 5 A DNS RR for Pointers to RRs outside class IN 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire in December 2002. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 The Domain Name System is a global distributed lookup system with 38 delegation. In the original specification of the DNS [RFC 1035], 39 CLASSes were described as parallel data structures within a single 40 namespace but with potentially different delegations of authority. 41 [BCP 42] defines a different vision, in which different CLASSes 42 represent fundamentally different namespaces. Though [BCP 42] 43 includes procedures for assignment of CLASSes, there has been 44 little use of this axis of extensibility; in practice, CLASS IN is 45 the only widely deployed CLASS in the DNS. The ubiquity of CLASS 46 IN for name to IP address mapping has caused a vicious cycle in 47 which extensions are placed within that CLASS to take advantage of 48 its global deployment, with each addition further increasing its 49 gravitational attraction. This document describes a Resource 50 Record for use within CLASS IN that contains a pointer to a CLASS 51 outside of IN. This mechanism is intended to allow administrators 52 to indicate that a named resource identified within CLASS IN is 53 also present in a different namespace, potentially under a different 54 name. This cross-class pointer will allow the DNS to handle 55 new namespaces with mechanisms appropriate to those namespaces 56 while providing a connection to the globally deployed CLASS IN 57 namespace. 59 Table of Contents 61 1. Terminology 62 2. Introduction 63 3. The OUT RR 64 3.1 OUT Presentation format 65 3.2 OUT RDATA Format 66 3.3 Examples 67 3.3.1 Example 1 68 3.4.2 Example 2 69 4. Use of the OUT RR 70 5. Alternatives 71 6. Security Considerations 72 7. IANA Considerations 73 8. IAB Considerations 74 9. References 75 10. Acknowledgments 76 11. Author's Address 77 12. Full Copyright Statement 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC 2119]. 85 2. Introduction 87 The Domain Name System is a distributed lookup system with 88 delegation. Though the DNS was initially described as related to a 89 single namespace[RFC 1035], its inclusion of CLASSes which may 90 derive from different roots creates a de facto mechanism for using 91 the DNS with multiple namespaces. The DNS uses common resource 92 record and packet formats for all CLASSes, but the namespaces thus 93 created are fully independent. This independence means that a name 94 within one class has no necessary relationship to the same name in 95 a different CLASS. 97 This independence is architecturally sound in principle, but the 98 deployment history of the DNS shows that resource records have been 99 highly concentrated in the CLASS IN namespace. Because developers 100 of new RRs wish to take immediate advantage of the deployed DNS 101 infrastructure, they use CLASS IN even in situations where the use 102 of a new namespace would produce a better long term result. This 103 document proposes a mechanism by which a Resource Record within 104 CLASS IN can be used as a pointer to a NAME in a CLASS outside IN. 105 It presumes that a cross-class pointer mechanism will allow 106 the development of namespaces outside CLASS IN without requiring 107 CLASS IN to be replaced or its resource records redeveloped 108 in the new CLASSes. 110 3. The OUT RR 112 The OUT RR is a CLASS IN RR used to store a pointer to related data 113 stored in a non-CLASS IN DNS namespace. The type number for the 114 OUT RR is to be assigned by IANA. The OUT RR occurs in CLASS IN 115 only. The format for the OUT RR is: 117 NAME TTL IN OUT IN-EXTERNAL-CLASS IN-EXTERNAL-NAME 119 Each OUT RR stores a single pointer, as a pair composed of an 120 IN-EXTERNAL-CLASS and an IN-EXTERNAL-NAME. Even if a NAME in CLASS 121 IN maps to multiple IN-EXTERNAL-NAMEs in the same 122 IN-EXTERNAL-CLASS, each pair should be stored in a separate OUT RR. 124 3.1 OUT Presentation format 126 The format for the OUT RR is: 128 NAME TTL IN OUT IN-EXTERNAL-CLASS IN-EXTERNAL-NAME 130 IN-EXTERNAL-CLASS is represented in decimal format when a mnemonic for 131 the class has not been established. 133 3.2 OUT RDATA Format 135 The RDATA section of the OUT RR in transmission contains RDLENGTH 136 bytes of binary data. The OUT RDATA is formed by concatenating the 137 CLASS bytes for the IN-EXTERNAL-CLASS and the octets representing 138 the IN-EXTERNAL-NAME in the IN-EXTERNAL-CLASS. CLASS assignments 139 are maintained by IANA according to the assignment criteria set out 140 in [BCP42]. 142 3.3 Examples 144 3.3.1 Example 1 146 A lookup is made against a DNS record in class IN for a device 147 which runs the IP version of BACNet (Building Automation and 148 Control Network; see Annex J of ANSI/ASHRAE Standard 135-2001). 149 The property manager for the property at which the device is 150 present maintains information on all its BACNet devices in its own 151 namespace within the private use CLASS space set out in [BCP42]. 152 In addition to reporting the data available within CLASS IN, the 153 DNS server reports the IN-EXTERNAL-CLASS and NAME at which more 154 information is available. 156 firealarm.example.com 3600 IN A 10.0.0.20 157 firealarm.example.com 3600 IN OUT 65410 SA_TEMP.AHU4.BLDG20.PAO 159 A lookup in the private class 65410 might return some set of 160 BACNet properties associated with that device: 162 SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_ID 2492492 163 SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_NAME SA_TEMP 164 SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_TYPE Analog.Input 165 SA_TEMP.AHU4.BLD20.PAO 3600 65410 Vendor_ID Example_Technologies 167 Note that the property manager may choose to keep all of its BACNet 168 devices within this namespace, whether or not the devices are 169 IP-addressable. Note also that this example relates to a 170 private namespace maintained by a property manager and should 171 not be taken to imply that the above CLASS or RRs have been 172 specified for use with BACNet. 174 3.3.2 Example 2 176 A lookup is made against a DNS record in class IN for a server which 177 is part of a Content Delivery Network. The Content Delivery 178 Network maintains its own DNS namespace within the private use 179 CLASS space set out in [BCP42]. In addition to reporting the data 180 available within CLASS IN, it reports the NAME at which further 181 information is available within its own namespace. 183 newsservice.example.com. 600 IN A 10.0.0.1 184 newsservice.example.com. 600 IN OUT 65500 surrogate1.cluster4.west.nam. 186 A DNS client configured to use private use CLASS 65500 can then 187 present the NAME surrogate1.cluster4.west.nam to the appropriate 188 DNS servers and retrieve resources records from that private 189 address space. Within a CDN context, this might provide 190 information on the state of that surrogate, which might include 191 information from resource record types that do not exist within 192 CLASS IN. For example: 194 Surrogate1.cluster4.west.nam 600 65300 USERS newsservice.example.com 195 Surrogate1.cluster4.west.nam 600 65300 USERS homepage.example.com 196 Surrogate1.cluster4.west.nam 600 65300 USERS info-gov.example.org 197 Surrogate1.cluster4.west.nam 600 65300 USERS sports-scores.example.net 199 might report the set of users for a specific surrogate to those who have 200 configured their DNS for lookups into that private use CLASS. 202 3.3.3 Example 3 204 A lookup is made against a DNS record in class IN for a host which 205 subscribes to a service that reports other proximate participating 206 hosts. By storing a pointer to its NAME in that service's private 207 use CLASS, a host advertises to those looking it up in CLASS IN 208 that it participates and what to use to lookup related records. A 209 query in CLASS IN thus might return: 211 hostname.example.com. 600 IN A 10.0.0.100 212 hostname.example.com. 600 IN OUT 65400 u103.rwc.ca.us.loc. 214 A user of the proximity service can then present the NAME 215 u103.rwc.ca.us.loc. to the DNS servers for CLASS 65400 and receive 216 appropriate information. For a proximity service a lookup might 217 yield something like: 219 u103.rwc.ca.us.loc. 100 65400 1000m u202.mp.ca.us.loc. 220 u103.rwc.ca.us.loc. 100 65400 1000m u002.pa.ca.us.loc. 221 u103.rwc.ca.us.loc. 100 65400 1000m u333.rwc.ca.us.loc. 223 reporting the 4 hosts which were within 1000 meters. This data 224 again contains resource records (and might well correspond to query 225 types) that do not exist with CLASS IN. 227 4. Use of the OUT RR 229 This RR MUST NOT be used for pointers within CLASS IN. Use of this 230 resource record as a pointer to a NAME within CLASS IN could easily 231 create conflicts with the information published for the original 232 NAME. If, for example, a lookup resulted in a CNAME record and an 233 OUT record pointing to CLASS IN, conflicts over which resource 234 record's data to use to derive an IP address might occur. In 235 certain circumstance, it may also create a resolution loop that 236 current use of the DNS system is not designed to detect. OUT 237 Resource Records pointing to CLASS IN MUST be treated as an error 238 by applications which receive them, and it would be useful if 239 server implementations reported attempts to use such pointers to 240 their administrators. 242 5. Alternatives 244 The OUT resource record presumes a benefit to mapping a name in one 245 namespace to a name in another namespace. In some cases, it can be 246 difficult to see when that mapping between namespaces is required 247 and when an additional resource record type in the existing 248 namespace is sufficient. In general, two or more namespaces are 249 required when there are distinguishable collections of identifiers, 250 rather than when there are additional attributes to existing 251 identifiers. In gross terms, the OUT RR allows the DNS to indicate 252 that something identified within one set (CLASS IN) is also a 253 member of another set, possibly under a different identifier; using 254 additional RRs within CLASS IN, even private RRs within CLASS IN, 255 does not imply the existence of another set. 257 6. Security Considerations 259 The storage of data within the DNS makes available information to an 260 Internet-scale audience. Revealing information about the namespaces in 261 which data is stored provides a hint to potential attackers about the 262 information and should be released only after due consideration of the 263 benefits and risks associated with that release. 265 7. IANA Considerations 267 IANA is requested to allocate an RR type number within CLASS IN for 268 the OUT resource record type. 270 8. IAB Considerations 272 The use of pointers within CLASS IN to namespaces outside of CLASS 273 IN risks creating a situation analogous to a split root for the 274 DNS; indeed, it is a basic principal that the different DNS CLASSes 275 do not need to share a single root. This document does not propose 276 to segment reachability information critical to the operation of 277 the Internet into different namespaces, but it does posit that some 278 information belongs in namespaces outside CLASS IN. That risks the 279 application namespace of the Internet being fragmented, even if the 280 Internet's reachability information is not. This fragmentation may 281 well be appropriate in certain instances and inappropriate in 282 others, and due care must be given to the creation and use of 283 namespaces outside CLASS IN. 285 9. References 287 TBA 289 10. Acknowledgments 291 Paul Mockapetris, David Conrad, and Andreas Gustafsson were all 292 kind enough to provide feedback on early drafts of this document; 293 that kindness should not be construed, however, as approval of 294 the ideas contained in the document. 296 11. Author's Address 298 Ted Hardie 299 Nominum, Inc. 300 2385 Bay Road 301 Redwood City, CA 94063 302 USA 304 EMail: Ted.Hardie@nominum.com 306 12. Full Copyright Statement 308 Copyright (C) The Internet Society (2002). All Rights Reserved. 310 This document and translations of it may be copied and furnished to 311 others, and derivative works that comment on or otherwise explain it 312 or assist in its implementation may be prepared, copied, published 313 and distributed, in whole or in part, without restriction of any 314 kind, provided that the above copyright notice and this paragraph 315 are included on all such copies and derivative works. However, this 316 document itself may not be modified in any way, such as by removing 317 the copyright notice or references to the Internet Society or other 318 Internet organizations, except as needed for the purpose of 319 developing Internet standards in which case the procedures for 320 copyrights defined in the Internet Standards process must be 321 followed, or as required to translate it into languages other than 322 English. 324 The limited permissions granted above are perpetual and will not be 325 revoked by the Internet Society or its successors or assigns. 327 This document and the information contained herein is provided on an 328 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 329 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 330 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 331 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 332 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 334 Acknowledgment 336 Funding for the RFC editor function is currently provided by the 337 Internet Society.