Глава 13. DNS — служба имен. Linux. Полное руководство.

Linux. Полное руководство.

Глава 13. DNS — служба имен.

13.1. Введение в DNS.

Перед началом настройки DNS-сервера давайте разберемся, как он работает. Пространство имен DNS — это иерархическая древовидная структура доменов. Корень дерева доменов обозначается «.». Под ним находятся домены верхнего уровня. Наиболее известные из них вы знаете: com, gov, net, org и т.п. Выделением имен доменов верхнего уровня занимается ICANN — International Corporation for Assigned Names and Numbers. Администрация домена регистрирует домены следующего уровня и так далее.

Всемирная система доменных имен представляет собой распределенную базу данных. Каждый компьютер, подключенный к сети, является клиентом этой базы, а некоторые компьютеры — серверами.

Допустим, пользователь вводит в окне браузера адрес: http://www.yahoo.com. Чтобы установить соединение с компьютером www.yahoo.com, компьютеру пользователя необходимо знать его IP-адрес, поэтому операционная система пользователя пытается разрешить (перевести) имя компьютера в IP-адрес. С этой целью она обращается к серверу DNS. Сервер DNS сначала пытается разрешить имя данного компьютера, используя свой собственный кэш имен. Если требуемое имя компьютера в нем отсутствует, то сервер DNS должен получить его у другого сервера DNS, поэтому база данных DNS и называется распределенной.

Сначала первичный сервер обращается к одному из корневых серверов, список IP-адресов которых находится в его конфигурационных файлах (конкретно, в файле named.ca). Далее запрос обрабатывается рекурсивно: корневой сервер знает имена и IP-адреса официальных серверов DNS всех доменов второго уровня и перенаправляет запрос к серверу, который отвечает за домен com, а тот, в свою очередь, — к серверу DNS домена yahoo.com.

Сервер DNS домена yahoo.com возвращает IP-адрес компьютера www — 64.58.76.222 или все адреса, которые сопоставлены этому имени (многие сетевые операционные системы, в том числе и Linux, позволяют одному имени сопоставлять несколько IP-адресов).

На самом деле, если выполнить разрешение имени www.yahoo.com, то сервер DNS возвратит следующие адреса: 64.58.76.222. 64.58.76.228. 64.58.76.223. 64.58.76.176. 64.58.76.224. 64.58.76.177. 64.58.76.227. 64.58.76.179. А официальное, или каноническое, имя компьютера www.yahoo.com — www.yahoo.akadns.net.

13.2. Настройка клиента DNS.

Разрешение имен на стороне DNS-клиента выполняет модуль распознавания (резолвер). В ОС Linux он представляет собой набор библиотечных функций. Конфигурационным файлом распознавателя служит /etc/resolv.conf, содержащий список DNS-серверов (от 1 до 3), которым можно посылать запросы:

Search subdomain.domain.com domain.com.

Nameserver 127.0.0.1 ; сервер по умолчанию.

; на локальном компьютере.

Nameserver 81.3.165.35; запасной — у провайдера.

Директива search используется для поиска компьютера в том случае, если указано только имя узла без домена. Например, если вы введете в окне броузера http://host, то сначала будет выполнена попытка обращения к узлу host.subdomatn.domain.com, а потом, если узел не будет найден, к узлу host.domain.com.

Комментариев в файле resolv.conf не полагается: произвольный текст можно вписывать только в строки с директивами nameserver после IP-адреса.

Кроме сервера имен, функции распознавателя могут просматривать и другие источники данных: файл /etc/hosts, СУБД NIS и т.п. Порядок просмотра определен в файле переключения служб /etc/nsswitch.conf:

Hosts: files dns.

13.3. Настройка сервера DNS.

Локальная сеть с выходом в Интернет может пользоваться сервером имен, работающим на компьютере провайдера. Но, учитывая типичную для бывшего СССР скорость соединения, при которой на обращение к серверу DNS провайдера требуется от 10 до 30 секунд, имеет смысл установить собственный сервер DNS — обычно на шлюзе, который используется для выхода в Интернет.

