INTERNET-DRAFT                                           Local DNS Names
                                                              March 1998
                                                  Expires September 1998



                        Local Domain (DNS) Names
                        ----- ------ ----- -----

                         Donald E. Eastlake 3rd



Status of This Document

   This draft, file name draft-ietf-dnsind-local-names-05.txt, is
   intended to be become an Experimental RFC.  Distribution of this
   document is unlimited. Comments should be sent to the DNS mailing
   list <namedroppers@internic.net> or to the author.

   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),
   ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
   munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).



Abstract

   A new top level domain (TLD) name is defined such that local private
   DNS zones can easily be maintained similar to the private IP
   addresses reserved in [RFC 1918].  These zones locally appear to be
   part of the global DNS name tree and can be locally resolved, even by
   "out of the box" resolvers starting at the global root zone, but are
   inaccessible outside their enclave.  Additional second level domain
   names are reserved under this TLD for IPv6 link and site local
   addresses and loopback addresses. User confusion is reduced by
   grouping all non-global names under this new TLD so they are more
   easily recognizable.




Donald E. Eastlake 3rd                                          [Page 1]


INTERNET-DRAFT                                           Local DNS Names


Acknowledgments

   The valuable contributions of the following persons are gratefully
   acknowledged:

        Dan Harrington

        Michael A. Patton



Table of Contents

      Status of This Document....................................1
      Abstract...................................................1

      Acknowledgments............................................2
      Table of Contents..........................................2

      1. Introduction............................................3
      2. Local Names Via The .local Top Level Domain.............4
      2.1 Local DNS Server Specifics.............................6
      2.2 Local in-addr.arpa Zones...............................6
      2.3 Name Conflicts.........................................7
      2.4 Nested Enclaves........................................8
      3. Other Names in .local...................................8
      4. Analysis of Alternatives................................8
      4.1 Locally Configured .local..............................8
      4.2 Local Delegations Anywhere.............................9
      4.3 No Change..............................................9
      5. Security Considerations.................................9
      5.1 Strength of Privacy Offered............................9
      5.2 Interaction with DNSSEC...............................10
      5.3 Network Abuse.........................................10

      References................................................11
      Author's Address..........................................11
      Expiration and File Name..................................11

      Appendix A: the .local zone...............................12

      Appendix  B: the .in-addr.arpa zone.......................14










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.  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 privacy 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 their DNS name.

   In the realm of IPv4 addresses, this has been accomplished by
   reserving three blocks of addresses as documented in [RFC 1918].
   This designation of private IP addresses also helps conserve global
   IP addresses.  Familiarity with the contents of [RFC 1918] is
   assumed.

   In the DNS area, [RFC 1918] recommends "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, etc. Such relatively complex configuration
   diddling is at variance with the simple global tree structure
   envisaged in the original DNS design.  It can cause the local names
   to be invisible to "out of the box" resolvers within the enclave if
   they start at a global root zone.  Furthermore, because local DNS
   names created in accordance with [RFC 1918] can be entirely arbitrary
   and unrecognizable as local, user confusion is increased.

   This document specifies an alternative approach to achieving the
   effect of local names that is more in tune with the concept of a
   single global DNS tree and reduces user confusion by making local
   names easily recognizable.  Use of this approach by local DNS
   administrators is not required and older techniques will continue to
   work as well as they have in the past.

   [RFC 1918] requires that private IP addresses not be indirectly
   exposed to the general Internet via DNS records or otherwise.  This
   RFC provides a recommended way to accomplish such private IP address
   hiding and carves out an exception thereto for the addresses of the
   servers for some zones which are children of the ".local" top level
   domain name.





Donald E. Eastlake 3rd                                          [Page 3]


INTERNET-DRAFT                                           Local DNS Names


2. Local Names Via The .local Top Level Domain

   The fundamental idea for providing local names, as described in more
   detail below, is to define second level domains under ".local" which
   are served by domain name system (DNS) name servers that have private
   IP addresses.  These server's 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, if the guidelines in
   this document are followed, be inaccessible outside the enclave.

   The following figure shows a highly simplified overview of an example
   configuration:

                                   +----------------------------+
                                   |      domain/enclave A      |
                                   |                            |
                                   |   #====================#   |
                                   |   H private IP addrs A H   |
                                   |   H                    H   |
                    +-----------------------O privhost1     H   |
                    |              |   H                    H   |
                    +-----+-----------------O privhost2     H   |
                    |     |        |   H                    H   |
                    |     |        |   #====================#   |
                    |     |    a   |                            |
                    |  +--------------------O pubhost3          |
            .local  |  |  |        |                            |
               +----+  |  |        +----------------------------+
               |    |  |  |
               |    |  |  |        +----------------------------+
               |    |  |  |        |      domain/enclave B      |
      (root)   |    |  |  |        |                            |
         . ----+    |  |  |        |   #====================#   |
               |    |  |  |        |   H private IP addrs B H   |
               |    |  |  |        |   H                    H   |
               |    +--|--------------------O privhost2     H   |
               |       |  |        |   H                    H   |
               +-------+  +-----------------O privhost3     H   |
             .com      |           |   H    :               H   |
                       |           |   #====:===============#   |
                       |           |        :                   |
                       |   b  +-------------O pubhost4          |
                       +------+    |                            |
                       |      +-------------O pubhost5          |
                       |           |                            |
                       |           +----------------------------+
                       |
                       |  example
                       +---------------------O pubhost6



