Структура и описание SOA-записи

Запись SOA (Start of Authority)

name        ttl class rr    name-server email-addr  (sn ref ret ex min)

$TTL 2d
$ORIGIN example.com.
@    IN    SOA   ns.example.com. hostmaster.example.com. (
                              2003080800   ; sn = serial number
                              172800           ; ref = refresh = 2d
                              900                 ; ret = update retry = 15m
                              1209600         ; ex = expiry = 2w
                              3600               ; min = minimum = 1h
                              )


$TTL время жизни данных зоны в кэше запросившего их сервера (в секундах)
По достижении установленного времени, кеширующий сервер запрашивает DNS сервер, содержащий доменную зону, информацию о зоне.
Перед запланированными процедурами, первую строку SOA записи следует изменить на значение $TTL    600 , или меньше, после чего изменить serial number и перегрузить зоны, т.е. рестартовать DNS сервер и спокойно идти за чаем в ожидании истечения времени указанного для TTL первоначально. После того как эти данные обновятся, что можно проверить с помощью команды dig, можно начинать производить необходимые процедуры по миграции серверов. Изменение IP адресов произойдет в течении указанного времени.
После того как все процедуры по переезду и миграции будут произведены, значение  TTL можно перевести в большее значение с тем, чтобы снизить нагрузку на DNS сервер и избежать слишком большого сетевого трафика при обновлении зон.

$ORIGIN задает суффикс по умолчанию для файла данных зоны и обязательно заканчивается точкой
$ORIGIN mydomain.ru.
Если эта директива не задана, то BIND определяет ее как имя зоны, заданной в файле named.conf
@ используется для обозначения корня зоны и принимает значение последней директивы $ORIGIN в файле

serial number - серийный номер версии данных (выбор номера произволен, но номер должен увеличиваться для каждой новой модификации), yyyymmddss where yyyy = year, mm = month and dd = day ss = a sequence number in case you update it more than once in the day
refresh - период запроса на обновление данных со стороны вторичного сервера (в секундах), рекомедуется от 1200 (если данные часто изменяются) до 43200 (если изменения очень редки)
retry - период повтора попыток запроса данных вторичным сервером в случае неудачи (в секундах), обычно от 3 до 15 минут или более
expiry - срок годности данных, т.е. время, через которое вторичный сервер прекратит обслуживать запросы, если ему не удастся восстановить связь с первичным сервером (в секундах), рекомендуется знаяения от 1209600 до 2419200 (2-4 недели)
minimum=negative caching - время жизни отрицательного кеширования (в секундах), этот показатель определяет, как долго удаленные DNS-серверы имеют право сохранять информацию об отрицательных ответах, связанных с зоной, т.е. ответах, суть которых заключается в том, что доменное имя или тип данных не существует в конкретном домене. Максимально 3 часа, рекомендуются небольшие значения от 15 минут до двух часов