INTERNET-DRAFT Local Domain Names July 1997 Expires January 1998 Local DNS Names ----- --- ----- Donald E. Eastlake 3rd Status of This Document This draft, file name draft-eastlake-local-names-00.txt, is intended to be become an Informational RFC. Distribution of this document is unlimited. Comments should be sent to the DNS mailing list or to the authors. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Abstract A set of second level domain names are defined under a new top level domain name such that local private DNS zones can be maintained similar to the private IP addresses reserved in RFC 1918 but which locally appear to be part of the global DNS name tree. Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Local DNS Names Table of Contents Status of This Document....................................1 Abstract...................................................1 Table of Contents..........................................2 1. Introduction............................................3 2. The .local Top Level Domain.............................4 2.1 Local DNS Servers......................................4 2.2 Local in-addr.arpa Zones...............................4 2.3 Name Conflicts.........................................5 2.4 Nested Enclaves........................................5 3. Security Considerations.................................6 3.1 Interaction with DNSSEC................................6 3.2 Network Abuse..........................................6 3.3 Strength of Privacy Offered............................6 References.................................................8 Author's Address...........................................8 Expiration and File Name...................................8 Appendix A: the .local zone................................9 Appendix B: the .in-addr.arpa zone.......................11 Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Local DNS Names 1. Introduction The global Internet Domain Name System (DNS) is documented in RFC 1034, 1035, 1591 and numerous additional Requests for Comment. It defines a tree of names starting with root, ".", immediately below which are top level domain names such as .com and .us as discussed in RFC 1591. Below top level domain names there are normally additional levels of names. Generally the information in the DNS is public and intended to be globally accessible. Certainly, in the past, the model of the Internet was one of end-to-end openness. [RFC 1958] However, with increasing security threats and concerns, firewalls and enclaves have appeared. In many cases, organizations have hosts or resources that they specifically want to reference with DNS names but which they also want to be walled off from global access and even from global knowledge of the DNS name. In the realm of IP addresses, this has been accomplished by reserving three blocks of addresses as documented in RFC 1918. In the DNS area, local private names have generally be achieved in the past by "splitting" DNS at the enclave boundary, giving different answers to resolvers depending or whether they are inside or outside of the enclave, using different servers for inside and outside, creating fake local root servers, and similar relatively complex configuration diddling, which is arguably at variance with the simple global tree structure of the DNS. The document specifies an alternative approach to achieving the effect of local names. Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Local DNS Names 2. The .local Top Level Domain The fundamental idea, as described in more detail below, is to define second level domains under .local which are served by DNS name servers that have private IP addresses. These server addresses would only be routed within the enclave to which the names are local. Thus the servers and the names and resource records inside them would automatically be inaccessible outside the enclave. 2.1 Local DNS Servers A variety of second level names are provided in the .local zone each of which is a delegation point to a zone with some number of name servers in one of the private IP address space blocks. The Appendix A to this document gives the recommended content of the .local zone. Glue records are provided to give private IP addresses for initial servers; however, it should be noted that the NS and A records in the local zones will dominate the information stored in the .local zone. This means that once a resolver has contacted a local server, the list of NS RRs in the local zone on that server will control and could contain more servers than were given at the chosen ??.local delegation point. It is only necessary for the local DNS servers to have private IP addresses to achieve the effect of local names. Any address pointers associated with these local names would most likely point to private IP addresses but could point to global addresses. However, care MUST be taken that none of the local DNS servers or any server that might cache their output is accessible by any network interface that has a non-private IP address. Otherwise considerable confusion could result if local names are resolved by a resolver outside a local enclave to private IP addresses which have a different meaning for the resolver. 2.2 Local in-addr.arpa Zones Inverse lookup of local names corresponding to private IP addresses needs to be provided via the in-addr.arpa zone. Appendix B contains recommended additions to the in-addr.arpa zone to accomplish this. Because of the fixed naming within this zone, different names with different numbers of servers can not be provided but two servers should be sufficient. As with the forward ??.local entries, the actual NS RRs in the servers serving the private portions of in- addr.arpa will dominate. When one of these is queried by a resolver, it can provide information on additional servers for that particular Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Local DNS Names subzone in the private IP address portion of the in-addr.arpa tree. 2.3 Name Conflicts The intention is that local names would only be used in the enclave where the entities they refer to exist, and these names would not be exported. However, experience indicates that such names will leak out and can cause confusion and if they can conflict with global names or names local to other enclaves. Use of the .local TLD assures no conflict with global names. To assure no conflict with different local names, the domain name of the enclave SHOULD always be prefixed to .local. For example, a company might have www.company.com.xx as a globally accessible web server and www.company.com.xx.b3.local as a web server for internal use only. The global name could normally be resolvable anywhere on the Internet while the local name could not be resolved anywhere except within the company enclave. 2.4 Nested Enclaves It is possible to have enclaves within enclaves. In general the best way to accomplish this is to use a different portion of the private IP address space at each level of enclave. (Private IP address space can be reused in enclaves that are siblings or the like.) Then similar entries to those proposed here for .local can be made in the private zone referring to name servers with addresses in the nested enclaves IP address space. Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Local DNS Names 3. Security Considerations 3.1 Interaction with DNSSEC Although an enclave may derive some small amount of security by virtue of its isolation, it will normally be desirable to implement DNS security [RFC 2065] within the enclave. The enclave owner should generate their own keys and sign their ??.local zone. However, a signed copy of their public key can not be included in the .local zone as it is different for every enclave. Thus, to authenticate the ??.local zone contents, it will be necessary to staticly configure the public key for the ??.local zone in local resolvers or cross sign the KEY RR at the apex of the local ??.local zone with another key that is trusted by local resolvers. 3.2 Network Abuse Use of the defined second level domain names under .local in URLs, email return addresses, or the like, can cause DNS, SMTP, and many other types of references to IP addresses in the RFC 1918 blocks. This can occur from within a firewall due to web browsing or email processing of web pages or email from virtually anywhere in the Internet. However, this is not a new situation as anyone who controls any zone in the DNS, say zone.foo.example, can create entries therein with arbitrary IP addresses (including multicast and undefined formats) and then, by using these name entries in email, web links, etc., cause a variety of spurious protocol connections to those addresses. Local names may provide another way for network abusers to create confusion to cover their tracks and make abuse hard to trace. But ephemeral or unreachable names can be created currently via rapid zone changes or delegation to non-existent server. Use of .local at least provides some warning that a name may be unreachable.. 3.3 Strength of Privacy Offered It should be noted that the privacy of the DNS information protected by storing it in servers with private IP addresses is relatively weak. It is completely dependent on the integrity of enclave perimeter routing to make these servers inaccessible. Software should not depend on local names being accessible only within a particular enclave as someone could deliberately create the Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Local DNS Names same names within a different enclave even if they include the name of the original enclave to try to avoid such conflicts. Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT Local DNS Names References RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", November 1987. RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", STD 13, November 1987. RFC 1035 - P. Mockapetris, "Domain Names - Implementation and Specifications", STD 13, November 1987. RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", 03/03/1994. RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, "Address Allocation for Private Internets", 02/29/1996. RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", 06/06/1996. RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", 01/03/1997. Author's Address Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508 287 4877 +1 703 620-4200 (main office, Reston, VA) FAX: +1 508 371 7148 EMail: dee@cybercash.com Expiration and File Name This draft expires January 1998. Its file name is draft-eastlake-local-names-00.txt. Donald E. Eastlake 3rd [Page 8] INTERNET-DRAFT Local DNS Names Appendix A: the .local zone ===== The .local zone ==== local. IN SOA ... ... ( 1234 ; serial 90000 ; refresh, 25 hours 18000 ; retry, 5 hours 3456000 ; expiry, 40 days 43200 ) ; minimum of 12 hours NS ... ; actual servers for .local zone NS ... ... a2.local. NS ns1.a2.local. ns1 A 10.1.1.2 NS ns2.a2.local. ns2 A 10.1.2.2 a3.local. NS ns1.a3.local. ns1 A 10.1.1.2 NS ns2.a3.local. ns2 A 10.1.2.2 NS ns3.a3.local. ns3 A 10.2.1.2 a4.local. NS ns1.a4.local. ns1 A 10.1.1.2 NS ns2.a4.local. ns2 A 10.1.2.2 NS ns3.a4.local. ns3 A 10.2.1.2 NS ns4.a4.local. ns4 A 10.128.1.2 b2.local. NS ns1.b2.local. ns1 A 172.16.1.2 NS ns2.b2.local. ns2 A 172.16.2.2 b3.local. NS ns1.b3.local. ns1 A 172.16.1.2 NS ns2.b3.local. ns2 A 172.16.2.2 NS ns3.b3.local. ns3 A 172.16.128.2 c2.local. NS ns1.c2.local. ns1 A 192.168.1.2 NS ns2.c2.local. ns2 A 192.168.2.2 c3.local. NS ns1.c3.local. ns1 A 192.168.1.2 Donald E. Eastlake 3rd [Page 9] INTERNET-DRAFT Local DNS Names NS ns2.c3.local. ns2 A 192.168.2.2 NS ns3.c3.local. ns3 A 192.168.128.2 Donald E. Eastlake 3rd [Page 10] INTERNET-DRAFT Local DNS Names Appendix B: the .in-addr.arpa zone ===== Entries in the in-addr.arpa zone ==== 10.in-addr.arpa. NS ns1.a2.local. NS ns2.a2.local. ns1.a2.local. A 10.1.1.2 ns2.a2.local. A 10.1.2.2 16.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. ns1.b2.local. A 172.16.1.2; one set of glue records ns2.b2.local. A 172.16.2.2 ; for all the b2 cases 17.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 18.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 19.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 20.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 21.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 22.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 23.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 24.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 25.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 26.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 27.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 28.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 29.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 30.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 31.172.in-addr.arpa. NS ns1.b2.local. NS ns2.b2.local. 168.192.in-addr.arpa. NS ns1.c2.local. NS ns2.c2.local. ns1.c2.local. A 192.168.1.2 ns2.c2.local. A 102.168.2.2 Donald E. Eastlake 3rd [Page 11]