Запись Start of Authority (SOA) отмечает начало зоны и обычно является первой записью в файле зоны. Все последующие записи являются частью зоны, объявленной в SOA. В каждой зоне только одна запись SOA; следующая SOA отмечает начало другой зоны. Поскольку файл зоны обычно связан только с одной зоной, он, как правило, содержит только одну запись SOA. Формат записи SOA:
[zone] [tti] IN SOA origin contact ( serial refresh retry expire negative_cache_ttl )
Составляющие записи SOA:
zone
Имя зоны. Обычно поле имени SOA содержит символ Внутри записи SOA символ @ является ссылкой на доменное имя, объявленное в соответствующем операторе zone файла named.conf.
ttl
Время жизни в записи SOA не указывается.
IN
Для всех RR-записей сети Интернет класс адресов - IN.
SOA
SOA - тип записи. Вся последующая информация составляет поле данных и имеет смысл только в контексте записи SOA.
origin
Имя узла основного сервера данного домена. Обычно записывается в виде абсолютного доменного имени. Если crab является основным сервером wrotethebook.com, данное поле в записи SOA зоны wrotethebook.com содержит значение wrotethebook.com.
contact
Адрес электронной почты лица, ответственного за домен. Адрес немного видоизменяется. Символ присущий адресам электронной почты сети Интернет, заменяется точкой. Следовательно, для адреса электронной почты Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. администратора домена wrotethebook.com запись SOA зоны wrotethebooh.com содержит значение david.crab.wrotethebook.com. в поле contact.
serial
Номер версии файла зоны. Данное десятиразрядное численное поле обычно содержит простые числа, например 117. Однако создание чисел возлагается на администратора. Некоторые используют формат, отражающий дату обновления зоны (к примеру, 2001061800). Независимо от выбранного формата важно помнить, что порядковый номер должен увеличиваться при каждом изменении данных в файле зоны.
Поле serial имеет особое значение. Оно используется подчиненными серверами для определения того, что файл зоны обновлен. Чтобы выявить это обстоятельство, подчиненный сервер запрашивает запись SOA у основного сервера и сравнивает порядковый номер хранимых данных с полученным от сервера. Если порядковый номер увеличился, подчиненный сервер запрашивает полную передачу зоны. В противном случае он предполагает, что хранимые данные отражают действительность. Увеличивайте порядковый номер при каждом обновлении данных зоны. Если вы этого не сделаете, новые данные могут не попасть на подчиненные серверы.
еfresh
Длительность интервала ожидания, по истечении которого подчиненный сервер должен обратиться к основному и выяснить, обновилась ли зона. Каждые refresh секунд подчиненный сервер запрашивает запись SOA, получает порядковый номер и определяет, необходима ли перезагрузка файла зоны. Подчиненные серверы проверяют порядковые номера своих зон при каждом перезапуске. При этом важно сохранять синхронизацию баз данных подчиненных серверов с базой данных основного сервера, что-бы named в работе не полагался на нерегулярное событие перезагрузки. Интервал обновления позволяет организовать предсказуемый цикл для перезагрузки зоны, находящейся под контролем администратора домена. Значение в поле refresh - это число длиной до восьми разрядов, указывающее максимальную длительность рассинхронизации баз данных основ-
ного и подчиненных серверов в секундах. Низкое значение обновления обеспечивает разумную степень синхронизации данных на серверах, а очень низкое значение обычно не требуется. Неоправданно короткий интервал обновления создает ненужную нагрузку на сеть и подчиненные серверы. Значение поля refresh должно отражать частоту обновлений вашей базы данных DNS.
Базы данных DNS большинства сетевых площадок очень стабильны. Системы периодически добавляются, но обычно вовсе не раз в час. Добавляя новую систему, вы можете назначить ей имя узла и адрес до непосредственного подключения к сети. Затем можно добавить соответствующую информацию в базу данных сервера имен - раньше, чем она потребуется, так что информация распространится по подчиненным серверам задолго до входа системы в строй.
Если планируются серьезные изменения, интервал обновления можно временно сократить - только на период работ. Следовательно, в обычной ситуации интервал обновления может быть длительным, что позволяет сократить нагрузку на сеть и серверы. От двух (43 200 секунд) до четырех (21600 секунд) раз в день - подходящее значение поля refresh для многих сетевых площадок.
Процесс получения записи SOA, анализа порядкового номера и при необходимости загрузки файла зоны носит название обновления зоны (zone refresh). Отсюда и название поля refresh.
retry
Длительность паузы, возникающей перед повторной попыткой обновления зоны, если основной сервер не ответил на предыдущий запрос обновления. Значение retry указывается в секундах и может быть до восьми десятичных разрядов длиной.
Не следует использовать слишком маленькие значения. Если основной сервер не ответил, дело может быть в сбое сервера или сети. Быстрый повтор попытки обращения к неработоспособной системе ничего не дает, только расходует ресурсы сети. Подчиненный сервер, обслуживающий большое число зон, может испытывать проблемы в случае низких значений retry. Если подчиненный сервер не может связаться с основным сервером нескольких из своих зон, он зацикливается на повторных попытках.
Избегайте осложнений; используйте час (3600) или полчаса (1800) в качестве значения retry.
expire
Длительность хранения данных зоны подчиненными серверами (без учета обновлений). Значение указывается в секундах и может быть до восьми цифр длиной. Если по истечении expire секунд подчиненный сервер так и не смог обновить зону, он должен удалить все данные зоны. Значение expire обычно очень велико. Широко используется значение в 604 800 секунд (около недели). Если основной сервер не отвечал на запросы обновлений, повторяемые каждые retry секунд, семь дней, данные удаляются. Семь дней - разумное значение, однако и гораздо более длинные интервалы устаревания данных не являются чем-то из ряда вон выходящим.
negative_cache_ttl
Поле negati ve_cache_ ttl записи SOA содержит значение TTL по умолчанию для отрицательной информации о данном домене, кэшируемой удаленными серверами. Все серверы кэшируют ответы и используют их для реагирования на последующие запросы. Большинство кэшируемых ответов представлено стандартными записями ресурсов. Но, кроме того, сервер имен может узнать от компетентного сервера, что определенная RR-запись не существует. Такая информация также является ценной и кэшируется.
Сервер хранит кэшированные записи, пока они не устареют, а время старения определяется значением TTL. Каждой записи соответствует TTL - будь то время жизни, указанное непосредственно для данной записи, или же значение по умолчанию TTL, определенное инструкцией $TTL. Однако для отрицательных «ответов» нет записей ресурсов, а значит - нет и явно установленных значений TTL. Именно значение negative_cache_ttl определяет для удаленных серверов длительность кэширования отрицательной информации.
Значение negative_cache_ttl обычно лежит в интервале от 5 до 15 минут. Достаточно большое значение, предохраняющее ваш сервер от повторных запросов несуществующей информации, но достаточно короткое время с точки зрения повторных запросов от удаленного пользователя.
Который в курсе, что система с определенным именем скоро вновь проявится в сети. Большинство полей записи SOA предназначено для синхронизации подчи- ненных серверов с основным. Эти значения позволяют гарантировать, что подчиненный сервер будет периодически получать копию зоны от основного сервера. В дополнение к этому (и совершенно безотносительно значений записи SO А) основной сервер уведомляет подчиненные серверы, что зона обновилась, с целью скорейшего распространения новой копии данных. Сочетание обновлений, инициируемых подчиненными серверами, и обновлений, инициируемых основным сервером, гарантирует, что файлы серверов надежно синхронизируются.
Пример записи SOA для домена wrotethebook.com:
@ IN SOA crab.wrotethebook.com. david.crab.wrotethebook.com. ( 2001061801 ; порядковый номер 21600 ; обновление четыре раза в день 1800 ; повтор попытки каждые полчаса 604800 ; устаревание через неделю 900 ; время жизни отрицательных ответов - 15 минут )
Обратите внимание на порядковый номер в данной записи SOA. Он имеет формат yyyymmddvv, где уууу - год, mm - месяц, dd - день, &vv- номер версии, созданной в этот день. Такой вид порядкового номера позволяет администратору определить, в какой день была обновлена зона. Добавление номера версии позволяет многократно вносить изменения в один день. Данный файл зоны был создан 18 июня 2001 года и для этой даты был первой версией. Данная запись сообщает, что основным сервером для зоны является crab, а связь с лицом, ответственным за зону, можно осуществить по электронной почте: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.. Запись предписывает подчиненным серверам проверять зону на предмет изменений четыре раза в день, повторять попытку обновления каждые полчаса, если нет ответа от основного сервера. Если в течение недели повторных попыток не получен ответ, следует удалить данные этой зоны. Наконец, если RR-запись не существует в данной зоне и удаленный сервер кэширует эту информацию, время кэширования составляет 15 минут.