idnits 2.17.1 draft-ietf-dnsind-local-names-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnsind-local-names-05.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnsind-local-names-05.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnsind-local-names-05.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnsind-local-names-05.txt,', but the file name used is 'draft-ietf-dnsind-local-names-05' == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC1918]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 23 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. ** 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 264: '... of local names. However, care MUST be...' RFC 2119 keyword, line 300: '... SHOULD always be included in ".loca...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1998) is 9354 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 1918' on line 436 looks like a reference -- Missing reference section? 'RFC 1958' on line 97 looks like a reference Summary: 13 errors (**), 1 flaw (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Local DNS Names 2 Expires September 1998 4 Local Domain (DNS) Names 5 ----- ------ ----- ----- 7 Donald E. Eastlake 3rd 9 Status of This Document 11 This draft, file name draft-ietf-dnsind-local-names-05.txt, is 12 intended to be become an Experimental RFC. Distribution of this 13 document is unlimited. Comments should be sent to the DNS mailing 14 list or to the author. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 A new top level domain (TLD) name is defined such that local private 36 DNS zones can easily be maintained similar to the private IP 37 addresses reserved in [RFC 1918]. These zones locally appear to be 38 part of the global DNS name tree and can be locally resolved, even by 39 "out of the box" resolvers starting at the global root zone, but are 40 inaccessible outside their enclave. Additional second level domain 41 names are reserved under this TLD for IPv6 link and site local 42 addresses and loopback addresses. User confusion is reduced by 43 grouping all non-global names under this new TLD so they are more 44 easily recognizable. 46 Acknowledgments 48 The valuable contributions of the following persons are gratefully 49 acknowledged: 51 Dan Harrington 53 Michael A. Patton 55 Table of Contents 57 Status of This Document....................................1 58 Abstract...................................................1 60 Acknowledgments............................................2 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 2. Local Names Via The .local Top Level Domain.............4 65 2.1 Local DNS Server Specifics.............................6 66 2.2 Local in-addr.arpa Zones...............................6 67 2.3 Name Conflicts.........................................7 68 2.4 Nested Enclaves........................................8 69 3. Other Names in .local...................................8 70 4. Analysis of Alternatives................................8 71 4.1 Locally Configured .local..............................8 72 4.2 Local Delegations Anywhere.............................9 73 4.3 No Change..............................................9 74 5. Security Considerations.................................9 75 5.1 Strength of Privacy Offered............................9 76 5.2 Interaction with DNSSEC...............................10 77 5.3 Network Abuse.........................................10 79 References................................................11 80 Author's Address..........................................11 81 Expiration and File Name..................................11 83 Appendix A: the .local zone...............................12 85 Appendix B: the .in-addr.arpa zone.......................14 87 1. Introduction 89 The global Internet Domain Name System (DNS) is documented in [RFC 90 1034, 1035, 1591] and numerous additional Requests for Comment. It 91 defines a tree of names starting with root, ".", immediately below 92 which are top level domain names such as .com and .us. Below top 93 level domain names there are normally additional levels of names. 95 Generally the information in the DNS is public and intended to be 96 globally accessible. Certainly, in the past, the model of the 97 Internet was one of end-to-end openness [RFC 1958]. However, with 98 increasing security threats and privacy concerns, firewalls and 99 enclaves have appeared. In many cases, organizations have hosts or 100 resources that they specifically want to reference with DNS names but 101 which they also want to be walled off from global access and even 102 from global knowledge of their DNS name. 104 In the realm of IPv4 addresses, this has been accomplished by 105 reserving three blocks of addresses as documented in [RFC 1918]. 106 This designation of private IP addresses also helps conserve global 107 IP addresses. Familiarity with the contents of [RFC 1918] is 108 assumed. 110 In the DNS area, [RFC 1918] recommends "splitting" DNS at the enclave 111 boundary, giving different answers to resolvers depending or whether 112 they are inside or outside of the enclave, using different servers 113 for inside and outside, etc. Such relatively complex configuration 114 diddling is at variance with the simple global tree structure 115 envisaged in the original DNS design. It can cause the local names 116 to be invisible to "out of the box" resolvers within the enclave if 117 they start at a global root zone. Furthermore, because local DNS 118 names created in accordance with [RFC 1918] can be entirely arbitrary 119 and unrecognizable as local, user confusion is increased. 121 This document specifies an alternative approach to achieving the 122 effect of local names that is more in tune with the concept of a 123 single global DNS tree and reduces user confusion by making local 124 names easily recognizable. Use of this approach by local DNS 125 administrators is not required and older techniques will continue to 126 work as well as they have in the past. 128 [RFC 1918] requires that private IP addresses not be indirectly 129 exposed to the general Internet via DNS records or otherwise. This 130 RFC provides a recommended way to accomplish such private IP address 131 hiding and carves out an exception thereto for the addresses of the 132 servers for some zones which are children of the ".local" top level 133 domain name. 135 2. Local Names Via The .local Top Level Domain 137 The fundamental idea for providing local names, as described in more 138 detail below, is to define second level domains under ".local" which 139 are served by domain name system (DNS) name servers that have private 140 IP addresses. These server's addresses would only be routed within 141 the enclave to which the names are local. Thus the servers, and the 142 names and resource records inside them, would, if the guidelines in 143 this document are followed, be inaccessible outside the enclave. 145 The following figure shows a highly simplified overview of an example 146 configuration: 148 +----------------------------+ 149 | domain/enclave A | 150 | | 151 | #====================# | 152 | H private IP addrs A H | 153 | H H | 154 +-----------------------O privhost1 H | 155 | | H H | 156 +-----+-----------------O privhost2 H | 157 | | | H H | 158 | | | #====================# | 159 | | a | | 160 | +--------------------O pubhost3 | 161 .local | | | | | 162 +----+ | | +----------------------------+ 163 | | | | 164 | | | | +----------------------------+ 165 | | | | | domain/enclave B | 166 (root) | | | | | | 167 . ----+ | | | | #====================# | 168 | | | | | H private IP addrs B H | 169 | | | | | H H | 170 | +--|--------------------O privhost2 H | 171 | | | | H H | 172 +-------+ +-----------------O privhost3 H | 173 .com | | H : H | 174 | | #====:===============# | 175 | | : | 176 | b +-------------O pubhost4 | 177 +------+ | | 178 | +-------------O pubhost5 | 179 | | | 180 | +----------------------------+ 181 | 182 | example 183 +---------------------O pubhost6 185 Starting at the bottom, pubhost6 is intended to illustrate an 186 ordinary host connected to the Internet with domain name 187 pubhost6.example.com. Though not indicated in the above diagram, 188 every DNS zone is in fact served by at least two hosts and some by 189 substantially more than two. The addresses of the servers for the 190 root ("."), ".com", and example.com zones would all be in the public 191 portion of the IP address space, i.e., in the space of unicast IP 192 addresses not reserved for private use so these servers are 193 accessible to all. 195 Moving to the top of the figure, enclave A represents some 196 organization that wishes to have some hosts with publicly visible 197 names and some with hidden names that are only visible locally. 198 pubhost3.a.com is an example of a publicly visible host which would 199 probably have a public IP address (although access to pubhost3 from 200 outside the enclave might be filtered or even blocked by a firewall 201 or the like). privhost1 and privhost2 are examples of hidden names. 202 If a zone with privhost1 and privhost2 in it is served by DNS servers 203 with private IP addresses ("private IP addresses A") such that the 204 servers are accessible within enclave A but not from outside enclave 205 A, then the information is that zone will only be locally visible. 206 As show in the above figure, privhost1 and privhost2 have addresses 207 that are also private IP addresses, making those hosts inaccessible 208 outside enclave A, but it is the private addresses of the DNS 209 servers, not of the hosts pointed to from within the private DNS 210 zone, that provides the protection for the DNS names and other 211 private DNS information. (From the above simplified diagram, it 212 might appear that fully qualified domain names of these hosts would 213 be privhost1.local and privhost2.local but the names are actually a 214 little more complex as explained in Section 2.1.) 216 Finally, in the middle, another enclave is shown with two hosts with 217 visible names and public IP addresses, pubhost4.b.com and 218 pubhost5.b.com. In addition, there are two private host names 219 privhost2 and privhost3. The duplication of privhost2 between 220 enclaves A and B would not be a problem as only DNS resolvers in 221 enclave A can access the DNS servers with the zone having the enclave 222 A version of privhost2 and only DNS resolvers in enclave B can access 223 the DNS servers with the zone having the enclave B version of 224 privhost2. 226 Publicly visible host names are required by [RFC 1918] to have public 227 (i.e., globally unique) IP addresses. Private DNS names would 228 normally have private IP addresses, and all do in the figure above, 229 but this is not required. A public IP address could be stored under 230 a private name. And, of course, it is possible for the same physical 231 host to have multiple IP addresses, including a mix of public and 232 private addresses. The dotted line in the figure above is intended 233 to indicate that privhost3 and pubhost4 are actually the same 234 physical machine. The could also be accomplished by storing a single 235 public address for that host under both the public and private names 236 or by having the host answer to both a public IP address stored under 237 the public name and a private IP address stored under the private 238 name. In the later case you could even also store the public address 239 along with the private address under the private name. 241 2.1 Local DNS Server Specifics 243 A variety of second level names are provided in the ".local" zone 244 each of which is a delegation point to a zone with some number of 245 name servers in one of the private IP address space blocks. The 246 multiple second level names permit choice between the different 247 private IP blocks and different numbers of servers. Thus the actual 248 fully qualified name for the private host examples in the figure 249 above would be more like privhost1.a2.local, privhost2.a2.local, etc. 250 (but see Section 2.3 below). 252 Glue records are provided to give private IP addresses for initial 253 name servers; however, it should be noted that the NS and A records 254 in the local zones will dominate the information stored in the 255 ".local" zone. This means that once a resolver has contacted a local 256 server, the list of NS RRs in the local zone on that server will 257 control and could contain more or different servers than were given 258 at the chosen ".local" delegation point. Nevertheless, the glue A 259 records in the global ".local" zone do place some constraints of the 260 private IP address of the local DNS servers implementing zones which 261 are children of ".local". 263 It is only necessary for the local DNS servers to have private IP 264 addresses to achieve the effect of local names. However, care MUST be 265 taken that none of the local DNS servers or any server that might 266 cache their output is accessible by any globally accessible network 267 interface. Otherwise confusion could result if local names are 268 resolved by a resolver outside a local enclave to private IP 269 addresses which are meaningless or have a different meaning for that 270 resolver. 272 The Appendix A to this document gives an initial content of the 273 ".local" zone. 275 2.2 Local in-addr.arpa Zones 277 Inverse look up of local names corresponding to private IP addresses 278 needs to be provided via the in-addr.arpa zone. Appendix B contains 279 recommended additions to the in-addr.arpa domain to accomplish this. 280 Because of the fixed naming within this zone, different names with 281 different numbers of servers or different addresses can not be 282 provided. As with the forward ".local" entries, the actual NS RRs in 283 the servers serving the private portions of the inverse in-addr.arpa 284 will dominate. When one of these is queried by a resolver, it can 285 provide information on additional servers for that particular subzone 286 in the private IP address portion of the in-addr.arpa tree. 288 2.3 Name Conflicts 290 The intention is that local names would only be used in the enclave 291 where the entities they refer to exist, and these names would not be 292 exported. However, experience indicates that, despite best efforts 293 to avoid it, some such names will occasionally leak out via email 294 cc's, URL's in HTML, etc. This occurs currently with local names not 295 following the design in this document. These leaked private names 296 can cause confusion if they can conflict with global names or names 297 local to other enclaves. Use of the ".local" top level domain 298 assures no conflict with global names. To assure no conflict with 299 different local fully qualified names, the domain name of the enclave 300 SHOULD always be included in ".local" names. 302 For example, a company might have 304 host1.company.co.xy 306 as a globally accessible host and 308 host2.company.co.xy.b3.local 310 as a host for internal use only. The global name could normally be 311 resolvable anywhere on the Internet while the local name would be 312 undefined anywhere except within the company.co.xy enclave. 314 Note that different names were chosen for the initial label in the 315 two names above, i.e., host1 and host2. The reason for this is that, 316 in some environments, local hosts are referred to by an unqualified 317 names, such as host3. For DNS look up purposes, such a name must be 318 expanded into a fully qualified domain name and a "search list" of 319 possible suffix qualifications is tried. If, for example, both 320 host4.school.ac.xy and host4.school.ac.xy.b3.local existed, then a 321 local reference to "host4" would be ambiguous and could lead to 322 either machine depending on the order of qualifications tried. This 323 order could even be different in different pieces of local software 324 or on different local hosts, resulting in local confusion. For this 325 reason, it is strongly recommended that fully qualified domain names 326 be used wherever practical and that disjoint name sets be used for 327 global and local entity unqualified domain names. 329 2.4 Nested Enclaves 331 It is possible to have enclaves within enclaves. The best way to 332 accomplish this is to use a different portion of the private IP 333 address space at each nesting level of enclave. (Private IP address 334 space can be reused in enclaves that are siblings or the like.) Then 335 similar entries to those proposed here for ".local" can be made in 336 the private zone referring to name servers with addresses in the next 337 lower level nested enclave's private IP address space. 339 3. Other Names in .local 341 Three additional second level domain names are assigned in the 342 ".local" top level domain for other types of local names. 344 In particular, link.local and site.local are reserved for use in 345 qualifying IPv6 link local names and site local names and 346 loopback.local is assigned and given the loopback address. 348 4. Analysis of Alternatives 350 Possible alternatives to the scheme described in this document are 351 (1) recommend that DNS administrators locally configure a ".local", 352 (2) recommend that DNS administrators do a similar thing to ".local" 353 somewhere in their current domain name tree, and (3) take no action 354 leaving [RFC 1918] fully in effect. These alternatives are examined 355 below. 357 Only the scheme recommended in the sections of this document above 358 always permit generic resolvers running within a enclave and starting 359 at a global root zone to find private names and minimize user 360 confusion. 362 4.1 Locally Configured .local 364 It is possible for an enclave to locally configure its own version of 365 the ".local" zone. This version could have whatever private 366 addresses were desired for the name servers involved. However this 367 generally requires that all of the resolvers within the enclave be 368 configured to go through DNS servers that have this local variant of 369 ".local" configured. Thus "out of the box" resolvers starting at a 370 true root zone will not find the information. Furthermore, the 371 probability is increased that some administrators will use a variant 372 name increasing confusion. 374 4.2 Local Delegations Anywhere 376 It would be possible to just recommend putting hidden names in a 377 branch of the enclave's domain, like put them for the example company 378 under local.example.com. If all these apexes of hidden name subtrees 379 are visible in this way, then there would be a large number of 380 different looking local domain names that could confuse users by not 381 being globally resolvable. There would be a much greater chance of 382 completely different names (private.example.com, hidden.example.com, 383 net10.example.com, ...) being used increasing confusion.. However, 384 generic resolvers starting from a global root inside an enclave would 385 find private names configured in this way. 387 4.3 No Change 389 Just banishing private IP addresses from the global DNS by fiat and 390 having everyone who wants to use them run split DNS is the 391 recommendation of RFC 1918. But as private IP addresses become more 392 and more common, this restriction is increasingly overlooked. The 393 private names leak out anyway. Browsers inside a enclave that 394 started at a global root server are unable to find such hidden names. 395 And there is be much less uniformity of naming resulting in more user 396 confusion. 398 5. Security Considerations 400 This section discusses the strength of the privacy offered by using 401 subzones of ".local", interactions with DNS security, and possible 402 interaction with network abuse. 404 5.1 Strength of Privacy Offered 406 It should be noted that the privacy of the DNS information protected 407 by storing it in servers with private IP addresses is relatively 408 weak. It is dependent on the integrity of enclave perimeter routing 409 to make these servers inaccessible. And the names may leak out in 410 any case due to inclusion in email address fields, web pages, and the 411 like; however, such leakage will be no worse than current split DNS 412 implementations of DNS data hiding. 414 Software should not depend on local names only existing within a 415 particular enclave as someone could deliberately create the same 416 names within a different enclave even if the names incorporate the 417 name of the original enclave in an attempt to avoid such conflicts. 419 5.2 Interaction with DNSSEC 421 Although an enclave may derive some amount of security by virtue of 422 its isolation, it will normally be desirable to implement DNS 423 security [RFC 2065, draft-ietf-dnssec-secext-*.txt] within the 424 enclave. The enclave owner should generate their own keys and sign 425 their subzone of ".local". However, a signed copy of their public 426 key can not be included in the ".local" zone as it is different for 427 every enclave. Thus, to authenticate the ".local" subzone contents, 428 it will be necessary to staticly configure the public key for the 429 ".local" subzone in local resolvers or sign the KEY RR at the apex of 430 the local subzone of ".local" with another key that is trusted by 431 local resolvers such as the enclave domain name zone key or the 432 ".local" zone key. 434 5.3 Network Abuse 436 The existence of local IP addresses as provided in [RFC 1918] 437 provides another way for network abusers to create confusion to cover 438 their tracks and make abuse hard to trace. Use of ".local" does not 439 change this but will reduce confusion by providing clearer notice 440 that an address is not globally meaningful. 442 References 444 RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", 445 November 1987. 447 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 448 STD 13, November 1987. 450 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 451 Specifications", STD 13, November 1987. 453 RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", 454 03/03/1994. 456 RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. 457 Lear, "Address Allocation for Private Internets", 02/29/1996. 459 RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", 460 06/06/1996. 462 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 463 Extensions", 01/03/1997. 465 draft-ietf-dnssec-secext2-*.txt - 467 Author's Address 469 Donald E. Eastlake 3rd 470 CyberCash, Inc. 471 318 Acton Street 472 Carlisle, MA 01741 USA 474 Telephone: +1 978 287 4877 475 +1 703 620-4200 (main office, Reston, VA) 476 FAX: +1 978 371 7148 477 EMail: dee@cybercash.com 479 Expiration and File Name 481 This draft expires September 1998. 483 Its file name is draft-ietf-dnsind-local-names-05.txt. 485 Appendix A: the .local zone 487 ===== The .local zone suggested initial contents ==== 489 local. IN SOA ... ... ( 490 .... ; serial 491 ..... ; refresh 492 ..... ; retry 493 ....... ; expiry 494 ..... ) ; minimum 495 NS ... ; actual servers for .local zone 496 NS ... 497 ... 499 loopback A 127.0.0.1 500 AAAA 0::1 501 MX 100 loopback.local. 503 link TXT "Reserved. See RFC xxxx." [the rfc this draft becomes] 505 site TXT "Reserved. See RFC xxxx." [the rfc this draft becomes] 507 a2.local. NS ns1.a2.local. 508 NS ns2.a2.local. 509 ns1.a2.local. A 10.1.1.2 510 ns2.a2.local. A 10.1.2.2 512 a3.local. NS ns1.a3.local. 513 NS ns2.a3.local. 514 NS ns3.a3.local. 515 ns1.a3.local. A 10.1.1.2 516 ns2.a3.local. A 10.1.2.2 517 ns3.a3.local. A 10.2.1.2 519 a4.local. NS ns1.a4.local. 520 NS ns2.a4.local. 521 NS ns3.a4.local. 522 NS ns4.a4.local. 523 ns1.a4.local. A 10.1.1.2 524 ns2.a4.local. A 10.1.2.2 525 ns3.a4.local. A 10.2.1.2 526 ns4.a4.local. A 10.128.1.2 528 b2.local. NS ns1.b2.local. 529 NS ns2.b2.local. 530 ns1.b2.local. A 172.16.1.2 531 ns2.b2.local. A 172.16.2.2 533 b3.local. NS ns1.b3.local. 534 NS ns2.b3.local. 536 NS ns3.b3.local. 537 ns1.b3.local. A 172.16.1.2 538 ns2.b3.local. A 172.16.2.2 539 ns3.b3.local. A 172.16.128.2 541 c2.local. NS ns1.c2.local. 542 NS ns2.c2.local. 543 ns1.c2.local. A 192.168.1.2 544 ns2.c2.local. A 192.168.2.2 546 c3.local. NS ns1.c3.local. 547 NS ns2.c3.local. 548 NS ns3.c3.local. 549 ns1.c3.local. A 192.168.1.2 550 ns2.c3.local. A 192.168.2.2 551 ns3.c3.local. A 192.168.128.2 553 Appendix B: the .in-addr.arpa zone 555 ===== Suggested additional entries in the in-addr.arpa zone ==== 557 10.in-addr.arpa. NS ns1.a2.local. 558 NS ns2.a2.local. 559 ns1.a2.local. A 10.1.1.2 560 ns2.a2.local. A 10.1.2.2 562 16.172.in-addr.arpa. NS ns1.b2.local. 563 NS ns2.b2.local. 564 ns1.b2.local. A 172.16.1.2 ; one set of glue records 565 ns2.b2.local. A 172.16.2.2 ; for all the b2 cases 566 17.172.in-addr.arpa. NS ns1.b2.local. 567 NS ns2.b2.local. 568 18.172.in-addr.arpa. NS ns1.b2.local. 569 NS ns2.b2.local. 570 19.172.in-addr.arpa. NS ns1.b2.local. 571 NS ns2.b2.local. 572 20.172.in-addr.arpa. NS ns1.b2.local. 573 NS ns2.b2.local. 574 21.172.in-addr.arpa. NS ns1.b2.local. 575 NS ns2.b2.local. 576 22.172.in-addr.arpa. NS ns1.b2.local. 577 NS ns2.b2.local. 578 23.172.in-addr.arpa. NS ns1.b2.local. 579 NS ns2.b2.local. 580 24.172.in-addr.arpa. NS ns1.b2.local. 581 NS ns2.b2.local. 582 25.172.in-addr.arpa. NS ns1.b2.local. 583 NS ns2.b2.local. 584 26.172.in-addr.arpa. NS ns1.b2.local. 585 NS ns2.b2.local. 586 27.172.in-addr.arpa. NS ns1.b2.local. 587 NS ns2.b2.local. 588 28.172.in-addr.arpa. NS ns1.b2.local. 589 NS ns2.b2.local. 590 29.172.in-addr.arpa. NS ns1.b2.local. 591 NS ns2.b2.local. 592 30.172.in-addr.arpa. NS ns1.b2.local. 593 NS ns2.b2.local. 594 31.172.in-addr.arpa. NS ns1.b2.local. 595 NS ns2.b2.local. 597 168.192.in-addr.arpa. NS ns1.c2.local. 598 NS ns2.c2.local. 599 ns1.c2.local. A 192.168.1.2 600 ns2.c2.local. A 102.168.2.2