Денис Колисниченко - Linux: Полное руководство

Таким образом, возвращаясь к настройке сервера, весь файл 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.

Как правило, кэширующий сервер запускается на отдельном компьютере, который подключается к Интернету по коммутируемому соединению. Нужно учитывать, что сервер 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.

Вы когда-нибудь обращали внимание, что у любого уважающего себя провайдера есть два сервера 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.

Утилита 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

Теперь рассмотрим несколько практических примеров. Допустим, вы знаете имя узла — www.server.com. Давайте посмотрим, какая информация будет выведена при указании типа any:

>set q=any

>server.com

Server: myserver.domain.com

Address: 127.0.0.1

Non-authoritative answer:

server.com nameserver = comp1.server.com

server.com nameserver = comp2.server.com

server.com nameserver = comp3.server.com

Authoritative answers can be found from:

server.com nameserver = comp1.server.com

server.com nameserver = comp2.server.com

server.com nameserver = comp3.server.com

comp1.server.com internet address = 323.111.200.1

comp2.server.com internet address = 323.111.200.2

comp3.server.com internet address = 323.555.200.3

А сейчас посмотрим информацию о других узлах в этой сети:

>ls server.com.

[comp2.server.com]

server.com. 323.111.200.2

server.com. server = comp1.server.com

server.com. server = comp2.server.com

server.com. server = comp3.server.com

mail 323.111.200.17

gold 323.111.200.22

www.ie 323.111.200.11

jersild 323.111.200.25

comp1 323.111.200.1

comp3 323.111.200.3

parasit3 323.111.200.20

www.press 323.111.200.30

comp1 323.111.200.1

www 323.111.200.2

Но ответ мог быть и таким:

[server.com]

Can't list domain server.com: Query refused