Внутренняя сеть (intranet) может обойтись и файлами /etc/hosts, но при большом количестве узлов целесообразно завести DNS-сервер и для нее.

Самый известный сервер имен для Linux — это демон named из пакета BIND (Berkeley Internet Name Daemon). Вам понадобится установить еще пакет bind-libs с необходимыми библиотеками и bind-utils, содержащий утилиты командной строки (dig, host, nslookup).

Существуют три версии пакета BIND: 4, 8 и 9 (версий 5-7 никогда не было). Сейчас везде используется девятая версия, о которой я и буду рассказывать.

Для установки девятой версии BIND требуются:

♦ ядро 2.4 или выше;

♦ библиотека OpenSLL.

Для работы сервера должен быть активизирован сервис network.

Основным конфигурационным файлом named служит named.conf, который устанавливается по умолчанию в /etc для версии 9 или в /etc/namedb (версия 8). Синтаксис этого файла подобен языку С (листинг 13.1).

Листинг 13.1. Примерный файл named.conf.

Logging {

category cname {null; };

};

Options {

directory "/var/named";

};

Zone "." {

type hint;

file "named.ca";

};

Zone "dhsilabs.com" {

type master;

file "dhsilabs.com";

notify no;

};

Zone "0.0.127.in-addr.arpa" {

type master;

file "named.local";

};

Zone "1.168.192.in-addr.arpa" {

type master;

file "192.168.1";

notify yes;

};

Рассмотрим этот пример подробнее. Обслуживаемая сервером зона (домен без поддоменов) — dhsilabs.com. Рабочий каталог сервера, от которого отсчитываются относительные пути файлов, — /var/named. Именно в этом каталоге сервер будет искать файлы dhsilabs.com, named.local, 192.168.1, named.ca.

Блок logging определяет опции протоколирования. За ним следует задание параметров самого сервера — блок options. Параметр directory определяет рабочий каталог сервера. Этот параметр обязателен, но кроме него в блоке options могут присутствовать и другие (forwarders, forward и т.п.), о которых будет сказано несколько позже.

После блока параметров должны быть перечислены зоны, обслуживаемые сервером. Мы будем обслуживать зону dhsilabs.com. Информация об этой зоне хранится в файле /var/named/dhsilabs.com, с помощью которого наш сервер будет преобразовывать имена компьютеров в IP-адреса. Для обратного преобразования служит файл /var/named/192.168.1.

Зоны «.» и «0.0.127.in-addr.arpa» — особые. Я не буду их подробно описывать: их назначение вы поймете из дальнейшего текста главы. Файл named.local — это файл обратного соответствия, предназначенный для преобразования IP-адресов в имена, то есть, в частности, он используется для преобразования адреса 127.0.0.1 в имя localhost.

Файл named.ca содержит набор IP-адресов корневых DNS-серверов. При разрешении имени в IP-адрес или наоборот полученная информация кэшируется и остается в памяти сервера определенное время. В дальнейшем, если нужно разрешить имя в IP-адрес или наоборот, ваш DNS-сервер сначала будет искать необходимую ему информацию в кэше. Если ее там не окажется, то сервер обратится к одному из корневых серверов DNS.

Файл named.ca необходимо регулярно обновлять, чтобы он всегда содержал свежие данные (первый раз его нужно обновить сразу же после установки сервера, несмотря на то, что этот файл будет только что создан). Если ваш DNS-сервер предназначен для обслуживания только внутренней сети без выхода в Интернет, то зону корневых серверов нужно удалить.

Файл данных сервера имен dhsilabs.com непосредственно служит для преобразования имен в IP-адреса (листинг 13.2).

Записи в этом файле называются записями ресурсов. Формат записи ресурса следующий:

[имя_домена] [TTL] <тип_сети> <тип_записи> <данные>

Где:

