Subject: "local" zones

From: Akira Kato <[email-masked]>
Date: Tue, 25 Feb 2003 14:59:50 +0900 (JST)

I missed the dead line of the initial submission of an I-D, I'd post it
to the list. I'd post it as a working group draft if applicable after
San Francisco IETF meeting.

-- Akira Kato

Internet Engineering Task Force                         Akira Kato, WIDE
INTERNET-DRAFT                                           Paul Vixie, ISC
Expires: August 24, 2003                               February 24, 2003

          Operational Guidelines for "local" zones in the DNS
                  draft-kato-dnsop-local-zones-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be August 24, 2003.

Abstract

A large number of DNS queries regarding to the "local" zones are sent
over the Internet in every second.  This memo describes operational
guidelines to reduce the unnecessary DNS traffic as well as the load of
the Root DNS Servers.

1.  Introduction

While it has yet been described in a RFC, .local is used to provide a
local subspace of the DNS tree.  Formal delegation process has not been
completed for this TLD.  In spite of this informal status, .local has
been used in many installations regardless of the awareness of the
users.  Usually, the local DNS servers are not authoritative to the
.local domain, they end up to send queries to the Root DNS Servers.

There are several other DNS zones which describe the "local"
information.  .localhost has been used to describe the localhost for
more than a couple of decades and virtually all of the DNS servers are
configured authoritative for .localhost and its reverse zone .127.in-

KATO                    Expires: August 24, 2003                [Page 1]


DRAFT                        DNS local zones               February 2003

addr.arpa.  However, there are other "local" zones currently used in the
Internet or Intranets connected to the Internet through NATs or similar
devices.

At a DNS server of an university in Japan, half of the DNS queries sent
to one of the 13 Root DNS Servers were regarding to the .local.  At
another DNS Server running in one of the Major ISPs in Japan, the 1/4
were .local.  If those "local" queries are able to direct other DNS
servers than Root, or they can be resolved locally, it contributes the
reduction of the Root DNS Servers.

2.  Rationale

Any DNS queries regarding to "local" names should not be sent to the DNS
servers on the Internet.

3.  Operational Guidelines

Those queries should be processed at the DNS servers internal to each
site so that the severs respond with NXDOMAIN rather than sending
queries to the DNS servers outside.

The "local" names have common DNS suffixes which are listed below:

3.1.  Local host related zones:

Following two zones are described in [Barr, 1996] and .localhost is also
defined in [Eastlake, 1999] .

     o .localhost
     o .127.in-addr.arpa

Following two zones are for the loopback address in IPv6 [Hinden, 1998]
.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
2001] , the old TLD .int has been used for this purpose for years
[Thomson, 1995] and many implementations still use .int.  So it is
suggested that both zones should be provided for each IPv6 reverse
lookup zone for a while.

     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa

3.2.  Locally created name space

While the use of .local has been proposed in several Internet-Drafts, it
has not been described in any Internet documents with formal status.
However, the amount of the queries for .local is much larger than
others, it is suggested to resolve the following zone locally:

KATO                    Expires: August 24, 2003                [Page 2]


DRAFT                        DNS local zones               February 2003

     o .local

3.3.  Private or site-local addresses

The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
local addresses [Hinden, 1998] should be resolved locally:

     o 10.in-addr.arpa
     o 16.172.in-addr.arpa
     o 17.172.in-addr.arpa
     o 18.172.in-addr.arpa
     o 19.172.in-addr.arpa
     o 20.172.in-addr.arpa
     o 21.172.in-addr.arpa
     o 22.172.in-addr.arpa
     o 23.172.in-addr.arpa
     o 24.172.in-addr.arpa
     o 25.172.in-addr.arpa
     o 26.172.in-addr.arpa
     o 27.172.in-addr.arpa
     o 28.172.in-addr.arpa
     o 29.172.in-addr.arpa
     o 30.172.in-addr.arpa
     o 31.172.in-addr.arpa
     o 168.192.in-addr.arpa
     o c.e.f.ip6.int
     o d.e.f.ip6.int
     o e.e.f.ip6.int
     o f.e.f.ip6.int
     o c.e.f.ip6.arpa
     o d.e.f.ip6.arpa
     o e.e.f.ip6.arpa
     o f.e.f.ip6.arpa