Donald E. Eastlake 3rd                                          [Page 4]


INTERNET-DRAFT                                           Local DNS Names


   Starting at the bottom, pubhost6 is intended to illustrate an
   ordinary host connected to the Internet with domain name
   pubhost6.example.com.  Though not indicated in the above diagram,
   every DNS zone is in fact served by at least two hosts and some by
   substantially more than two. The addresses of the servers for the
   root ("."), ".com", and example.com zones would all be in the public
   portion of the IP address space, i.e., in the space of unicast IP
   addresses not reserved for private use so these servers are
   accessible to all.

   Moving to the top of the figure, enclave A represents some
   organization that wishes to have some hosts with publicly visible
   names and some with hidden names that are only visible locally.
   pubhost3.a.com is an example of a publicly visible host which would
   probably have a public IP address (although access to pubhost3 from
   outside the enclave might be filtered or even blocked by a firewall
   or the like).  privhost1 and privhost2 are examples of hidden names.
   If a zone with privhost1 and privhost2 in it is served by DNS servers
   with private IP addresses ("private IP addresses A") such that the
   servers are accessible within enclave A but not from outside enclave
   A, then the information is that zone will only be locally visible.
   As show in the above figure, privhost1 and privhost2 have addresses
   that are also private IP addresses, making those hosts inaccessible
   outside enclave A, but it is the private addresses of the DNS
   servers, not of the hosts pointed to from within the private DNS
   zone, that provides the protection for the DNS names and other
   private DNS information.  (From the above simplified diagram, it
   might appear that fully qualified domain names of these hosts would
   be privhost1.local and privhost2.local but the names are actually a
   little more complex as explained in Section 2.1.)

   Finally, in the middle, another enclave is shown with two hosts with
   visible names and public IP addresses, pubhost4.b.com and
   pubhost5.b.com.  In addition, there are two private host names
   privhost2 and privhost3.  The duplication of privhost2 between
   enclaves A and B would not be a problem as only DNS resolvers in
   enclave A can access the DNS servers with the zone having the enclave
   A version of privhost2 and only DNS resolvers in enclave B can access
   the DNS servers with the zone having the enclave B version of
   privhost2.

   Publicly visible host names are required by [RFC 1918] to have public
   (i.e., globally unique) IP addresses.  Private DNS names would
   normally have private IP addresses, and all do in the figure above,
   but this is not required.  A public IP address could be stored under
   a private name.  And, of course, it is possible for the same physical
   host to have multiple IP addresses, including a mix of public and
   private addresses.  The dotted line in the figure above is intended
   to indicate that privhost3 and pubhost4 are actually the same
   physical machine.  The could also be accomplished by storing a single


Donald E. Eastlake 3rd                                          [Page 5]


INTERNET-DRAFT                                           Local DNS Names


   public address for that host under both the public and private names
   or by having the host answer to both a public IP address stored under
   the public name and a private IP address stored under the private
   name.  In the later case you could even also store the public address
   along with the private address under the private name.



2.1 Local DNS Server Specifics

   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
   multiple second level names permit choice between the different
   private IP blocks and different numbers of servers.  Thus the actual
   fully qualified name for the private host examples in the figure
   above would be more like privhost1.a2.local, privhost2.a2.local, etc.
   (but see Section 2.3 below).

   Glue records are provided to give private IP addresses for initial
   name 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 or different servers than were given
   at the chosen ".local" delegation point.  Nevertheless, the glue A
   records in the global ".local" zone do place some constraints of the
   private IP address of the local DNS servers implementing zones which
   are children of ".local".

   It is only necessary for the local DNS servers to have private IP
   addresses to achieve the effect of local names. However, care MUST be
   taken that none of the local DNS servers or any server that might
   cache their output is accessible by any globally accessible network
   interface. Otherwise confusion could result if local names are
   resolved by a resolver outside a local enclave to private IP
   addresses which are meaningless or have a different meaning for that
   resolver.

   The Appendix A to this document gives an initial content of the
   ".local" zone.



