Root Servers

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Any comments?

						Masataka Ohta
---






INTERNET DRAFT                                                   M. Ohta
draft-ohta-root-servers-00.txt             Tokyo Institute of Technology
                                                                May 1999

Root Name Servers Sharing Administratively Scoped Shared Unicast Addresses

Status of this Memo

   (standard disclaimer)

Abstract

   This memo describes an operational guideline for root name servers to
   share unicast addresses.

1. Motivation

   For the stability of the Internet, it is critical that there are
   sufficiently many DNS root servers operating at various places of the
   Internet.

   For the stability of the domestic Internet, it is critical for each
   country that there are sufficiently many DNS root servers operating
   at various places of the Internet in the country.

   However, the number of unicast IP addresses of root servers is
   limited.  Thus, with the legacy operation of DNS, the number of root
   servers in each country (including US) must be equal to the number of
   unicast IP addresses of root servers divided by the number of
   countries (some weight may be given according to the number of
   Internet hosts in each country).

   Given the current number of countries and IP addresses of root
   servers, each country (again, including US) will be able to have 1/20
   root servers, which definitely is not sufficiently many.

   Thus, it is necessary to increase the number of root servers by
   administratively scoping the routing range of unicast addresses of
   root servers.

   With administratively scoped unicast addresses, any entity, including
   a country, can use the addresses for its local root servers and set
   the scope of the routing range of the addresses appropriately.

   Note that operations similar to that described in this memo is
   possible today locally without global coordination by any operator
   who may be irritated by the lack of his control on (sufficiently
   many) root servers, which may be a source of some operational



M. Ohta                 Expires on Nov 19, 1999                 [Page 1]

INTERNET DRAFT             Root Name Servers                    May 1999


   problems. This memo is an attempt to document the way to solve the
   problem in a least harmful manner.

   Similar operation described in this memo may be applicable to gTLD
   servers but it is outside the scope of this memo.

2. Suggested Operation

   As is demonstrated by the proliferated private use addresses, it is
   easy to set up routers to let unicast addresses have local scopes. It
   is also easy to let the unicast addresses have nested local scopes.

   A possible problem of such addresses is that the shared addresses can
   not be used for global communication. So, it is proposed that the
   root name servers with the administratively scoped shared unicast
   addresses should have additional globally unique unicast addresses,
   which may be used for global communication such as zone transfer.

   The other possible problem of such addresses is that the shared
   addresses is not managed by a single entity that the mapping from the
   address to some operational entity is impossible. However, if the
   entities adjacent to the root server has a global addresses, it is
   possible to map from the global address to an operational entity.

   To be compatible with the current practice that a single address
   belong to a single AS, each administratively scoped shared unicast
   address is assigned its own AS number. There will be multiple ASes of
   the AS number containing the same address ranges.

   ASes, still, can be identified by adjacent ASes.  For example,
   network operators may choose their favorite root server based on the
   AS numbers of the next hop ASes with, for example, AS path and BGP
   policy.

   It is required that operators of an AS adjacent to the root servers'
   AS be fully responsible to the operation of the root servers.  If a
   root server's AS is adjacent to multiple ASes, operators of all the
   ASes must be fully responsible to the operation of the root server.
   When there is a routing problem of a root server, contact the next
   hop AS.

3. Assignment

   Considering that each country is likely to need a considerable number
   of root servers, it is reasonable to make most, if not all, of the IP
   addresses of the root servers administratively scoped and shared.

   Considering the huge effort to change the file containing the IP



M. Ohta                 Expires on Nov 19, 1999                 [Page 2]

INTERNET DRAFT             Root Name Servers                    May 1999


   addresses of the root servers all around the Internet, the IP
   addresses of the root servers should better be same as that of today.
   Organizations running the current root servers are requested to
   release the current class B or C address blocks containing the
   current IP addresses of the root server for the public use.

   The AS numbers assigned to root server addresses are:

      <to be assigned by IANA>

4. Security Considerations

   This memo describes just an operational guideline with no protocol
   change. As such, the guideline does not introduce any security issues
   of the protocol level.

   As the route forgery to the root servers can be implemented today
   without this memo by anyone including local intruders, the guideline
   does not not introduce any security issues of the operational level,
   either.

   A guideline to track down and verify valid or forged AS route to the
   root servers is described in section 2.

5. Author's Address

   Masataka Ohta
   Computer Center
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo 152-8550, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415
   EMail: mohta@necom830.hpcl.titech.ac.jp
















M. Ohta                 Expires on Nov 19, 1999                 [Page 3]