3.4.  Link-local addresses

The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
1998] should be resolved locally:

     o 254.169.in-addr.arpa
     o 8.e.f.ip6.int
     o 9.e.f.ip6.int
     o a.e.f.ip6.int
     o b.e.f.ip6.int
     o 8.e.f.ip6.arpa
     o 9.e.f.ip6.arpa
     o a.e.f.ip6.arpa
     o b.e.f.ip6.arpa

KATO                    Expires: August 24, 2003                [Page 3]


DRAFT                        DNS local zones               February 2003

4.  Suggestions to developers

4.1.  Suggestions to DNS software implementors

In order to avoid unnecessary traffic, it is suggested that DNS software
implementors provide configuration templates or default configurations
so that the names described in the previous section are resolved locally
rather than sent to other DNS servers in the Internet.

4.2.  Suggestions to developers of NATs or similar devices

There are many NAT or similar devices available in the market.
Regardless of the availability of DNS Servers in those devices, it is
suggested that those devices are able to filter the DNS traffic or
respond to the DNS traffic related to "local" zones by configuration
regardless of its ability of DNS service.  It is suggested that this
functionality is activated by default.

5.  IANA Consideration

While .local TLD has yet defined officially, there are substantial
queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
traffic sent to the Root DNS Servers are related to the .local zone.
Therefore, while it is not formally defined, it is suggested that IANA
delegates .local TLD to an organization.

The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
address and the link-local address.  It has several DNS server instances
around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
Project is one of the candidates to host the .local TLD.

Authors' addresses

     Akira Kato
     The University of Tokyo, Information Technology Center
     2-11-16 Yayoi Bunkyo
     Tokyo 113-8658, JAPAN
     Tel: +81 3-5841-2750
     Email: [email-masked]

     Paul Vixie
     Internet Software Consortium
     950 Charter Street
     Redwood City, CA 94063, USA
     Tel: +1 650-779-7001
     Email: [email-masked]

KATO                    Expires: August 24, 2003                [Page 4]


DRAFT                        DNS local zones               February 2003

References

To be filled

References

Barr, 1996.
D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
(February 1996).

Eastlake, 1999.
D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).

Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998).

Bush, 2001.
R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).

Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995).

Rekhter, 1996.
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
"Address Allocation for Private Internets" in RFC1918 (February 1996).

IANA, 2002.
IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).

Vixie, .
P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.

Hardie, 2002.
T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
Addresses" in RFC3258 (April 2002).

KATO                    Expires: August 24, 2003                [Page 5]

---

From: [email-masked]
Date: Tue, 11 Mar 2003 13:14:40 +0900

>delegates .local TLD to an organization.

	i guess it's "about 1/4 to 1/2", not 0.5%.

itojun
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Simon Coffey <[email-masked]>
Date: Tue, 11 Mar 2003 19:17:32 +0000

>San Francisco IETF meeting.

I was co-author of an I-D that proposed the reservation of a ".pri" TLD 
that would be the recommended TLD to use on "internal" networks.   We 
chose ".pri"(vate) as we felt is reflected the intended application more 
accurately than .local,  which was confusingly similar to .localhost.

I approached ICANN, whose opinion was that they would gladly reserve 
that TLD if instructed by the IETF/IANA.    However, the draft failed to 
progress - partly because ICANN hadn't reserved the TLD, and partly due 
to technical argument over whether non-registered domains should ever be 
encouraged. 

The authors continue to receive enquiries from folks designing an 
internal DNS namespace and wishing to use a "standard" TLD,  so I still 
believe there is a need for some standard TLD for use on "private" 
networks,   whether it be ".pri", ".local" or something else...

FYI:  
http://www.kblabs.com/lab/lib/drafts/draft-coffeystrain-privatednstld-00.txt.html

- Simon Coffey

---

