INTERNET-DRAFT Local Domain Names
November 1998
Expires May 1999
Local DNS Names
----- --- -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-local-names-06.txt, is
intended to be become an Informational 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 view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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]. These
zone locally appear to be part of the global DNS name tree.
Additional second level domain names are assigned under this TLD for
loopback addresses and IPv6 link and site local addresses.
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.............3
2.1 Local DNS Server Specifics.............................6
2.2 Local in-addr.arpa Zones...............................7
2.3 Name Conflicts.........................................7
2.4 Nested Enclaves........................................8
3. Other Names in .local...................................8
4. Security Considerations.................................8
4.1 Strength of Privacy Offered............................8
4.2 Interaction with DNSSEC................................9
4.3 Network Abuse..........................................9
References................................................10
Author's Address..........................................10
Expiration and File Name..................................10
Appendix A: the .local zone...............................11
Appendix B: the .in-addr.arpa zone.......................13
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 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]. Familiarity
with the contents of that RFC is assumed.
In the DNS area, local private names have generally been 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, etc.
as mentioned in [RFC 1918]. Such relatively complex configuration
diddling is at variance with the simple global tree structure of the
initial DNS.
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 or at least the appearance of a single tree.
Use of this approach is not required and older techniques will
continue to work.
[RFC 1918] requires that private IP addresses not be indirectly
exposed to the general Internet via DNS records or otherwise. This
RFC provides the 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.
2. Local Names Via 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's addresses
would only be routed within the domain to which the names are local.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
Thus the servers, and the names and resource records inside them,
would not be directly accessible outside the enclave, if the
guidelines in this document are followed.
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
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 but
substantially more). The addresses of the servers for the root (.),
.com, and example.com zones would all be in the public portion of the
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
IP address space, i.e., in the space of all unicast IP addresses not
reserved for private use.
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 visible only 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
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. The dotted line in the figure above is intended to indicate
that privhost3 and pubhost4 are actually the same physical machine.
The could be accomplished equally well by storing a single 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.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
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 also possible for an enclave to locally configure its own
version of the .local zone. Depending on its enclave boundary
implementation, it might be able to constrain all of its internal
references to .local to use its own variant version. This version
could have whatever private addresses were desired for the name
servers involved. Such a configuration MAY be used, but it is
recommended that the globally accessible .local specified herein be
used for uniformity. That way, even a unconstrained resolver
starting from the normal root servers (i.e., an "out of the box"
resolver) will correctly resolve or fail to resolve names under
.local depending on the resolvers location in the network as
specified herein.
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 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
that resolver.
The Appendix A to this document gives the recommended initial content
of the .local zone.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Local DNS Names
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 (or subzones thereof)
to accomplish this. Because of the fixed naming within this zone,
different names with 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 leak out via email cc's, URL's in
HTML, etc. (Such leakage occurs regardless of how the local names
are formed or whether they are accessible via the default root zone.)
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 prefixed to .local.
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 could not be
resolved anywhere except within the company 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 substantial confusion. For
this reason, it is strongly recommended that disjoint name sets be
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Local DNS Names
used for global and local entity unqualified domain names and that
fully qualified domain names be used wherever practical.
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 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 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.
In addition, loopback.local is assigned and given the loopback
address.
4. 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.
4.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 not strong. It
is completely dependent on the integrity of enclave perimeter routing
to make these servers inaccessible. And it may occasionally leak out
in any case due to inclusion in email address fields, web pages, and
the like, although such leakage should be no worse than current split
DNS implementations of DNS data hiding.
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 8]
INTERNET-DRAFT Local DNS Names
same names within a different enclave even if the names incorporate
the name of the original enclave in an attempt to avoid such
conflicts.
4.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 [draft-ietf-dnssec-secext2-*.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 sign the KEY RR at the apex of the local subzone of
.local with the .local zone key or another key that is trusted by
local resolvers or staticly configure the public key for the .local
subzone in local resolvers.
4.3 Network Abuse
Use of the defined private server second level domain names under
return addresses, or the like, could 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, although
this violates [RFC 1918], create entries therein with arbitrary IP
addresses (including multicast and undefined formats). Then, by
using these name entries in email, web links, etc., attempt to cause
a variety of spurious protocol connections to those addresses.
Use of .local at least provides some warning that a name may be not
be correctly resolvable.
Donald E. Eastlake 3rd [Page 9]
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.
draft-ietf-dnssec-secext2-*.txt - D. Eastlake "Domain Name System
Security Extensions".
Author's Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires May 1999.
Its file name is draft-ietf-dnsind-local-names-06.txt.
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT Local DNS Names
Appendix A: the .local zone
===== The .local zone suggested initial contents ====
local. IN SOA ... ... (
1234 ; serial
90000 ; refresh, 25 hours
36000 ; retry, 10 hours
3456000 ; expiry, 40 days
43200 ) ; minimum of 12 hours
NS ... ; actual servers for .local zone
NS ...
...
loopback A 127.0.0.1
AAAA 0::1
MX 100 loopback.local.
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.
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
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Local DNS Names
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 12]
INTERNET-DRAFT Local DNS Names
Appendix B: the .in-addr.arpa zone
===== Auggested 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 13]
