3.1.3. Регистрация доменных имен
Для того, чтобы получить зону надо отправить заявку в РосНИИРОС, который отвечает за делегирование поддоменов в пределах домена 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-адреса доменному имени.
- Администрирование в информационных системах
- Глава 1. Информационные процессы в системах управления. Цели, задачи и функции администрирования в информационных системах
- Глава 2. Программное и техническое обеспечение современных ис и технологий управления организацией
- Глава 3. Методология построения администрирования и его средства
- Глава 4. Обеспечение иб в администрировании ис
- Глава 5. Управление конфигурацией и ресурсами ис
- Глава 6. Сетевые службы и их мониторинг
- Глава 7. Управление пользователями, сетевыми службами, дисками, службой печати
- 1.Теория администрирования сетей tcp/ip
- 1.1. Организация сети tcp/ip
- 1.2. Межсетевой обмен в сетях tcp/ip
- 1.3. Основные протоколы стека tcp/ip
- IPing - новое поколение протоколов ip
- 1.4. Принципы построения ip-адресов
- 1.5. Подсети
- 1.6.Порты и сокеты
- 1.7.Основные принципы ip-маршрутизации
- 1.8.Информационные сервисы Internet
- 1.9 Система Доменных Имен
- 1.10 Электронная почта в Internet
- 1.11 Взаимодействие отдельных эвм друг с другом
- 1.12 Обмен файлами. Служба ftp
- 2. Администрирование сетей
- 2.1. Учетные записи и группы безопасности
- 2.1.1. Понятие пользовательской учетной записи
- 2.1.2.Встроенные пользовательские учетные записи Windows 2000/xp
- 2.1.3. Группы безопасности
- 2.1.4.Типы учетных записей
- 2.1.5. Встроенные группы безопасности
- 2.2. Администрирование файлов и папок
- 2.2.1. Режимы доступа к папкам
- 2.2.2. Права доступа
- 2.3.3 Права доступа при копировании (перемещении) файлов.
- 2.3. Сервисы сетей ncp/ip
- 2.3.1. Протокол динамической конфигурации клиентских машин
- Администрирование информационных систем Правила эксплуатации и ответственные за их соблюдение
- Проектирование информационных систем и их приемка
- Защита от вредоносного программного обеспечения
- Обслуживание систем
- Сетевое администрирование
- Защита носителей информации
- Обмен данными и программным обеспечением
- Проблема организации администрирования крупных информационных систем.
- Администрирование в информационных системах
- 1. Ведение. Основные проблемы администрирования сетей tcp/ip и информационных технологий Internet
- 1.1. Организация сети tcp/ip
- 1.2. Подключениe локальной или корпоративной сети к Internet
- 1.3. Маршрутизация в сетях tcp/ip
- 1.4. Система доменных имен
- 1.5. Обмен электронной почтой
- 1.6. Организация информационного обслуживания на основе технологий Internet
- 1.7. Проблемы безопасности сетей tcp/ip
- 2. Основы межсетевого обмена в сетях tcp/ip
- 2.1. Структура стека протоколов tcp/ip
- 2.2. Основные протоколы стека tcp/ip
- 2.2.1. Протоколы slip и ppp
- 2.2.2. Протокол arp. Отображение канального уровня на уровень межсетевого обмена
- 2.2.3. Протокол ip
- 2.8. Формат пакета Ipv4
- 2.2.4. IPing - новое поколение протоколов ip
- 2.3. Принципы построения ip-адресов
- 2.4. Подсети
- 2.5. Порты и сокеты
- 2.6. Основные принципы ip-маршрутизации
- 2.7. Настройка операционной системы и сетевые интерфейсы
- 2.8. Настройка сетевых интерфейсов
- 2.8.1. Настройка Ethernet-интерфейса
- 2.8.2. Настройка slip
- 2.8.3. Настройка интерфейса ppp
- 2.9. Маршрутизация, протоколы динамической маршрутизации, средства управления маршрутами
- 2.9.1. Статическая маршрутизация
- 2.9.2. Динамическая маршрутизация
- 2.9.3. Программа routed
- 2.9.4. Программа gated
- 2.10 Анализ и фильтрация tcp/ip пакетов
- 3. Информационные сервисы Internet
- 3.1. Система Доменных Имен
- 3.1.1. Принципы организации dns
- 3.1.3. Регистрация доменных имен
- 3.1.4. Серверы доменных имен и механизм поиска ip-адреса
- 3.1.5. Настройка resolver
- 3.1.6. Программа named
- 3.1.6.1. Файлы настройки named
- 3.1.6.2. Запись "Start Of Authority"
- 3.1.6.3. Запись "Name Server"
- 3.1.6.4. Адресная запись "Address"
- 3.1.6.5. Запись Mail eXchanger
- 3.1.6.6. Запись назначения синонима каноническому имени "Canonical Name"
- 3.1.6.7. Записи типа "Pointer"
- 3.1.6.8. Запись типа hinfo
- 3.1.6.9. Запись определения информационных сервисов "Well Known Services"
- 3.1.6.10. Команды описания зоны
- 3.1.6.11. Файлы описания зоны
- 3.1.7. Примеры настроек программы named и описания зон
- 3.1.7.1. Небольшой поддомен в домене ru
- 3.1.7.2. Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях
- 3.1.7.3. Делегирование поддомена внутри домена
- 3.1.8. Программа nslookup
- 3.1.9. Dns и безопасность
- 3.2. Электронная почта в Internet
- 3.2.1. Принципы организации
- 3.2.2. Формат почтового сообщения (rfc-822)
- 3.2.3. Формат представления почтовых сообщений mime и его влияние на информационные технологии Internet
- 3.2.3.1. Поле версии mime (mime-Version)
- 3.2.3.2. Поле типа содержания тела почтового сообщения (Content-Type)
- 3.2.3.3. Поле типа кодирования почтового сообщения (Content-Transfer-Encoding)
- 3.2.3.4. Дополнительные необязательные поля
- 3.2.4. Протокол обмена почтой smtp (Simple Mail Transfer Protocol)
- 3.2.5. Интерфейс Eudora
- 3.2.6. Системы почтовой рассылки (программа sendmail)
- 3.2.6.1. Принцип работы программы sendmail
- 3.2.7. Настройка программы sendmail
- 3.2.7.1. Тестирование Sendmail и способы запуска
- 3.3. Эмуляция удаленного терминала. Удаленный доступ к ресурсам сети
- 3.3.1. Протокол Telnet
- 3.3.2. Интерфейс пользователя (telnet) и демон (telnetd)
- 3.3.2.1. Программа-сервер (telnetd)
- 3.3.2.2. Программа-клиент (telnet)
- 3.3.3. Организация модемных пулов, настройка оборудования. Квоты пользователей
- 3.4. Обмен файлами. Служба архивов ftp
- 3.4.1. Типы информационных ресурсов
- 3.4.2. Протокол ftp
- 3.4.3. Сервер протокола - программа ftpd
- 3.5. Администрирование серверов World Wide Web
- 3.5.1. История развития, отцы-основатели, современное состояние
- 3.5.2. Понятие гипертекста
- 3.5.3. Основные компоненты технологии World Wide Web
- 3.5.4. Архитектура построения системы
- 3.5.4.1. Язык гипертекстовой разметки html
- 3.5.4.2. Принципы построения и интерпретации html
- 3.5.5. Протокол обмена гипертекстовой информацией (HyperText Transfer Protocol, http 1.0.)
- 3.5.5.1. Форма запроса клиента
- 3.5.5.2. Методы доступа
- 3.5.5.3. Ответ сервера
- 3.5.5.4. Защита сервера от несанкционированного доступа
- 3.5.6. Universal Resource Identifier - универсальный идентификатор. Спецификация универсального адреса информационного ресурса в сети
- 3.5.6.1. Принципы построения адреса www
- 3.5.6.2. Схемы адресации ресурсов Internet
- 3.5.7. Common Gateway Interface - средство расширения возможностей технологии World Wide Web
- 3.5.7.1. Механизмы обмена данными
- 3.5.7.2. Практика применения скриптов cgi
- 3.5.8. Выбор и установка сервера протокола http и другого программного обеспечения базы данных World Wide Web
- 3.5.8.1. Структура базы данных сервера www
- 3.5.8.2. Редакторы html-документов
- 3.5.8.3. Графические редакторы и их особенности
- 3.5.8.4. Серверы протокола http
- 3.5.8.5. Выбор, установка и настройка сервера
- 3.5.8.6. Обслуживание запросов
- 3.5.9. Организация информационной службы на основе технологии World Wide Web
- 3.5.9.1. Статистика доступа к системе и ее анализ
- 3.6. Информационно-поисковые системы Internet
- 3.6.1. Архитектура современных информационно-поисковых систем World Wide Web
- 3.6.2. Информационные ресурсы и их представление в информационно-поисковой системе
- 3.6.3. Информационно-поисковый язык системы
- 3.6.4. Типы информационно-поисковых языков
- 3.6.5. Традиционные информационно-поисковые языки и их модификации
- 3.6.6. Информационно-поисковые языки Internet
- 3.6.7. Интерфейс системы
- 5. Литература
- Администрирование сети и сервисов internet учебное пособие
- Содержание
- Введение в ip-сети
- Принципы построения составных сетей
- Локализация трафика и изоляция сетей
- Согласование протоколов канального уровня
- Маршрутизация в сетях с произвольной топологией
- Сетевой уровень и модель osi
- Функции сетевого уровня
- Протоколы передачи данных и протоколы обмена маршрутной информацией
- Стек протоколов tcp/ip История и перспективы стека tcp/ip
- Структура стека tcp/ip. Краткая характеристика протоколов
- Адресация в ip-сетях Типы адресов: физический (mac-адрес), сетевой (ip-адрес) и символьный (dns-имя)
- Три основных класса ip-адресов
- Соглашения о специальных адресах: broadcast, multicast, loopback
- Отображение физических адресов на ip-адреса: протоколы arp и rarp
- Отображение символьных адресов на ip-адреса: служба dns
- Автоматизация процесса назначения ip-адресов узлам сети - протокол dhcp
- Протокол межсетевого взаимодействия ip
- Формат пакета ip
- Управление фрагментацией
- Маршрутизация с помощью ip-адресов
- Пример взаимодействия узлов с использованием протокола ip
- Структуризация сетей ip с помощью масок
- Протокол доставки пользовательских дейтаграмм udp
- Зарезервированные и доступные порты udp
- Мультиплексирование и демультиплексирование прикладных протоколов с помощью протокола udp
- Формат сообщений udp
- Протокол надежной доставки сообщений tcp
- Сегменты tcp
- Порты и установление tcp-соединений
- Концепция квитирования
- Реализация скользящего окна в протоколе tcp
- Выбор тайм-аута
- Реакция на перегрузку сети
- Формат сообщений tcp
- Протокол обмена управляющими сообщениями icmp Общая характеристика протокола icmp
- Формат сообщений протокола icmp
- Сообщения о недостижимости узла назначения
- Перенаправление маршрута
- Протоколы обмена маршрутной информацией стека tcp/ip
- Дистанционно-векторный протокол rip
- Комбинирование различных протоколов обмена. Протоколы egp и bgp сети Internet
- Протокол состояния связей ospf
- Развитие стека tcp/ip: протокол iPv.6
- Администрирование информационных систем (tcp/ip)
- Преподаватели
- Аннотация
- Знания и умения, полученные в результате обучения
- Зачет и экзамен
- Требования к начальному уровню знаний
- Программа курса
- Полезные Интернет-ссылки