, содержащий список корневых серверов, можно скопировать посредством протокола FTP, обратившись по адресу
ftp://ftp.rs.internic.net/domain/
.
• Если в вашей системе установлена программа
dig
, вы можете задать команду
dig @a.root-servers.net.ns > named.са
. Эта команда копирует файл, содержащий список корневых серверов, и присваивает ему имя
named.са
.
Чтобы вы могли воспользоваться вторым или третьим из описанных выше способов, в вашей сети должен работать сервер DNS. Если сервер DNS в сети отсутствует, вы можете скопировать нужный файл, воспользовавшись компьютером другой сети, либо временно настроить компьютер, на котором должен быть установлен сервер DNS для преобразования посредством внешнего
сервера имен (действия по настройке были описаны в главе 2).
Получив файл со списком корневых серверов, скопируйте его в каталог
/var/named
. Кроме того, вам следует убедиться в том, что ссылка на этот файл присутствует в конфигурационном файле
/etc/named.conf
. В листинге 18.1 файл, содержащий список корневых серверов, указан с помощью опции
file
, расположенной в разделе
zone "."
, (Каждое доменное имя должно оканчиваться точкой, но имя корневой зоны состоит только из точки.)
Настройка сервера для перенаправления запросов
BIND осуществляет преобразование имен одним из трех описанных ниже способов.
1. Если пакет BIND настроен для поддержки запрошенного имени, сервер возвращает адрес, указанный в его конфигурационном файле.
2. Если запрашиваемый адрес находится в кэше, сервер возвращает его. В этом случае повышается быстродействие и снижается нагрузка на сеть.
3. Если требуемый адрес в кэше отсутствует, сервер передает запрос корневому серверу и другим серверам. Типичная процедура преобразования имен была рассмотрена выше. Для выполнения преобразования требуется лишь несколько секунд, но чтение из кэша осуществляется гораздо быстрее.
В пакете BIND реализована еще одна возможность. Он может перенаправить запрос серверу DNS, чтобы тот выполнял всю рутинную работу по преобразованию адресов. Настроенный таким образом, пакет BIND осуществляет перенаправление запроса после того, как убеждается, что в кэше необходимые данные отсутствуют, но перед тем, как приступить к стандартной процедуре преобразования. В некоторых ситуациях такое перенаправление может повысить скорость преобразования имен. Произойдет это в том случае, если сервер, установленный в небольшой локальной сети, подключенной к Internet через линию с низкой пропускной способностью, будет перенаправлять запрос другому локальному серверу, который имеет возможность передавать данные по более быстродействующим линиям. Предположим, что вы выполняете администрирование сети, подключенной к Internet по коммутируемой линии или через спутниковое соединение. В этом случае имеет смысл перенаправить запросы на преобразование имен серверу DNS провайдера. Соединение по коммутируемой линии само по себе обладает низким быстродействием, а спутниковое соединение характеризуется большой задержкой, поэтому для передачи многочисленных запросов при выполнении стандартной процедуры преобразования имен потребуется слишком много времени.
Почему же не настроить локальные компьютеры так, чтобы они непосредственно обращались к серверу DNS провайдера? Локальный сервер DNS удобно использовать для преобразования локальных имен, кроме того, кэширование результатов обработки запросов повышает быстродействие при работе с Internet. Помимо того, сервер DNS провайдера может функционировать нестабильно, поэтому наличие собственного сервера позволяет повысить надежность при установлении сетевых соединений.
Перенаправление запросов задается с помощью опций
forwarders
и
forward
(см. листинг 18.1). Опция
forwarders
позволяет задать один или несколько IP-адресов серверов DNS, к которым локальный сервер станет обращаться перед тем, как начать выполнение стандартной процедуры преобразования адресов. Опция
forward
допускает одно из двух значений:
only
или
first
. Если вы зададите
forward only
, BIND при работе будет полагаться лишь на удаленный сервер DNS, указанный с помощью опции
forwarders
, и не будет выполнять стандартную процедуру преобразования имен. Значение
first
опции
forward
указывает на то, что BIND должен сначала обратиться к удаленному серверу DNS, а если такое обращение не дало результатов (например, если удаленный сервер не ответил на запрос), он
должен осуществить преобразование имен по стандартному алгоритму. В любом случае, если к серверу поступит запрос на преобразование имен, которые принадлежат зоне, обслуживаемой данным сервером, он будет использовать описание зоны в своем конфигурационном файле.
Описание зоны
При настройке BIND вы должны указать, как следует обрабатывать запросы, в которых указаны определенные домены, поддомены и диапазоны IP-адресов. Различные группы имен и адресов называются зонами. Зоной может быть домен или поддомен (например, зоной является домен
threeroomco.com
, указанный в листинге 18.1) либо диапазон IP-адресов (такой диапазон присутствует в имени зоны, оканчивающемся символами
in-addr.arpa
). Для простого сервера DNS задается лишь несколько зон.
• Корневая зона. Зона, идентифицируемая посредством точки (
"."
), определяет корневой узел пространства имен. В определении зоны присутствует опция t
ype hint
, которая сообщает о том, что список серверов содержится в файле, указанном посредством опции
file
.
• Локальный домен. Если ваш сервер DNS предназначен не только для кэширования, вам придется сконфигурировать BIND для поддержки зоны, соответствующей вашему домену. В листинге примером такой зоны является
threeroomco.com
.
• Обратная зона. Несмотря на то что в большинстве случаев сервер DNS используется для преобразования символьных имен в IP-адреса, сервер имен также должен поддерживать обратное преобразование. Для выполнения подобного преобразования создается зона, имя которой оканчивается на
in-addr.arpa
. Перед этой последовательностью символов указывается имя зоны, т.е. часть IP-адреса, заданная в обратном порядке. Например, запись для сети 192.168.1.0/24 имеет имя
1.168.192.in-addr.arpa
.
В определении зоны указывается тип зоны и список конфигурационных файлов, предоставляющих дополнительную информацию о зоне. Типы зон описаны ниже.
•
master
. Первичный, или ведущий (master), сервер содержит описание зоны. Если вы создаете сервер DNS для небольшой сети, то, вероятнее всего, объявите локальные зоны как master. Пример зоны такого типа приведен в листинге 18.1.
•
slave
. Вторичный, или ведомый (slave), сервер получает информацию о зоне от другого сервера DNS. Такой сервер также может выступать в роли источника информации о зоне. В следующем разделе данный тип зоны будет рассмотрен более подробно. Простой сервер DNS может выступать для некоторых зон как ведущий, а для других зон — как ведомый.
•
stub
. Сервер такого типа похож на ведомый, но он копирует только записи NS, т.е. спецификации сервера имен. Данный тип зоны следует использовать в том случае, если вы хотите создать отдельный сервер DNS для поддомена. Предположим, что домен
threeroomco.com
содержит поддомен
sub.threeroomco.com
и вы хотите использовать для управления им отдельный сервер DNS. Для этого вы должны включить в состав конфигурационного файла сервера BIND для
threeroomco.com
определение зоны с именем
sub.threeroomco.com
типа
stub
, указывающее на сервер DNS
sub.threeroomco.com
. Вы можете также использовать один сервер DNS для поддержки всего домена, включая поддомен
sub.threeroomco.
com. В этом случае вам не понадобится формировать специальную зону
sub.threeroomco.com
.
•
forward
. Подобно опции
forward
в разделе
options
, зона
forward
сообщает BIND, что запросы на получение информации о зоне должны передаваться другому серверу DNS. BIND формирует собственный запрос к указанному серверу, а затем использует полученные данные для построения ответа. Используя зону такого типа, вы должны включить опцию
forwarders
, указывающую BIND, какому из удаленных серверов DNS должны перенаправляться запросы.