Return to rfc920.lpr CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc

Annotation of 43BSDReno/usr.sbin/named/doc/rfc920.lpr, revision 1.1

1.1     ! root        1: 
        !             2: 
        !             3: Network Working Group                                          J. Postel
        !             4: Request for Comments: 920                                    J. Reynolds
        !             5:                                                                      ISI
        !             6:                                                             October 1984
        !             7: 
        !             8:                           Domain Requirements
        !             9: 
        !            10: 
        !            11: Status of this Memo
        !            12: 
        !            13:    This memo is a policy statement on the requirements of establishing a
        !            14:    new domain in the ARPA-Internet and the DARPA research community.
        !            15:    This is an official policy statement of the IAB and the DARPA.
        !            16:    Distribution of this memo is unlimited.
        !            17: 
        !            18: Introduction
        !            19: 
        !            20:    This memo restates and refines the requirements on establishing a
        !            21:    Domain first described in RFC-881 [1].  It adds considerable detail
        !            22:    to that discussion, and introduces the limited set of top level
        !            23:    domains.
        !            24: 
        !            25: The Purpose of Domains
        !            26: 
        !            27:    Domains are administrative entities.  The purpose and expected use of
        !            28:    domains is to divide the name management required of a central
        !            29:    administration and assign it to sub-administrations.  There are no
        !            30:    geographical, topological, or technological constraints on a domain.
        !            31:    The hosts in a domain need not have common hardware or software, nor
        !            32:    even common protocols.  Most of the requirements and limitations on
        !            33:    domains are designed to ensure responsible administration.
        !            34: 
        !            35:    The domain system is a tree-structured global name space that has a
        !            36:    few top level domains.  The top level domains are subdivided into
        !            37:    second level domains.  The second level domains may be subdivided
        !            38:    into third level domains, and so on.
        !            39: 
        !            40:    The administration of a domain requires controlling the assignment of
        !            41:    names within that domain and providing access to the names and name
        !            42:    related information (such as addresses) to users both inside and
        !            43:    outside the domain.
        !            44: 
        !            45: 
        !            46: 
        !            47: 
        !            48: 
        !            49: 
        !            50: 
        !            51: 
        !            52: 
        !            53: 
        !            54: 
        !            55: 
        !            56: Postel & Reynolds                                               [Page 1]
        !            57: 
        !            58: 
        !            59: 
        !            60: RFC 920                                                     October 1984
        !            61: Domain Requirements
        !            62: 
        !            63: 
        !            64: General Purpose Domains
        !            65: 
        !            66:    While the initial domain name "ARPA" arises from the history of the
        !            67:    development of this system and environment, in the future most of the
        !            68:    top level names will be very general categories like "government",
        !            69:    "education", or "commercial".  The motivation is to provide an
        !            70:    organization name that is free of undesirable semantics.
        !            71: 
        !            72:    After a short period of initial experimentation, all current
        !            73:    ARPA-Internet hosts will select some domain other than ARPA for their
        !            74:    future use.  The use of ARPA as a top level domain will eventually
        !            75:    cease.
        !            76: 
        !            77: Initial Set of Top Level Domains
        !            78: 
        !            79:    The initial top level domain names are:
        !            80: 
        !            81:       Temporary
        !            82: 
        !            83:          ARPA  =  The current ARPA-Internet hosts.
        !            84: 
        !            85:       Categories
        !            86: 
        !            87:          GOV  =  Government, any government related domains meeting the
        !            88:                  second level requirements.
        !            89: 
        !            90:          EDU  =  Education, any education related domains meeting the
        !            91:                  second level requirements.
        !            92: 
        !            93:          COM  =  Commercial, any commercial related domains meeting the
        !            94:                  second level requirements.
        !            95: 
        !            96:          MIL  =  Military, any military related domains meeting the
        !            97:                  second level requirements.
        !            98: 
        !            99:          ORG  =  Organization, any other domains meeting the second
        !           100:                  level requirements.
        !           101: 
        !           102:       Countries
        !           103: 
        !           104:          The English two letter code (alpha-2) identifying a country
        !           105:          according the the ISO Standard for "Codes for the
        !           106:          Representation of Names of Countries" [5].
        !           107: 
        !           108: 
        !           109: 
        !           110: 
        !           111: 
        !           112: 
        !           113: Postel & Reynolds                                               [Page 2]
        !           114: 
        !           115: 
        !           116: 
        !           117: RFC 920                                                     October 1984
        !           118: Domain Requirements
        !           119: 
        !           120: 
        !           121:       Multiorganizations
        !           122: 
        !           123:          A multiorganization may be a top level domain if it is large,
        !           124:          and is composed of other organizations; particularly if the
        !           125:          multiorganization can not be easily classified into one of the
        !           126:          categories and is international in scope.
        !           127: 
        !           128: Possible Examples of Domains
        !           129: 
        !           130:    The following examples are fictions of the authors' creation, any
        !           131:    similarity to the real world is coincidental.
        !           132: 
        !           133:    The UC Domain
        !           134: 
        !           135:       It might be that a large state wide university with, say, nine
        !           136:       campuses and several laboratories may want to form a domain.  Each
        !           137:       campus or major off-campus laboratory might then be a subdomain,
        !           138:       and within each subdomain, each department could be further
        !           139:       distinguished.  This university might be a second level domain in
        !           140:       the education category.
        !           141: 
        !           142:       One might see domain style names for hosts in this domain like
        !           143:       these:
        !           144: 
        !           145:          LOCUS.CS.LA.UC.EDU
        !           146:          CCN.OAC.LA.UC.EDU
        !           147:          ERNIE.CS.CAL.UC.EDU
        !           148:          A.S1.LLNL.UC.EDU
        !           149:          A.LAND.LANL.UC.EDU
        !           150:          NMM.LBL.CAL.UC.EDU
        !           151: 
        !           152:    The MIT Domain
        !           153: 
        !           154:       Another large university may have many hosts using a variety of
        !           155:       machine types, some even using several families of protocols.
        !           156:       However, the administrators at this university may see no need for
        !           157:       the outside world to be aware of these internal differences.  This
        !           158:       university might be a second level domain in the education
        !           159:       category.
        !           160: 
        !           161:       One might see domain style names for hosts in this domain like
        !           162:       these:
        !           163: 
        !           164:          APIARY-1.MIT.EDU
        !           165:          BABY-BLUE.MIT.EDU
        !           166:          CEZANNE.MIT.EDU
        !           167:          DASH.MIT.EDU
        !           168: 
        !           169: 
        !           170: Postel & Reynolds                                               [Page 3]
        !           171: 
        !           172: 
        !           173: 
        !           174: RFC 920                                                     October 1984
        !           175: Domain Requirements
        !           176: 
        !           177: 
        !           178:          MULTICS.MIT.EDU
        !           179:          TAC.MIT.EDU
        !           180:          XX.MIT.EDU
        !           181: 
        !           182:    The CSNET Domain
        !           183: 
        !           184:       There may be a consortium of universities and industry research
        !           185:       laboratories called, say, "CSNET".  This CSNET is not a network
        !           186:       per se, but rather a computer mail exchange using a variety of
        !           187:       protocols and network systems.  Therefore, CSNET is not a network
        !           188:       in the sense of the ARPANET, or an Ethernet, or even the
        !           189:       ARPA-Internet, but rather a community.  Yet it does, in fact, have
        !           190:       the key property needed to form a domain; it has a responsible
        !           191:       administration.  This consortium might be large enough and might
        !           192:       have membership that cuts across the categories in such a way that
        !           193:       it qualifies under the "multiorganization rule" to be a top level
        !           194:       domain.
        !           195: 
        !           196:       One might see domain style names for hosts in this domain like
        !           197:       these:
        !           198: 
        !           199:          CIC.CSNET
        !           200:          EMORY.CSNET
        !           201:          GATECH.CSNET
        !           202:          HP-LABS.CSNET
        !           203:          SJ.IBM.CSNET
        !           204:          UDEL.CSNET
        !           205:          UWISC.CSNET
        !           206: 
        !           207: General Requirements on a Domain
        !           208: 
        !           209:    There are several requirements that must be met to establish a
        !           210:    domain.  In general, it must be responsibly managed.  There must be a
        !           211:    responsible person to serve as an authoritative coordinator for
        !           212:    domain related questions.  There must be a robust domain name lookup
        !           213:    service, it must be of at least a minimum size, and the domain must
        !           214:    be registered with the central domain administrator (the Network
        !           215:    Information Center (NIC) Domain Registrar).
        !           216: 
        !           217:    Responsible Person:
        !           218: 
        !           219:       An individual must be identified who has authority for the
        !           220:       administration of the names within the domain, and who seriously
        !           221:       takes on the responsibility for the behavior of the hosts in the
        !           222:       domain, plus their interactions with hosts outside the domain.
        !           223:       This person must have some technical expertise and the authority
        !           224:       within the domain to see that problems are fixed.
        !           225: 
        !           226: 
        !           227: Postel & Reynolds                                               [Page 4]
        !           228: 
        !           229: 
        !           230: 
        !           231: RFC 920                                                     October 1984
        !           232: Domain Requirements
        !           233: 
        !           234: 
        !           235:       If a host in a given domain somehow misbehaves in its interactions
        !           236:       with hosts outside the domain (e.g., consistently violates
        !           237:       protocols), the responsible person for the domain must be
        !           238:       competent and available to receive reports of problems, take
        !           239:       action on the reported problems, and follow through to eliminate
        !           240:       the problems.
        !           241: 
        !           242:    Domain Servers:
        !           243: 
        !           244:       A robust and reliable domain server must be provided.  One way of
        !           245:       meeting this requirement is to provide at least two independent
        !           246:       domain servers for the domain.  The database can, of course, be
        !           247:       the same.  The database can be prepared and copied to each domain
        !           248:       server.  But, the servers should be in separate machines on
        !           249:       independent power supplies, et cetera; basically as physically
        !           250:       independent as can be.  They should have no common point of
        !           251:       failure.
        !           252: 
        !           253:       Some domains may find that providing a robust domain service can
        !           254:       most easily be done by cooperating with another domain where each
        !           255:       domain provides an additional server for the other.
        !           256: 
        !           257:       In other situations, it may be desirable for a domain to arrange
        !           258:       for domain service to be provided by a third party, perhaps on
        !           259:       hosts located outside the domain.
        !           260: 
        !           261:       One of the difficult problems in operating a domain server is the
        !           262:       acquisition and maintenance of the data.  In this case, the data
        !           263:       are the host names and addresses.  In some environments this
        !           264:       information changes fairly rapidly and keeping up-to-date data may
        !           265:       be difficult.  This is one motivation for sub-domains.  One may
        !           266:       wish to create sub-domains until the rate of change of the data in
        !           267:       a sub-domain domain server database is easily managed.
        !           268: 
        !           269:       In the technical language of the domain server implementation the
        !           270:       data is divided into zones.  Domains and zones are not necessarily
        !           271:       one-to-one.  It may be reasonable for two or more domains to
        !           272:       combine their data in a single zone.
        !           273: 
        !           274:       The responsible person or an identified technical assistant must
        !           275:       understand in detail the procedures for operating a domain server,
        !           276:       including the management of master files and zones.
        !           277: 
        !           278:       The operation of a domain server should not be taken on lightly.
        !           279:       There are some difficult problems in providing an adequate
        !           280:       service, primarily the problems in keeping the database up to
        !           281:       date, and keeping the service operating.
        !           282: 
        !           283: 
        !           284: Postel & Reynolds                                               [Page 5]
        !           285: 
        !           286: 
        !           287: 
        !           288: RFC 920                                                     October 1984
        !           289: Domain Requirements
        !           290: 
        !           291: 
        !           292:       The concepts and implementation details of the domain server are
        !           293:       given in RFC-882 [2] and RFC-883 [3].
        !           294: 
        !           295:    Minimum Size:
        !           296: 
        !           297:       The domain must be of at least a minimum size.  There is no
        !           298:       requirement to form a domain because some set of hosts is above
        !           299:       the minimum size.
        !           300: 
        !           301:       Top level domains must be specially authorized.  In general, they
        !           302:       will only be authorized for domains expected to have over 500
        !           303:       hosts.
        !           304: 
        !           305:       The general guideline for a second level domain is that it have
        !           306:       over 50 hosts.  This is a very soft "requirement".  It makes sense
        !           307:       that any major organization, such as a university or corporation,
        !           308:       be allowed as a second level domain -- even if it has just a few
        !           309:       hosts.
        !           310: 
        !           311:    Registration:
        !           312: 
        !           313:       Top level domains must be specially authorized and registered with
        !           314:       the NIC domain registrar.
        !           315: 
        !           316:       The administrator of a level N domain must register with the
        !           317:       registrar (or responsible person) of the level N-1 domain.  This
        !           318:       upper level authority must be satisfied that the requirements are
        !           319:       met before authorization for the domain is granted.
        !           320: 
        !           321:       The registration procedure involves answering specific questions
        !           322:       about the prospective domain.  A prototype of what the NIC Domain
        !           323:       Registrar may ask for the registration of a second level domain is
        !           324:       shown below.  These questions may change from time to time.  It is
        !           325:       the responsibility of domain administrators to keep this
        !           326:       information current.
        !           327: 
        !           328:       The administrator of a domain is required to make sure that host
        !           329:       and sub-domain names within that jurisdiction conform to the
        !           330:       standard name conventions and are unique within that domain.
        !           331: 
        !           332:       If sub-domains are set up, the administrator may wish to pass
        !           333:       along some of his authority and responsibility to a sub-domain
        !           334:       administrator.  Even if sub-domains are established, the
        !           335:       responsible person for the top-level domain is ultimately
        !           336:       responsible for the whole tree of sub-domains and hosts.
        !           337: 
        !           338:       This does not mean that a domain administrator has to know the
        !           339: 
        !           340: 
        !           341: Postel & Reynolds                                               [Page 6]
        !           342: 
        !           343: 
        !           344: 
        !           345: RFC 920                                                     October 1984
        !           346: Domain Requirements
        !           347: 
        !           348: 
        !           349:       details of all the sub-domains and hosts to the Nth degree, but
        !           350:       simply that if a problem occurs he can get it fixed by calling on
        !           351:       the administrator of the sub-domain containing the problem.
        !           352: 
        !           353: Top Level Domain Requirements
        !           354: 
        !           355:    There are very few top level domains, each of these may have many
        !           356:    second level domains.
        !           357: 
        !           358:    An initial set of top level names has been identified.  Each of these
        !           359:    has an administrator and an agent.
        !           360: 
        !           361:    The top level domains:
        !           362: 
        !           363:       ARPA =  The ARPA-Internet   *** TEMPORARY ***
        !           364: 
        !           365:          Administrator:  DARPA
        !           366:          Agent:          The Network Information Center
        !           367:          Mailbox:        [email protected]
        !           368: 
        !           369:       GOV  =  Government
        !           370: 
        !           371:          Administrator:  DARPA
        !           372:          Agent:          The Network Information Center
        !           373:          Mailbox:        [email protected]
        !           374: 
        !           375:       EDU  =  Education
        !           376: 
        !           377:          Administrator:  DARPA
        !           378:          Agent:          The Network Information Center
        !           379:          Mailbox:        [email protected]
        !           380: 
        !           381:       COM  =  Commercial
        !           382: 
        !           383:          Administrator:  DARPA
        !           384:          Agent:          The Network Information Center
        !           385:          Mailbox:        [email protected]
        !           386: 
        !           387:       MIL  =  Military
        !           388: 
        !           389:          Administrator:  DDN-PMO
        !           390:          Agent:          The Network Information Center
        !           391:          Mailbox:        [email protected]
        !           392: 
        !           393: 
        !           394: 
        !           395: 
        !           396: 
        !           397: 
        !           398: Postel & Reynolds                                               [Page 7]
        !           399: 
        !           400: 
        !           401: 
        !           402: RFC 920                                                     October 1984
        !           403: Domain Requirements
        !           404: 
        !           405: 
        !           406:       ORG  =  Organization
        !           407: 
        !           408:          Administrator:  DARPA
        !           409:          Agent:          The Network Information Center
        !           410:          Mailbox:        [email protected]
        !           411: 
        !           412:       Countries
        !           413: 
        !           414:          The English two letter code (alpha-2) identifying a country
        !           415:          according the the ISO Standard for "Codes for the
        !           416:          Representation of Names of Countries" [5].
        !           417: 
        !           418:          As yet no country domains have been established.  As they are
        !           419:          established information about the administrators and agents
        !           420:          will be made public, and will be listed in subsequent editions
        !           421:          of this memo.
        !           422: 
        !           423:       Multiorganizations
        !           424: 
        !           425:          A multiorganization may be a top level domain if it is large,
        !           426:          and is composed of other organizations; particularly if the
        !           427:          multiorganization can not be easily classified into one of the
        !           428:          categories and is international in scope.
        !           429: 
        !           430:          As yet no multiorganization domains have been established.  As
        !           431:          they are established information about the administrators and
        !           432:          agents will be made public, and will be listed in subsequent
        !           433:          editions of this memo.
        !           434: 
        !           435:       Note:  The NIC is listed as the agent and registrar for all the
        !           436:       currently allowed top level domains.  If there are other entities
        !           437:       that would be more appropriate agents and registrars for some or
        !           438:       all of these domains then it would be desirable to reassign the
        !           439:       responsibility.
        !           440: 
        !           441: Second Level Domain Requirements
        !           442: 
        !           443:    Each top level domain may have many second level domains.  Every
        !           444:    second level domain must meet the general requirements on a domain
        !           445:    specified above, and be registered with a top level domain
        !           446:    administrator.
        !           447: 
        !           448: 
        !           449: 
        !           450: 
        !           451: 
        !           452: 
        !           453: 
        !           454: 
        !           455: Postel & Reynolds                                               [Page 8]
        !           456: 
        !           457: 
        !           458: 
        !           459: RFC 920                                                     October 1984
        !           460: Domain Requirements
        !           461: 
        !           462: 
        !           463: Third through Nth Level Domain Requirements
        !           464: 
        !           465:    Each second level domain may have many third level domains, etc.
        !           466:    Every third level domain (through Nth level domain) must meet the
        !           467:    requirements set by the administrator of the immediately higher level
        !           468:    domain.  Note that these may be more or less strict than the general
        !           469:    requirements.  One would expect the minimum size requirements to
        !           470:    decrease at each level.
        !           471: 
        !           472: The ARPA Domain
        !           473: 
        !           474:    At the time the implementation of the domain concept was begun it was
        !           475:    thought that the set of hosts under the administrative authority of
        !           476:    DARPA would make up a domain.  Thus the initial domain selected was
        !           477:    called ARPA.  Now it is seen that there is no strong motivation for
        !           478:    there to be a top level ARPA domain.  The plan is for the current
        !           479:    ARPA domain to go out of business as soon as possible.  Hosts that
        !           480:    are currently members of the ARPA domain should make arrangements to
        !           481:    join another domain.  It is likely that for experimental purposes
        !           482:    there will be a second level domain called ARPA in the ORG domain
        !           483:    (i.e., there will probably be an ARPA.ORG domain).
        !           484: 
        !           485: The DDN Hosts
        !           486: 
        !           487:    DDN hosts that do not desire to participate in this domain naming
        !           488:    system will continue to use the HOSTS.TXT data file maintained by the
        !           489:    NIC for name to address translations.  This file will be kept up to
        !           490:    date for the DDN hosts.  However, all DDN hosts will change their
        !           491:    names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
        !           492:    the future.  The schedule for changes required in DDN hosts will be
        !           493:    established by the DDN-PMO.
        !           494: 
        !           495: Impact on Hosts
        !           496: 
        !           497:    What is a host administrator to do about all this?
        !           498: 
        !           499:       For existing hosts already operating in the ARPA-Internet, the
        !           500:       best advice is to sit tight for now.  Take a few months to
        !           501:       consider the options, then select a domain to join.  Plan
        !           502:       carefully for the impact that changing your host name will have on
        !           503:       both your local users and on their remote correspondents.
        !           504: 
        !           505:       For a new host, careful thought should be given (as discussed
        !           506:       below).  Some guidance can be obtained by comparing notes on what
        !           507:       other hosts with similar administrative properties have done.
        !           508: 
        !           509:    The owner of a host may decide which domain to join, and the
        !           510: 
        !           511: 
        !           512: Postel & Reynolds                                               [Page 9]
        !           513: 
        !           514: 
        !           515: 
        !           516: RFC 920                                                     October 1984
        !           517: Domain Requirements
        !           518: 
        !           519: 
        !           520:    administrator of a domain may decide which hosts to accept into his
        !           521:    domain.  Thus the owner of a host and a domain administrator must
        !           522:    come to an understanding about the host being in the domain.  This is
        !           523:    the foundation of responsible administration.
        !           524: 
        !           525:       For example, a host "XYZ" at MIT might possible be considered as a
        !           526:       candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
        !           527:       XYZ.MIT.EDU.
        !           528: 
        !           529:          The owner of host XYZ may choose which domain to join,
        !           530:          depending on which domain administrators are willing to have
        !           531:          him.
        !           532: 
        !           533:    The domain is part of the host name.  Thus if USC-ISIA.ARPA changes
        !           534:    its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
        !           535:    changed its name.  This means that any previous references to
        !           536:    USC-ISIA.ARPA are now out of date.  Such old references may include
        !           537:    private host name to address tables, and any recorded information
        !           538:    about mailboxes such as mailing lists, the headers of old messages,
        !           539:    printed directories, and peoples' memories.
        !           540: 
        !           541:    The experience of the DARPA community suggests that changing the name
        !           542:    of a host is somewhat painful.  It is recommended that careful
        !           543:    thought be given to choosing a new name for a host - which includes
        !           544:    selecting its place in the domain hierarchy.
        !           545: 
        !           546: The Roles of the Network Information Center
        !           547: 
        !           548:    The NIC plays two types of roles in the administration of domains.
        !           549:    First,  the NIC is the registrar of all top level domains.  Second
        !           550:    the NIC is the administrator of several top level domains (and the
        !           551:    registrar for second level domains in these).
        !           552: 
        !           553:    Top Level Domain Registrar
        !           554: 
        !           555:       As the registrar for top level domains, the NIC is the contact
        !           556:       point for investigating the possibility of establishing a new top
        !           557:       level domain.
        !           558: 
        !           559:    Top Level Domain Administrator
        !           560: 
        !           561:       For the top level domains designated so far, the NIC is the
        !           562:       administrator of each of these domains.  This means the NIC is
        !           563:       responsible for the management of these domains and the
        !           564:       registration of the second level domains or hosts (if at the
        !           565:       second level) in these domains.
        !           566: 
        !           567: 
        !           568: 
        !           569: Postel & Reynolds                                              [Page 10]
        !           570: 
        !           571: 
        !           572: 
        !           573: RFC 920                                                     October 1984
        !           574: Domain Requirements
        !           575: 
        !           576: 
        !           577:       It may be reasonable for the administration of some of these
        !           578:       domains to be taken on by other authorities in the future.  It is
        !           579:       certainly not desired that the NIC be the administrator of all top
        !           580:       level domains forever.
        !           581: 
        !           582: Prototypical Questions
        !           583: 
        !           584:    To establish a domain, the following information must be provided to
        !           585:    the NIC Domain Registrar ([email protected]):
        !           586: 
        !           587:       Note:  The key people must have computer mail mailboxes and
        !           588:       NIC-Idents.  If they do not at present, please remedy the
        !           589:       situation at once.  A NIC-Ident may be established by contacting
        !           590:       [email protected].
        !           591: 
        !           592:    1)  The name of the top level domain to join.
        !           593: 
        !           594:       For example:  EDU
        !           595: 
        !           596:    2)  The name, title, mailing address, phone number, and organization
        !           597:    of the administrative head of the organization.  This is the contact
        !           598:    point for administrative and policy questions about the domain.  In
        !           599:    the case of a research project, this should be the Principal
        !           600:    Investigator.  The online mailbox and NIC-Ident of this person should
        !           601:    also be included.
        !           602: 
        !           603:       For example:
        !           604: 
        !           605:          Administrator
        !           606: 
        !           607:             Organization  USC/Information Sciences Institute
        !           608:             Name          Keith Uncapher
        !           609:             Title         Executive Director
        !           610:             Mail Address  USC/ISI
        !           611:                           4676 Admiralty Way, Suite 1001
        !           612:                           Marina del Rey, CA. 90292-6695
        !           613:             Phone Number  213-822-1511
        !           614:             Net Mailbox   [email protected]
        !           615:             NIC-Ident     KU
        !           616: 
        !           617:    3)  The name, title, mailing address, phone number, and organization
        !           618:    of the domain technical contact.  The online mailbox and NIC-Ident of
        !           619:    the domain technical contact should also be included.  This is the
        !           620:    contact point for problems with the domain and for updating
        !           621:    information about the domain.  Also, the domain technical contact may
        !           622:    be responsible for hosts in this domain.
        !           623: 
        !           624: 
        !           625: 
        !           626: Postel & Reynolds                                              [Page 11]
        !           627: 
        !           628: 
        !           629: 
        !           630: RFC 920                                                     October 1984
        !           631: Domain Requirements
        !           632: 
        !           633: 
        !           634:       For example:
        !           635: 
        !           636:          Technical Contact
        !           637: 
        !           638:             Organization  USC/Information Sciences Institute
        !           639:             Name          Craig Milo Rogers
        !           640:             Title         Researcher
        !           641:             Mail Address  USC/ISI
        !           642:                           4676 Admiralty Way, Suite 1001
        !           643:                           Marina del Rey, CA. 90292-6695
        !           644:             Phone Number  213-822-1511
        !           645:             Net Mailbox   [email protected]
        !           646:             NIC-Ident     CMR
        !           647: 
        !           648:    4)  The name, title, mailing address, phone number, and organization
        !           649:    of the zone technical contact.  The online mailbox and NIC-Ident of
        !           650:    the zone technical contact should also be included.  This is the
        !           651:    contact point for problems with the zone and for updating information
        !           652:    about the zone.  In many cases the zone technical contact and the
        !           653:    domain technical contact will be the same person.
        !           654: 
        !           655:       For example:
        !           656: 
        !           657:          Technical Contact
        !           658: 
        !           659:             Organization  USC/Information Sciences Institute
        !           660:             Name          Craig Milo Rogers
        !           661:             Title         Researcher
        !           662:             Mail Address  USC/ISI
        !           663:                           4676 Admiralty Way, Suite 1001
        !           664:                           Marina del Rey, CA. 90292-6695
        !           665:             Phone Number  213-822-1511
        !           666:             Net Mailbox   [email protected]
        !           667:             NIC-Ident     CMR
        !           668: 
        !           669:    5)  The name of the domain (up to 12 characters).  This is the name
        !           670:    that will be used in tables and lists associating the domain and the
        !           671:    domain server addresses.  [While technically domain names can be
        !           672:    quite long (programmers beware), shorter names are easier for people
        !           673:    to cope with.]
        !           674: 
        !           675:       For example:  ALPHA-BETA
        !           676: 
        !           677:    6)  A description of the servers that provides the domain service for
        !           678:    translating name to address for hosts in this domain, and the date
        !           679:    they will be operational.
        !           680: 
        !           681: 
        !           682: 
        !           683: Postel & Reynolds                                              [Page 12]
        !           684: 
        !           685: 
        !           686: 
        !           687: RFC 920                                                     October 1984
        !           688: Domain Requirements
        !           689: 
        !           690: 
        !           691:       A good way to answer this question is to say "Our server is
        !           692:       supplied by person or company X and does whatever their standard
        !           693:       issue server does".
        !           694: 
        !           695:          For example:  Our server is a copy of the server operated by
        !           696:          the NIC, and will be installed and made operational on
        !           697:          1-November-84.
        !           698: 
        !           699:    7)  A description of the server machines, including:
        !           700: 
        !           701:       (a) hardware and software (using keywords from the Assigned
        !           702:       Numbers)
        !           703: 
        !           704:       (b) addresses (what host on what net for each connected net)
        !           705: 
        !           706:       For example:
        !           707: 
        !           708:          (a) hardware and software
        !           709: 
        !           710:             VAX-11/750  and  UNIX,    or
        !           711:             IBM-PC      and  MS-DOS,  or
        !           712:             DEC-1090    and  TOPS-20
        !           713: 
        !           714:          (b) address
        !           715: 
        !           716:             10.9.0.193 on ARPANET
        !           717: 
        !           718:    8)  An estimate of the number of hosts that will be in the domain.
        !           719: 
        !           720:       (a) initially,
        !           721:       (b) within one year,
        !           722:       (c) two years, and
        !           723:       (d) five years.
        !           724: 
        !           725:       For example:
        !           726: 
        !           727:          (a) initially  =   50
        !           728:          (b) one year   =  100
        !           729:          (c) two years  =  200
        !           730:          (d) five years =  500
        !           731: 
        !           732: 
        !           733: 
        !           734: 
        !           735: 
        !           736: 
        !           737: 
        !           738: 
        !           739: 
        !           740: Postel & Reynolds                                              [Page 13]
        !           741: 
        !           742: 
        !           743: 
        !           744: RFC 920                                                     October 1984
        !           745: Domain Requirements
        !           746: 
        !           747: 
        !           748: Acknowledgment
        !           749: 
        !           750:    We would like to thank the many people who contributed to this memo,
        !           751:    including the participants in the Namedroppers Group, the ICCB, the
        !           752:    PCCB, and especially the staff of the Network Information Center,
        !           753:    particularly J. Feinler and K. Harrenstien.
        !           754: 
        !           755: References
        !           756: 
        !           757:    [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
        !           758:         Information Sciences Institute, November 1983.
        !           759: 
        !           760:    [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
        !           761:         RFC-882, USC Information Sciences Institute, November 1983.
        !           762: 
        !           763:    [3]  Mockapetris, P., "Domain Names - Implementation and
        !           764:         Specification", RFC-883, USC Information Sciences Institute,
        !           765:         November 1983.
        !           766: 
        !           767:    [4]  Postel, J., "Domain Name System Implementation Schedule",
        !           768:         RFC-897, USC Information Sciences Institute, February 1984.
        !           769: 
        !           770:    [5]  ISO, "Codes for the Representation of Names of Countries",
        !           771:         ISO-3166, International Standards Organization, May 1981.
        !           772: 
        !           773:    [6]  Postel, J., "Domain Name System Implementation Schedule -
        !           774:         Revised", RFC-921, USC Information Sciences Institute, October
        !           775:         1984.
        !           776: 
        !           777:    [7]  Mockapetris, P., "The Domain Name System", Proceedings of the
        !           778:         IFIP 6.5 Working Conference on Computer Message Services,
        !           779:         Nottingham, England, May 1984.  Also as ISI/RS-84-133,
        !           780:         June 1984.
        !           781: 
        !           782:    [8]  Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
        !           783:         for Distributed Systems", Proceedings of the Seventh
        !           784:         International Conference on Computer Communication, October 30
        !           785:         to November 3 1984, Sidney, Australia.  Also as ISI/RS-84-132,
        !           786:         June 1984.
        !           787: 
        !           788: 
        !           789: 
        !           790: 
        !           791: 
        !           792: 
        !           793: 
        !           794: 
        !           795: 
        !           796: 
        !           797: Postel & Reynolds                                              [Page 14]
        !           798: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.