⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc921.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 2 页
字号:


Network Working Group                                         Jon Postel
Request for Comments: 921                                            ISI
                                                            October 1984
Updates:  RFC 897, RFC 881

          Domain Name System Implementation Schedule - Revised


Status of this Memo

   This memo is a policy statement on the implementation of the Domain
   Style Naming System in the Internet.  This memo is an update of
   RFC-881, and RFC-897.  This is an official policy statement of the
   IAB and the DARPA.  Distribution of this memo is unlimited.

   The intent of this memo is to detail the schedule for the
   implementation for the Domain Style Naming System.  The explanation
   of how this system works is to be found in the references.

The Current Situation

   There are three aspects to the domain style naming system, (1) the
   names themselves, (2) the method of translating names to addresses,
   and (3) the relationship between the Internet and the rest of the
   world.

   Names

      The names are being changed from simple names, or globally unique
      strings, to structured names, where each component name is unique
      only with respect to the superior component name.

      Simple Names

         Until recently, hosts in the DARPA research and DDN operational
         communities were assigned names in a flat or global name space
         of character strings.  There are some limits on these names.
         They must start with a letter, end with a letter or digit and
         have only letters or digits or hyphen as interior characters.
         Case is not significant.

            For example:  USC-ISIF

      Hierarchical Names

         Because of the growth of the Internet, structured names (or
         domain style names) have been introduced.  Each element of the
         structured name will be a character string (with the same
         constraints that previously applied to the simple names).  The




Postel                                                          [Page 1]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


         elements (or components) of the structured names are separated
         with periods, and the elements are written from the most
         specific on the left to the most general on the right.

            For example:  USC-ISIF.ARPA

      The Initial and Temporary Domain

         The introduction of these hierarchical names has been very
         limited.  Every current name in this new system has the form
         "old-simple-name.ARPA".  That is, the all the hosts are in a
         domain called "ARPA".  This is a temporary situation.  The
         current intention is for the ARPA domain to cease to exist.
         This means that all hosts will change their names as the domain
         style names come into full use.

   Name to Address Lookup

      Every host in the Internet is expected to have a way of
      translating the name of any other host into its Internet address.

      By and large, the name to address translation is done by looking
      up the information in a table of all hosts.

      The maintenance of this table is centralized at the Network
      Information Center (NIC).  Each host is expected to obtain a
      current copy of the table on a timely basis.  This table is called
      "HOSTS.TXT" [8] and is normally accessed via the Hostnames
      Server [9].

   Interface to the World

      A great deal of mail moves between the Internet and other
      "systems" that somehow transport mail among computers.  This is
      currently done by hiding some sort of "other-system" addressing
      information in the local-part of the mail address and using a
      mail-relay host in the host-part of the mailbox.

      For example,

         OBERST%EDUCOM.MAILNET@MIT-MULTICS.ARPA
         EDMISTON.CIC@CSNET-RELAY.ARPA







Postel                                                          [Page 2]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


The Future Situation

   Names

      Hierarchical Names

         The use of the hierarchical names will be greatly expanded
         according to the rules established in the "Domain Requirements"
         memo (RFC-920) [5].

            For example:  F.ISI.USC.EDU

      There are several levels of development for use of the domain
      style names.

      First, there is the current simple substitution of the domain
      style names for the old style host names.  At this stage all
      domain style names directly translate to host addresses (using the
      NIC tables) and all domain style names have two components.  The
      mail system uses addresses of the form "local-part@host", where
      host is a domain style host name.

         For example:  USC-ISIF.ARPA  and  Postel@USC-ISIF.ARPA

         Here we expect that "USC-ISIF.ARPA" is the name of an Internet
         host and that we can send mail for "Postel" to the SMTP port on
         that host.  It may be that some backward host can still fake it
         by ignoring the ".ARPA" and looking up an address for
         "USC-ISIF" in some old style file.

      Second, there is an extension to more name components and more top
      level domains.  The mail system still uses addresses of the form
      "local-part@host", where host is a domain style host name.

         For example:  F.ISI.USC.EDU  and  Postel@F.ISI.USC.EDU

         Here we expect that "F.ISI.USC.EDU" is the name of an Internet
         host and that we can send mail for "Postel" to the SMTP port on
         that host.  It is likely that the NIC will enter these new
         domain style names in the centrally maintained table (i.e.,
         HOSTS.TXT) during the transition period.  It is unlikely that a
         backward host can hack this at all.

      Third, there is an extension to domain style names that may
      represent only organizations or administrative entities.  Finding
      a host that acts for such entities may require a level of



