Origin
- это доменное имя primary master сервера зоны. В случае описания зоны kyky.ru в качестве сервера используется машина ns.kyky.ru. Данное доменное имя и должно быть указано в поле origin.
Очень часто в этом поле можно встретить имена, которые начинаются с "ns", например, ns.kiae.su или ns.relarn.ru. В данном случае это означает только то, что primary master сервер зоны размещен на машине с таким именем. Никого специального зарезервированного имени для указания в поле origin нет. Использование, указанных выше имен обосновано тем, что их просто легче запомнить, т.к. "ns" означает "name server".
Довольно часто администраторы зон, которые делегируют части своих зон другим организациям, в ультимативной форме требуют, чтобы имя primary master не совпадало с именем зоны.
Elz и Bush в RFC-2181 отмечали, что это требование повсеместно нарушается и практически является бесполезным. Кроме того, существует документ (ripe-203), в котором написано, что данное требование (отличие имени primary master сервера от имени зоны в SOA) справедливо, за исключением случая, когда доменное имя зоны связано адресной записью с IP-адресом primary master этой зоны. Для небольших зон это случается сплошь и рядом, т.к. и primary master зоны и почтовый транспортный агент и прочие сервисы в мелких организациях устанавливаются на одной и той же машине.
Требование, однако, справедливо при заполнении интерактивных форм регистрации домена, т.к. система в момент регистрации не имеет ни малейшего понятия о том, что администратор зоны напишет в файле описания зоны, т.е. гарантии того, что имя зоны и имя primary master сервера совпадают, в момент регистрации домена нет.
Поле
Вообще говоря, основное назначение $ORIGIN - это упрощение содержания файла описания зоны при определении поддоменов в той же зоне, где описан и выше стоящий домен:
$ORIGIN kyky.ru. ns IN A 192.168.0.1 www IN A 192.168.0.2 $ORIGIN sub1.kyky.ru. host1 IN A 192.168.0.3 host2 IN A 192.168.0.4 $ORIGIN sub2.kyky.ru. host1 IN A 192.168.0.5 host2 IN A 192.168.0.6
В приведенном выше примере мы завели два поддомена в домене kyky.ru, при чем именование машин в них одинаковое, но полные доменные имена различаются, что и не удивительно.
Еще несколько лет назад довольно часто можно было видеть в файлах описания зон следующую картину:
@ IN SOA ns.kyky.ru. adm.kuku.ru. ( 1 2h 30m 2d 30m ) IN NS ns.kyky.ru. IN NS ns.provider.ru. ns IN A 192.168.0.2 $ORIGIN provider.ru. ns IN A 192.168.10.5
Что тут не так? Формально все верно. Для зоны kyky.ru должно быть определено два сервера доменных имен с независимым подключением к сети, т.к. речь идет о корпоративном домене.
Первый сервер определен в сети компании и имеет имя ns.kyky.ru, а второй сервер - это сервер провайдера, который обеспечивает дублирование, т.е. ns.kyky.ru - это master, а ns.provider.ru - это slave.
Вся штука в том, что имя ns.provider.ru не принадлежит домену kyky.ru. На самом деле наш сервер не является авторитативным для зоны provider.ru, поэтому он не вправе отвечать на запросы к этой зоне.
Тем не менее, существует процедура делегирования зон ответственности, и там возникает ситуация, когда IP-адрес сервера доменных имен нельзя получить иначе, как из зоны, в которой описано делегирование.
В этом случае отклик нашего сервера называют рефералом (refferal) и он содержит IP-адреса серверов доменных имен в качестве дополнительной информации. Эти адресные записи принято называть присоединенными (glue - буквально "приклеенные").
Так вот, присоединять адресную запись для ns.provider.ru нет смысла, т.к. ее можно найти в другой зоне. Более того, там она может оказаться более свежей, чем у нас, и указывающей совсем на другой адрес.Присоединяют только те записи, информацию о которых иначе получить просто нельзя, например, адреса серверов доменных имен, чьи имена находятся в делегируемой нами зоне.
Новые версии BIND (4.9 и выше) отслеживают этот момент, а вот более старые версии такой проверки не делают. Администраторы системы доменных имен включали такие "приклеенные" записи для того, чтобы сэкономить на трафике (нет нужды опрашивать серверы доменных имен).
О "приклеенных" записях подробно поговорим позже при описании адресных и NS записей.
Директива