2.2 Local in-addr.arpa Zones

   Inverse look up 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 domain to accomplish this.
   Because of the fixed naming within this zone, different names with


Donald E. Eastlake 3rd                                          [Page 6]


INTERNET-DRAFT                                           Local DNS Names


   different numbers of servers or different addresses can not be
   provided.  As with the forward ".local" entries, the actual NS RRs in
   the servers serving the private portions of the inverse in-addr.arpa
   will dominate.  When one of these is queried by a resolver, it can
   provide information on additional servers for that particular 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, despite best efforts
   to avoid it, some such names will occasionally leak out via email
   cc's, URL's in HTML, etc. This occurs currently with local names not
   following the design in this document.  These leaked private names
   can cause confusion if they can conflict with global names or names
   local to other enclaves.  Use of the ".local" top level domain
   assures no conflict with global names.  To assure no conflict with
   different local fully qualified names, the domain name of the enclave
   SHOULD always be included in ".local" names.

   For example, a company might have

        host1.company.co.xy

   as a globally accessible host and

        host2.company.co.xy.b3.local

   as a host for internal use only.  The global name could normally be
   resolvable anywhere on the Internet while the local name would be
   undefined anywhere except within the company.co.xy enclave.

   Note that different names were chosen for the initial label in the
   two names above, i.e., host1 and host2. The reason for this is that,
   in some environments, local hosts are referred to by an unqualified
   names, such as host3.  For DNS look up purposes, such a name must be
   expanded into a fully qualified domain name and a "search list" of
   possible suffix qualifications is tried.  If, for example, both
   host4.school.ac.xy and host4.school.ac.xy.b3.local existed, then a
   local reference to "host4" would be ambiguous and could lead to
   either machine depending on the order of qualifications tried.  This
   order could even be different in different pieces of local software
   or on different local hosts, resulting in local confusion. For this
   reason, it is strongly recommended that fully qualified domain names
   be used wherever practical and that disjoint name sets be used for
   global and local entity unqualified domain names.



Donald E. Eastlake 3rd                                          [Page 7]


INTERNET-DRAFT                                           Local DNS Names


2.4 Nested Enclaves

   It is possible to have enclaves within enclaves.  The best way to
   accomplish this is to use a different portion of the private IP
   address space at each nesting 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 next
   lower level nested enclave's private IP address space.



3. Other Names in .local

   Three additional second level domain names are assigned in the
   ".local" top level domain for other types of local names.

   In particular, link.local and site.local are reserved for use in
   qualifying IPv6 link local names and site local names and
   loopback.local is assigned and given the loopback address.



4. Analysis of Alternatives

   Possible alternatives to the scheme described in this document are
   (1) recommend that DNS administrators locally configure a ".local",
   (2) recommend that DNS administrators do a similar thing to ".local"
   somewhere in their current domain name tree, and (3) take no action
   leaving [RFC 1918] fully in effect.  These alternatives are examined
   below.

   Only the scheme recommended in the sections of this document above
   always permit generic resolvers running within a enclave and starting
   at a global root zone to find private names and minimize user
   confusion.



4.1 Locally Configured .local

   It is possible for an enclave to locally configure its own version of
   the ".local" zone.  This version could have whatever private
   addresses were desired for the name servers involved.  However this
   generally requires that all of the resolvers within the enclave be
   configured to go through DNS servers that have this local variant of
   ".local" configured. Thus "out of the box" resolvers starting at a
   true root zone will not find the information.  Furthermore, the
   probability is increased that some administrators will use a variant
   name increasing confusion.


Donald E. Eastlake 3rd                                          [Page 8]


INTERNET-DRAFT                                           Local DNS Names


4.2 Local Delegations Anywhere

   It would be possible to just recommend putting hidden names in a
   branch of the enclave's domain, like put them for the example company
   under local.example.com.  If all these apexes of hidden name subtrees
   are visible in this way, then there would be a large number of
   different looking local domain names that could confuse users by not
   being globally resolvable.  There would be a much greater chance of
   completely different names (private.example.com, hidden.example.com,
   net10.example.com, ...) being used increasing confusion..  However,
   generic resolvers starting from a global root inside an enclave would
   find private names configured in this way.



4.3 No Change

   Just banishing private IP addresses from the global DNS by fiat and
   having everyone who wants to use them run split DNS is the
   recommendation of RFC 1918.  But as private IP addresses become more
   and more common, this restriction is increasingly overlooked.  The
   private names leak out anyway.  Browsers inside a enclave that
   started at a global root server are unable to find such hidden names.
   And there is be much less uniformity of naming resulting in more user
   confusion.



5. Security Considerations

   This section discusses the strength of the privacy offered by using
   subzones of ".local", interactions with DNS security, and possible
   interaction with network abuse.