Postel                                                          [Page 3]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


      indirection in the search.  The mail system may use
      "local-part@domain-name", where the "domain-name" identifies a
      host (as before) or an organization.

         For example:  USC-ISI.EDU  and  Postel@USC-ISI.EDU

         Here we don't count on "USC-ISI. EDU" being the name of an
         Internet host.  When we want to send mail to "Postel" we ask
         the domain name server about sending mail to "USC-ISI.EDU".
         The server will tell us the name (and address) of a real
         Internet host that handles mail on this organizations behalf,
         for example, "F.ISI.USC.EDU = 10.2.0.52".  We then send mail
         for "Postel@USC-ISI.EDU" to the SMTP port on F.ISI.USC.EDU.

   Name to Address Lookup

      Every host in the Internet will be expected to have a way of
      translating the name of any other host into its Internet address.

      By and large, the name to address translation will be done by
      interacting with a lookup server.  There will be a number of
      servers that each hold a portion of the name to address
      information.

      The maintenance of the translation data base will be subdivided
      and distributed.

      The design and implementation details for this service are given
      in RFC-882 [2] and RFC-883 [3].

   Interface to the World

      Mail will continue to move between the Internet and other
      "systems".  This may be done by designating some sort of
      "other-system" representative organization in the domain server
      data bases that can indirect mail to a mail-relay host.

      For example,

         Oberst@EDUCOM.MAILNET

         When we want to send mail to "Oberst" we ask the domain name
         server about sending mail to "EDUCOM.MAILNET".  The server will
         tell us the name (and address) of a real Internet host that
         handles mail on this organizations behalf, for example,
         "MIT-MULTICS.ARPA = 10.0.0.6".  We then send mail for
         "Oberst@EDUCOM.MAILNET" to the SMTP port on MIT-MULTICS.ARPA.


Postel                                                          [Page 4]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


      For example,

         Edmiston@CIC.CSNET

         When we want to send mail to "Edmiston" we ask the domain name
         server about sending mail to "CIC.CSNET".  The server will tell
         us the name (and address) of a real Internet host that handles
         mail on this organizations behalf, for example,
         "CSNET-RELAY.ARPA = 10.4.0.5".  We then send mail for
         "Edmiston@CIC.CSNET" to the SMTP port on CSNET-RELAY.ARPA.

The Transition Situation

   Actually, the situation is a bit more complicated, of course.  Hosts
   are already using domain style names under the constraint that their
   domain style name is exactly their old style name with the string
   ".ARPA" appended.  The first transition step is to ensure that all
   hosts do this, and then to eliminate the use of old style names
   altogether.

   Please note carefully that two types of changes are being made:

      One is a change in the support mechanism for translating a host
      name to an internet address,

         that is from using local copies of a full centrally maintained
         table to dynamically accessing a distributed set of servers
         each posesing a portion of a data base maintained in a
         distributed fashion.

      The other is a change in the host names themselves,

         from a flat global space of unstructured strings to a
         hierarchical structure of names.

   There are two steps to the transition plan.

      First, change from old names to domain style names.

      Second, change from using central tables to using name servers.

   There are two communities that are taking slightly different courses
   in this transition.  The DARPA research community is making the full
   transition.  The DDN operational community is making the change in
   naming on the same schedule, but is not requiring hosts in the DDN
   operational community make the change to using servers at the same



Postel                                                          [Page 5]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


   time (they can if they want to).  The DDN PMO will establish a
   schedule for that change at a later time.  The NIC will maintain a
   central table of all DDN operational hosts.

   Interface to the World

      The interchange of mail with "other-systems" will have to continue
      pretty much as it has (except that RELAY-HOST is RELAY-HOST.ARPA)
      until organization names can be used.  Then representative
      organizations can be designated for each "other-system" in the
      domain server data bases that will then specify a mail-relay host.

All Hosts Change Names

   The impact of introducing the domain style names is that all hosts
   change their names at least once.  Hosts that move to new domains or
   subdomains may change their names several times.

   Hosts have an official (or primary) name and possibly several
   nicknames.  When mail is sent from a host, the official name is used
   in the mail header address fields.

   Suppose, that in the old days before domains were thought of, a host
   changed its name.  What is the impact on users of changing the name
   of a host?

      Mail that was sent before the name was changed can not be answered
      using mail program commands that automatically fill in the return
      address.  While it may be possible to use special tricks to fix up
      the "From" or the "To" users addresses, the "Cc" addresses are
      very difficult to correct.

         Suppose one host changed its name from FOO to BAR.  Mail that
         was sent from FRED@FOO to JOE@ABC can not be answered unless
         the change of name is known to the user or the mail program at
         ABC and the host name BAR substituted for FOO.  Mail that is
         sent to JOE@ABC from SAM@DEF with a cc to FRED@FOO can not be
         answered easily.

      Any mailing lists that have mailboxes with the host that changed
      names will now have incorrect entries.

   The point is that while the host that changed names may be able to
   use special tricks for a while to fix things up for the users, it is
   difficult for other hosts to do this.




Postel                                                          [Page 6]



RFC 921                                                     October 1984
Domain Implementation Schedule - Revised


   A general trick is to make the old name a nickname for the host for
   some period of time.

   The introduction of domain style names means that all hosts change
   their names essentially at the same time.

   To lessen the havoc, there will be a period of time when both the old
   and the new names are allowed.  That is, the old names will be
   nicknames for a while.

Primary Names

   Currently, host have an official or primary names and may have
   several nicknames.  For example,

      Primary Name             Nicknames

      USC-ISIF.ARPA            USC-ISIF ISIF

      ADA-VAX.ARPA             ADA-VAX ISI-VAXB  AJPO  VAXB

   The data base is such than given any of the names for a host one can
   find the address, and given the address one can find the primary

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -