Как правило, никто не подключается к сети Internet по выделенному каналу не имея даже минимального опыта работы в Internet и представления о том, что это такое. Практически любой квалифицированный пользователь сети Internet знает о том, что в этой сети существуют два способа указать хост, к ресурсам которого необходимо получить доступ. Это либо указание его цифрового IP адреса (например, 194.87.0.8), либо указание доменного имени (например, ns.demos.su). Естественно, первая форма менее удобна для человека, так как запомнить некое символическое имя гораздо проще, чем последовательность из четырех чисел. Компьютер, в отличие от человека, "предпочитает" в данном случае работать с цифрами.
DNS, как прикладная система, выполняет несколько функций, наиболее
известными из которых являются:
- определение IP адреса(ов) хоста по его доменному имени;
- определение доменного имени хоста по его IP адресу;
- определение хоста, на который должна пересылаться электронная почта
для заданного адресата.
DNS является распределенной иерархической системой. Вы храните у себя необходимые для работы DNS данные о Вашем домене, а на более высоких уровнях иерархии доменов проставляются ссылки, двигаясь по которым можно эти данные найти.
До тех пор, пока Вы не настроите у себя DNS и не делегируете необходимые домены, Ваши компьютеры не будут известны внешнему миру по символическим именам. Кроме этого, многие общедоступные сервера в Internet'е блокируют доступ к себе с хостов, не прописанных должным образом в DNS. Эти факторы ограничивают Вашу работу в сети. Как правило, настройка DNS является первой задачей, которую Вам необходимо решить.
Список и порядок действий, необходимых для делегирования домена, в общем
случае, следующий:
- создание primary nameserver'а;
- размещение secondary Вашей зоны;
- делегирование домена.
Пока Вы не настроили DNS у себя, вы можете пользоваться нашим DNS-сервером (nameserver'ом) для получения необходимых Вам данных. Все операционные системы позволяют использовать внешний nameserver, а для некоторых операционных систем такой путь является единственным возможным. Для использования внешнего nameserver'а необходимо указать его IP адрес(а) в соответствующих настройках Вашей операционной системы (для Unix'а это файл /etc/resolv.conf). Наш nameserver имеет IP адреса 194.87.0.8 и 194.87.0.9.
Более подробная информация о принципах функционирования DNS и его настройке находится в соответствующих RFC и руководству по Вашей операционной системе.
Работоспособность DNS является довольно критичным фактором для работы остальных прикладных служб. Поэтому nameserver должен работать и быть доступен постоянно.
При планировании Вашей сети обязательно учтите, что смена IP адреса вашего primary nameserver'а повлечет за собой необходимость перерегистрации Ваших доменов и перенастройку программного обеспечения на других компьютерах в сети. Поэтому, зарезервируйте для nameserver'а IP адрес, который, по возможности, будет закреплен за ним навсегда.
Возможным решением (если это устойчиво работает в Вашей операционной системе) является резервирование для nameserver'а специального IP адреса, отличного от основного IP адреса компьютера, на котором он будет функционировать, и назначение этого адреса одному из интерфейсов при помощи опции alias в команде ifconfig (в операционной системе Unix). В этом случае, при переносе nameserver'а на другой компьютер достаточно лишь удалить этот адрес со старого компьютера и сконфигурировать его на новом.
Описание действий по настройке необходимых для функционирования primary nameserver'а программ и созданию и размещению файлов, описывающих Ваш домен, Вы можете найти в руководстве по Вашей операционной системе и различных RFC. Наиболее часто встречающиеся ошибки описаны в RFC-1537
Предположим, необходимо создать файл с зоной для домена NNN.RU, в котором для поддержки DNS, приема почты, WWW и FTP серверов используется некий компьютер (server.nnn.ru) с IP адресом 194.87.3.2 из полученной для подключения к Демосу сети 194.87.3.0/24. Остальные компьютеры (host1.nnn.ru, host2.nnn.ru, host3.nnn.ru) имеют адреса 194.87.3.3, 194.87.3.4 и 194.87.3.5 соответственно. Для приема и передачи почты используются адреса типа user@nnn.ru. Ниже приведен пример файла с зоной (для программы named), не содержащий ошибок.
nnn.ru. IN SOA server.nnn.ru. hostmaster.nnn.ru. ( 19970601 ; Serial 28800 ; Refresh 8 hours 7200 ; Retry 2 hours 604800 ; Expire 7 days 86400 ) ; Minimum TTL 1 day IN NS server.nnn.ru. ; primary IN NS ns.demos.su. ; secondaries IN NS ns1.demos.net. IN MX 10 server.nnn.ru. localhost IN A 127.0.0.1 server IN A 194.87.3.2 IN MX 10 server.nnn.ru. www IN CNAME server.nnn.ru. ftp IN CNAME server.nnn.ru. host1 IN A 194.87.3.3 host2 IN A 194.87.3.4 host3 IN A 194.87.3.5
Размещение secondary Ваших зон на
nameserver'ах Демоса
Для установки secondary на наших серверах, заполните соответствующую заявку и пошлите ее по электронной почте по адресу dol-mnt@dol.ru. Нажмите сюда чтобы получить форму заявки и инструкции по ее заполнению. Эта же заявка используется и для удаления secondary Вашей зоны с наших серверов.
Если Ваш primary nameserver работает правильно, и зона не содержит ошибок, secondary для нее будут размещены на серверах ns.demos.su и ns1.demos.net .
Делегирование домена производится только после того, как будет обеспечено размещение зоны на всех nameserver'ах.
Для делегирования домена необходимо оформить и послать заявку по соответствующей форме в организацию, отвечающую за делегирование доменов в выбранной иерархии. Форма заявки и адрес, по которому ее надо посылать, могут различаться в зависимости от домена.
Если Вы не знаете к кому обратиться по вопросам, связанным с делегированием домена в той или иной иерархии, воспользуйтесь утилитами nslookup или dig в ОС Unix или их аналогами в других операционных системах для того, чтобы узнать содержимое SOA записи для вышестоящего домена. Например, если Вы хотите узнать к кому обратиться с вопросами о делегирования домена в иерархии ORG.RU, Вы можете сделать это следующим образом:
% nslookup
Default Server: server.nnn.ru
Address: 0.0.0.0
> set type=soa
> org.ru.
Server: server.nnn.ru
Address: 0.0.0.0
Non-authoritative answer:
org.ru
origin = ns.ripn.net
mail addr = hostmaster.ripn.net
serial = 100019
refresh = 86400 (1 day)
retry = 14400 (4 hours)
expire = 2592000 (30 days)
minimum ttl = 345600 (4 days)
Authoritative answers can be found from:
org.ru nameserver = ns.ripn.net
org.ru nameserver = ns.ussr.eu.net
ns.ripn.net internet address = 144.206.2.1
ns.ussr.eu.net internet address = 193.124.22.65
>^D
%
Это означает, что Вы можете обратиться к hostmaster@ripn.net
с вопросами, связанными с делегированием домена в иерархии
ORG.RU. Значение параметров записи SOA изложено в соответствующей
документации.
Технические и административные процедуры, связанные с ведением домена RU, выполняет Российский НИИ развития общественных сетей (РосНИИ РОС).
Вы можете выполнять все необходимые действия по составлению завок и оплате доменов в зоне RU самостоятельно или поручить это нам. Если вы хотите воспользоваться нашими услугами, ознакомьтесь с инструкциями.
Делегирование доменов в зонах COM, NET, ORG производит Network Solutions Inc.
В географических зонах msk.su и
msk.ru
Делегирование доменов в зонах msk.su и msk.ru осуществляет ООО "Релком.ДС"
В других российских доменах общего
пользования
В этом случае для того, чтобы узнать к кому обратиться с вопросами о делегировании домена, необходимо проанализировать SOA запись для этого домена (см. пример выше). Организации, ведущие домены общего пользования, обязаны регистрировать домены независимо от того, кто их запрашивает, если соблюдены Правила регистрации доменов, действующие в данной иерархии.
Делегирование и администрирование
публичных зон
Возможно, что у Вас возникнет желание взять на себя администрирование какой-либо географической зоны. Например, если Вы, являясь узлом сети Relcom, переходите с UUCP на IP и уже имеете клиентов. Естественно, в этом случае, Вам может быть удобнее администрировать географический домен самостоятельно. Однако учтите, что администрирование такого домена не только дает право самостоятельно делегировать домены следующего уровня, но и обязывает Вас делегировать домены по заявкам всех, кому такие домены могут понадобиться.
Если географический домен, администрирование которого Вы желаете взять на себя, поддерживается АО Релком, заранее согласуйте процедуру его передачи Вам. Для этого обратитесь к noc@relcom.eu.net. Учтите, что при передаче домена Вам необходимо сохранить уже имеющиеся в зоне записи.
Делегирование обратной (IN-ADDR.ARPA)
зоны
Общий порядок действий при делегировании обратных зон аналогичен
процедуре делегирования прямых зон. Вам необходимо:
- разместить зону на Вашем primary сервере;
- добиться размещения зоны на предполагаемых secondary серверах;
- послать соответствующую заявку на делегирование домена по правильному
адресу, дождаться положительного ответа и проверить делегирование.
Для сетей из провайдерских
блоков Демоса
Для делегирования IN-ADDR.ARPA зоны, соответствующей сети из провайдерских блоков Демоса ( блоки 194.87.0.0/16 и 195.133.0.0/16), необходимо оформить заявку согласно документу RIPE-185 и послать ее по адресу noc@demos.net.
Обращайтесь в организацию, в которой получено адресное пространство. Опять же, некоторую информацию можно получить по SOA записи для зоны, стоящей в DNS на ступеньку выше.
Замечания для сетей, меньших чем
class C
Делегирование IN-ADDR.ARPA зон для сетей, меньших чем class C, является чуть более сложной процедурой, которая описана в документе IETF Classless IN-ADDR.ARPA delegation.
В заявке на делегирование IN-ADDR.ARPA зоны для сети из провайдерского блока Демоса в поле domain Ваша зона указывается как < адрес подсети> /< длина маски> .< зона, соответствующая сети класса C>", например, для сети 194.87.72.0/26 это будет выглядеть как 0/26.72.87.194.in-addr.arpa
Собственно сложность работы с IN-ADDR.ARPA зонами для такого рода сетей
обусловлена, в частности, тем, что текущая техническая процедура, описанная
в вышеупомянутом документе IETF может показаться своего рода "затычкой"
и далека от изящности. Одним из отрицательных моментов этого является то, что
nameserver, на котором поддерживается такая IN-ADDR.ARPA зона для такой
сети, сам не в состоянии получить имя хоста из его IP адреса для "локальных"
компьютеров без участия nameserver'а, на котором производится делегирование.
Это происходит потому, что в его файлах конфигурации в итоге присутствуют
только записи типа
2.0/26.72.87.194.IN-ADDR.ARPA. IN PTR host.domain. а не записи типа
2.72.87.194.IN-ADDR.ARPA. IN PTR host.domain.
которых не существует вовсе. Для того, чтобы по IP адресу получить имя
хоста, необходимо "знать" о существовании записи типа
2.72.87.194.IN-ADDR.ARPA IN CNAME 2.0/26.72.87.194.IN-ADDR.ARPA.
которая, в свою очередь, содержится на nameserver'е, на котором выполняется
делегирование зоны. Следствием этого может явится нарушение
работоспособности nameserver'а даже с точки зрения обслуживания локальных
клиентов при потере связи с внешним миром. Одним из решений, позволяющим
"обойти" эту проблему, является наличие на локальном nameserver'е
secondary для "вышестоящей" зоны. В нашем примере - зоны
72.87.194.IN-ADDR.ARPA (а если таковой не существует, то
87.194.IN-ADDR.ARPA).
Иногда требуется изменить набор nameserver'ов для какого-либо домена. Сохранение домена при смене провайдера является частным случаем, когда это может потребоваться.
Общий порядок действий в этом случае следующий:
- предупредить администраторов nameserver'ов, с которых Вы планируете
удалить зону, об этом намерении;
- создать новый набор nameserver'ов;
- отправить на соответствующий адрес заявку на переделегирование домена,
оформленную по соответствующей форме (обратив, если нужно, внимание
на изменение glue записей);
- дождаться переделегирования домена;
- подождать, пока старые NS записи исчезнут из кэшей nameserver'ов по всему
миру (это время должно соотвествовать TTL, определенному в зоне на старых
nameserver'ах);
- добиться удаления primary и secondary зоны со всех nameserver'ов, которые
перестали быть таковыми.
Администрирование и поддержка Вашего домена
Как уже было сказано, нормальная работа DNS критична для остальных приложений. Поэтому, необходимо все изменения в зоны вносить аккуратно и регулярно проверять работу DNS.
При запуске программы named в Unix'е, сообщения о синтаксических ошибках в файлах зон выводятся согласно настройкам syslogd (см. /etc/syslog.conf). Не забывайте просматривать эти сообщения.
Проверка secondary nameserver'ов
Регулярно проверяйте копии Ваших зон на secondary nameserver'ах на предмет их наличия и совпадения с оригиналом, хранящимся на primary.
Довольно распространенной ошибкой является установка на primary nameserver'е значения Serial, меньшего, чем текущее значение на secondary. Следствием этого является прекращение обновления зоны на secondary nameserver'ах. Если Вы по каким-либо причинам не можете снова увеличить значение Serial на primary, свяжитесь с администраторами всех secondary и попросите вручную перечитать (удалить файл, затем перезапустить named) Вашу зону. Если Ваши secondary расположены на Демосе, пишите по адресу noc@demos.net.
Средства для проверки и отладки
Существуют специальные программы, облегчающие контроль за работоспособностью
DNS и поиск ошибок. Они описаны в
RFC-1713.