Данное руководство описывает механизмы конфигурирования 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-сервера
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-сервера
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-сервера
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. (
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. (
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. Заглянем в них:
Как видите, и в одном и в другом присутствует необходимый нам ключ (я
его выделил наклонным шрифтом). Так что, открываете любой из этих
файлов и списываете себе ключ, после чего файлы необходимо удалить.
Теперь возвращаемся к конфигурационному файлу /etc/named.conf на
master-сервере и приводим его к следующему виду:
Конфигурационный файл /etc/named.conf для master DNS-сервера с
использованием ключа при трансфере зон
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 - указывает клиентом какого домена вы являетесь, а nameserver -
адреса DNS-серверов. Причем опрос идет в порядке сверху-вниз и
максимальное количество объявленных северов - три. Адрес 127.0.0.1
нужно указывать только если вы настраиваете клиента на самом сервере.
Вот и все что нужно сделать, все значения система подхватывает "на
лету".
Не хочется утомлять Вас банальностями, объясняющими влияние полнолуния
на безопасность информационных систем...
Юрий Кажаров, http://a-sys.ru
(эксперт в области дизайна и администрирования UNIX/Linux информационных систем)
Vova