From: Brad Knowles <[email-masked]>
Date: Wed, 12 Mar 2003 00:37:44 +0100

>  	i guess it's "about 1/4 to 1/2", not 0.5%.

	Considering that .local is used with Rendezvous, multicast DNS, 
etc..., this would probably be a good idea.  Or maybe a bad idea, if 
it causes things to break.  Dunno.  This needs more work.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 11 Mar 2003 20:00:09 -0500

At 06:37 PM 3/11/2003, Brad Knowles wrote:
> etc..., this would probably be a good idea.  Or maybe a bad idea, if it 
> causes things to break.  Dunno.  This needs more work.

How much damage would be caused by adding NS glue records to the root zone 
for .local pointing at 127.0.0.1? Sites which misconfigure and allow 
lookups for .local to leak out will be told to go ask themselves.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 12 Mar 2003 12:50:20 +1100

> local addresses [Hinden, 1998] should be resolved locally:

I support this style of solution.

I think this document is a much better operational guideline than
"don't publish private addresses in the DNS", which has generally
been ignored.

Rather than say: "should be resolved locally", I would prefer to
say that anyone may set up a DNS server to be authoritative for
these zones.  That means that ISP DNS resolvers are licensed to
become authoritative and squash requests to these zones.

A number of people appear to have written drafts along these lines.
Mine (Jul 2002) is: draft-williams-dnsext-private-namespace-01.txt
Feel free to swipe any text you like the look of.

- aidan

---

From: Brad Knowles <[email-masked]>
Date: Wed, 12 Mar 2003 02:59:34 +0100

At 8:00 PM -0500 2003/03/11, Daniel Senie wrote:

>  How much damage would be caused by adding NS glue records to the
>  root zone for .local pointing at 127.0.0.1? Sites which misconfigure
>  and allow lookups for .local to leak out will be told to go ask
>  themselves.

	When using Rendezvous, not all machines have local nameservers. 
You'd need to find the right multicast group and use that in the glue 
for .local at the roots.

	That's assuming that the multicast group in question is at a 
fixed address in the standard and doesn't change.  ;-(

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 12 Mar 2003 00:39:45 -0600

>                   draft-kato-dnsop-local-zones-00.txt

This draft is admirable for its objective, but is missing the single
largest piece of good advice, which is to use real friggin domain names
from delegated space instead of making up your own. Could that be added?
Something to the affect of ~"if you want a locally resolvable, private
domain, use local.<company>.<your-isp> so that leakage is limited, but so
that the namespace authority model continues to function."

For those who would argue in favor of a reusable private-space TLD, I will
reiterate the point that this kind of approach simply reintroduces the
same kinds of problems we already have with NAT (leakage, collisions when
merging networks, etc.). It was a bad idea for the IP crunch, it's a bad
idea for DNS for almost the exact same reasons, but with the key
difference that there is no shortage of domain names.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Simon Coffey <[email-masked]>
Date: Wed, 12 Mar 2003 09:34:33 +0000

>that the namespace authority model continues to function."

I would accept that delegating from a registered domain is a purer 
solution and yes that should be mentioned in any draft on the subject 
(although I figure you would rather not see any draft at all).   I still 
believe that folks will want to use an alternative,  if only because 
"intranet.acme.pri" is shorter and easier to manage than 
"intranet.local.acme.co.uk". 

Simon

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Mar 2003 18:32:00 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:

    Daniel> How much damage would be caused by adding NS glue records to the
    Daniel> root zone  
    Daniel> for .local pointing at 127.0.0.1? Sites which misconfigure and
    Daniel> allow  
    Daniel> lookups for .local to leak out will be told to go ask themselves. 

  A very good idea.

  It might be funny if it confused some "personal firewall".

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Mar 2003 16:43:04 -0800

>                   draft-kato-dnsop-local-zones-00.txt

A very good draft.

>queries to the DNS servers outside.

Name servers offering recursive service ought to serve the zones 
listed herein.  When I have been giving DNS tutorials, I use the 
example of having a root hints file, a (master) localhost file and a 
(master) 0.0.127.in-addr.arpa file.  I should expand the material on 
recursive servers to suggest being authoritative for all the listed 
zones.

