Регистрация доменных имен
Для того, чтобы получить зону надо отправить заявку в РосНИИРОС, который отвечает за делегирование поддоменов в пределах домена ru. В заявке указывается адрес компьютера-сервера доменных имен, почтовый адрес администратора сервера, адрес организации и ряд другой информации. Разберем эту заявку на примере заявки Международной лаборатории VEGA.
domain: vega.ru descr: International Agency VEGA descr: Kurchatov sq. 1 descr: 115470 Moscow descr: Russian Federation admin-c: Pavel B Khramtsov zone-c: Pavel B Khramtsov tech-c: Pavel B Khramtsov nserver: vega-gw.vega.ru nserver: ns.relarn.ru nserver: polyn.net.kiae.su dom-net: 194.226.43.0 changed: paul@kiae.su 961018 source: RIPN
person: Pavel B Khramtsov address: International Agency Vega address: Kurchatov sq. 1 address: 115470 Moscow address: Russian Federation phone: +7 095 1969124 fax-no: +7 095 9393670 e-mail: paul@kiae.su changed: paul@kiae.su 961018 source: RIPN
При заполнении этой заявки следует иметь в виду, что она будет обрабатываться роботом автоматом. Этот автомат проверяет ее на наличие ошибок заполнения и противоречия с существующей базой данных делегированных доменов. Так как робот не терпит неточностей и глух к различного рода просьбам, то заполнять заявку следует аккуратно. Автомат обрабатывает заявку, выделяет в ней записи для базы данных регистрации доменов. Сами эти записи состоят из полей. Каждое поле идентифицируется в заявке именем поля, после которого ставится символ ":".
В строке описания поля "domain:" указывается имя домена, которое вы просите зарегистрировать. РосНИИРОС регистрирует только поддомены домена ru. Регистрировать следует как "прямую" зону, так и "обратную"(см. раздел 3.1.4). В нашем случае это просто зона 43.226.194.inaddr.arpa.
В строке описания поля "descr:" указывают название и адрес организации, которая запрашивает домен. Так как на одной строке эта информация не может разместиться, то команд descr может быть несколько.
В строке описания поля "admin-c:" указывается персона, которая осуществляет администрирование домена. Поле имеет обязательный формат: <имя> <первая буква отчества> <фамилия>. Таких строк может быть несколько, если лиц отвечающих за администрирование домена больше одного. Вместо указанного выше формата можно использовать также и идентификатор персоны, если таковой имеется. Идентификатор называют nichandle, или персональный код.
Поле "zone-c:" заполняется для той персоны, чей почтовый адрес указан в записи SOA в описании зоны. Формат этого поля идентичен формату команды admin-c.
Поле "tech-c:" указывается для технического администратора домена, к которому обращаются в случае экстренных ситуаций. Формат этого поля совпадает с форматом команды admin-c. По моему глубокому убеждению во всех полях (admin-c, zone-c и tech-c) имеет смысл указывать координаты одного и того же человека. Мало кто из российских пользователей Internet может позволить роскошь держать сразу трех разных специалистов на обслуживании сервиса доменных имен. Учитывая отечественные реалии, можно со всей ответственностью утверждать, что кроме неразберихи ни к чему другому большое количество администраторов не приводит.
В строке описания поля "nserver:" указывают доменные имена серверов зоны. Как правило, таких строк в заявке бывает несколько. Первым указывается primary или главный сервер домена. В нашем случае это vega-gw.vega.ru. На этом сервере хранится база данных домена. Вторым указывается secondary или дублирующий сервер домена. В нашем случае это ns.relarn.ru. Дублирующие сервера призваны повысить надежность работы всей системы доменных имен, поэтому дублирующих серверов может быть несколько. Если существуют другие дублирующие сервера, то указываются и они (сервер polyn.net.kiae.su из нашей заявки также является дублирующим для домена vega.ru). При указании дублирующих серверов первым следует указывать тот, который наиболее надежно обслуживает запросы к домену. В нашем примере таким является сервер ns.relarn.ru. Выбран он был по тем соображениям, что регистрация проводилась в РосНИИРОС, специалисты которого администрируют домен relarn.ru. Первоначально, дублирующим сервером был только сервер polyn.net.kiae.su. Однако, медленная скорость разрешения доменных имен в домене kiae.su всем хорошо известна. Это приводит к достаточно большим задержкам при ответах на запросы на расширение имени. Особенно долго обрабатываются обратные запросы. В результате, автомат постоянно выдавал сообщение что сервер polyn.net.kiae.su недоступен, хотя при ручном тестировании все работало нормально. Для того, чтобы решить эту проблему было решено просить разрешения на использование ns.relarn.ru в качестве secondary сервера для домена vega.ru, справедливо полагая, что сервер доменных имен расположенный в том же домене, что и автомат, и сервер установленный на машине, использующий общий коаксиальный кабель с машиной автомата, будет отвечать гораздо оперативнее сервера, расположенного в другом домене, за несколькими репитерами и мостами. При выборе места размещения дублирующих серверов следует иметь в виду, что сначала проверяется возможность взаимодействия именно с этими серверами. Если хотя бы один из них не откликается на запросы автомата, то заявка отклоняется.
Поле "sub-dom:" описывает поддомены домена. В нашей заявке нет поля sub-net, т.к. в домене vega.ru нет поддоменов. Но если бы нам понадобилось изменять структуру домена, а именно, разбить его на зоны, то тогда следовало бы включить в заявку между строками nserver и строкой dom-net строку:
sub-net: zone1 zone2
В этом случае весь домен vega.ru разбит на два поддомена: zone1 и zone2. Например, машина quest из зоны zone1 будет иметь доменное имя quest.zone1.vega.ru, а машина query из зоны zone2 - query.zone2.vega.ru. Поддомены указываются в команде sub-dom через пробел.
Поле "dom-net:" указывает на список IP-сетей данного домена. В нашей заявке указана только одна сеть 194.226.43.0, но если у организации, которая заводит свой собственный домен имеется в наличии несколько сетей, то эти сети можно указать в этом поле, разделяя их пробелами.
Поле "changed:" является обязательным и служит указателем на то лицо, которое последним вносило изменения в заявку. В качестве значения поля после символа ":" указывается почтовый адрес этого лица и, через пробел дата внесения изменения в формате ГГММДД (Г-год, М-месяц, Д-день).
Последняя запись в заявке - это поле source, которое отделяет различные записи во входном потоке данных программы робота. Значение этого поля - RIPN.
Вслед за записью заявки следует запись описания персоны. Именно эта запись позволяет связывать поля admin-c, zone-c, tech-c с информацией о конкретном лице, которая содержится в записи описания персоны.
Запись описания персоны начинается с поля "person:". В данном поле указывается информация о лице (персоне). Обычно, данное поле имеет следующий формат: <имя> <первая буква отчества> <фамилия>.
Поле "address:" вслед за полем "person:". Данное поле состоит из нескольких строк, каждая из которых начинается с имени поля. Первым указывается организация, во второй строке - улица и номер дома, в третьей - почтовый индекс и название города или поселка, в последней строке - название страны. Одним словом - это типичный американский почтовый адрес.
За адресом следует поле "phone:". В нем указывается номер телефона, по которому можно связаться с указанным лицом. Номер задается с указанием номера страны и кода города. Для Москвы - +7 095 ___ __ __. Телефонов можно указать несколько.
Все выше сказанное для поля "phone:" относится и к полю "fax-no:". В этом поле указывается номер телефакса.
Самым важным, на мой взгляд, из всех полей, определяющих координаты персоны, является поле адреса электронной почты - "e-mail:", хотя оно и не является обязательным полем заявки. Адрес электронной почты указывается как адрес электронной почты Internet. Для абонентов других сетей возможны проблемы с регистрацией их адресов, т.к. указание символов "!", "%", "::" нежелательно.
В поле "nic-hdl:" указывается персональный номер пользователя, если он у данного пользователя есть. Поле не является обязательным, но, как подчеркивается в инструкции по заполнению заявок "крайне желательно".
Последним полем в описании персоны, как и в заявке на домен, является поле "source:". В заявке можно указать несколько персон, что породит для каждой из них свою собственную запись в базе данных описания доменов. Информация о зоне и лицах, которые ответственны за ведение зоны (и не только о них) можно найти по команде:
/usr/paul>whois -h whois.ripn.net <имя зоны или персоны>
Теперь после описания самой заявки перейдем к описанию ее регистрации. После того как заявка отправлена, следует настроить и запустить сервер в локальном режиме. Администратор РосНИИРОС обычно извещает о том, что у администрации домена ru нет претензий к вашей заявке и разрешает запустить ваш сервер для тестирования. Если в домене есть уже запрашиваемый вами поддомен или у администрации домена ru есть другие возражения по поводу регистрации вашего домена, то администрация домена ru вас об этом известит.
Если у администратора домена ru нет причин для отказа в регистрации, то он разрешает запуск сервера для тестирования. Если ваш сервер уже запущен, то это сообщение вы просто примете к сведению, если нет, то нужно срочно, обычно в течении 2-х часов настроить и запустить сервер (вообще-то, запускать надо сразу как только решили отправлять заявку).
Еще раз обратите внимание на то, что заявка, отправленная на адрес ru-dns@RIPN.net попадает на автомат обработки заявок, с которым бесполезно вступать в пререкания и прения по поводу различного рода ошибок и неточностей. При этом проблемы с регистрацией могут возникать как по вине заявителя (ошибки в полях заявки, например), так и по вине регистрирующей стороны. Так, например, регистрация домена vega.ru длилась почти два месяца из-за того, что в начале были ошибки в заявке, потом были выявлены несоответствия заявки и описания зоны, затем сломался автомат регистрации и заявка была утеряна. Затем возникли проблемы с дублирующим сервером зоны (слишком большое время отклика, из-за которого автомат отклонял заявку). При этом и сам автомат работал медленно, т.к. проблема скорости разрешения запросов на серверах имен РНЦ "Курчатовский Институт" хорошо всем известна. Поэтому лучше всего сразу узнать телефон администратора и общаться с ним непосредственно.
Именно "телефон", и об этом упоминается не случайно. Общение с администраторами по электронной почте ни к чему хорошему, в большинстве случаев, не приводит. Как правило, вы будете получать назад ваши же письма откомментированные администратором, который в момент отправки этого письма мгновенно забывает о ваших проблемах. Вообще, вся эта переписка напоминает разговор двух склеротиков, когда строк типа: "В письме от такого-то числа пользователь написал..." становится больше, чем содержательной информации. Выискивать в большом письме комментарии, которые могут занимать не больше двух слов трудно и нудно. Особенно глупо это выглядит если вы, того не ведая, вступите в переписку с автоматом. Я никому не хочу навязывать правила поведения в сети, но должны же существовать какие-то нормы, обусловленные здравым смыслом.
При размещении сервера домена следует позаботиться о том, чтобы существовал вторичный (secondary) сервер имен вашего домена. Согласно большинству рекомендаций, следует иметь от 2-х до 4-х серверов на случай отказа основного сервера доменных имен.
Вообще говоря, можно вести переговоры о создании вторичного сервера доменных имен и с самим РосНИИРОС и с любым провайдером. Но за услуги последнего придется заплатить. Можно запустить вторичный сервер и на одном из своих компьютеров, но в этом случае вы просто выполните требования РосНИИРОС формально, так как надежности процедуре разрешения имен вашего домена такое решение не принесет.
Рис.3.4. Схема подключения локальной сети к провайдеру
Действительно, если ваша сеть подключена к провайдеру через один единственный шлюз (рисунок 3.4), то все ваши компьютеры, оказываются за шлюзом. При отказе шлюза все они для внешнего пользователя сети исчезают, а это значит, что если сервер доменных имен расположен на шлюзе или одном из компьютеров вашей сети, то для внешнего пользователя и их имена исчезнут также, в отличии от IP-адресов, которые прописаны в маршрутизаторе провайдера.
На первый взгляд кажется, что если нет доступа, то и трансляция доменных имен в IP-адресе не нужна. Однако, это не совсем так. Если система не может разрешить доменное имя, то она сообщает - "unknown host", т.е. система такого компьютера не знает. Если же доменное имя успешно транслируется в IP-адрес, то, в случае потери связи, система сообщает - "host un-reachable", т.е. система знает о такой машине, но в данный момент достичь эту машину нет никакой возможности.
В критических ситуациях не всегда можно быстро сообразить, что происходит в сети, поэтому разница в сообщениях важна - она позволяет избежать лишних непродуманных действий.
В РосНИИРОС регистрируют не только "прямую" зону, но также и "обратную". Это две самостоятельные заявки. Понятие "прямая" зона - это калька с английского - forward zone, а понятие "обратная" зона - reverse zone. "Прямая" зона определяет соответствие доменного имени IP-адресу, в то время, как "обратная" зона определяет обратное соответствие IP-адреса доменному имени.