5.1 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 dependent on the integrity of enclave perimeter routing
   to make these servers inaccessible.  And the names may leak out in
   any case due to inclusion in email address fields, web pages, and the
   like; however, such leakage will be no worse than current split DNS
   implementations of DNS data hiding.

   Software should not depend on local names only existing within a
   particular enclave as someone could deliberately create the same
   names within a different enclave even if the names incorporate the
   name of the original enclave in an attempt to avoid such conflicts.


Donald E. Eastlake 3rd                                          [Page 9]


INTERNET-DRAFT                                           Local DNS Names


5.2 Interaction with DNSSEC

   Although an enclave may derive some amount of security by virtue of
   its isolation, it will normally be desirable to implement DNS
   security [RFC 2065, draft-ietf-dnssec-secext-*.txt] within the
   enclave.  The enclave owner should generate their own keys and sign
   their subzone of ".local".  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" subzone contents,
   it will be necessary to staticly configure the public key for the
   ".local" subzone in local resolvers or sign the KEY RR at the apex of
   the local subzone of ".local" with another key that is trusted by
   local resolvers such as the enclave domain name zone key or the
   ".local" zone key.



5.3 Network Abuse

   The existence of local IP addresses as provided in [RFC 1918]
   provides another way for network abusers to create confusion to cover
   their tracks and make abuse hard to trace.  Use of ".local" does not
   change this but will reduce confusion by providing clearer notice
   that an address is not globally meaningful.




























Donald E. Eastlake 3rd                                         [Page 10]


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.

   draft-ietf-dnssec-secext2-*.txt -



Author's Address

   Donald E. Eastlake 3rd
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 978 287 4877
                +1 703 620-4200 (main office, Reston, VA)
   FAX:         +1 978 371 7148
   EMail:       dee@cybercash.com



Expiration and File Name

   This draft expires September 1998.

   Its file name is draft-ietf-dnsind-local-names-05.txt.






Donald E. Eastlake 3rd                                         [Page 11]


INTERNET-DRAFT                                           Local DNS Names


Appendix A: the .local zone

   =====   The .local zone suggested initial contents  ====

   local.        IN  SOA  ...  ...  (
                     ....           ; serial
                     .....          ; refresh
                     .....          ; retry
                     .......        ; expiry
                     ..... )        ; minimum
                 NS  ...            ; actual servers for .local zone
                 NS  ...
                 ...

   loopback      A      127.0.0.1
                 AAAA   0::1
                 MX     100 loopback.local.

   link          TXT    "Reserved.  See RFC xxxx." [the rfc this draft becomes]

   site          TXT    "Reserved.  See RFC xxxx." [the rfc this draft becomes]

   a2.local.     NS     ns1.a2.local.
                 NS     ns2.a2.local.
   ns1.a2.local. A      10.1.1.2
   ns2.a2.local. A      10.1.2.2

   a3.local.     NS     ns1.a3.local.
                 NS     ns2.a3.local.
                 NS     ns3.a3.local.
   ns1.a3.local. A      10.1.1.2
   ns2.a3.local. A      10.1.2.2
   ns3.a3.local. A      10.2.1.2

   a4.local.     NS     ns1.a4.local.
                 NS     ns2.a4.local.
                 NS     ns3.a4.local.
                 NS     ns4.a4.local.
   ns1.a4.local. A      10.1.1.2
   ns2.a4.local. A      10.1.2.2
   ns3.a4.local. A      10.2.1.2
   ns4.a4.local. A      10.128.1.2

   b2.local.     NS     ns1.b2.local.
                 NS     ns2.b2.local.
   ns1.b2.local. A      172.16.1.2
   ns2.b2.local. A      172.16.2.2

   b3.local.     NS     ns1.b3.local.
                 NS     ns2.b3.local.


Donald E. Eastlake 3rd                                         [Page 12]


INTERNET-DRAFT                                           Local DNS Names


                 NS     ns3.b3.local.
   ns1.b3.local. A      172.16.1.2
   ns2.b3.local. A      172.16.2.2
   ns3.b3.local. A      172.16.128.2

   c2.local.     NS     ns1.c2.local.
                 NS     ns2.c2.local.
   ns1.c2.local. A      192.168.1.2
   ns2.c2.local. A      192.168.2.2

   c3.local.     NS     ns1.c3.local.
                 NS     ns2.c3.local.
                 NS     ns3.c3.local.
   ns1.c3.local. A      192.168.1.2
   ns2.c3.local. A      192.168.2.2
   ns3.c3.local. A      192.168.128.2




































Donald E. Eastlake 3rd                                         [Page 13]


INTERNET-DRAFT                                           Local DNS Names


Appendix  B: the .in-addr.arpa zone

   =====  Suggested additional 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 14]