RFC 1032 DOMAIN ADMINISTRATORS GUIDE

Network Working Group                                       M. Stahl
Request for Comments: 1032                         SRI International
                                                       November 1987

Руководство администратора домена

DOMAIN ADMINISTRATORS GUIDE

PDF

Статус документа

Этот документ описывает процедуры регистрации доменов в агентстве NIC DDN1, а также дает рекомендации по организации и поддержке домена в соответствии с требованиями RFC-920. Документ предназначен для администраторов доменов. Данный документ следует использовать вместе с RFC-920, где содержатся официальные правила IAB2 и DARPA3. Документ может распространяться без ограничений.

Основы

Домены представляют собой административные элементы, обеспечивающие децентрализованное управление именованием и адресацией. Система именования доменов4 является распределенной и иерархической.

Сетевой центр NIC назначен агентством DCA5 для предоставления услуг по регистрации для системы именования доменов в относящихся к DDN и DARPA частях Internet.

В качестве регистратора доменов верхнего и второго уровней, а также администратора корневых серверов доменных имен, действующего от имени и по поручению DARPA и DDN, NIC отвечает за поддержку файлов зон корневого уровня и их двоичных эквивалентов. В дополнение к этому NIC отвечает за администрирование доменов верхнего уровня ARPA, COM, EDU, ORG, GOV и MIL от имени и по поручению DCA и DARPA, пока те не сочтут нужным выбрать для решения этих задач другие организации.

Приведенные в этом документе руководства рекомендуются для администраторов, создающих и контролирующих домены второго уровня.

Администратор домена

Администратор домена (DA) является координатором, управляющим и техническим специалистом. Если домен относится ко второму или третьему уровню иерархии доменов, DA должен регистрировать его во взаимодействии с администратором вышележащего домена, чтобы обеспечить соответствие требованиям того домена. Для выяснения лица, наделенного полномочиями для пространства имен, к которому присоединяется домен DA может задать вопрос в NIC (NIC Hostmaster). Контактные данные для доменов первого и второго уровня можно найти в файле NETINFO:DOMAIN-CONTACTS.TXT, который можно загрузить с сервера NIC по протоколу FTP с анонимным доступом.

Администратору домена следует быть технически компетентным, он должен понимать концепции и процедуры работы сервера имен, описанные в RFC-1034, а также обеспечивать надежность и непрерывность работы этого сервера. В сферу ответственности DA и лиц, получающих от него полномочия, входит обеспечение актуальности данных на серверах имен. В качестве управляющего DA должен быть способен адекватно реагировать на жалобы по поводу работы его сервера имен. Он должен быть обеспечить соответствие поведения хостов своего домена принятым протоколам, а также принимать своевременные меры при возникновении проблем, отклонении от протоколов, а также других неполадках. Администратор домена должен быть ответственным лицом, имеющим полномочия выполнять требуемые действия от своего имени или передавать эти полномочия другим людям.

Распределение имен в рамках домена контролируется DA, которому следует проверять уникальность каждого имени в домене и соответствие имен стандартам именования. Администратор дает доступ к именам и связанной с ними информации пользователям домена и внешним пользователям. Администратору следует тесно взаимодействовать с лицами, указанными в качестве контактов (technical and zone) для домена, поскольку множество принимаемых административных решений требует информации от этих людей.

Контакты для зоны

Зона включает те непрерывные части дерева доменных имен, для которых сервер имен содержит полную информацию и наделен полномочиями. Сервер имен может быть полномочным для одной или множества зон. Лица, указанные в контактах для зоны (technical/zone) отвечают за технические аспекты поддержки сервера имен, работы распознавателей (resolver) и файлов базы данных. Эти люди обеспечивают работу сервера имен и контактируют с техническими специалистами других доменов и зон при возникновении воздействующих на зону проблем.

Политика

