отсутствуют. Эти записи применяются для обратного преобразования и будут рассматриваться ниже.
•
NS
. Запись
NS
(name server — сервер имен) задает сервер имен для домена. В конфигурационном файле должна присутствовать хотя бы одна запись
NS
, указывающая на компьютер, заданный в качестве ведущего сервера имен в записи
SOA
. В поле имени данной записи указывается либо имя домена, либо символ
@
. IP-адрес компьютера, содержащего сервер имен, задается с помощью записи
А
.
•
MX
.
Запись
MX
(mail exchanger — обмен почтой) предоставляет информацию о почтовом сервере для зоны. В поле имени этой записи указывается символ
@
либо имя домена. В поле содержимого записи содержатся два компонента: код приоритета и имя узла. Когда удаленный почтовый сервер собирается передать сообщение пользователю в домене (например,
lorax@threeroomco.com
), он запрашивает у сервера имен записи MX. Затем уделенный сервер пытается связаться с компьютером, для которого указано наименьшее значение приоритета (в листинге 18.2 это
birch.threeroomco.com.
). Если этот компьютер не доступен, удаленный сервер предпринимает попытку установить соединение с тем узлом, приоритет которого выражается следующим по величине значением (в листинге 18.2 это
mail.pangaea.edu.
). Перебор компьютеров продолжается до тех пор, пока сообщение не будет доставлено либо пока не выяснится, что все узлы, указанные в записях
MX
, не доступны. Очевидно, что компьютер, имя которого задано в записи
MX
, должен быть настроен для приема почты. Вопросы передачи почтовых сообщений будут рассматриваться в главе 19.
Совет
Некоторые типы записей указывают на компьютеры, расположенные за пределами домена. Так, например, вы можете задать в качестве почтового сервера узел внешней сети.
В листинге 18.2 приведены примеры многих из перечисленных выше записей. В реальном конфигурационном файле зоны содержится информация о гораздо большем количестве компьютеров.
Конфигурация зоны для обратного преобразования
В листинге указано несколько зон, некоторые из них предназначены для обратного преобразования. Эти зоны позволяют серверу DNS определять доменное имя по IP-адресу. Для того чтобы это стало возможным, необходимо создать псевдодомен
in-addr.arpa
. В файле
/etc/named.conf
содержатся указатели на конфигурационные файлы, описывающие подмножества этого домена. Поскольку имя домена уточняется при движении справа налево, а IP-адрес уточняется по мере движения слева направо, в имени псевдодомена адрес должен быть указан в обратном порядке. Например, имя зоны для диапазона адресов 192.168.1.0/24 будет иметь вид
1.168.192.in-addr.arpa
.
Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи
SOA
и
NS
, но основное место в нем занимают записи
PTR
. При обратном преобразовании не возникает необходимость в записях
MX
, А и
CNAME
. В листинге 18.3 содержится конфигурационный файл обратной зоны, соответствующий файлу, приведенному в листинге 18.2.
В поле имени записи PTR указывается либо сокращенный вариант адреса (например, 1 для 192.168.1.1), либо полный IP-адрес, расположенный в обратном порядке и сопровождаемый именем
in-addr.arpa
. В листинге 18.3 продемонстрированы оба подхода. В поле содержимого включается полное доменное имея с точкой в конце.
Поскольку обратная зона отличается от зоны, используемой для прямого преобразования, попытка задать в поле содержимого сокращенное имя приведет к некорректному преобразованию, например, при указании
birch
вместо
birch.threeroomco.com.
будет получен результат
birch.1.168.192.in-addr.arpa
.
Листинг 18.3. Пример конфигурационного файла обратной зоны
1.168.192.in-addr.arpa. IN SOA spruce.threeroomco.com. \
admin.threeroomco.com. (
2002043004 ; serial
3600 ; refresh
600 ; retry
604800 ; expire
86400 ; default_ttl
)
1 IN PTR gingko.threeroomco.com.
2.1.168.192.in-addr.arpa. IN PTR birch.threeroomco.com.
3.1.168.192.in-addr.arpa. IN PTR spruce.threeroomco.com.
4.1.168.192.in-addr.arpa. IN PTR threeroomco.com.
@ IN NS spruce.threeroomco.com.
Настройка сервера, предназначенного только для кэширования
В небольших сетях часто используются серверы DNS, основная задача которых — кэширование результатов преобразования имен. Сервер такого типа не поддерживает конкретный домен (за исключением домена для обратного преобразования
localhost
). Вместо этого сервер перенаправляет запросы внешним серверам DNS и записывает полученные от них сведения в кэш. Такая конфигурация сервера может ускорить работу клиент-программ, в частности, Web-броузеров, если сеть связана с Internet посредством линий с низкой пропускной способностью или большой задержкой. Так, например, линия спутниковой связи характеризуется задержкой порядка половины секунды при двусторонней передаче данных. Задержка при использовании коммутируемых линий составляет около 200 миллисекунд, что лучше, чем для линий спутниковой связи, но все же существенно замедляет преобразование имен.
Следует заметить, что время преобразования снижается только в том случае, когда необходимые данные уже содержатся в кэше сервера. Поэтому рассматриваемую здесь конфигурацию имеет смысл использовать только в сетях с относительно большим количеством пользователей, которые часто обращаются к одним и тем же узлам глобальной сети.
Основной конфигурационный файл сервера, предназначенного лишь для кэширования, имеет тот же формат, что и файл, представленный в листинге 18.1, однако в нем присутствует лишь определение зоны, предназначенной для обратного преобразования
localhost
(
0.0.127.in-addr.arpa
), и корневой зоны (
.
). Даже эти зоны не являются обязательными.
Наиболее важными компонентами конфигурационного файла сервера DNS, предназначенного только для кэширования, являются опции
forwarders
и
forward
, расположенные в разделе
options
. Опция
forwarders
должна содержать список серверов DNS провайдера. BIND использует эти серверы для выполнения преобразования. Вместо выражения
forward first
, приведенного в листинге 18.1, необходимо указать
forward only
. В этом случае сервер прекратит попытки преобразования, если серверы, указанные в качестве значения