- •История доменной системы имен
- •Кому нужна доменная система имен?
- •Пространство имен dns
- •Выбор нмени домена
- •Конфигурирование определителя
- •База Данных dns
- •Заппсь soa
- •Записи mx
- •Записи снаме
- •Записи hinfo
- •Имя [время] [класс] wks [адрес] протокол программы
- •Новые записи о ресурсах
- •Isdn Поле isdn содержит isdn-адрес, который, по сути дела, является замаскированным номером телефона.
- •О чем мы еше не говорили
- •16.12. Корректировка Фанпов зон
- •Зонные пересылки
- •Вопросы зашиты
- •Тестирование и отладка
- •Напрасное делегирование
- •Рекомендуемая дополнительная литература
Конфигурирование определителя
На каждой машине-клиенте BIND должен быть файл /etc/resolv.conf, содержащий список серверов имен, которым нужно посылать запрос. Этот файл имеет следующий формат:
; Комментарий
search имя_домена . . .
nameserver ip-адрес
Может быть указано от одного до трех серверов имен. Вот полный пример:
search cs.сolorado,edu сolorado, edu
; ns, piper, boulder
nameserver 128.138.243.151
nameserver 128.138.204.4
nameserver 128.138.240.1
Если машина сама является сервером имен, она должна быть первой. Вместо закольцовывающего адреса (127.0.0.1) используйте фактический IP-адрес. Если использовать закольцовывающий адрес, то ошибка в сетевом программном обеспечении BSD может вызвать проблемы. На каждой из указанных машин должен работать рекурсивный сервер имен; рассматриваемый определитель не отслеживает отсылки.
Первый контакт устанавливается с сервером имен, который указан в файле /etc/resolv.conf первым. Если этот сервер на запрос не отвечает, выделенное для ответа время (тайм-аут) истекает и запрашивается следующий сервер имен, указанный в списке. Все серверы запрашиваются по очереди, до четырех раз каждый. С каждой неудачей интервал тайм-ayт увеличивается.
В небольшой организации файл /etc/resolv.conf необходимо конфигурировать так, чтобы он указывал на основной сервер имен организации или, если такого сервера нет, на сервер Internet-провайдера. В крупной организации должно быть несколько серверов имен, работающих во всех ее частях, а файл resolv. conf необходимо доработать так, чтобы распределить нагрузку среди серверов, минимизировать сетевой трафик и уменьшить уязвимость машин к одиночным отказам. В противном случае сбой сервиса имен приведет в останову всего комплекса.
Если пользователь дает команду telnet foo, определитель дополняет это имя первым доменом из списка search (здесь — cs.colorado.edu) и ищет имя foo.cs.colorado.edu. Если foo в этом домене не существует, определитель пробует foo.colorado.edu.
Это, конечно, подразумевает, что имена машин уникальны для всех трех указанных доменов. В директиве search можно указывать до шести доменов.
В некоторых системах для начала работы с DNS нужно лишь добавить в файл /etc/reвolvconf строку сервер-имен. В других системах нужно дать явное указание на использование DNS вместо файла /etc/hosts или NIS.
Настройка сервера имен
В этом разделе мы предполагаем, что политические задачи Вами решены. У Вас есть имя домена (возможно, под домена), согласованное с администратором DNS родительского домена. Вы выбрали основной сервер имен и пару вспомогательных. Наконец, Вы инсталлировали BIND.
Полная конфигурация демона named состоит из файла начальной загрузки, кэш-файла и — для основных серверов — файла (или файлов) данных, содержащего адресные соответствия для каждой зоны.
Файл начальной загрузки: /etc/named.boot
Демон named запускается во время начальной загрузки и работает непрерывно. Он может например, запускаться из файла /etc/rс.local.
Запускаясь, named записывает свой PID в файл /etc/named, pid (в BSDI — в файл /var/run/named.pid.
Файл named, boot задает роль данной машины (основная, вспомогательная или кэширующая) относительно каждой зоны и способ, которым она должна получать свой экземпляр записей о ресурсах, составляющих локальную часть базы данных. Файл named, boot имеет следующий формат:
directory имя каталога
cache . имя_ файла
primary зона имя_файла
secondary зона ip-адрес [...] имя файла
Элементы файла named.boot разделяются пробелами или знаками табуляции. Точка с запятой является признаком комментария.
Ключевое слово directory указывает на то, что все последующие имена файлов даются относительно указанного каталога.
Ключевое слово cache задает имя файла, который содержит адреса серверов корневых имен (т.н. подсказки о серверах корневых имен). Эти подсказки используются для "натаскивания" кэша на содействие запуску системы. Точка посередине — это не клякса, она обозначает домен, для которого предназначен кэш, т.е. корень иерархии. Сначала кэш-файл назывался /etc/named.ca, но многие организации перенесли все файлы системы BIND в каталог /var.
Ключевое слово primary показывает, что эта машина — основной сервер для указанной зоны зона и что данные для этой зоны находятся в файле имя_файла.
Ключевое слово secondary показывает, что эта машина — вспомогательный сервер для зоны зона. Для вспомогательных серверов указывается минимум два параметра: IP-адреса основного сервера, с которого необходимо получать данные об этой зоне, и файл имя_файла на диске, в котором будут кэшироваться данные. Когда вспомогательный сервер имен проходит этап начальной загрузки, он загружает данные из своего дискового файла, а затем обращается к основному серверу, чтобы определить, изменились ли данные и нужно ли их перезагружать.
Если основной сервер не работает, вспомогательный сервер попробует обратиться по другому IP-адресу, если он есть в файле начальной загрузки, или просто использовать данные, сохраненные на диске после последнего изменения. Следует помнить: несмотря на то, что может быть указано несколько IP-адресов, они обозначают не разные машины, а разные интерфейсы одного основного сервера.
Один сервер имен может обслуживать несколько разных зон. Соответственно, в файле named.boot может быть несколько строк primary и secondary.
Как мы видели, в файле named.boot указываются имена файлов, содержащих записи базы данных DNS. Кэш-файл и файлы, связанные с доменами, для которых named — основной сервер, должны конфигурироваться вручную. Файлы, связанные с объявлениями secondary, ведутся демоном named.
Каждый раз, когда сервер имен запрашивает другой сервер, он добавляет ответ в свой кэш. Вместо того чтобы заставлять каждый сервер имен делать свои собственные внешние запросы, Вы можете назначить один или несколько пересыльщиков. Обычный сервер имен смотрит в свой кэш и на записи, для которых он является авторитетным; если он не находит искомого ответа, то посылает запрос на машину-пересыльщик. Таким образом, пересыльщики создают кэши, которые выгодны для всей организации. Если пересыльщик в течение определенного периода времени не отвечает, то исходный сервер сам выполняет запрос.
Например, строка
forwarders 128.138.243.151
в конце файла named.boot назначает машину 128.138.243.151 пересыльщиком данной организации. Она, кроме того, предоставляет возможность запутать конфигурацию named и создать замкнутый цикл пересылки DNS: например, машина А пересылает запрос на машину Б, которая пересылает его на машину В, которая пересылает его на машину А... Количество циклов в таком "бесконечном" цикле равно приблизительно двадцати, потому что BIND вовремя предупреждает нас о случившемся.
Если сервер имен собирается использовать пересыльщиков эксклюзивно (например, потому, что это уставшая старая система Sun3 или машина, находящаяся за брандмауэром), он может после строки forwarders поставить директиву slave. Подчиненный сервер кэширует запросы и направляет их пересыльшикам, никому больше запросы не посылая. В результате могут получиться "трусливые" циклы пересылки: например, пересылка на другие подчиненные машины, которые пересылают запросы обратно Вам.
В некоторых организациях пересыльщиками назначают более мощные и богатые памятью серверы, чтобы снизить как общую нагрузку на сеть, так и нагрузку на процессоры и память более слабых серверов.