Выбор имени домена и хостов в нем, а также распределение пространства имен в домене решаются на определяются уровне. При возникновении конфликтов NIC не участвует в решении локальных проблем. NIC не будет выступать в качестве арбитра по спорным вопросам правомочности той или иной организации на имена доменов верхнего или второго уровня. NIC считает эти вопросы локальными и предполагает, что они должны решаться между сторонами, вовлеченными в конфликт до оплаты взносов, связанных с процессом регистрации в NIC. Следовательно, предполагается, что ответственные за домен лица уже решили все локальные конфликты между членами своего домена до регистрации этого домена в NIC. По запросу NIC будет предоставлять рекомендации в части выбора технических решений, но не будет выступать в качестве арбитра по спорным вопросам на локальном уровне. Эта политика соответствует распределенной природе системы доменных имен, помогая распределить задачи по решению проблем и обслуживанию системы.

При именовании хостов следует придерживаться соглашений, указанных в RFC-952. С технической точки зрения доменные имена могут быть очень длинными. Каждый сегмент имени может содержать до 64 символов, однако NIC настоятельно рекомендует DA выбирать имена не длиннее 12 символов, поскольку с именами имеют дело люди, использующие эти имена в адресах электронной почты, контактных данных и др. С ростом размера имен возрастает вероятность возникновения ошибок при работе с ними. Для пользователей короткие имена более удобны. Многие люди считают, что такие имена проще запоминать и набирать; размер большинства зарегистрированных имен не превышает 12 символов.

Распределение доменных имен происходит в порядке очередности поступления запросов. NIC не регистрирует отдельные хосты в администрируемых им доменах верхнего уровня. Одним из преимуществ системы доменных имен является передача полномочий по выделению и администрированию имен вниз по ветвям дерева иерархии доменов. Регистрация хостов вместе с доменами верхнего уровня может привести к утрате этого преимущества. Кроме того, администратор домена отвечает за действия хостов в своем домене. Мы не хотели бы принимать на себя функции контроля исполнения правил по отношению к отдельным хостам. Разумнее передать эту ответственность в субдомены, зарегистрированные в доменах верхнего уровня.

Страны, желающие зарегистрировать домены верхнего уровня, должны именовать себя после включения двухсимвольного кода в международный стандарт ISO-3166. Однако в некоторых случаях двухсимвольные коды стран в стандарте ISO совпадают с сокращенными обозначениями штатов в почтовой службе США. Для выполнения запросов стран в таких случаях могут использоваться трехсимвольные коды ISO-3166.

Анкету для регистрации домена можно получить от NIC hostmaster или загрузить по протоколу FTP файл NETINFO:DOMAIN-TEMPLATE.TXT с хоста SRI-NIC.ARPA. После заполнения всех разделов анкеты ее следует отправить по электронной почте на адрес HOSTMASTER@SRI-NIC.ARPA.

Приложение к данному документу содержит форму, которую нужно заполнить для регистрации домена верхнего или второго уровня в NIC. Эта форма является заменой опросника, опубликованного в RFC-920. Анкета должна быть целиком заполнена лицом, принимающим административную ответственность за домен и только после этого NIC разрешит организацию домена верхнего или второго уровня. DA несет ответственность за актуальность данных о домене, предоставленных в NIC или регистрационному агенту, проводившему регистрацию домена. Например, сети CSNET и UUCP функционируют в качестве «доменных фильтров», обрабатывая заявки на домены от своих организаций. Эти сети периодически отправляют в NIC полученную информацию для включения в базы данных и файлы корневых серверов. Эта процедура описана в документе NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT. Администраторам доменов настоятельно рекомендуется периодически просматривать данные о своем домене и вносить требуемые корректировки. Исправления следует направлять по электронной почте.

Имя для домена

Разработчики системы именования доменов предложили несколько общих категорий для доменов верхнего уровня, каждый из которых подходит для множества разных организаций. В число доменов верхнего уровня, зарегистрированных в DDN NIC входят домены ARPA, COM, EDU, GOV, MIL, NET, ORG, а также множество доменов верхнего уровня разных стран. Для включения своего домена в один из доменов верхнего уровня DA следует определиться с целями, для достижения которых создается домен.

ARPA Временный домен. Имя верхнего уровня просто было добавлено в конце имен хостов, которые добавлялись в домен. На начальном этапе создания системы (1984), имена всех хостов Official DoD Internet Host Table6, поддерживаемой NIC, были изменены путем добавления суффикса .ARPA в целях ускорения переходя к системе доменных имен. Другой причиной смены имен было желание стимулировать хоста на переход к новой системе именования и при необходимости обновить программное обеспечение. Это выполнялось в масштабе сети под руководством DCA в соответствии с документом DDN Management Bulletin No. 22. Хосты этого домена с течением времени будут перемещены в другие ветви дерева доменных имен.

COM Домен верхнего уровня для размещения в нем доменов разных компаний и бизнес-структур.

EDU Домен верхнего уровня для размещения в нем доменов университетов и других учебных заведений.

GOV Родительский домен для размещения в нем доменов государственных агентств.

MIL Домен верхнего уровня для размещения в нем доменов военных организаций.

NET Родительский домен для разного рода сетевых организаций. В этот домен будут включаться домены второго уровня регистрационных центров, консорциумов, а также организаций, связанных с управлением сетями (информационные центры и т. п..

ORG Родительский домен для размещения в нем доменов организаций, которые не могут быть отнесены ни к одной мз перечисленных выше категорий. К ним могут относиться группы технической поддержки, профессиональные объединения и т. п.

Одной из действующих рекомендаций системы доменных имен является именование хостов, не зависящее от сетей, к которым они подключены. Это подразумевает, что в общем случае, в доменные имена на следует включать адреса или маршруты. Например, хост может иметь подключения к сетям Interent и BITNET, но его имя для обеих сетей должно быть одинаково. Описание синтаксиса доменных имен приведено в разделе 3 документа RFC-1034.

Проверка данных

Процесс верификации данных может осуществляться несколькими способами. Одним из таких способов является работа с сервером NIC WHOIS. Имеющий доступ к WHOIS администратор может ввести команду whois domain <domain name> для получения отклика WHOIS, содержащего название и адрес владеющей доменом организации, контактные данные для администратора, зоны и технических вопросов, имена хостов и сетевые адреса сайтов, обеспечивающих службу имен для домена.

Пример информации о домене показан ниже.

         @whois domain rice.edu<Return>

            Rice University (RICE-DOM)
            Advanced Studies and Research
            Houston, TX 77001

            Domain Name: RICE.EDU

               Administrative Contact:
               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
               Technical Contact, Zone Contact:
               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
               (713) 527-8101 ext 3844

            Domain servers:

            RICE.EDU                     128.42.5.1
            PENDRAGON.CS.PURDUE.EDU      128.10.2.5

В дополнение к этому DA может отправить письмо по адресу SERVICE@SRI-NIC.ARPA, указав в заголовке команду whois domain <domain name>. Информация о домене будет отправлена электронной почтой по обратному адресу администратора. Этот метод удобен для организаций, не имеющих доступа к сервису NIC WHOIS.

При организации анкету с данными следует направлять по электронной почте на адрес HOSTMASTER@SRI-NIC.ARPA. Опросник, приведенный в приложении, можно также загрузить по протоколу FTP с хоста SRI-NIC.ARPA. Предоставленная администратором информация будет просмотрена персоналом сетевого центра на предмет ее полноты. Вполне вероятно, что в процессе регистрации будет происходить некий обмен сообщениями по электронной почте для уточнения информации.

Получение дополнительной информации

Информация о доменах верхнего уровня и обслуживающих их серверах имен хранится в файле NETINFO:DOMAINS.TXT, доступном на хосте SRI-NIC.ARPA. Таблицу с информацией можно загрузить по протоколу FTP. Кроме того, эту информацию можно получить, организовав по протоколу TCP или UDP соединение с сервером имен NIC (Host Name Server) через порт 101 на хосте SRI-NIC.ARPA и введя команду ALL-DOM.

Информация о доменах содержится в перечисленных ниже файлах, которые доступны по протоколу FTP на хосте SRI-NIC.ARPA.

  • NETINFO:DOMAINS.TXT — таблица всех доменов верхнего уровня и обслуживающих эти домены серверов имен. Таблиуа обновляется при каждом добавлении домена верхнего уровня.

  • NETINFO:DOMAIN-INFO.TXT — список всех доменов верхнего и второго уровня, зарегистрированных в NIC. Список обновляется ежемесячно.

  • NETINFO:DOMAIN-CONTACTS.TXT — список всех доменов верхнего и второго уровня с контактными данными администраторов, зоны и технического персонала для каждого из доменов.

  • NETINFO:DOMAIN-TEMPLATE.TXT — анкета для регистрации доменов верхнего и второго уровня.

Для получения общей или конкретной информации о системе доменных имен можно воспользоваться перечисленными ниже способами.

  1. Направить сообщение по адресу HOSTMASTER@SRI-NIC.ARPA.

  2. Позвонить по бесплатному (в Северной Америке) телефонному номеру NIC (800) 235-3155

  3. По протоколу FTP загрузить базовые документы RFC и другие файлы, доступные в NIC. Некоторые из этих RFC указаны в разделе Литература данного документа.

Литература

Приведенные ниже ссылки указывают документы, содержащие базовую информацию по системе доменных имен. В квадратных скобках указаны имена файлов, которые можно загрузить по протоколу FTP с анонимным доступом в хоста SRI-NIC.ARPA7.

  1. Defense Communications Agency DDN Defense Communications System, DDN Management Bulletin No. 22, Domain Names Transition, March 1984. [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]

  2. Defense Communications Agency DDN Defense Communications System, DDN Management Bulletin No. 32, Phase I of the Domain Name Implementation, January 1987. [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]

  3. Harrenstien, K., M. Stahl, and E. Feinler, “Hostname Server”, RFC-9538, DDN Network Information Center, SRI International, October 1985. [ RFC:RFC953.TXT ]

  4. Harrenstien, K., M. Stahl, and E. Feinler, “Official DoD Internet Host Table Specification”, RFC-9529, DDN Network Information Center, SRI International, October 1985. [ RFC:RFC952.TXT ]

  5. ISO, “Codes for the Representation of Names of Countries”, ISO-3166, International Standards Organization, May 1981. [ Не доступен в сети ]

  6. Lazear, W.D., “MILNET Name Domain Transition”, RFC-1031, Mitre Corporation, October 1987. [ RDC:RFC1031.TXT ]

  7. Lottor, M.K., “Domain Administrators Operations Guide”, RFC-1033, DDN Network Information Center, SRI International, July 1987. [ RFC:RFC1033.TXT ]

  8. Mockapetris, P., “Domain Names – Concepts and Facilities”, RFC-1034, USC Information Sciences Institute, October 1987. [ RFC:RFC1034.TXT ]

  9. Mockapetris, P., “Domain Names – Implementation and Specification”, RFC-1035, USC Information Sciences Institute, October 1987. [ RFC:RFC1035.TXT ]

  10. Mockapetris, P., “The Domain Name System”, Proceedings of the IFIP 6.5 Working Conference on Computer Message Services, Nottingham, England, May 1984. Also as ISI/RS-84-133, June 1984. [ Not online ]

  11. Mockapetris, P., J. Postel, and P. Kirton, “Name Server Design for Distributed Systems”, Proceedings of the Seventh International Conference on Computer Communication, October 30 to November 3 1984, Sidney, Australia. Also as ISI/RS-84-132, June 1984. [ Не доступен в сети ]

  12. Partridge, C., “Mail Routing and the Domain System”, RFC-97411, CSNET-CIC, BBN Laboratories, January 1986. [ RFC:RFC974.TXT ]

  13. Postel, J., “The Domain Names Plan and Schedule”, RFC-881, USC Information Sciences Institute, November 1983. [ RFC:RFC881.TXT ]

  14. Reynolds, J., and Postel, J., “Assigned Numbers”, RFC-101012 USC Information Sciences Institute, May 1986. [ RFC:RFC1010.TXT ]

  15. Romano, S., and Stahl, M., “Internet Numbers”, RFC-1020, SRI, November 1987. [ RFC:RFC1020.TXT ]

Приложение

Ниже приведен текст опросника13, который можно загрузить по протоколу FTP с хоста SRI-NIC.ARPA (файл NETINFO:DOMAIN-TEMPLATE.TXT).


   To establish a domain, the following information must be sent to the
   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):

   NOTE: The key people must have electronic mailboxes and NIC
   "handles," unique NIC database identifiers.  If you have access to
   "WHOIS", please check to see if you are registered and if so, make
   sure the information is current.  Include only your handle and any
   changes (if any) that need to be made in your entry.  If you do not
   have access to "WHOIS", please provide all the information indicated
   and a NIC handle will be assigned.

   (1)  The name of the top-level domain to join.

         For example:  COM

   (2) The NIC handle of the administrative head of the organization.
   Alternately, the person's name, title, mailing address, phone number,
   organization, and network mailbox.  This is the contact point for
   administrative and policy questions about the domain.  In the case of
   a research project, this should be the principal investigator.

         For example:

            Administrator

               Organization  The NetWorthy Corporation
               Name          Penelope Q. Sassafrass
               Title         President
               Mail Address  The NetWorthy Corporation
                             4676 Andrews Way, Suite 100
                             Santa Clara, CA 94302-1212
               Phone Number  (415) 123-4567
               Net Mailbox   Sassafrass@ECHO.TNC.COM
               NIC Handle    PQS

   (3)  The NIC handle of the technical contact for the domain.
   Alternately, the person's name, title, mailing address, phone number,
   organization, and network mailbox.  This is the contact point for
   problems concerning the domain or zone, as well as for updating
   information about the domain or zone.

         For example:

            Technical and Zone Contact

               Organization  The NetWorthy Corporation
               Name          Ansel A. Aardvark
               Title         Executive Director
               Mail Address  The NetWorthy Corporation
                             4676 Andrews Way, Suite 100
                             Santa Clara, CA. 94302-1212
               Phone Number  (415) 123-6789
               Net Mailbox   Aardvark@ECHO.TNC.COM
               NIC Handle    AAA2

   (4)  The name of the domain (up to 12 characters).  This is the name
   that will be used in tables and lists associating the domain with the
   domain server addresses.  [While, from a technical standpoint, domain
   names can be quite long (programmers beware), shorter names are
   easier for people to cope with.]

         For example:  TNC

   (5)  A description of the servers that provide the domain service for
   translating names to addresses for hosts in this domain, and the date
   they will be operational.

         A good way to answer this question is to say "Our server is
         supplied by person or company X and does whatever their standard
         issue server does."

            For example:  Our server is a copy of the one operated by
            the NIC; it will be installed and made operational on
            1 November 1987.

   (6) Domains must provide at least two independent servers for the
   domain.  Establishing the servers in physically separate locations
   and on different PSNs is strongly recommended.  A description of the
   server machine and its backup, including
         (a) Hardware and software (using keywords from the Assigned
         Numbers RFC).

         (b) Host domain name and network addresses (which host on which
         network for each connected network).

         (c) Any domain-style nicknames (please limit your domain-style
         nickname request to one)

         For example:

            - Hardware and software

               VAX-11/750  and  UNIX,    or
               IBM-PC      and  MS-DOS,  or
               DEC-1090    and  TOPS-20

            - Host domain names and network addresses

               BAR.FOO.COM 10.9.0.193 on ARPANET

            - Domain-style nickname

               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)

   (7)  Planned mapping of names of any other network hosts, other than
   the server machines, into the new domain's naming space.

         For example:

            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM


   (8)  An estimate of the number of hosts that will be in the domain.

         (a) Initially
         (b) Within one year
         (c) Two years
         (d) Five years.

         For example:

            (a) Initially  =   50
            (b) One year   =  100
            (c) Two years  =  200
            (d) Five years =  500

   (9)  The date you expect the fully qualified domain name to become
   the official host name in HOSTS.TXT.

         Please note: If changing to a fully qualified domain name (e.g.,
         FOO.BAR.COM) causes a change in the official host name of an
         ARPANET or MILNET host, DCA approval must be obtained beforehand.
         Allow 10 working days for your requested changes to be processed.

         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
         further instructions.

   (10) Please describe your organization briefly.

         For example: The NetWorthy Corporation is a consulting
         organization of people working with UNIX and the C language in an
         electronic networking environment.  It sponsors two technical
         conferences annually and distributes a bimonthly newsletter.

   ---------------------------------------------------------------------

   This example of a completed application corresponds to the examples
   found in the companion document RFC-1033, "Domain Administrators
   Operations Guide."

   (1)  The name of the top-level domain to join.

            COM

   (2)  The NIC handle of the administrative contact person.

            NIC Handle    JAKE

   (3)  The NIC handle of the domain's technical and zone
         contact person.

            NIC Handle    DLE6

   (4)  The name of the domain.

            SRI

   (5)  A description of the servers.

            Our server is the TOPS20 server JEEVES supplied by ISI; it
            will be installed and made operational on 1 July 1987.

   (6)  A description of the server machine and its backup:

            (a) Hardware and software

               DEC-1090T   and  TOPS20
               DEC-2065    and  TOPS20

            (b) Host domain name and network address

               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET

            (c) Domain-style nickname

               None

   (7)  Planned mapping of names of any other network hosts, other than
   the server machines, into the new domain's naming space.

            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM

   (8)  An estimate of the number of hosts that will be directly within
   this domain.

            (a) Initially  =   50
            (b) One year   =  100
            (c) Two years  =  200
            (d) Five years =  500

   (9)  A date when you expect the fully qualified domain name to become
   the official host name in HOSTS.TXT.

            31 September 1987

   (10)  Brief description of organization.

            SRI International is an independent, nonprofit, scientific
            research organization.  It performs basic and applied research
            for government and commercial clients, and contributes to
            worldwide ecomomic, scientific, industrial, and social progress
            through research and related services.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru 

1Network Information Center of Defense Data Network – Сетевое информационное агентство министерства обороны США.

2Internet Activities Board.

3Defense Advanced Research Projects Agency — агентство перспективных оборонных исследований США.

4DNS в современной терминологии. Прим. перев.

5Defense Communications Agency — агентство оборонных коммуникаций.

6Официальная таблица хостов Internet министерства обороны США.

7Следует отметить, что в настоящее время эти ссылки не будут работать. Большая часть указанных документов доступна по протоколу HTTP на сайте www.rfc-egitor.org. Прим. перев.

8Документ утратил актуальность и в настоящее время имеет статус HISTORIC. Прим. перев.

9Документ обновлен RFC 1123. Прим. перев.

11Этот документ отменен RFC 2821, который, в свою очередь отменен RFC 5321. Прим. перев.

12В соответствии с RFC 3232 документ Assigned Numbers утратил силу. В настоящее время информация о выделенных значениях доступна по ссылке www.iana.org/numbers. Прим. перев.

13В настоящее время процедуры регистрации доменов существенно упростились и заполнять данный опросник не требуется. В связи с этим текст анкеты сохранен в документе без перевода на русский язык. Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.