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 или удаленного сервера максимально возможное время.