Админисрирование сети и сервисов INTERNET



         

Пример 4. - часть 3


secondary <имя зоны> <список IP-адресов серверов зоны> <имя файла описания зоны>

В наших примерах описано две зоны, для которых данный сервер является secondary сервером - polyn.kiae.su и 160.206.144.in-addr.arpa. В примерах для каждой из этих зон указано по два IP-адреса серверов, которые описывают зону. Вообще говоря, достаточно указывать адрес только primary сервера для зоны. С точки зрения актуальности состояния базы данных зоны, для которой создается secondary сервер, указание одного только primary наиболее правильное решение, т.к. только primary сервер содержит наиболее актуальную базу данных зоны. Однако, в ряде случаев, имеет смысл указать несколько серверов, primary и secondary, например, в случае указания нескольких серверов, база копируется с того, который указан первым, если он доступен. Если сервер не доступен, то опрашивается следующий в списке, до первого доступного сервера.

Файл, который указан последним аргументом в команде secondary, создается named при запуске и постоянно обновляется в соответствии с описанием взаимодействия primary и secondary серверов. Редактировать вручную этот файл не имеет смысла, т.к. это калька с primary сервера, и через постоянные промежутки времени этот файл обновляется программой named. Таким образом, если кто-либо и внесет в него изменения, то named, создавая новую копию базы данных зоны, затрет эти изменения.

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

Главное назначение secondary сервера - это повышение надежности службы доменных имен. Описание зоны named копирует с серверов, указанных в качестве аргумента команды secondary. Там указаны не только primary сервер, но и другие secondary серверы. Зона копируется с того сервера, который доступен. Это значит, что на данном сервере может оказаться копия с другого secondary сервера, что, вообще говоря, не очень хорошо, если речь идет о сервере, который действительно предназначается для дублирования зоны.

В самом начале описания BIND было сказано, что сервис работает по 53 портам UDP и TCP. Для чего для одного и того же сервиса было организовывать информационные магистрали с использованием различных типов транспорта? Дело в том, что обычные запросы на разрешение имен IP-адресами или IP-адресов именами отправляются по транспорту UDP. Это делается из-за того, что объем передаваемой информации небольшой. Но при организации secondary сервера ситуация меняется. Этот сервер запрашивает другой сервер, прописанный в команде secondary, целиком все описание зоны, а это может быть довольно большой объем информации. Вот в этом случае и используется сервис TCP. Из-за такой архитектуры проистекают многие проблемы связанные как со скоростью обслуживания запросов к системе доменных имен, так и с безопасностью сети вообще.

Скорость DNS - "это притча во языцах". При установке больших временных интервалов ожидания ответов отказ на обслуживание приходит только после истечения времени ожидания для данного сервиса UDP. Это если сервис неактивен. Если сервис активен, то нельзя точно установить работает он или нет, т.к. сервис UDP - это сервис без установки соединения. Но если говорить о копировании зон, то можно столкнуться со следующей ситуацией: запросы разрешаются, а зоны не копируются. В этом случае кроме администратора данного сервера никто ничего сказать не может. Администратор может намерено запретить копирование зоны, а может быть за отведенный интервал времени не удается передать зону, или во время передачи разрывается TCP сессия. Для российской части Internet такое случается довольно часто. Если вдруг пользователям кажется, что система начинает медленно "умирать", то это может происходить из-за того, что secondary сервера не могут обновить описания зон, а так как копии могут быть получены в разное время, то сервера "мрут" в разное время.

Команда cache служит для определения файла с начальными данными для запуска named. Для того, чтобы начать отвечать на запросы named должна знать адреса других серверов доменных имен, к которым можно было бы обратиться с запросами на разрешение IP-адреса по имени или имени по IP-адресу.

Формат команды выглядит следующим образом:




Содержание  Назад  Вперед