Работа с клиентом BIND
Категория: Система доменных имен | Автор: admin | 10-04-2010, 02:57 | Просмотров: 2761

Перед тем как вплотную заняться проблемами конфигурирования пакета BIND, давайте определим круг основных задач, которые сопряжены с использованием BIND в Internet. В табл. 16.6 показано, что нужно делать, кому и как часто. Если элемент в столбце "Как часто" содержит слово "распространить", то это означает, что указанное действие необходимо выполнить один раз в каждой подсети или архитектуре, а затем скопировать результат на другие компьютеры с помощью такой программы, как rdist или rsync.

 

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

Таблица 16.6. Задачи, связанные с инсталляцией и сопровождением пакета BIND

Задача

Для

Как часто

Получить доменное имя

Организации

Один раз

Выбрать серверы имен

Организации

Один раз или больше

Получить дистрибутив BIND

Организации

Один раз, но следить за обновлениями

Сконфигурировать распознаватель

Клиента

Один раз и распространить

Сконфигурировать эффективный распознаватель

Клиента

Для каждой подсети и распространить

Сконфигурировать файл "переключения сервисов"

Клиента

Для каждой архитектуры и распространить

Запустить демон named во время начальной загрузки

Сервера

Для каждого сервера имен

Отредактировать конфигурационный файл демона named

Сервера

Для каждого типа сервера

Сконфигурировать файл "подсказок"

Сервера

Один раз1 и распространить на серверы имен

Сконфигурировать файлы зон

Главных серверов

Один раз

Обновлять файлы зон

Главных серверов

По мере необходимости

Просматривать журнальные файлы

Узла-регистратора

Хотя бы раз в неделю

Обучать пользователей

Всех узлов

Постоянно

1   Нужно выполнять повторно, если меняются корневые серверы.

 

 

Конфигурирование распознавателя

 

На каждом компьютере, подключенном к сети, должен быть файл /etc/resolv.conf, содержащий список серверов имен, которым можно посылать запросы. Если узел получает свой IP-адрес и сетевые параметры от DHCP-сервера, этот файл заполняется автоматически. В противном случае его нужно редактировать вручную. Файл имеет следующий формат:

search имя_домена ...

nameserver ip-адрес

 

Может быть указано от одного до трех серверов имен. Вот полный пример:

search cs.colorado.edu colorado.edu ee.colorado.edu

nameserver 128.138.243.151       ; ns

nameserver 128.138.204.4         ; piper

nameserver 128.138.240.1         ; anchor

 

Для файла resolv.conf никогда не вводилось понятие комментариев. Они поддерживаются лишь в том смысле, что любой нераспознанный элемент файла игнорируется. Комментарии разрешается размещать в конце директивы nameserver, поскольку анализатор файла ищет лишь IP-адрес, игнорируя остальную часть строки. Директива search может содержать несколько аргументов, поэтому комментарии в ней лучше не ставить.

В директиве search указан список доменов, которые следует опрашивать, если имя компьютера оказывается не полностью определенным. Например, когда пользователь вводит команду ssh foo, распознаватель дополняет имя первым доменом в списке (в данном случае — cs.colorado.edu) и в результате ищет узел foo.cs.colorado.edu. Если это имя не найдено, делается попытка найти узел foo.colorado.edu, затем foo.ee.colorado.edu.

Пользователи нашего поддомена "cs" могут обращаться к любому локальному узлу по сетевому имени, а вот пользователи родительского домена должны указывать имя_узла.cs, чтобы получить доступ к нужному компьютеру в этом поддомене. При создании новых поддоменов приходится дополнительно обучать пользователей.

Директива search в файлах resolv.conf компьютеров родительского домена может допускать использование простых имен в обоих направлениях:

search colorado.edu. cs.colorado.edu. ee.colorado.edu.

 

Естественно, в такой конфигурации предполагается, что имена компьютеров уникальны в пределах всех трех доменов. В директиве search можно задавать до восьми доменов.

