Макс

Родной город: Омск

Фото галерея: смотреть

Контакты: написать

О себе:

Интересы:

- программирование

- интернет

- психология

- менеджмент

- автоматизация

Погляди
Голосование

Нравиться ли вам блог

  Да
  Нет
  Я тут случайно

 

ГлавнаяКарта сайтаПечать страницы

Значения SOA для BIND/NAMED (CentOS, Red Hat)


site.ru. IN SOA ns.site.ru root@site.ru (
1247490039   ; Порядковый номер
10800   ; Обновление
3600   ; Повторение попытки
604800  ; Устаревание через
3600  ); Отрицательное TTL

Порядковый номер относится ко всем данным в пределах зоны. Мы начали с единицы, что вполне логично. Но многие люди находят более удобным использовать в качестве порядкового номера даты, к примеру “1997102301. Это дата в формате ГГГГММДД^, где ГГГГ - год, ММ -месяц года, ДД - день месяца, а NN - счетчик числа изменений зо-нальныхданных в этот день. Порядок полей менять нельзя, поскольку только этот порядок приводит к увеличению значения порядкового номера при смене даты. Это очень важно: какой бы формат не использовался, порядковый номер должен увеличиваться при обновлении данных зоны.

Когда вторичный DNS-сервер устанавливает соединение со своим мастером на предмет получения информации о зоне, прежде всего он запрашивает порядковый номер данных. Если порядковый номер данных зоны у вторичного DNS-сервера меньше, чем порядковый номер данных мастера, считается, что зональные данные вторичного сервера устарели. В этом случае вторичный сервер получает новую копию зоны. Если при запуске вторичного сервера не существует резервной копии, происходит безусловная загрузка зоны. Как можно догадаться, при изменении файлов данных зоны на первичном мастер-сервере следует увеличивать порядковый номер.

Следующие четыре поля определяют различные временные интервалы, причем по умолчанию значения указываются в секундах:

Обновление (refresh)
Интервал обновления инструктирует вторичный DNS-сервер, с какой частотой следует проверять актуальность информации для зоны. Чтобы читатели получили представление о нагрузке, которую создает это значение, сообщаем, что вторичный сервер при каждом обновлении делает один запрос SOA-записи для зоны. Выбранное значение, три часа, умеренно агрессивно. Большинство пользователей смирятся с задержкой в половину рабочего дня, ожидая, когда их рабочие станции станут частью сети. Если речь идет о ежедневных процедурах, касающихся DNS, вполне можно увеличить значение до восьми часов. Если же данные зоны меняются не очень часто, а все вторичные DNS-серверы удалены на большие расстояния (как корневые DNS-серверы), имеет смысл задуматься о большем значении, скажем, интервале в 24 часа.

Повторение попытки (retry)
Если по истечении интервала обновления вторичный сервер не может достучаться до своего мастера (который, вполне возможно, не работает на этот момент), он повторяет попытки через равные интервалы времени, определяемые данным значением. В обычной ситуации интервал повторения попытки короче, чем интервал обновления, но это необязательно.

Устаревание (expire)
Если вторичный DNS-сервер не может соединиться с основным в течение указанного числа секунд, данные зоны на вторичном сервере устаревают. Устаревание зоны означает, что вторичный сервер перестает отвечать на запросы по этой зоне, поскольку зональные данные настолько утратили актуальность, что не могут быть полезными. По сути дела, это поле определяет момент, когда данные становятся настолько старыми, что лучше не использовать их вовсе. Интервалы устаревания порядка недели - обычное дело, они могут быть длиннее (до месяца) в случаях, если существуют проблемы связи с первичным источником информации. Интервал устаревания всегда должен быть гораздо длиннее, чем интервалы обновления и повторения попытки; в противном случае, данные зоны будут устаревать еше до попытки их обновления.


Отрицательное TTL
TTL - это время жизни (time to live). Это значение относится ко всем отрицательным ответам DNS-серверов, авторитативных для данной зоны.