Linux: Полное руководство — страница 46 из 98

Каждую зону обслуживает один главный сервер имен, хранящий официальную копию данных о зоне. Он называется «авторитетным», потому что его ответ — точный и окончательный. В зоне может быть также сколько угодно кэширующих серверов, у которых собственных данных нет: они накапливают данные, кэшируя ответы на свои запросы. Ответ кэширующего сервера неавторитетен, зато быстр. Обычно они используются для уменьшения DNS-трафика во внутренней сети.
Если собственного домена у вас нет, то имеет смысл возложить обработку DNS-запросов на провайдера, создав у себя кэширующий DNS-сервер. Вместо того, чтобы запрашивать последовательно несколько удаленных корневых серверов, он будет отсылать в сеть только один запрос на разрешение имени (DNS-серверу провайдера) и получать только один окончательный ответ. Это особенно полезно, если у вас плохое соединение с Интернетом.
13.4.1. Настройка кэширования на DNS-сервере
Для того, чтобы насладиться такой возможностью, следует в блок options файла 
named.conf
 добавить следующие параметры:
forward first;
forwarders {
 81.3.165.35;
 81.3.150.2;
};
Директива forwarders задает заключенный в фигурные скобки список IP-адресов DNS-серверов, которым ваш DNS-сервер будет переадресовывать запросы вместо того, чтобы отвечать на них самому. IP-адреса перечисляются через точку с запятой.
Директива forward может принимать одно из двух следующих значений:
♦only — ваш DNS-сервер никогда не должен предпринимать попыток обработать запрос самостоятельно;
♦first — ваш DNS-сервер должен пытаться сам обработать запрос, если указанные далее параметром forwarders сервера DNS не были найдены.
Без директивы forwarders директива forward не имеет смысла.
Таким образом, возвращаясь к настройке сервера, весь файл 
named.conf
 будет выглядеть так:
Листинг 13.7. Файл named.conf кэширующего сервера DNS
options {
 directory "/var/named";
 forward first;
 forwarders {
  81.3.165.35;
  81.3.150.2;
 };
 // Раскомментируйте следующую строку, если брандмауэр
 // мешает работе службы DNS
 // query-source port 53;
};

zone "." {
 type hint;
 file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
 type slave;
 file " named.local ";
}
Обратите внимание, что в этом примере уже не поддерживается зона dhsilabs.com.
13.4.2. Возможные проблемы и их решение
Как правило, кэширующий сервер запускается на отдельном компьютере, который подключается к Интернету по коммутируемому соединению. Нужно учитывать, что сервер DNS сразу требует обращения к какому-нибудь сетевому ресурсу. В нашем же случае, если соединение не установлено, то устройство 
ppp0
 существовать не будет, a named будет страшно ругаться на то, что сеть недоступна. При этом недоступным окажется даже интерфейс 
lo
, а программа nslookup, если она нам понадобится без существования сети, просто «подвиснет», ожидая ответа от сервера DNS.
Есть два способа решить данную проблему. Какой использовать — это решать вам. Первый заключается в том, чтобы запускать сервер DNS после установления PPP-соединения и останавливать перед его разрывом.
Для управления демоном named служит утилита rndc (ndc в BIND 8). Ее можно использовать с параметрами start, stop, reload (перегрузить файлы данных зоны, если в них произошли изменения), restart. Команду 
rndc start
 следует включить в сценарий установления PPP-соединения, а команду 
rndc stop
 — в сценарий разрыва.
Второй способ состоит в том, чтобы при постоянно работающем сервере DNS подменять файл корневого кэша 
named.ca
. В отсутствие PPP-соединения по этому имени находится пустой файл, а сценарий установки соединения содержит команду, копирующую на его место нормальный файл кэша 
named.ca.ppp-on
. При использовании этого способа в ваших протоколах (журналах) будут регулярно появляться сообщения примерно такого содержания:
Jan 5 16:10:11 den named[10147]: No root nameserver for class IN
Для полноты картины хочу отметить, что, если при использовании DNS у вас возникают проблемы с монтированием удаленных файловых систем, запускайте сервер named после запуска nfsd и mountd.
13.5. Вторичный сервер DNS
Вы когда-нибудь обращали внимание, что у любого уважающего себя провайдера есть два сервера DNS — первичный (primary или master) и вторичный (secondary или slave)? Вторичный сервер копирует данные о зоне с первичного. Эта операция называется зонной пересылкой. В любой зоне должен быть хотя бы один вторичный сервер на тот случай, если с первичным сервером что-нибудь случилось или он просто не в состоянии обработать большое количество запросов клиентов. Получив отказ от первичного сервера, система разрешения имен обращается к вторичному. Для повышения надежности работы службы имен желательно включать вторичный сервер в другую сеть и в другую цепь питания.
Для вторичного сервера DNS. обслуживающего домен dhsilabs.com, секция зоны в файле 
named.conf
 будет выглядеть так:
zone " dhsilabs.com" {
 type slave;
 file " dhsilabs.com";
 masters { 192.168.1.1; 192.168.1.2; };
};
IP-адреса основных серверов DNS вашей сети указываются в директиве masters через точку с запятой. Вторичный сервер, в отличие от кэширующего, всегда должен иметь тип slave.
13.6. Просмотр DNS-зоны. Утилита nslookup
Утилита nslookup, служащая для просмотра информации о зоне (домене), входит в пакет 
bind-utils
 и в популярных дистрибутивах устанавливается по умолчанию. Она есть также в Windows NT/2000/XP.
Зоны бывают разные: одни содержат информацию о компьютерах в домене и служат для преобразования имени компьютера в IP-адрес и наоборот, другие содержат информацию о корневых серверах — зона «.». Последняя зона относится к типу hint — подсказка. Зоны для разрешения имен обычно имеют тип master (главный), а зоны вторичных серверов относятся к типу slave (подчиненный). Обычно просмотр зоны разрешается только определенным, доверенным узлам. Итак, запустите nslookup:
# nslookup
Default Server: ns4.obit.ru
Address: 81.3.165.35
>
Для того, чтобы получить информацию от сервера, нужно ввести в строку приглашения тип запроса: 
set q=<тип>
 (или 
set type=<тип>
). Типы запросов перечислены в таблице 13.2.

Типы запросов Таблица 13.2


    






    

        
Оглавление

        
К карточке книги

        
    















ТипОписание
soaНачало полномочий
aПреобразование имени в IP-адрес узла
aaaaОтображение IPv6-адреса узла
nsОтображение информации о сервере DNS
ptrПреобразование IP-адреса в имя узла
whsРаспространенные службы
hinfoИнформация об аппаратном обеспечении узла
mxИнформация о почтовых серверах домена
txtОтображение записи общего назначения
cnameОтображение канонического имени