Серверы имен, указанные в файле resolv.conf, должны быть рекурсивными (распознаватель не понимает отсылок) и иметь свой кэш. Если используется пакет BIND 4 или BIND 8, то серверы не должны быть авторитетными ни для одной зоны. Их кэши могут стать очень большими, а поскольку в версиях 4 и 8 работа с кэшем ведется некорректно, вся память компьютера может оказаться занятой. При смешении кэшированных и авторитетных данных нужно воспользоваться конфигурационным параметром listen-on, позволяющим запустить на одном компьютере два отдельных сервера, прослушивающих разные порты.

Серверы имен опрашиваются в том порядке, в котором заданы директивы nameserver. Если первый сервер отвечает на запрос, другие серверы игнорируются. В случае превышения периода тайм-аута запрос переадресуется следующему серверу. Все серверы опрашиваются по очереди, до четырех раз каждый. С каждой неудачей период тайм-аута увеличивается.

Большинство распознавателей допускает наличие максимум трех серверов имен. Все остальные просто игнорируются. Если узел сам является сервером имен, он должен быть указан первым в собственном файле resolv.conf.

В ранних версиях BIND вместо директивы search в файле resolv.conf использовалась директива domain. Она задавала единый домен, который следовало добавлять к неполным именам. Мы рекомендуем заменить директивы domain директивами search. Они являются взаимоисключающими, так что только одна из них должна присутствовать. Если имеется старый распознаватель, а в файле resolv.conf присутствуют обе директивы, действительной будет та, что указана последней.

По умолчанию современные распознаватели ведут себя каждый по-своему. Одни предполагают, что локальный компьютер является DNS-сервером, если в конфигурационном файле не указаны серверы имен. Другие раскладывают полное имя локального компьютера на компоненты, формируя список поиска. Третьи могут работать вообще без файла /etc/resolv.conf. Не обращайте на все это внимание. Просто сконфигурируйте должным образом файл resolv.conf на каждом компьютере.

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

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

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

 

 

Тестирование распознавателя

 

В некоторых системах для начала работы с DNS нужно лишь добавить в файл /etc/resolv.conf директиву nameserver. В других системах следует дать явное указание на использование DNS вместо файла /etc/hosts или службы NIS (это делается в файле "переключения сервисов", который чаще всего называется /etc/nsswitch.conf). Комментарии по использованию пакета BIND в наших тестовых системах приведены в параграфе 16.16. Описание того, как назначать приоритеты источникам административных данных, дано в параграфе 18.3.

После конфигурирования файла /etc/resolv.conf (предполагаем, что соединение с локальной сетью установлено и функционирует правильно) пользователь сможет ссылаться на другие компьютеры по именам, а не IP-адресам. Если при обращении к локальному компьютеру команда "зависнет", попробуйте найти машину по IP-адресу. Успешное завершение такого поиска означает, что в конфигурации DNS есть ошибка. Убедитесь, что IP-адреса серверов имен в файле /etc/resolv.conf правильны, а самим серверам разрешено обрабатывать запросы из вашей сети (см. описание параметра allow-query в следующем параграфе).

 

Влияние на остальную часть системы

 

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

Ссылки на имена компьютеров в сценариях /etc/rc* или init.d могут оказаться неразрешимыми, если они встречаются раньше, чем загружается сетевая подсистема. Команды сценариев будут безуспешно пытаться связаться с DNS. Благодаря устойчивости распознавателя они станут повторять попытки много раз на многих серверах, при каждой из попыток увеличивая интервал тайм-аута. Пару минут спустя команда, которой нужно имя компьютера, наконец, выдаст ошибку.

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

Полностью определенные имена доменов требуются в нескольких местах. Одно из них — файл /etc/exports, который управляет совместным использованием файлов NFS в некоторых системах. В списках компьютеров, имеющих право монтировать файловые системы, должны содержаться полностью определенные имена этих машин. В некоторых системах каждая строка в файле exports ограничена 1024 знаками; когда имена компьютеров меняются с anchor на anchor.cs.colorado.edu, этот предел достигается пугающе быстро.


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page