♦ Имя_домена обязательно для первой записи в файле, оно всегда должно начинаться с первой колонки. Для следующих записей это поле можно опускать. Символ @ обозначает текущий домен.

♦ Необязательное поле TTL (Time to Live) — это время в секундах, в течение которого данные в кэше считаются достоверными. Если значение не указано, то оно берется из записи SOA (см. ниже).

♦ Тип_сети может содержать значение IN (Internet) или HS (информационная служба Hesiod).

♦ Тип_записи: типы записи ресурсов приведены в таблице 13.1. Остальные поля данных зависят от типа записи ресурса.

Пустые строки и строки, начинающиеся с точки с запятой, считаются комментариями.

Листинг 13.2. Файл dhsilabs.com.

@ IN SOA den.dhsilabs.com. host.master.dhsilabs.com. (

93011120 ; серийный номер.

10800 ; обновление каждые 3 часа.

3600 ; повтор каждый час.

3600000 ; хранить информацию 1000 часов.

86400) ; TTL записи - 24 часа.

IN NS den.dhsilabs.com.

IN A 192.168.1.1.

IN MX 150 den.dhsilabs.com.

Den IN A 192.168.1.1.

IN HINFO INTEL CELERON (LINUX).

IN MX 100 den.

IK MX 150 evg.dhsilabs.com.

Ns IN CNAME den.dhsilabs.com.

Www IN CNAME den.dhsilabs.com.

Ftp IN CNAME den.dhsilabs.com.

Mail IN CNAME den.dhsilabs.com.

Evg IN A 192.168.1.2.

IN MX 100 den.dhsilabs.com.

Localhost IN A 127.0.0.1.

Тип записи SOA (Start of Authority) означает начало зоны. Для каждой зоны такая запись единственна и должна стоять первой по порядку. Она содержит имя зоны, почтовый адрес ее администратора (где знак @ заменен на «.») и параметры обновления данных. Круглые скобки служат для разбиения одной записи на несколько строк.

Имя домена может быть сокращенным или полным. Полностью определенные имена заканчиваются символом точки. Если точки нет, то имя считается сокращенным и к нему автоматически добавляется имя текущего домена: так, den.dhsilabs.com без точки будет интерпретировано как den.dhsilabs.com.dhsilabs.com. He делайте этой распространенной ошибки, не забывайте ставить точку после имени домена.

Серийный номер — это число, на которое ориентируются подчиненные серверы, перезапрашивая данные у главного сервера зоны в том случае, если его серийный номер больше, чем у них. Обычно номер представляет собой дату последнего изменения файла данных зоны.

Типы записи ресурсов Таблица 13.1.

Запись	Назначение
SOA	Начало полномочий: определение DNS-зоны
NS	Определение сервера имен
A	IP-адрес (IPv4), соответствующий имени компьютера. Для IPv6-адресов используется тип A6
PTR	Обратное преобразование: имя компьютера, соответствующее IP-адресу
MX	Mail exchange: почтовый сервер, обслуживающий домен. Можно перечислить несколько почтовых серверов, указав приоритет: чем меньше число, тем приоритет выше
CNAME	Каноническое имя узла, к которому преобразуются псевдонимы: так, по адресу http://www.dhsilabs.com обращение будет производиться к den.dhsilabs.com
HINFO	Информация об узле: операционной системе и аппаратном обеспечении. Рекомендую не заполнять эту запись или использовать заведомо неправильные данные. Чем меньше информации о вашей сети получит злоумышленник, тем сложнее ему будет атаковать ее
TXT	Произвольный текст — комментарии или нестандартная информация

Содержание файлов обратного преобразования, устанавливающих соответствие между IP-адресами и именами при помощи записей типа PTR, приведено в листингах 13.3 и 13.4. Внимание! IP-адреса указываются в обратном порядке: 2.1.168.192. Если указан неполный IP, например, 1, то к нему будет добавлен адрес подсети 1.168.192.

Листинг 13.3. Файл named.local.

