Родерик Смит - Сетевые средства Linux
Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи 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. В этом случае сервер прекратит попытки преобразования, если серверы, указанные в качестве значения forwarders, окажутся не доступными.
ВниманиеЕсли вы включите в состав конфигурационного файла корневую зону и зададите опцию forward first, то в случае, когда серверы, предназначенные для перенаправления запроса, станут не доступны, BIND предпримет попытку выполнения стандартной процедуры преобразования адресов. Само по себе это неплохо, но при этом процедура выявления ошибки и генерации соответствующего сообщения окажется длительной. В особенности этот будет заметно в том случае, если соединение с Internet осуществляется посредством линии с большой задержкой.
Ранее в данной главе упоминались серверы, предназначенные лишь для кэширования результатов преобразований. Эти серверы занимают меньше памяти, чем BIND, тем не менее, они используются достаточно редко. Причина в том, что BIND поставляется в составе многих дистрибутивных пакетов и гораздо проще в настройке по сравнению с другими серверами. Если вы захотите сэкономить ресурсы, вы можете вместо BIND использовать dnscache или pdnsd.
Сконфигурировав и запустив сервер имен (либо полнофункциональный, либо предназначенный только для кэширования), вам необходимо указать его IP-адрес для всех компьютеров, которые должны работать с ним. Если вы забудете сделать это, узлы вашей сети по-прежнему будут обращаться к внешним серверам DNS.
Взаимодействие с сервером DHCP
Если в вашей сети IP-адреса распределяются посредством сервера DHCP, вы не сможете задавать фиксированные адреса в конфигурационном файле зоны, так как адрес, выделенный клиенту DHCP, становится известным лишь при его загрузке и может измениться при следующей загрузке. В главе 5 рассматривались два решения этой проблемы: настройка сервера DHCP для предоставления клиенту одного и того же IP-адреса и настройка DHCP и серверов DNS для совместной работы. Если вы выберете первый способ, т.е. сконфигурируете сервер DHCP так, что он будет выделять конкретным клиентам фиксированные IP-адреса, вам придется уделять много внимания сопровождению этих серверов. Предположим, что вам необходимо указать, что компьютеру birch.threeroomco.com должен соответствовать адрес 192.168.1.2. Для этого вам надо изменить как конфигурационный файл сервера DHCP, так и конфигурационные файлы зон сервера DNS, используемых для прямого и обратного преобразования. При этом приходится следить за тем, чтобы значения в обоих файлах совпадали. Несмотря на то что данное решение реализуется относительно просто, для больших доменов оно неприемлемо.
В главе 5 рассматривалась конфигурация сервера DHCP для совместной работы с сервером DNS. Чтобы соответствующим образом настроить BIND, вам надо внести изменения в файл named.conf. Вы должны добавить в определение соответствующей зоны опцию allow-update. В результате определение зоны примет следующий вид:
zone "threeroomco.com" {
type master;
file "named.threeroomco.com";
allow-update { 192.168.1.1; }
};
Теперь BIND будет принимать информацию об IP-адресах от компьютера с адресом 192.168.1.1. Как нетрудно догадаться, это должен быть адрес узла сети, на котором выполняется сервер DHCP. Аналогичные изменения надо внести в определение обратной зоны.
ВниманиеЕсли ваш сервер DNS доступен из Internet или если вы не полностью доверяете пользователям локальной сети, получение информации об обновлении DNS-данных представляет угрозу безопасности системы. Хакер может взломать сервер DHCP или, фальсифицировав адрес, внести необходимые ему изменения в конфигурацию сервера DNS. Чтобы уменьшить опасность атаки, желательно разместить серверы DNS и DHCP на одном компьютере и разрешить обновление только с локального узла (127.0.0.1).
Запуск и тестирование сервера
Для запуска сервера DNS можно применить любой из способов, рассмотренных в главе 4, но чаще всего сервер DNS запускается с помощью сценария SysV или локального сценария запуска. Запуск сервера DNS посредством суперсервера снизит скорость преобразования имен.
Для тестирования сервера имен хорошо подходит инструмент host. Программа host поставляется в составе большинства версий Linux; обычно она располагается в пакете bind-utils. Данная утилита передает указанному серверу DNS запросы на преобразование имен. В простейшем случае host взаимодействует с сервером, указанным в файле /etc/resolv.conf на том компьютере, на котором она выполняется. Для вызова данной программы надо ввести ее имя, а также имя узла либо IP-адрес.
$ host www.awl.com
www.awl.com is a nickname for awl.com
awl.com has address 165.193.123.224
В данном примере первая строка, отображаемая программой, сообщает о том, что www.awl.com представляет собой каноническое имя (заданное с помощью записи CNAME) узла awl.com. Этот компьютер имеет адрес 165.193.123.224. Такой тест подтверждает, что сервер DNS может преобразовывать имена внешних узлов. Если вы сконфигурировали сервер для поддержки собственного домена, вы должны указать при проверке локальные имя и адрес. Убедитесь в том, что сервер выполняет как прямое, так и обратное преобразование. При необходимости вы также можете просмотреть записи требуемого типа, задавая при вызове утилиты опцию -t. Например, чтобы проверить записи MX для домена, вам потребуется выполнить следующую команду:
