Конфигурирование DNS-сервера BIND

Данное руководство описывает механизмы конфигурирования DNS-сервера BIND 8.х и выше. Рассматриваются не только вопросы настройки сервера, доменных зон, но и ряд функциональных возможностей, повышающих безопасность работы данного сервиса.

Введение

DNS-сервис является одним из важных сервисов для нормального функционирования Internet сети. Его основная задача состоит в определении соответствия между сетевыми адресами узлов сети и их удобочитабельными названиями. Существует два варианта определения этого соответствия - прямое и реверсивное определение. При прямом разрешении DNS-сервер по имени определяет и выдает сетевой адрес, а при реверсивном - по адресу ищет соответствующее имя. Это необходимо учитывать при настройке DNS-сервиса, поскольку для осуществления данных механизмов используются разные таблицы.

В операционной системе Sun Solaris, как, в прочем, и в других UNIX-системах, в качестве DNS-сервера используется BIND-сервер версии 8.х и выше. Хотя, нужно заметить, в Solaris-е есть возможность использования и сервера версии 4.х. Система определяет какой версии DNS-сервер запускать по тому, какой конфигурационный файл существует в каталоге /etc. Если используется файл - named.boot, то запускается старая версия сервиса, а если - named.conf - то, соответственно, новая (в Solaris 9 старой версии уже нет). Лучше естественно использовать BIND 8.х и выше. Если у вас остались конфигурационные файлы named.boot и вы хотите перевести ваш DNS-сервер на новую версию, то можно воспользоваться скриптом /usr/sbin/named-bootconf который конвертирует конфигурационный файл BIND 4.x в BIND 8.x.

Строгое имя сборки вычисляет кэш или контрольную сумму подписываемой сборки и тем самым гарантирует ее подлинность для клиентского приложения (или почти гарантирует).

 

Технология использования “strong name” определяется правилами использования криптографических ключей в конкретной организации. Рассмотрим алгоритм формирования строгих имен сборок в наиболее общем виде.

Конфигурирование BIND 8.x

Конфигурирование BIND-сервера состоит из двух этапов - настройка конфигурационного файла /etc/named.conf и создания и заполнения таблиц доменных зон.

BIND 8.х позволяет создавать 4 типа доменных зон:

·         master (раньше называлась - primary). Данный DNS-сервер является головным для данного домена.

·         slave (раньше называлась - secondary). Такие DNS-серверы хранят копии доменных зон, которые скачивают и периодически обновляют с master-сервера.

·         hint (раньше называлась - cache). Кэширующий сервер. Не хранит никаких таблиц зон, а просто собирает с объявленных root-серверов кэш резолвенных адресов. Используется для повышения эффективности работы DNS-сервера.

·         stub аналог slave зоны, но в отличие от нее таблиц зоны не хранит, только NS-записи, и просто перенаправляет запросы на объявленные DNS-сервера.

Очевидно, что вы можете настроить так ваш BIND-сервер, что он одновременно может обслуживать несколько разных доменных зон и для одних он может быть master-ом, для других - slave и тд.

В любом случае, какие-бы типы зон вы не настраивали, две зоны будут присутствовать у вас почти всегда - это зона hint и localhost (прямая и реверсивная).

Итак, начнем с просто кэширующего DNS-сервера. Создаем /etc/named.conf и прописываем там глобальные параметры и те две "стандартные" зоны о которых я только что упоминал:

//Конфигурационный файл /etc/named.conf для кэширующего DNS-сервера

options {
directory "/var/named";
listen-on { 192.168.6.1; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24; localhost; };
forward first;
forwarders { 192.168.1.1; };
};

zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};

zone "." in {
type hint;
file "/var/named/root.hint";
};

Синтаксис этого файла очень похож на С++. Структура options - описывает глобальные параметры для сервера, а структуры zone - описывают, соответственно, доменные зоны.

-directory - указывает каталог расположения таблиц зон

-listen-on - позволяет указать на какие сетевые интерфейсы будет "вешаться" демон. Тут прописываем адрес локального интерфейса, у меня это 192.168.6.1, и не забываем указать и 127.0.0.1

-version - строка, которая будет выдаваться на запрос определения версии DNS-сервера

-allow-transfer - устанавливает возможность передачи зон для slave-серверов. В нашем случае трансфер запрещен.

-allow-query - а этот параметр указывает кому разрешается подавать запросы к нашему серверу. Мы прописали нашу локальную сетку 192.168.6.0 и 127.0.0.1

-forward - этот параметр позволяет указать каким образом сервер обрабатывает запрос клиента. Я указал first - это означает что сервер сначала перенаправит запрос выше и если не получит положительного результата, то посмотрит в своем кэше. Если указать only - то у себя смотреть не будет

-forwarders - а тут вы и указываете куда перенаправлять запросы клиентов. Я указал, для примера, свой вышестоящий DNS-сервер 192.168.1.1

-type - тип зоны

-file - имя файла таблицы зоны

-allow-update - разрешить или нет, и кому если разрешить, возможность изменения(обновления) таблицы зоны

Теперь добавим записи для master-зон:

//Конфигурационный файл /etc/named.conf для master DNS-сервера

options {
directory "/var/named";
listen-on { 192.168.6.1; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24; localhost; };
};

zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};

zone "." in {
type hint;
file "/var/named/root.hint";
};

zone "sun.urix.ru" in {
type master;
file "/var/named/sun.urix.zone";
};

zone "6.168.192.in-addr.arpa" in {
type master;
file "/var/named/192.168.6.zone";
};

Я добавил две структуры: "прямую" зону - sun.urix.ru и реверсивную - 6.168.192.in-addr.arpa. Удалил опции определяющие форвард запросов и пока не разрешаю трансфер своих таблиц. Таким образом у меня получился мастер DNS-сервер для моего домена sun.urix.ru.

Теперь настроим наш BIND в случае когда у нас существуют и slave-серверы. Сначала необходимо подправить на мастер-сервере возможность передачи таблиц зон. Для этого нужно только разрешить трансфер зон:

allow-transfer { 192.168.6.2; 192.168.6.3; };

Здесь 192.168.6.2 и 192.168.6.3 - мои slave-серверы. А теперь на slave-сервере делаем конфигурационный файл:

//Конфигурационный файл /etc/named.conf для slave DNS-сервера

options {
directory "/var/named";
listen-on { 192.168.6.2; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24; localhost; };
};

zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};

zone "." in {
type hint;
file "/var/named/root.hint";
};

zone "sun.urix.ru" in {
type slave;
file "/var/named/sun.urix.zone";
masters { 192.168.6.1; };
};

zone "6.168.192.in-addr.arpa" in {
type slave;
file "/var/named/192.168.6.zone";
masters { 192.168.6.1; };
};

Все, теперь когда демон на slave-сервере будет запускаться он прочитает адрес, прописанный в masters, и скачает таблицу зоны, а в последствии будет ее и обновлять.

Несколько слов о том, как запускать и останавливать bind-демон и где читать логи:

#/usr/sbin/in.named - так запускается демон

#pkill in.named - а так его можно "убить"

/var/log/messages - файл логов куда и демон in.named пишет свои логи.

Таблицы зон

Теперь приступаем к созданию таблиц зон. Понятно, что для slave-сервера большинство таблиц будут скачены с master-сервера. Первым делом пропишим таблицы для localhost и зоны hint. Мы объявили, что /var/named - каталог где помещаются таблицы - вот и идем туда и создаем необходимые таблицы.

//Файл /var/named/localhost.zone

$ttl 38400
localhost. IN SOA localhost. root.localhost. (

2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)

localhost.	IN	NS	solaris.
localhost.	IN	A	127.0.0.1

 

//Файл /var/named/127.0.0.zone

$ttl 38400
0.0.127.in-addr.arpa. IN SOA localhost. root.localhost. (

2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)

0.0.127.in-addr.arpa.	IN	NS	solaris.
1.0.0.127.in-addr.arpa.	PTR		localhost.

 

//Файл /var/named/root.hint

.	3600000	IN	NS	A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.	3600000	A		198.41.0.4

 

Разберемся теперь в формате этих таблиц. localhost.zone и 127.0.0.zone - это прямая и реверсивная таблицы loopback интерфейса, а файл root.hint - используется для кэширующего сервера. Эти три файла, как мы помним, присутствуют неизменно на любом DNS-сервере.

Что касается файла root.hint, то его, как правило, берут у своего провайдера. Данные в нем периодически устаревают и меняются, поэтому выкачивать его у своего провайдера - это самый оптимальный вариант. Но я хочу посоветовать вам упростить этот файл всего до одной-двух записей рутовых серверов и указать их на DNS-серверы вашего провайдера. Что это даст? Дело в том, что ваш сервер при каждом запуске и по истечении параметра TTL(time-to-live) будет обращаться ко всем серверам из этого файла и, таким образом, создаст вам огромный трафик, хотя накопленной информации, хранящейся на сервере вашего провайдера, вполне для вас будет достаточно. В качестве примера я написал только один адрес А-root сервера, если вы хотите добавить еще сервера, то создайте B,C,D... и т.д.

Расшифровка полей файлов зон:

-2004071001 ;serial - серийный номер версии таблицы. Самый лучший формат - ГГГГММДДNN, где NN - номер изменения таблицы за текущий день

-108000 ;refresh - время в секундах, указывающее как часто необходимо проверять таблицу мастер-сервера на необходимость update-а

-1800 ;retry - время в секундах, которое сервер ожидает при ошибочном сеансе refresh-а чтобы начать его заново

-1209600 ;expiry - максимальный предел в секундах времени хранения таблицы, по его истечении таблица считается устаревшей и скачивается заново.

-604800 ;ttl - параметр time-to-live. Время в секундах, которое указывает серверу сколько хранить в кэше данные таблицы. По его истечении срвер перечитывает таблицу заново.

 

//Файл /var/named/sun.urix.zone

$ttl 38400
sun.urix.ru. IN SOA solaris. root.solaris.sun.urix.ru. (

2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)

sun.urix.ru.	IN	NS	solaris.
sun.urix.ru.	IN	MX 10	solaris.sun.urix.ru.
solaris	IN	A	192.168.6.1
class	IN	A	192.168.6.10
slave	IN	A	192.168.6.2
www	IN	CNAME	solaris

 

//Файл /var/named/192.168.6.zone

$ttl 38400
6.168.192.in-addr.arpa. IN SOA solaris. root.solaris.sun.urix.ru. (

2004012001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)

6.168.192.in-addr.arpa.	IN	NS	solaris.
1	IN	PTR	solaris.sun.urix.ru.
2	IN	PTR	slave.sun.urix.ru.
10	IN	PTR	class.sun.urix.ru.

 

-NS - указывает name-серверы для данной зоны

-MX - указывает на почтовые серверы домена, очередность - 0,10,20,

-A - "прямая" запись ресурса (имя-адрес)

-PTR - "реверсивная" запись (адрес-имя)

-CNAME - псевдоним

Точка в конце некоторых названий означает, что не нужно дописывать название доменной зоны. Если ее не ставить, то сервер автоматически допишет название домена для которого данная таблица и составляется. Не забывайте про это.

Вот и все, если таблицы готовы, то теперь можно и запускать ваш сервер. Как это делать мы уже рассмотрели выше.

Передача зон по защищенному ключу

Если перед вами стоит задача повысить уровень безопасности при трансфере таблиц между master и slave серверами, то необходимо наложить дополнительную аутентификацию на этот механзм. Вообще, механизм аутентификации по ключу, который мы сейчас настроим, может применяться не только при передаче зон, но и даже при обработке запросов клиент-сервер. Но это уже особый случай повышенной безопасности.

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

#dnskeygen -H 128 -z -n ns1

-H - указывает что необходимо сгенерировать ключ HMAC-MD5, диапазона [1..512]. Я указал - 128.

-z - ключ генерируется для зоны

-n - указывает имя ключа

В результате в текущем каталоге создаются два файла - Kns1.+157+00000.key и ns1.+157+00000.private. Заглянем в них:

//Содержимое файла Kns1.+157+00000.key

ns1. IN KEY 257 3 157 cArC69abJAYH8sqijvyxjw==

 

//Содержимое файла Kns1.+157+00000.private

Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: cArC69abJAYH8sqijvyxjw==

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

Теперь возвращаемся к конфигурационному файлу /etc/named.conf на master-сервере и приводим его к следующему виду:

//Конфигурационный файл /etc/named.conf для master DNS-сервера с использованием ключа при трансфере зон

key ns1 {
algorithm hmac-md5;
secret "cArC69abJAYH8sqijvyxjw==";
};

server 192.168.6.2 {
keys { ns1; };
};

server 192.168.6.3 {
keys { ns1; };
};

options {
directory "/var/named";
listen-on { 192.168.6.1; localhost; };
version "Go away!";
allow-transfer { key ns1; };
allow-query { 192.168.6.0/24; localhost; };
};

zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};

zone "." in {
type hint;
file "/var/named/root.hint";
};

zone "sun.urix.ru" in {
type master;
file "/var/named/sun.urix.zone";
};

zone "6.168.192.in-addr.arpa" in {
type master;
file "/var/named/192.168.6.zone";
};

Как видно, добивились две новые структуры - key и server. Первая задает нам ключ, а вторая - какие серверы этим ключем подписываются. В моем примере я указал две структуры для моих slave-серверов и обоим приписал один ключ. Конечно, вы можете генерировать ключи для каждого сервера отдельно и даже несколько ключей на один сервер и использовать их потом для разных целей.

На slave-серверах необходимо, так же, прописать аналогичные структуры. Причем структура key - "один в один" - иначе не пройдет аутентификация, а вот структура server должна быть одна с адресом вашего master-сервера.

Вот и все, запускаете службу и если не ошиблись при наборе ключа серверы начнут трансфер зон. Единственно на что еще хочется обратить внимание - это на синхронизацию времени между master и slave серверами. Если трансфер зон не прошел, то читайте лог - там причина будет описана. Если ошиблись в ключе - проверяйте его идентичность, если не совпадает время - синхронизируйте его (команды date, rdate либо запустите ntp механизм) и все будет - ОК!

DNS-клиент

Для настройки DNS-клиента первое что необходимо сделать - это подправить файл /etc/nsswitch.conf. Найдите там следующую строчку и допишите как это показано у меня:

hosts: files dns

Таким образом вы указываете системе откуда и в каком порядке определять сетевые адреса. Теперь создаем файл /etc/resolv.conf и прописываем туда следующее:

domain sun.urix.ru

nameserver 127.0.0.1

nameserver 192.168.6.2

nameserver 192.168.6.3

Domain - указывает клиентом какого домена вы являетесь, а nameserver - адреса DNS-серверов. Причем опрос идет в порядке сверху-вниз и максимальное количество объявленных северов - три. Адрес 127.0.0.1 нужно указывать только если вы настраиваете клиента на самом сервере. Вот и все что нужно сделать, все значения система подхватывает "на лету".

Не хочется утомлять Вас банальностями, объясняющими влияние полнолуния на безопасность информационных систем…

 

Юрий Кажаров.

 

(эксперт в области дизайна и администрирования UNIX/Linux информационных систем)