@ IN SOA dhsilabs.com. root. dhsilabs.com. (

199609203 ;серийный номер.

28800 ;обновление каждые 8 часов.

7200 ;повтор каждые 2 часа.

604800 ;хранить информацию 168 часов (1 неделю).

86400) ;TTL записи - 24 часа.

NS dhsilabs.com.

1 PTR localhost.

Листинг 13.4. Файл 192.168.1.

@ IN SOA den.dhsilabs.com. hostmaster.dhsilabs.com. (

93011120 ; серийный номер.

10800 ; обновление каждые 3 часа.

3600 ; повтор каждый час.

3600000 ; хранить информацию 1000 часов.

86400 ) ; TTL записи - 24 часа.

@ IN NS den.dhsilabs.com.

1 IN PTR den.dhsilabs.com.

2.1.168.192 IN PTR evg.dhsilabs.com.

13.3.1. Обновление корневого кэша.

Если вы настраиваете сервер DNS только для своей внутренней сети, которая не имеет выхода в Интернет, то не спешите обновлять файл кэша! Он вам вообще не нужен. Вы также должны удалить зону, описывающую корневой кэш в файле named.conf.

Обычно файл named.ca содержит примерно такую информацию:

Листинг 13.5. Файл корневых серверов.

. 6D IN NS G.ROOT-SERVERS.NET.

. 6D IN NS J.ROOT-SERVERS-NET.

. 6D IN NS K.ROOT-SERVERS.NET.

. 6D IN NS L.ROOT-SERVERS.NET.

. 6D IN NS M.ROOT-SERVERS.NET.

. 6D IN NS A.ROOT-SERVERS.NET.

. 6D IN NS H.ROOT-SERVERS.NET.

. 6D IN NS B.ROOT-SERVERS.NET,

. 6D IN NS C.ROOT-SERVERS.NET.

. 6D IN NS D.ROOT-SERVERS.NET.

. 6D IN NS E.ROOT-SERVERS.NET.

. 6D IN NS I.ROOT-SERVERS.NET.

. 6D IN NS F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:

G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4.

J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10.

K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129.

L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12.

M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33.

A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4.

H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53.

B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107.

C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12.

D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90.

E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.23 0.10.

I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17.

F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241.

Для установки файла корневого кэша следует установить пакет caching-nameserver, но я рекомендую получить и установить самую новую версию. Для этого подключитесь к Интернету, запустите сервер DNS, а затем выполните команду.

# nslookup | tee ns.

В ответ на приглашение утилиты nslookup введите две команды:

> set q=ns (или set type=ns).

> .

На экране вы увидите список корневых серверов DNS, который будет помешен в файл ns. Для преобразования файла ns в формат named.ca воспользуйтесь следующим awk-сценарием (листинг 13.6), вызвав его так:

# reformat ns named.ca.

Листинг 13.6. Сценарий reformat.

#!/bin/awk awk ' BEGIN {

/root/ { print ". IN NS " $4"." }.

/internet/ { print $1"." " 999999 IN A " $5 }.

END '.

Теперь осталось скопировать named.ca в каталог /var/named, и на этом — все.

Можно обновить корневой кэш и проще, воспользовавшись утилитой dig:

# dig @a.root-servers.net.ns > named.ca.new.

Или.

# dig @198.41.0.4.ns > named.ca.new.

После этого остается только заменить старый файл named.ca новым файлом named.ca.new.

13.4. Кэширующий сервер DNS.

Каждую зону обслуживает один главный сервер имен, хранящий официальную копию данных о зоне. Он называется «авторитетным», потому что его ответ — точный и окончательный. В зоне может быть также сколько угодно кэширующих серверов, у которых собственных данных нет: они накапливают данные, кэшируя ответы на свои запросы. Ответ кэширующего сервера неавторитетен, зато быстр. Обычно они используются для уменьшения 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	Отображение канонического имени
any	Отображение всех ресурсных записей

Теперь рассмотрим несколько практических примеров. Допустим, вы знаете имя узла — 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.

