OpenNET: статья - Конфигурирование DNS-сервера BIND (dns bind domain)

Ключевые слова: dns, bind, domain, (найти похожие документы)
Автор: Юрий Кажаров <[email protected]> Date: Mon, 16 Feb 2008 18:21:07 +0000 (UTC) Subject: Конфигурирование DNS-сервера BIND Оригинал: http://a-sys.ru/Articles/Article.aspx?ID=62 Данное руководство описывает механизмы конфигурирования 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 нужно указывать только если вы настраиваете клиента на самом сервере. Вот и все что нужно сделать, все значения система подхватывает "на лету". Не хочется утомлять Вас банальностями, объясняющими влияние полнолуния на безопасность информационных систем... Юрий Кажаров, http://a-sys.ru (эксперт в области дизайна и администрирования UNIX/Linux информационных систем)

2.5, bagotu (ok), 23:46, 06/04/2009 [^] [^^] [^^^] [ответить]	+/–
allow-query = хосты которым разрешено выполнять запросы к DNS

3.13, rvs2016 (ok), 19:49, 15/02/2024 [^] [^^] [^^^] [ответить]

+/–

> allow-query = хосты которым разрешено выполнять запросы к DNS

Результаты проведённых мною испытаний показали, что в allow-query указываются хосты да сети, из которых разрешены запросы не любые, а запросы к зонам, находящимся на этом сервере.

А хосты да сети, из которых разрешены запросы к зонам, находящимся не на этом сервере, указываются в allow-recursion.

2.6, bagotu (ok), 23:46, 06/04/2009 [^] [^^] [^^^] [ответить]	+1 +/–
allow-query = хосты которым разрешено выполнять запросы к DNS