«DNS и BIND»

4. Установка BIND

Запуск вторичного DNS-сервера

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

Откуда DNS-сервер знает, является он первичным для зоны или вторичным? Эта информация содержится в файле named.conf для каждой зоны. NS-записи не содержат такую информацию о серверах имен - они лишь идентифицируют серверы. (Вообще говоря, DNS нет разницы: если происходит разрешение имен, вторичные DNS-серверы ничем не хуже первичных.)

В чем разница между первичным DNS-сервером и вторичным? Коренное различие в том, откуда сервер получает свои данные. Первичный DNS-сервер читает данные из файлов данных зоны. Вторичный сервер загружает данные по сети, получая их от другого DNS-сервера. Этот процесс носит название передачи зоны.

Вторичный DNS-сервер может получать свои данные не только от первичного DNS-сервера, но и от другого вторичного сервера.

Большим преимуществом в использовании вторичных DNS-серверов является тот факт, что необходимо сопровождать единственный набор файлов данных для зоны, а именно - набор файлов для первичного сервера. Нет необходимости беспокоиться о синхронизации файлов нескольких DNS-серверов; вторичные DNS-серверы синхронизируются автоматически. Минус в том, что вторичный сервер не синхронизируется каждое мгновение, но проверяет актуальность своих данных через определенные интервалы времени. Интервал опроса - одно из тех чисел в SOA-записи, про которые мы еще ничего не рассказывали. (BIND версий 8 и 9 реализует механизм ускорения распределения зональных данных, который будет описан позже.)

Вторичный DNS-сервер не должен получать по сети все свои данные: «лишние» файлы db.cache и db.127.0.0 точно такие же, как на основном сервере, так что имеет смысл хранить их локальную копию. Это означает, что вторичный DNS-сервер является первичным сервером для 0.0.127.in-addr.arpa. Конечно, возможно сделать вторичный сервер вторичным и для 0.0.127.in-addr.arpa, но данные этой зоны никогда не изменяются, так что особой разницы нет.

Установка

Чтобы установить вторичный DNS-сервер, потребуется создать каталог для файлов данных зоны на узле, который будет являться вторичным сервером (например, /var/named) и скопировать в него файлы /etc/named. conf, db.cache и db.127.0.0:

# rcp /etc/named.conf host:/etc
# rcp db.cache db.127.0.0 host:db-file-directory

Потребуется отредактировать файл /etc/named.conf на узле вторичного DNS-сервера. Замените каждое вхождение ключевого слова master на slave, за исключением относящегося к зоне 0.0.127.in-addr.arpa, и добавьте строку masters, указывающую IP-адрес первичного сервера, который и будет основным сервером DNS для этих зон. Если исходная строка в файле настройки выглядела так:

zone "movie.edu" in { type master; file "db.movie.edu"; };

измененная выглядит так:

zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; }; };

Так мы говорим DNS-серверу, что он является вторичным для зоны movie.edu и что он должен реагировать на изменения этой зоны, хранимой DNS-сервером с IP-адресом 192.249.249.3. Вторичный DNS- сервер будет хранить резервную копию этой зоны в локальном файле bak.movie.edu.

Вторичный DNS-сервер Университета кинематографии будет размещен на узле wormhole.movie.edu. Напоминаем, что файл настройки на узле toystory.movie.edu (на котором размещается основной сервер) выглядит так:

options { directory "/var/named"; };

zone "movie.edu" in { type master; file "db.movie.edu"; };

zone "249.249.192.in-addr.arpa" in { type master; file "db.192.249.249"; };

zone "253.253.192.in-addr.arpa" in { type master; file "db.192.253.253"; };

zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; };

zone "." in { type hint; file "db.cache"; };

Мы копируем файлы /etc/named.conf, db.cache и db.127.0.0 на машину wormhole.movie.edu, а затем редактируем файл настройки, как описано выше. Файл настройки на узле wormhole.movie.edu выглядит теперь следующим образом:

options { directory "/var/named"; };

zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; }; };

zone "249.249.192.in-addr.arpa" in { type slave; file "bak.192.249.249"; masters { 192.249.249.3; }; };

zone "253.253.192.in-addr.arpa" in { type slave; file "bak.192.253.253"; masters { 192.249.249.3; }; };

zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; };

zone "." in { type hint; file "db.cache"; };

Он инструктирует DNS-сервер, работающий на узле wormhole.movie.edu, загружать movie.edu, 249.249.192.in-addr.arpa и 253.253.192.inaddr. arpa по сети, получая информацию от DNS-сервера с адресом 192.249.249.3 (toystory.movie.edu). Помимо этого сервер сохраняет резервную копию этих файлов в каталоге /var/named. Возможно, комуто будет удобнее размещать резервные копии файлов в отдельном подкаталоге. Мы добавляем к файлам уникальный префикс (bak), поскольку иногда появляется необходимость вручную удалить все резервные копии. Удобно, когда уже по имени видно, что файлы являются резервными копиями, и редактировать их не имеет смысла. Позже мы обсудим резервное копирование файлов подробнее.

Теперь запустим вторичный DNS-сервер. Следует проверить наличие сообщений об ошибках в log-файле демона syslog - точно так же, как это делалось для основного сервера. Как и для первичного сервера, команда запуска:

# /usr/sbin/named

