idnits 2.17.00 (12 Aug 2021) /tmp/idnits4001/draft-ietf-dnsind-local-names-07.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1918,, 2373]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 270: '... a configuration MAY be used, but it i...' RFC 2119 keyword, line 279: '...ct of local names. However, care MUST...' RFC 2119 keyword, line 311: '...e of the enclave SHOULD always be pref...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 46 has weird spacing: '...this if for p...' -- 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 (June 1999) is 8369 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 section? 'RFC 1958' on line 103 looks like a reference -- Missing reference section? 'RFC 1918' on line 228 looks like a reference -- Missing reference section? 'RFC 2373' on line 113 looks like a reference -- Missing reference section? 'RFC 2535' on line 389 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Working Group Donald E. Eastlake, 3rd 2 INTERNET-DRAFT IBM 3 Expires December 1999 June 1999 5 draft-ietf-dnsind-local-names-07.txt 7 Local Domain Name System (DNS) Names 8 ----- ------ ---- ------ ----- ----- 10 Donald E. Eastlake 3rd 12 Status of This Document 14 This draft, file name draft-ietf-dnsind-local-names-07.txt. 15 Distribution of this document is unlimited. Comments should be sent 16 to the DNS mailing list or to the author. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To view the entire list of current Internet-Drafts, please check the 37 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 38 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 39 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 40 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 42 Abstract 44 It is increasingly common for their to be "local" domain names which 45 are not intended to be seen from the global Internet. In some cases 46 this if for policy reasons, in other cases because they map to IP 47 addresses or other data which is only locally meaningful [RFC 1918, 48 2373]. 50 A new top level domain (TLD) name (.local) is reserved and a name 51 structure suggested below this TLD such that local private DNS zones 52 can safely be created without fear of conflict if these names should 53 leak out of a private enclave. It addition, a method of providing 54 DNS service for these names is suggested such that they are 55 maintained privately, similar to the reserved private IP addresses, 56 yet locally appear to be part of the global DNS name tree and are 57 reachable by a local resolver with no special knowledge. Additional 58 second level domain names are assigned under this TLD for IPv6 link 59 and site local addresses and loopback functions. 61 Acknowledgments 63 The valuable contributions of the following persons are gratefully 64 acknowledged: 66 Dan Harrington 68 Michael A. Patton 70 Table of Contents 72 Status of This Document....................................1 73 Abstract...................................................1 74 Acknowledgments............................................2 76 Table of Contents..........................................3 78 1. Introduction............................................4 79 2. Local Names Via The .local Top Level Domain.............5 80 2.1 Local DNS Server Specifics.............................7 81 2.2 Local in-addr.arpa Zones...............................8 82 2.3 Name Conflicts.........................................8 83 2.4 Nested Enclaves........................................9 84 3. Other Names in .local...................................9 85 4. Security Considerations.................................9 86 4.1 Strength of Privacy Offered............................9 87 4.2 Interaction with DNSSEC...............................10 89 References................................................11 90 Author's Address..........................................11 91 Expiration and File Name..................................11 93 1. Introduction 95 The global Internet Domain Name System (DNS) is documented in [RFC 96 1034, 1035, 1591, 2606] and numerous additional Requests for Comment. 97 It defines a tree of names starting with root, ".", immediately below 98 which are top level domain names such as .com and .us. Below top 99 level domain names there are normally additional levels of names. 101 Generally the information in the DNS is public and intended to be 102 globally accessible. Certainly, in the past, the model of the 103 Internet was one of end-to-end openness [RFC 1958]. However, with 104 increasing security threats and concerns, firewalls and enclaves have 105 appeared. In many cases, organizations have hosts or resources that 106 they specifically want to reference with DNS names but which they 107 also want to be walled off from global access and even from global 108 knowledge of the DNS name for the resource. 110 In the realm of IP addresses, this has been accomplished by reserving 111 three blocks of IPv4 addresses as documented in [RFC 1918] and by 112 allocating parts of the IPv6 address space for link and site local 113 addresses [RFC 2373]. Familiarity with the contents of these RFCs is 114 assumed. Addresses in these blocks are not to be globally routed. 116 In the DNS area, local private names have generally been achieved in 117 the past by "splitting" DNS at the enclave boundary, giving different 118 answers to resolvers depending or whether they are inside or outside 119 of the enclave, using different servers for inside and outside, etc. 120 as mentioned in [RFC 1918]. Such relatively complex configuration 121 diddling is at variance with the simple global tree structure of the 122 initial DNS concept. 124 This document specifies an alternative approach to achieving the 125 effect of local names that is more in tune with the concept of a 126 single global DNS tree or at least the appearance of a single tree. 127 Use of this approach is not required and older techniques will 128 continue to work. 130 [RFC 1918] requires that private IP addresses not be indirectly 131 exposed to the general Internet via DNS records or otherwise. By 132 implication, the same would be true of IPv6 local addresses. This 133 RFC provides the recommended way to accomplish such private IP 134 address hiding and carves out a limited exception thereto for the 135 addresses of the servers for some zones which are children of the 136 .local top level domain name. 138 2. Local Names Via The .local Top Level Domain 140 The fundamental idea, as described in more detail below, is to define 141 second level domains under .local which are served by DNS name 142 servers that have private IP addresses. These server's addresses 143 would only be routed within the domain to which the names are local. 144 Thus the servers, and the names and resource records inside them, 145 would not be directly accessible outside the enclave, if the 146 guidelines in this document are followed. 148 The following figure shows a highly simplified overview of an example 149 configuration: 151 +----------------------------+ 152 | domain/enclave A | 153 | | 154 | #====================# | 155 | H private IP addrs A H | 156 | H H | 157 +-----------------------O privhost1 H | 158 | | H H | 159 +-----+-----------------O privhost2 H | 160 | | | H H | 161 | | | #====================# | 162 | | a | | 163 | +--------------------O pubhost3 | 164 .local | | | | | 165 +----+ | | +----------------------------+ 166 | | | | 167 | | | | +----------------------------+ 168 | | | | | domain/enclave B | 169 (root) | | | | | | 170 . ----+ | | | | #====================# | 171 | | | | | H private IP addrs B H | 172 | | | | | H H | 173 | +--|--------------------O privhost2 H | 174 | | | | H H | 175 +-------+ +-----------------O privhost3 H | 176 .com | | H : H | 177 | | #====:===============# | 178 | | : | 179 | b +-------------O pubhost4 | 180 +------+ | | 181 | +-------------O pubhost5 | 182 | | | 183 | +----------------------------+ 184 | 185 | example 186 +---------------------O pubhost6 188 Starting at the bottom, pubhost6 is intended to illustrate an 189 ordinary host connected to the Internet with domain name 190 pubhost6.example.com. Though not indicated in the above diagram, 191 every DNS zone is in fact served by at least two hosts (and some but 192 substantially more). The addresses of the servers for the root (.), 193 .com, and example.com zones would all be in the public portion of the 194 IP address space, i.e., in the space of all unicast IP addresses not 195 reserved for private use. 197 Moving to the top of the figure, enclave A represents some 198 organization that wishes to have some hosts with publicly visible 199 names and some with hidden names that are visible only locally. 200 pubhost3.a.com is an example of a publicly visible host which would 201 probably have a public IP address although access to pubhost3 from 202 outside the enclave might be filtered or even blocked by a firewall 203 or the like. privhost1 and privhost2 are examples of hidden names. 204 If a zone with privhost1 and privhost2 in it is served by DNS servers 205 with private IP addresses ("private IP addresses A") such that the 206 servers are accessible within enclave A but not from outside enclave 207 A, then the information is that zone will only be locally visible. 208 As show in the above figure, privhost1 and privhost2 have addresses 209 that are also private IP addresses, making those hosts inaccessible 210 outside enclave A, but it is the private addresses of the DNS 211 servers, not of the hosts pointed to from within the private DNS 212 zone, that provides the protection for the DNS names and other 213 private DNS information. (From the above simplified diagram, it 214 might appear that fully qualified domain names of these hosts would 215 be privhost1.local and privhost2.local but the names are actually 216 more complex as explained in Section 2.1.) 218 Finally, in the middle, another enclave is shown with two hosts with 219 visible names and public IP addresses, pubhost4.b.com and 220 pubhost5.b.com. In addition, there are two private host names 221 privhost2 and privhost3. The duplication of privhost2 between 222 enclaves A and B would not be a problem as only DNS resolvers in 223 enclave A can access the DNS servers with the zone having the enclave 224 A version of privhost2 and only DNS resolvers in enclave B can access 225 the DNS servers with the zone having the enclave B version of 226 privhost2. 228 Publicly visible host names are required by [RFC 1918] to have public 229 (i.e., globally unique) IP addresses. Private DNS names would 230 normally have private IP addresses, and all do in the figure above, 231 but this is not required. A public IP address could be stored under 232 a private name. And, of course, it is possible for the same physical 233 host to have multiple IP addresses, including a mix of public and 234 private. The dotted line in the figure above is intended to indicate 235 that privhost3 and pubhost4 are actually the same physical machine. 236 The could be accomplished equally well by storing a single public 237 address for that host under both the public and private names or by 238 having the host answer to both a public IP address stored under the 239 public name and a private IP address stored under the private name. 240 In the later case you could even also store the public address along 241 with the private address under the private name. 243 2.1 Local DNS Server Specifics 245 A variety of second level names are provided in the .local zone each 246 of which is a delegation point to a zone with some number of name 247 servers in one of the private IP address space blocks. The multiple 248 second level names permit choice between the different private IP 249 blocks and different numbers of servers. Thus the actual fully 250 qualified name for the private host examples in the figure above 251 would be more like privhost1.a2.local, privhost2.a2.local, etc. (but 252 see Section 2.3 below). 254 Glue records are provided to give private IP addresses for initial 255 name servers; however, it should be noted that the NS and A records 256 in the local zones will dominate the information stored in the .local 257 zone. This means that once a resolver has contacted a local server, 258 the list of NS RRs in the local zone on that server will control and 259 could contain more or different servers than were given at the chosen 260 .local delegation point. Nevertheless, the glue A records in the 261 global .local zone do place some constraints of the private IP 262 address of the local DNS servers implementing zones which are 263 children of .local. 265 It is also possible for an enclave to locally configure its own 266 version of the .local zone. Depending on its enclave boundary 267 implementation, it might be able to constrain all of its internal 268 references to .local to use its own variant version. This version 269 could have whatever private addresses were desired for the name 270 servers involved. Such a configuration MAY be used, but it is 271 recommended that the globally accessible .local specified herein be 272 used for uniformity. That way, even a unconstrained resolver 273 starting from the normal root servers (i.e., an "out of the box" 274 resolver) will correctly resolve or fail to resolve names under 275 .local depending on the resolvers location in the network as 276 specified herein. 278 It is only necessary for the local DNS servers to have private IP 279 addresses to achieve the effect of local names. However, care MUST 280 be taken that none of the local DNS servers or any server that might 281 cache their output is accessible by any network interface that has a 282 non-private IP address. Otherwise considerable confusion could 283 result if local names are resolved by a resolver outside a local 284 enclave to private IP addresses which have a different meaning for 285 that resolver. 287 2.2 Local in-addr.arpa Zones 289 Inverse lookup of local names corresponding to private IP addresses 290 needs to be provided via the in-addr.arpa and ip6.int zones. Because 291 of the fixed naming within this zone, different names with different 292 numbers of servers or different addresses can not be provided. As 293 with the forward .local entries, the actual NS RRs in the servers 294 serving the private portions of the inverse in-addr.arpa will 295 dominate. When one of these is queried by a resolver, it can provide 296 information on additional servers for that particular subzone in the 297 private IP address portion of the in-addr.arpa tree. 299 2.3 Name Conflicts 301 The intention is that local names would only be used in the enclave 302 where the entities they refer to exist, and these names would not be 303 exported. However, experience indicates that. despite best efforts 304 to avoid it, some such names will leak out via email cc's, URL's in 305 HTML, etc. (Such leakage occurs regardless of how the local names 306 are formed or whether they are accessible via the default root zone.) 307 These leaked private names can cause confusion if they can conflict 308 with global names or names local to other enclaves. Use of the 309 .local top level domain assures no conflict with global names. To 310 assure no conflict with different local fully qualified names, the 311 domain name of the enclave SHOULD always be prefixed to .local. 313 For example, a company might have 314 host1.company.example 315 as a globally accessible host and 316 host2.company.example.b3.local 317 as a host for internal use only. The global name could normally be 318 resolvable anywhere on the Internet while the local name could not be 319 resolved anywhere except within the company enclave. 321 Note that different names were chosen for the initial label in the 322 two names above, i.e., host1 and host2. The reason for this is that, 323 in some environments, local hosts are referred to by an unqualified 324 names, such as host3. For DNS look up purposes, such a name must be 325 expanded into a fully qualified domain name and a "search list" of 326 possible suffix qualifications is tried. If, for example, both 327 host4.school.ac.example and host4.school.ac.example.b3.local existed, 328 then a local reference to "host4" would be ambiguous and could lead 329 to either machine depending on the order of qualifications tried. 330 This order could even be different in different pieces of local 331 software or on different local hosts, resulting in substantial 332 confusion. For this reason, it is strongly recommended that disjoint 333 name sets be used for global and local entity unqualified domain 334 names and that fully qualified domain names be used wherever 335 practical. 337 2.4 Nested Enclaves 339 It is possible to have enclaves within enclaves. In general the best 340 way to accomplish this is to use a different portion of the private 341 IP address space at each nesting level of enclave. (Private IP 342 address space can be reused in enclaves that are siblings or the 343 like.) Then similar entries to those proposed here for .local can be 344 made in the private zone referring to name servers with addresses in 345 the nested enclave's private IP address space. 347 3. Other Names in .local 349 Three additional second level domain names are assigned in the .local 350 top level domain for other types of local names. 352 In particular, 353 link.local and 354 site.local 355 are reserved for use in qualifying IPv6 link local names and site 356 local names. 358 In addition, loopback.local is assigned and given the loopback 359 address. 361 4. Security Considerations 363 This section discusses the strength of the privacy offered by using 364 subzones of .local and interactions with DNS security. 366 4.1 Strength of Privacy Offered 368 Local names, as proposed herein, are not intended to be a strong 369 security mechanism. 371 The privacy of the DNS information protected by storing it in servers 372 with private IP addresses is weak. It is completely dependent on the 373 integrity of enclave perimeter routing to make these servers 374 inaccessible. And it may occasionally leak out in any case due to 375 inclusion in email address fields, web pages, and the like, although 376 such leakage should be no worse than current split DNS 377 implementations of DNS data hiding. 379 Software should not depend on local names being accessible only 380 within a particular enclave as someone could deliberately create the 381 same names within a different enclave. This is true even if, as 382 recommended herein, the names incorporate the domain name of the 383 original enclave in an attempt to avoid such conflicts. 385 4.2 Interaction with DNSSEC 387 Although an enclave may derive some amount of security by virtue of 388 its isolation, it will normally be desirable to implement DNS 389 security [RFC 2535] within the enclave. The enclave owner should 390 generate their own keys and sign their subzone of .local. However, a 391 signed copy of their public key can not be included in the .local 392 zone as it is different for every enclave. Thus, to authenticate the 393 .local subzone contents, it will be necessary to sign the KEY RR at 394 the apex of the local subzone of .local with the .local zone key or 395 another key that is trusted by local resolvers or staticly configure 396 the public key for the .local subzone in local resolvers. 398 References 400 RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", 401 November 1987. 403 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 404 STD 13, November 1987. 406 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 407 Specifications", STD 13, November 1987. 409 RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", 410 03/03/1994. 412 RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. 413 Lear, "Address Allocation for Private Internets", 02/29/1996. 415 RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", 416 06/06/1996. 418 RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing 419 Architecture", July 1998 421 RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", 422 March 1999. 424 RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 425 June 1999. 427 Author's Address 429 Donald E. Eastlake 3rd 430 IBM 431 65 Shindegan Hill Road, RR #1 432 Carmel, NY 10512 USA 434 Telephone: +1 914-276-2668 (h) 435 +1 914-784-7913 (w) 436 FAX: +1 914-784-3833 (w) 437 EMail: dee3@us.ibm.com 439 Expiration and File Name 441 This draft expires December 1999. 443 Its file name is draft-ietf-dnsind-local-names-07.txt.