Чтобы разрешить передачу зоны определенным узлам (а, значит, запретить всем остальным), в файле конфигурации DNS-сервера применяется директива allow-transfer. В следующем примере трансфер зоны разрешен узлам 10.1.1.1 и 10.1.2.1, то есть все остальные узлы в ответ на запрос nslookup ls получат ответ «Query refused»:

Options {

allow-transfer {

10.1.1.1;

10.1.2.1;

};

Вторичный сервер DNS не передает никакой информации о зоне, поэтому обязательно укажите следующую строку в его файле конфигурации (в секции options):

Allow-transfer { none; }.

13.7. Оптимизация настроек сервера DNS.

Как любой хороший администратор, вы хотите, чтобы ваш сервер DNS быстро обслуживал запросы клиентов. Но к вашему серверу могут подключаться пользователи не из вашей сети, а, например, из сети конкурирующего провайдера. Тогда ваш сервер будет обслуживать «чужих» клиентов. Непорядок! Директива allow-query позволяет указать адреса узлов и сетей, которым можно использовать наш сервер DNS:

Allow-query { 192.168.1.0/24; localhost; };

В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целесообразно разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:

Allow-recursion { 192.168.1.0/24; localhost; };

Обычно взлом любой сети начинается со сбора информации — о структуре сети, об установленном программном обеспечении и его версиях и т.п. Мы можем заставить сервер DNS не сообщать номер своей версии, а выдавать произвольное сообщение:

Version "Made in USSR";

Все перечисленные директивы должны быть указаны в секции options файла конфигурации /etc/named.conf:

Options {

allow-query { 192.168.1.0/24; localhost; };

allow-recursion { 192.168.1.0/24; localhost; };

allow-transfer { 10.1.1.1; 10.1.2.1; };

version "Made in USSR";

}

13.8. Защита сервера DNS.

13.8.1. Настройка и запуск DNS-сервера в chroot-окружении.

Из соображений безопасности рекомендуется запускать все сетевые сервисы в так называемом chroot-окружении (change root). Это файловая система, повторяющая структуру корневой файловой системы, но содержащая только те файлы, которые необходимы для запуска нашего сетевого сервиса. Взломав сетевой сервис и получив доступ к корневой файловой системе, злоумышленник не сможет повредить всей системе в целом, поскольку он получит доступ только к файлам данного сервиса. Некоторые сетевые службы не могут работать в chroot-окружении. BIND — может, и сейчас я покажу, как это организовать.

Не нужно создавать отдельный раздел на диске для каждого сетевого сервиса: нужно только создать каталог, например, root-dns, в который вы скопируете все файлы, необходимые для запуска сервера DNS. Потом, при запуске сервиса, будет выполнена команда chroot для этого сервиса, которая подменит файловую систему. А так как в каталоге root-dns, который станет каталогом /, имеются все необходимые файлы для работы BIND, то для сервиса запуск и работа в chroot-окружении будут совершенно прозрачными.

Сразу нужно оговорить, что настраивать chroot-окружение мы будем для девятой версии BIND, поскольку это значительно проще, чем для восьмой версии. В отличие от восьмой версии, где для настройки chroot-окружения нужно было копировать все бинарные файлы или библиотеки, необходимые для запуска BIND, для работы девятой версии достаточно скопировать только файлы конфигурации и зон, обслуживаемых сервером.

Создайте каталоги корневой файловой системы сервера DNS:

# mkdir -p /root-dns.

# mkdir -p /root-dns/etc.

# mkdir -p /root-dns/var/run/named.

# mkdir -p /root-dns/var/named.

Остановите сервер DNS, если он запущен:

# service named stop.

Переместите файл конфигурации, файлы зон и файл /etc/localtime (он нужен для корректной работы сервера DNS со временем) в каталог /root-dns:

# mv /etc/named.conf /root-dns/etc/

# mv /var/named/* /root-dns/var/named/

# chown named.named /chroot/etc/named.conf.

# chown -R named.named /root-dns/var/named/*

Защитите от редактирования и удаления файл конфигурации:

# chattr +i /root-dns/etc/named.conf.

Добавьте в файл /etc/sysconfig/named строку:

ROOTDIR="/root-dns/".

Все, теперь можно запустить сервер named:

# service named start.

Проверьте, все ли сделано правильно:

$ ps -ax | grep named.

5380 ? S 0:00 named -u named -t /root-dns/

5381 ? S 0:00 named -u named -t /root-dns/

5382 ? S 0:00 named -u named -t /root-dns/

13.9. Использование подписей транзакций. Механизм TSIG.

В девятой версии BIND появилась возможность создавать подписи транзакций (TSIG — Transaction SIGnatures). Механизм TSIG работает так: сервер получает сообщение, подписанное ключом, проверяет подпись и, если она «правильная», сервер отправляет ответ, подписанный тем же ключом.

Механизм TSIG очень эффективен при передаче информации о зоне, уведомлений об изменении зоны и рекурсивных сообщений. Согласитесь, проверка подписи надежнее, чем проверка IP-адреса. Злоумышленник может вывести из строя вторичный сервер DNS банальной атакой на отказ, и, пока администратор будет «поднимать» вторичный сервер, он заменит свой IP-адрес адресом вторичного сервера. При использовании TSIG задача злоумышленника значительно усложняется: ведь ему придется «подобрать» 128-битный MD5-ключ, а вероятность такого подбора близка к нулю.

Итак, приступим к настройке. Остановите сервис named.

Сгенерируйте общие ключи для каждой пары узлов. Общие ключи используются при «общении» первичного и вторичного серверов DNS.

[root@dns] # dnssec-keygen -a hmac-md5 -b 128 -n HOST ns1-ns2 Kns1-ns2.+157+49406.

Мы используем алгоритм HMAC-MD5, 128-битное шифрование, ns1-ns2 — это имя ключа. После выполнения этой команды будет создан файл Kns1-ns2.+176+40946.private. Откройте его в любом текстовом редакторе. Вы увидите примерно следующее:

Private-key-format: v1.2.

Algorithm: 157 (HMAC_MD5).

Key: ms7dfts87Cjhj7FD91k7a3==

Ключ «ms7dfts87Cjhj7FD91k7a3==» и будет тем секретом, который будет передаваться между серверами. Запишите это значение на бумаге (которую потом нужно будет уничтожить) и удалите файлы Kns1-ns2.+157+49406.key и Kns1-ns2.+157+49406.private.

Добавьте в файлы конфигурации первичного и вторичного серверов DNS директивы, указывающие на использование ключа (листинги 13.8 и 13.9).

Листинг 13.8. Фрагмент файла named.conf первичного сервера DNS.

Key ns1-ns2 {

algorithm hmac-md5;

secret "ms7dfts87Cjhj7FD91k7a3==";

};

# прописываем вторичный сервер DNS — 192.168.1.2:

Server 192.168.1.2 {

keys { ns1-ns2; };

};

Options {

# разрешаем передачу зоны вторичному серверу DNS.

allow-transfer { 192.168.1.2; };

};

Листинг 13.9. Фрагмент файла named.conf вторичного сервера DNS.

Key ns1-ns2 {

algorithm hmac-md5;

secret "ms7dfts87Cjhj7FD91k7a3==";

};

# прописываем первичный сервер DNS — 192.168.1.1:

Server 192.168.1.1 {

keys { ns1-ns2; };

};

Options {

# никому не передаем зону.

allow-transfer { none };

};

Можно также настроить передачу зоны «по ключу». Для этого директива allow-transfer в файле конфигурации первичного сервера DNS должна выглядеть так:

Allow-transfer { key ns1-ns2; };

Осталось только «спрятать» файлы конфигурации обоих серверов DNS от посторонних глаз — ведь они содержат ключи в открытом виде.

Chmod 600 named.conf.

Запустите сервис named. Теперь о его безопасности будет заботиться TSIG.

Оглавление.