For authoritative only servers, perhaps this is not as important, but 
should be a suggestion.  For recursive servers, this is a significant 
suggestion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Kenneth Porter <[email-masked]>
Date: Tue, 18 Mar 2003 17:31:40 -0800

--On Sunday, March 16, 2003 4:43 PM -0800 Edward Lewis <[email-masked]> 
wrote:

> Name servers offering recursive service ought to serve the zones listed
> herein.

That's an interesting idea. How might this be automated? While BIND 
supports dynamic updates within a zone, it doesn't support dynamic creation 
and destruction of entire zones. One would have to restart a server with a 
new named.conf when a new bogon list was issued.

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 Mar 2003 18:30:16 -0800

>>>>> "Kenneth" == Kenneth Porter <[email-masked]> writes:

    Kenneth> While BIND supports dynamic updates within a zone, it
    Kenneth> doesn't support dynamic creation and destruction of
    Kenneth> entire zones. One would have to restart a server with a
    Kenneth> new named.conf when a new bogon list was issued.

Nope. A reconfig will do just fine for all reasonably up to date
versions of BIND. There's no need to restart the server. [That should
only be needed whenever the software is replaced.] Even if there was a
need for BIND to restart, there are other DNS implementations. Although
it's common to confuse the DNS protocol with "what BIND does", this is
a mistake. DNS protocol design shouldn't be predicated on what BIND
can and can't do. However this may be a factor for aspects of a new
protocol like its interoperability considerations.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 19 Mar 2003 04:09:06 +0100

At 5:31 PM -0800 2003/03/18, Kenneth Porter wrote:

>  supports dynamic updates within a zone, it doesn't support dynamic
>  creation and destruction of entire zones. One would have to restart
>  a server with a new named.conf when a new bogon list was issued.

	The bind-dlz project has proven that this is not true.  With the 
current version of BIND, you would need no more than a reload.  If we 
can update the DNSUPDATE protocol to include the creation of entirely 
new zones, we can avoid this problem, too.

---

From: Kevin C Miller <[email-masked]>
Date: Tue, 18 Mar 2003 19:36:45 -0800

I support the idea of recursive server implementations providing automatic 
means of trapping .local and other zones.

However I'd like two modes to be considered: trapping the zone on the 
server, but also forwarding queries for these zones to specific other 
servers. This provides the ability to create consistent views of 
.local/other space in a specific organization.

For reference, here's the page where we tell people on our campus what to 
do, so that we have a consistent .local view:
http://www.net.cmu.edu/docs/services/ip/local-dns.html

-Kevin

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 19 Mar 2003 12:03:31 +0100 (CET)

On Tue, 18 Mar 2003, Kenneth Porter wrote:

> That's an interesting idea. How might this be automated?

I'm not sure that the automated creation of new zones is quite what you'd
want for a list of 'local' zones.  It'd be more like the standard root
'hints' file (with the same issues regarding propagation delays due to it
being encoded in software releases etc).

I think most nameserver software just requires a reload to be issued for
them to notice additions/removals of zones in their configuration files,
and for preference, a reload on just the new zone.

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B             Operations/Security

---

From: Kenneth Porter <[email-masked]>
Date: Fri, 21 Mar 2003 09:15:33 -0800

> being encoded in software releases etc).

I was thinking of automating the bogon stuff. Something that would receive 
the bogon list through one of the automated delivery systems and feed it to 
one's DNS, possibly filtered for bogons one uses locally.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Kenneth Porter <[email-masked]>
Date: Fri, 21 Mar 2003 09:19:35 -0800

--On Tuesday, March 18, 2003 06:30:16 PM -0800 Jim Reid 
<[email-masked]> wrote:

> can and can't do.

Sorry, I didn't mean to suggest that. It's just that BIND is so ubiquitous 
(it comes with the major Linux distros) that implementing automatic bogon 
trapping with it seems like a natural objective.

(DNS protocol might be better described as "what dig does". ;) )
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.