3.1.6.2. Запись "Start Of Authority"
Перейдем теперь к описанию форматов записей описания ресурсов. Такое описание по традиции начинают с записи SOA (Start Of Authority). Запись SOA отмечает начало описания зоны. Обычно, это первая запись описания зоны. Некоторые авторы, в частности, упоминавшийся ранее Kavli, рекомендуют наличие одной и только одной записи типа SOA в каждом файле, который указан в записи primary файла named.boot.
Формат записи SOA можно представить как:
[zone] [ttl] IN SOA origin contact ( serial refresh retry expire minimum )
В этой записи каждое из полей обозначает следующее:
Поле zone - имя зоны. Если речь идет о зоне, описанной в записи primary файла named.boot, то в качестве имени употребляется символ коммерческого эй - "@". В этом случае в качестве имени текущей зоны берется имя, указанное в качестве первого аргумента команды primary из файла named.boot. Поле зоны обязательно должно быть указано. Иначе named не сможет привязать следующие за данной записью описания к имени зоны. Пустое имя зоны не является допустимым.
Поле ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается последним аргументом данных записи SOA.
Поле origin - это доменное имя primary сервера зоны. В случае описания зоны vega.ru в качестве сервера используется машина vega-gw.vega.ru. Данное доменное имя и должно быть указано в поле origin. Очень часто в этом поле можно встретить имена, которые начинаются с "ns", например, ns.kiae.su или ns.relarn.ru. В данном случае это означает только то, в данных зонах существуют машины с именем "ns", и на них размещены primary серверы этих зон. Никакого специального зарезервированного имени для указания в поле origin нет. Использование, указанных выше имен обосновано тем, что их просто легче запомнить, т.к. "ns" означает "name server".
Поле contact определяет почтовый адрес лица, осуществляющего администрирование зоны. Данный адрес должен совпадать со значением адреса указанным в заявке на домен в поле "zone-c:". Есть, однако, одна особенность при указании этого адреса. Так как символ "@" имеет особый смысл при описании зоны, то вместо этого символа в почтовом адресе используется символ ".". Например, если ваш покорный слуга выступает администратором домена, то в поле contact следует писать не paul@kiae.su, а paul.kiae.su. Если в имени пользователя есть какие-либо особые символы, имеющие специальные значения при описании зоны, то они должны маскироваться символом обратного слэша - "\". Типичный пример - почтовый адрес типа user.name@kuku.ru. В этом случае точку следует замаскировать и написать в поле contact: user\.name.kuku.ru. Поступая таким образом мы исключили особое значение точки как разделителя поддоменов и обеспечили интерпретацию имени как единой символьной строки.
Поле данных в записи SOA разбито на аргументы, которые определяют порядок работы сервера с записями описания зоны. Как правило все аргументы располагают на другой строке или, для лучшего отображения каждый на своей строке, что заставляет записывать их внутри скобок.
Атрибут serial - определяет серийный номер файла зоны. Если говорить проще, то в этом поле ведется учет изменений файла описания зоны. Поле может состоять из восьми десятичных цифр. В принципе это могут быть любые числа, но чаще всего администраторы используют в качестве серийного номера год, месяц и день внесения изменений в файл описания зоны. Честно говоря, я предпочитаю просто порядковые имена. Во-первых, не будет проблемы 2000 года, о которой так много сейчас говорят, а во-вторых, в данный момент наша сеть довольно интенсивно растет, что заставляет делать изменения по нескольку раз на дню. Простое увеличение номера решает все эти проблемы. Важность серийного номера определяется тем, что когда вторичный (secondary) сервер обращается к первичному (primary) серверу для обновления информации о зоне, то он сравнивает серийный номер из своего кэша с серийным номером из базы данных первичного сервера. Если серийный номер из primary сервер больше, то secondary сервер обращается к primary и копирует описание всей зоны целиком, если нет, то он не вносит изменений в свою базу данных. Таким образом, когда производятся изменения в базе данных primary сервера, то значение атрибута serial в поле данных записи SOA для зоны, описание которой было изменено, должно быть увеличено. Неизменение номера - это типичная ошибка, на которой автор не раз себя ловил.
Атрибут refresh определяет интервал времени после которого secondary сервер обязан обратиться к primary серверу с запросом на верификацию своего описания зоны. Как уже ранее было сказано при этом проверяется серийный номер описания зоны. Описание зоны загружается secondary сервером каждый раз когда он стартует или перегружается. Однако, при стабильной работе может пройти достаточно большой интервал времени, пока эти события не произойдут в действительности. Кроме того, большинство систем, которые поддерживают сервис доменных имен, работают круглосуточно. Следовательно, необходим механизм синхронизации баз данных primary и secondary серверов. Поле refresh задает интервал после которого эта синхронизация автоматически выполняется. Длительность интервала указывается в секундах. В поле refresh можно указать до восьми цифр. Указание маленькой цифры приведет к неоправданной загрузке сети, ведь в большинстве случае описание зон довольно стабильно, но в ряде случаев, когда зона только организуется, можно указать и небольшой интервал. Наиболее типичным является синхронизация состояния описания зон один (86400) - два (43200) раза в сутки.
Атрибут retry начинает играть роль тогда, когда primary сервер по какой-либо причине не способен удовлетворить запрос secondary сервера за время определенное атрибутом refresh. А точнее, в момент наступления времени синхронизации описания зоны, primary сервер не отвечает на запросы secondary сервера. Атрибут retry определяет интервал времени после которого secondary сервер должен повторить попытку синхронизовать описание зоны с primary сервером. Значение этого атрибута также может состоять максимум из восьми цифр. При установке этого значения во внимание следует принимать несколько факторов. Во-первых, если primary сервер не отвечает, то, скорее всего произошло что-то серьезное (отделочники вырезали часть сети, т.к. мешала красить стены, экскаватор перекопал магистраль или отключили питание в сети). Такая причина не может быть быстро устранена, поэтому установка слишком малого времени опроса просто зря нагружает сеть. Во-вторых, если на primary сервер прописано много зон, и он обслуживает большое количество запросов, то он может просто не успеть ответить на запрос, а очень частые запросы от secondary сервера просто "подливают масло в огонь" ухудшая и так медленную работу сервера. Обычно значение этого атрибута устанавливают равным одному часу (3600).
Атрибут expire определяет интервал времени, после которого secondary должен прекратить обслуживание запросов к зоне, если он не смог в течении этого времени верифицировать описание зоны, используя информацию с primary сервера. Обычно это интервал делают достаточно большим, скажем полтора месяца (3888000). Если сделать маленький интервал, то какой смысл в secondary сервере, если он скоропостижно скончается после отключения primary сервера. В течении всего этого времени secondary сервер будет пытаться установить контакт c primary сервером и обслуживать запросы к зоне. Правда все эти соображения хороши для случая, когда просто отключится или ломается машина, на которой стоит primary сервер. Если же отключится вся сеть, которая описана в зоне, а для большинства организаций так оно и есть, то secondary сервер становится подобным космическому аппарату "Пионер", который путешествует во Вселенной, давно потеряв всякую связь с Землей.
Последний атрибут из поля данных записи SOA - minimum. Он определяет время хранения записи описания ресурса в кэше удаленной машины, т.е. значение поля ttl по умолчанию для всех записей описания зоны. Именно по этой причине поле ttl в записи SOA остается пустым. Данное поле влияет на то, как часто удаленные серверы будут обращаться к серверу описания зоны за информацией. Хорошим тоном считается установка значения в этом поле не меньше, чем значения в поле expire. Иногда указывают вообще максимально возможное значение - 99999999. Маленькое значение будет приводить к непроизводительной загрузке сети - ведь соответствия межу IP-адресами меняются очень редко.
Обратите внимание на то, что все атрибуты записи SOA определяют порядок взаимодействия primary сервера и secondary серверов. Исключение составляет только атрибут minimum. В данном случае речь идет о кэшировании адресов не сервером, а системой resolver. Однако, в большинстве случаев эта разница не проявляется. Дело в том, что в качестве resolver на локальной вычислительной установке выступают функции из стандартной библиотеки, которые направляют запросы к локальному серверу доменных имен и сами не осуществляют кэширования соответствий между именами и IP-адресами. В этом случае кэширование осуществляется локальным сервером доменных имен. В том случае когда на машине запускается свой кэширующий сервер, который не описывает никакой зоны, а используется только для обслуживания запросов к сервису доменных имен, именно он и является той частью resolver, которая кэширует соответствия.
Таким образом, когда речь идет об атрибуте minimum, то чаще всего его описывают в контексте программы named, которая может использоваться не только как primary или secondary сервер, но и как кэширующий сервер. В этом случае поле ttl записи описания ресурса и атрибут minimum задают время хранения записи описания ресурса в кэше.
Приведем пример записи типа SOA:
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
99999999 ) ; default ttl is set to maximum value
В данном примере имя зоны берется из записи primary файла named.boot, поэтому в поле имени зоны указан символ "@". В качестве сервера для зоны используется машина с именем vega-gw.vega.ru. Почтовый адрес ответственного за зону - paul@kiae.su. Открывающаяся скобка говорит о том, что описание записи SOA будет продолжено на следующих строках. Каждая из последующих строк описывает один атрибут из поля данных записи SOA. При этом обратите внимание на то, что символ ";" маскирует весь остаток строки для интерпретации программой named, т.е. комментарий начинается с символа ";" и заканчивается символом перехода на новую строку. Атрибут serial определяет данную 101-ю версию описания зоны, атрибут refresh устанавливает периодичность опроса primary сервера secondary сервером как один раз в сутки, в случае неудачи secondary сервер начинает опрашивать primary сервер каждый час и, если восстановить взаимодействие не удается, то через 45 дней secondary сервер перестает обслуживать запросы к данной зоне. Информация о соответствии доменных имен IP-адресам должна храниться в кэше resolver или удаленного сервера максимально возможное время.
3.1.6.3. Запись "Name Server"
Запись NS используется для обозначения сервера, который поддерживает описание зоны. Эта запись позволяет делегировать поддомены, поддерживая тем самым иерархию доменов системы доменных имен Internet. Для того, чтобы домен был виден в сети в зоне описания домена старшего уровня должна быть указана запись типа NS для этого поддомена. Формат записи NS можно записать в виде:
[domain][ttl] IN NS [server]
В поле domain указывается имя домена, для которого сервер, указанный последним аргументом записи NS поддерживает описание зоны. Значение поля ttl обычно оставляют пустым, тем самым заставляя named устанавливать значение по умолчанию (поле minimum из записи SOA для данной зоны). При указании имени сервера следует иметь в виду следующие обстоятельства: если в качестве сервера указывается сервер из текущей зоны, то можно обойтись только именем машины, не указывая полное доменное имя этого компьютера, т.к. имя может быть расширено именем домена, но это скорее исключение, чем правило. В записях NS указываются как primary, так и secondary серверы. Последние же скорее всего принадлежат другим зонам, и для них следует указывать полное доменное имя сервера с указанием имени машины и имени зоны. Например, для сервера из домена polyn.kiae.su c именем ns следует писать полностью ns.polyn.kiae.su. Для того, чтобы придерживаться какого-то единого стиля и во избежание ошибок рекомендуется писать всегда полное имя сервера.
Приведем пример записи описывающей делегирование поддомена:
$ORIGIN vega.ru. zone1 IN NS ns.zone1.vega.ru.
В данном примере в качестве первой строки используется команда $ORIGIN, которая определяет имя текущей зоны. Об этой команде поговорим несколько позже. Здесь она введена только для того, чтобы определить текущую зону. В поле имени зоны указано имя zone1 без точки на конце. В данном контексте это означает делегирование зоны в домене vega.ru, полное имя которой будет zone1.vega.ru. В качестве имени сервера, который управляет делегированной зоной указано имя ns.zone.vega.ru, т.е. полное имя машины в делегированном домене. В принципе, в данном случае можно было бы написать и по другому:
$ORIGIN vega.ru. zone1 IN NS ns.zone1
т.к. имя принадлежит текущему домену и может быть расширено его именем.
3.1.6.4. Адресная запись "Address"
Основное назначение адресной записи - установить соответствие между доменным именем машины и IP-адресом. В принципе для разных имен можно установить один и тот же адрес. Адресная запись - это основа файла описания "прямой" зоны. Запись имеет следующий формат:
[host][ttl] IN A [address]
Поле host определяет доменное имя машины. Чаще всего это имя указывается относительно имени текущей зоны, поэтому на конце имени не проставляется символ ".". Если же надо описать машину из другой зоны, то следует указать ее полное доменное имя и не забыть в конце этого имени символ ".". Например, "quest.polyn.kiae.su.", указанное в поле host ссылается на машину с именем quest.polyn.kiae.su. Поле ttl обычно оставляют пустым, а в поле address указывают IP-адрес машины. В этом адресе точку на конце ставить не надо. При делегировании доменов и в самом начале описания зоны возникает проблема описания серверов, поддерживающих базы данных описания зоны и поддоменов. Ведь реально при маршрутизации пакетов по сети нужно знать только IP-адреса, а их-то как раз и не хватает для обращения к серверам поддоменов и к серверу зоны, если он расположен в той же зоне. Для решения этой проблемы используются "приклеенные" (буквально "glue") записи типа "А". При этом вообще-то нет разницы что будет указано раньше использование доменного имени или определение соответствия этого имени IP-адресу.
Приведем пример записи типа A и использование "приклеенных" адресных записей. Во-первых, рассмотрим простую запись типа A:
$ORIGIN vega.ru. vega-gw IN A 194.226.43.1
В данном случае в зоне vega.ru определяется доменное имя для машины с IP-адресом 194.226.43.1. Для каждой машины зоны будет указана такая же запись.
Теперь рассмотрим возможность назначения "приклеенной" записи для сервера зоны для обращений по имени зоны, а не конкретной машины, что бывает полезно при настройке электронной почты.
$ORIGIN vega.ru.
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
99999999 ) ; default ttl is set to maximum value
IN NS vega-gw.vega.ru.
IN A 194.226.43.1
;
vega-gw IN A 194.226.43.1
В данном примере при назначении сервера зоны в записи NS IP-адрес этого сервера еще не определен, но это и не суть важно, главное, чтобы он был определен далее в одной из адресных записей определения. Кроме этого, для обслуживания типа:
/usr/paul>mail paul@vega.ru
"приклеена" еще одна адресная запись, которая назначает текущему домену IP-адрес 194.226.43.1. Формально эта запись определяет адрес для, так называемых, запросов по неполному имени. В данном случае для всех запросов, которые используют имя зоны, определен адрес шлюза, на котором установлено обслуживание всех сервисов, например, http://vega.ru/ или gopher://vega.ru/. Обычно такой подход используют в маленьких сетях для упрощения работы с сервисами этих сетей [Tom Yager].
Другим примером "приклеенной" записи может служить делегирование зон внутри домена. Пусть мы создаем два поддомена zone1 и zone2, серверы которых также расположены в этих же поддоменах:
$ORIGIN vega.ru.
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
99999999 ) ; default ttl is set to maximum value
IN NS vega-gw.vega.ru.
IN A 194.226.43.1
;
vega-gw IN A 194.226.43.1
.........
; Glue address records.
zone1-gw.zone1 IN A 194.226.43.2
zone2-gw.zone2 IN A 194.226.43.3
; Subdomain delegation.
zone1 IN NS zone1-gw.zone1.vega.ru.
zone2 IN NS zone2-gw.zone2.vega.ru.
Данный пример - это расширение предыдущего примера. Сначала мы определили IP-адреса серверов поддоменов в рамках текущего домена, а потом определили их в качестве серверов соответствующих зон нашего домена. При разбиении домена на зоны не следует увлекаться. Запоминать и набивать длинные имена также трудно, как и числа IP-адреса.
3.1.6.5. Запись Mail eXchanger
Данная запись служит для определения адреса почтового сервера. Запись MX может быть определена как для всей зоны, так и для отдельно взятой машины. Запись MX имеет следующий формат:
[name] [ttl] IN MX [prference] [host]
Поле name определяет имя машины или домена, на который может отправляться почта. Это может быть как полностью определенное имя, так и частичное имя машины. Поле ttl обычно оставляют пустым. В поле preference указывается приоритет почтового сервера, указанного последним аргументом в поле данных MX-записи. Запись MX используется следующим образом:
Типичными примерами пересылки почты является работа с почтой UUCP и BITNET. Пересылка касается, как правило, уходящей из домена почты, которая не является проблемой данного домена. В файле настройки sendmail прописывается имя соответствующего шлюза и на этом все заканчивается. Но для российских сетей здесь возможны свои проблемы, которые связаны с переходом от старой почты UUCP, которая активно внедрялась сетью Relcom к системе работы по тому же протоколу, но уже через свой собственный домен. Однако более подробно на этой проблеме мы остановимся в разделе описания настроек программы sendmail.
Приведем пример использования записей MX:
$ORIGIN vega.ru.
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
99999999 ) ; default ttl is set to maximum value
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
IN NS polyn.net.kiae.su.
IN A 194.226.43.1
IN MX 10 vega-gw.vega.ru.
IN MX 20 ns.relarn.ru.
IN MX 30 relay.relarn.ru.
*.vega.ru. IN MX 0 vega-gw.vega.ru.
;
vega-gw IN A 194.226.43.1
IN MX 0 vega-gw
IN MX 10 ns.relarn.ru.
IN MX 20 relay.relarn.ru.
В данном примере мы определили несколько записей типа MX для типов почтовой рассылки.
Записи в описании зоны, сразу после A-записи, следующей за записью SOA, определяют пути поступления почты в данный домен. Самый высокий приоритет здесь имеет прямая отправка почты на шлюз vega-gw.vega.ru. Если отправить почту на эту машину не удастся, то почтовый агент должен попробовать путь через почтовый сервер ns.relarn.ru . Если и этот путь окажется невозможным, то почту можно попытаться отправить на пересыльный пункт relay.relarn.ru . Такой порядок опроса почтовых серверов определяется полем preference - чем меньше значение поля, тем выше приоритет сервера в записи MX.
В нашем домене, который мы используем в качестве примера, большинство почтовых ящиков пользователей расположено на машине vega-gw.vega.ru. Для этой машины также указаны несколько записей MX. Наибольший приоритет среди них имеет запись с именем почтового сервера vega-gw. Обратите внимание на то, что данное имя не оканчивается точкой. Это значит, что оно расширяется именем текущей зоны. Все же другие имена серверов - это полностью определенные доменные имена (fully-qualified).
Кроме описанных MX-записей в нашем примере есть еще одна, которая определяет почтовый шлюз для нашего домена - запись с именем "*.vega.ru.". Данная запись введена для того, чтобы определить шлюз по умолчанию для любой машины из нашего домена, если для нее не определен шлюз в ее собственных MX-записях. Главным в этой записи является использование символа "*", который обозначает все возможные имена машин и поддоменов данного домена.
3.1.6.6. Запись назначения синонима каноническому имени "Canonical Name"
Запись CNAME определяет синонимы для реального доменного имени машины, которое определено в записи типа A. Имя в записи типа A называют каноническим именем машины. Формат записи CNAME можно определить следующим образом:
[nickname] [ttl] IN CNAME [host]
Поле nickname определяет синоним для канонического имени, которое задается в поле host.
Запись CNAME чаще всего используется для определения информационных сервисов Internet, которые установлены на машине. Следующий пример определяет синонимы, для компьютера, на котором установлены серверы протоколов http и gopher:
$ORIGIN polyn.net.kiae.su. olga IN A 144.206.192.2 www IN CNAME olga.polyn.kiae.su. gopher IN CNAME olga.polyn.kiae.su.
Как и в предыдущих примерах команда $ORIGIN введена только для определения текущей зоны. Две записи типа CNAME позволяют организовать доступ к серверам, используя имена распределенных информационных систем Internet, в рамках технологий которых работают данные серверы. Именно такие синонимы и используются при обращении к таким системам, как Yahoo (www.yahoo.com) или Altavista (www.altavista.digital.com). Правда при обращении к серверу протокола http, который является базовым для системы World Wide Web, изменение имени машины, с которой осуществляют обслуживание, может быть вызвано многими причинами: перенаправлением запроса на другой сервер, использование виртуального сервера и т.п. (см. раздел "Администрирование баз данных World Wide Web").
При использовании записей типа CNAME следует учитывать, что запись этого типа следует использовать очень аккуратно. Некоторые администраторы рекомендуют вообще от нее отказаться и если нужно еще одно имя, то лучше вообще указать еще одну A-запись для того же самого IP-адреса. В частности запись типа MX может присоединяться только к адресной записи. Если быть более точным, то просто не все почтовые агенты способны обрабатывать записи типа CNAME, т.к. это требует дополнительного обращения к серверу доменных имен. Приведем пример правильного и неправильного использования записи CNAME:
$ORIGIN polyn.net.kiae.su.
olga IN A 144.206.192.2
IN MX 0 olga
IN MX 10 ns.polyn.kiae.su.
www IN CNAME olga.polyn.kiae.su.
gopher IN CNAME olga.polyn.kiae.su.
В данном случае записи типа CNAME указаны правильно, т.к. не мешают переадресации почты на машину olga.polyn.kiae.su. Но если их поменять местами с записями типа MX, то скорее всего почта работать не будет:
$ORIGIN polyn.net.kiae.su.
olga IN A 144.206.192.2
www IN CNAME olga.polyn.kiae.su.
gopher IN CNAME olga.polyn.kiae.su.
IN MX 0 olga
IN MX 10 ns.polyn.kiae.su.
Это будет происходить по следующей причине. Почтовый агент для получения адреса машины абонента почтового сервера в ответ на свой запрос получит запись из базы данных сервера с именем этой машины. Если бы это была запись типа A, то по ней почтовый агент определяет IP-адрес машины-получателя или машины шлюза. Получив этот адрес агент организует взаимодействие по протоколу SMTP и отправляет почтовое сообщение получателю или в очередь почтового агента шлюза. Если же он получил в результате обращения к серверу доменных имен запись типа CNAME, то никакого IP-адреса в ней нет, а следовательно и организовать SMTP-соединение нельзя.
Сами серверы доменных имен для определения IP-адреса используют несколько обращений. Когда получен ответ на запрос, сервер анализирует тип полученной записи, если это запись типа A, то IP-адрес передается системе resolver, если же это запись типа CNAME, то сервер снова запрашивает удаленный сервер на предмет получения новой записи, но уже по новому имени, которое он берет из поля host записи типа CNAME. Если в качестве resolver используется программа named, которая работает как resolver (команда slave в файле named.boot), то в этом случае resolver умеет обрабатывать записи типа CNAME, но в большинстве случаев, как в уже рассмотренном нами случае с электронной почтой, многие системы, которые работают в качестве "мудрых" resolver'ов не умеют анализировать записи типа CNAME, что и заставляет использовать вместо них записи типа A. Кроме того последние имеют еще и то преимущество, что сокращается число запросов к серверу доменных имен, т.к. IP-адрес запрашивающая сторона получает с первой попытки.
В качестве еще одного примера использования записей типа CNAME приведем трассу получения IP-адреса для доменного имени ftp.netscape.com:
ftp.netscape.com. IN CNAME anonftp6.netscape.com. anonftp6.netscape.com. IN CNAME ftp22.netscape.com. ftp22.netscape.com. IN A 204.152.166.45
Как видно из примера при поиске IP-адреса для ftp.netscape.com локальный сервер доменных имен дважды получает в ответ на свой запрос запись типа CNAME.
3.1.6.7. Записи типа "Pointer"
До сих пор мы описывали записи, которые используются главным образом в файле обслуживающем "прямую" зону, т.е. запросы на получение IP-адреса по доменному имени. Но существует, как мы выяснили ранее, и запросы другого типа, когда необходимо по IP-адресу получить доменное имя. Для реализации ответов на эти запросы сервер ведет описание "обратной" зоны, база данных которой состоит, главным образом, из записей типа "Pointer" или P-записей. Формат записи имеет следующий вид:
[name][ttl] IN PTR [host]
Поле name задает номер. Это не реальный IP-адрес машины, а имя в специальном домене in-addr.arpa или в одной из его зон. Существует специальный формат записи имен этого домена. Так, например, машина vega.-gw.vega.ru, которая имеет адрес 194.226.43.1 должна быть описана в домене in-addr.arpa как 1.43.226.194.in-addr.arpa, т.е. адрес записывается в обратном порядке. Так как речь идет о доменной адресации, то разбиение на сети (подсети в данном случае) значения не имеет. Имена обрабатываются точно также, как и обычные доменные имена. Это значит, что систему доменных имен машин этого домена можно представить в виде:
Рис. 3.12. Пример структуры части домена in-addr.arpa
Как видно из рисунка, в данном случае не играет ни какой роли тип сети или разбиение на подсети. Согласно правилам описания доменов и зон в этих доменах, разделителем в имени, которое определяет подчиненное значение зоны в домене, является только символ ".". Согласно этому правилу подсети сети класса B (144.206.0.0) и сеть класса С (194.226.43.0) находятся на одном уровне иерархии в системе домена in-addr.arpa. Поэтому не надо комплексовать перед записями типа:
$ORIGIN 194.in-addr.arpa. 1.43.226 IN PTR vega-gw.vega.ru.
Однако следует признать, что соответствие "обратных" зон сетям - это общая практика описания "обратных" зон. Ведь здесь точно также надо делегировать зоны из "обратного" домена. А делается это, как правило, на основе разбиения сети на подсети или сети.
В качестве примера для нашей учебной зоны в файле named.boot определена "обратная" зона 43.226.194.in-addr.arpa:
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
99999999 ) ; default ttl is set to maximum value
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
;
1 IN PTR vega-gw.vega.ru.
4 IN PTR dos1.vega.ru.
5 IN PTR dos2.vega.ru
2 IN PTR zone1-gw.zone1.vega.ru.
3 IN PTR zone2-gw.zone2.vega.ru.
Из этого примера видно, что для "обратной" зоны указаны те же записи описания зоны, что и для "прямой". Кроме того, "обратную" зону вовсе не обязательно разбивать в соответствии с разделением "прямой" зоны. С точки зрения домена in-addr.apra все машины принадлежат одной зоне - 43.226.194.in-addr.arpa.
Другое дело машина с IP-адресом 127.0.0.1. С точки зрения домена in-addr.arpa, она принадлежит другой ветке иерархии, отличной от той, которой принадлежат все остальные машины. Поэтому для домена 127.in-addr.arpa на любой машине есть отдельный файл "обратной" зоны, хотя машина localhost, которой соответствует этот IP-адрес, обычно описывается в "прямой" зоне домена вместе с другими машинами.
3.1.6.8. Запись типа HINFO
Описание записи этого типа приводится здесь из соображений полноты представления стандартных записей описания зоны. В записи типа HINFO указывается тип компьютера (hardware) и тип операционной системы, установленной на этом компьютере. Запись имеет следующий формат:
[host][ttl] IN HINFO [hardware] [software]
Поле host определяет имя машины. Поле ttl обычно оставляют пустым. Поле hardware определяет тип аппаратуры, например, SUN-3/60 или IBM-PC/AT. Значение поля определяется согласно RFC "Assigned Numbers". Однако, т.к. развитие средств вычислительной техники и программного обеспечения идет очень быстро, то многие администраторы пишут произвольные названия как hard- так и software. Если в названии встречается пробел, то название должно записываться в кавычках. Отказ от использования этого типа записей вызван также и соображениями безопасности.
3.1.6.9. Запись определения информационных сервисов "Well Known Services"
Данная запись определяет наличие на машине так называемых "Well Known Servisces" (буквально - "хорошо известный сервис"). В данном случае речь идет о прикладных программах, которые обслуживают запросы по портам TCP и UDP до 1024 порта. Наиболее простой способ выяснить какие сервисы реально работают на машине с операционной системой UNIX - это обратиться к файлу /etc/services. Для каждой машины можно указать только две записи типа WKS: одну для TCP и одну для UDP. Формат записи выглядит следующим образом:
[host][ttl] IN WKS [address] [protocol] [services]
Поле host определяет имя машины. Поле address - IP-адрес машины. В поле protocol указывается протокол - TCP или UDP. В поле services перечисляются информационные сервисы, которые установлены на данной машине. Так как сервисов может быть много и потребуется продолжение записи на следующих строках, список сервисов можно записать в круглых скобках. При указании сервисов можно ссылаться только на те, которые описаны в файле /etc/services.
Запись типа WKS используется редко. Во-первых, все сервисы управляются не сервером доменных имен, а поэтому лишний раз их указывать в описании зоны равносильно фразе "масло масленое", во-вторых, мало какие программы умеют работать с этим типом записей и, в-третьих, это дополнительная информация для возможных "взломщиков", т.к. именно сервисы являются инструментом несанкционированного доступа.
3.1.6.10. Команды описания зоны
Кроме записей описания ресурсов, в файлах описания зоны используют еще две команды $INCLUDE и $ORIGIN. Первая команда используется для того, чтобы в файл описания зоны можно было включить содержание другого файла. Так рекомендуется поступать при описании больших зон, разбивая из на небольшие фрагменты. При этом имя включаемого файла должно быть описано либо полностью от корня файловой системы, либо оно будет привязано к директории, указанной в файле named.boot.
$INCLUDE my_zone.dsc
В этом случае используется файл /etc/namedb/my_zone.dsc, т.к. обычно команда directory определяет именно эту директорию для хранения файлов базы данных named.
$INCLUDE /etc/my_zone
В данном случае указан полный путь и именно он будет использоваться при доступе к файлу.
Команда $ORIGIN служит для определения имени текущего домена. В отличии от предыдущей команды, которая практически не используется, по крайней мере российскими провайдерами, $ORIGIN используется и весьма интенсивно. Типичным примером использования $ORIGIN является объявление зоны для "приклеенной" записи типа A:
@ IN SOA ns.vega.ru. ......
IN NS ns.vega.ru.
IN NS ns.relarn.ru.
$ORIGIN relarn.ru.
ns IN A 194.226.130.1
$ORIGIN vega.ru.
ns IN A 194.226.43.1
; The rest of zone description.
.......
В этом примере мы вынуждены были применить команду $ORIGIN дважды. Первый раз при определении "приклеенной" записи для ns.relarn.ru, а второй раз для того, чтобы вернуться к описанию домена vega.ru. Как будет показано в примерах описания файлов, такая практика - обычное дело при использовании named.
3.1.6.11. Файлы описания зоны
Собственно записи описания ресурсов не существуют сами по себе, они составляют файлы описания зоны. Эти файлы размещаются в директории, указанной в команде directory файла настройки программы named - named.boot.
Все эти файлы можно разделить на три категории: файлы описания "прямой" зоны, файлы описания "обратной" зоны и файл описания начальной загрузки базы данных для named.
Обычно, в описании зоны имеется один файл описания "прямой" зоны и не менее двух файлов описания "обратны"х зон. Наличие не менее двух файлов объясняется тем, что существует "обратная" зона для адреса 127.0.0.1 и "обратная" зона для каждой из сетей или подсетей выделенных для данного домена.
Файл начальной загрузки - cache-файл служит для того, чтобы программа named смогла начать общаться с другими серверами сервиса доменных имен, установленными в сети. В этом файле обычно указывают адреса root-серверов.
Для знакомства с содержанием этих файлов проще всего обратиться к примерам организации сервиса доменных имен для различного сорта локальных сетей, подключенных к Internet.
Назад | Содержание | Вперед
[an error occurred while processing this directive]