Помимо тестов, уже описанных для первичного DNS-сервера, вторичный следует подвергнуть еще одному. Необходимо проверить, были ли созданы резервные копии файлов. Вскоре после того, как вторичный сервер был запущен на узле wormhole.movie.edu, мы обнаружили в каталоге var/named файлы bak.movie.edu, bak.192.249.249 и bak.192.253.253. Это означает, что вторичный сервер успешно получил зону от основного сервера и сохранил ее резервную копию.

Чтобы завершить установку вторичного DNS-сервера, попробуйте произвести поиск для тех же доменных имен, которые использовались при тестировании первичного сервера. На этот раз следует выполнять nslookup на узле, на котором работает вторичный DNS-сервер, чтобы именно этот сервер получал запросы. Если вторичный DNS-сервер работает как должен, добавьте соответствующие строки в загрузочные файлы системы, чтобы при загрузке системы DNS-сервер стартовал автоматически, а также воспользуйтесь командой hostname(1) для установки доменного имени.

Резервные копии файлов

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

Зачем нужна резервная копия? Предположим, первичный DNS-мастер-сервер недоступен на момент запуска вторичного сервера. В таком случае вторичный сервер не сможет произвести передачу зоны и не будет функционировать в качестве DNS-сервера для зоны, пока основной сервер не станет доступен. В случае наличия резервной копии вторичный сервер обладает информацией, хотя она может быть немного устаревшей. И поскольку при использовании резервного копирования вторичный DNS-сервер становится менее зависим от основного, он более надежен в работе.

Чтобы избежать создания резервных копий, удалите строку file из файла настройки. При этом мы советуем настраивать дополнительные DNS-серверы таким образом, чтобы они создавали резервные копии. Сохранение резервных копий файлов данных зоны ничего не стоит, зато недешево обойдется ситуация, когда резервная копия спасла бы положение, но ее нет.

Значения SOA

movie.edu. IN SOA toystory.movie.edu. al.movie.edu. (

1 ; Порядковый номер
3h ; Обновление через 3 часа
1h ; Повторение попытки через 1 час
1w ; Устаревание через 1 неделю
1h ) ; Отрицательное TTL в 1 час

Мы так и не объяснили, для чего нужны значения в скобках.

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

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

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

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

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

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

Отрицательное TTL

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

Для версий BIND более старых, чем 8.2, последнее поле SOA-записи определяет оба значения - стандартное (по умолчанию) и отрицательное значение времени жизни информации для зоны.

Те из читателей, кто знаком с предыдущими изданиями этой книги, могут заметить, что изменился формат значений полей в SOA-записях. Когда-то BIND понимал значения, выраженные в секундах, только для четырех описанных полей. (В результате выросло целое поколение администраторов, которые знают, что в неделе 60 8400 секунд.) Теперь при работе со всеми серверами кроме самого старого (BIND 4.8.3) можно указывать значения в других единицах измерения, причем не только в SOA-записи, но и в качестве аргумента управляющего оператора TTL, что мы видели выше по тексту. К примеру, задать трехчасовой интервал обновления можно значениями 3h, 180m и даже 2h60m. Дни обозначаются буквой d, а недели - буквой w.

Корректные значения SOA-записи зависят от конкретного случая. В целом, более длительные интервалы времени снижают нагрузку на DNS-серверы и замедляют распространение изменений, более короткие увеличивают нагрузку и ускоряют распространение изменений. Значения, которые мы используем в этой книге, вполне подойдут для большинства установок. Документ RFC 1537 рекомендует следующие значения для DNS-серверов высшего уровня:

Обновление            24 часа 
Повторение попытки 2 часа
Устаревание          30 дней 
Стандартное TTL       4 дня

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

Итак, мы рассказали о том, как DNS-серверы обновляют свои данные... но в BIND 8 и 9 механизм распространения данных зоны другой! Опрос основных серверов все еще доступен, но в BIND 8 и 9 существует механизм уведомления об изменениях в зональных данных. Если первичный мастер-сервер и все вторичные являются серверами пакета BIND версии 8 или 9, первичный сервер DNS уведомляет вторичные серверы об изменениях зоны в течение пятнадцати минут после загрузки новой копии этой зоны. Уведомление заставляет вторичный сервер сократить интервал обновления и попытаться загрузить зону немедленно. Более подробно мы обсудим этот механизм в главе 10.

Несколько мастер-серверов

Существуют ли другие способы сделать работу вторичных DNS-серверов более надежной? Разумеется: можно указать до десяти IP-адресов мастер-серверов. В файле настройки следует добавить эти адреса после первого IP-адреса, используя точку с запятой в качестве разделителя:

zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; 192.249.249.4; }; };

В случае BIND 9.3 и более поздних версий вы можете назначить имя списку IP-адресов мастер-серверов, а затем просто ссылаться на это имя. Это позволяет избежать повторения IP-адресов для каждой зоны.

masters "movie-masters" { 192.249.249.3; 192.249.249.4; };

zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { movie-masters; }; };

Вторичный сервер будет перебирать мастер-серверы из списка, пока не получит ответ. Вплоть до BIND версии 8.1.2 вторичный DNS-сервер всегда производил передачу зоны с первого ответившего мастер-сервера, если данные на этом мастере имели больший порядковый номер. Последующие DNS-серверы опрашивались только в случае отсутствия ответов от предшествующих. Начиная с BIND версии 8.2 вторичный сервер опрашивает все перечисленные мастер-серверы DNS и производит передачу зоны с сервера, данные которого имеют наибольший порядковый номер. Если таких серверов несколько, вторичный сервер получает данные зоны от первого (в порядке чтения списка) из этих серверов.

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