Конфигурирование сервера BIND
Категория: Система доменных имен | Автор: admin | 10-04-2010, 03:15 | Просмотров: 7350

В следующих разделах мы предполагаем, что все "политические" задачи вами решены, т.е. вы получили имя домена (возможно, поддомена), связались с администратором DNS-сервера родительского домена и передали полномочия по обратному преобразованию адресов домену in-addr.arpa. Был выбран главный сервер имен и несколько подчиненных, а также инсталлирован пакет BIND.

 

Аппаратные требования

 

Пакет BIND — настоящий пожиратель ресурсов. Его база данных хранится в памяти, поэтому одновременно с увеличением кэша растет число страниц памяти, занимаемых демоном named. Некоторые новые компоненты BIND 9, особенно DNSSEC и подсистема IPv6, столь же интенсивно используют центральный процессор. Для снижения нагрузки пакет BIND 9 был сделан многопотоковым, и теперь он способен эффективно работать в многопроцессорных системах. Имеются также конфигурационные параметры, посредством которых можно контролировать, как демон named использует системные ресурсы.

Лучший способ определить, достаточно ли памяти на компьютере, где установлен сервер имен, — дать серверу поработать некоторое время, а затем проверить размер процесса named. Требуется одна-две недели, чтобы этот размер стабилизировался и старые записи в кэше устаревали с той же скоростью, с какой появляются новые записи.

 

Запуск демона named

 

Демон named запускается во время начальной загрузки и работает непрерывно. Например, для запуска этого демона в Solaris необходимо добавить в один из стартовых сценариев следующие строки:

 

if [ -f /usr/sbin/in.named -a -r /etc/named.conf ]; then

/usr/sbin/in.named; echo -n ' named' > /dev/console

fi

 

 

В последних версиях BIND имеется программа ndc (или rndc, в зависимости от версии), позволяющая посылать команды демону named. Ее формат прост:

 

# ndc команда
 

 

Среди полезных команд назовем start, stop, restart и status, назначение которых очевидно. Программа ndc будет подробно описана в параграфе 16.14.

Демон named использует систему Syslog, поэтому сначала нужно запустить демон syslogd. Не применяйте для управления сервером имен демон inetd: он будет при малейшей необходимости перезапускать демон named, замедляя время его реакции и препятствуя накоплению полезной информации в кэше.

 

Конфигурационные файлы

 

Под конфигурацией демона named понимается конфигурационный файл, файл "подсказок" и, в случае главного сервера, файлы зонных данных, содержащие адресные привязки для каждого узла. Конфигурационный файл имеет свой собственный формат; остальные файлы представляют собой коллекции отдельных DNS-записей, отформатированных в соответствии со спецификацией DNS. Ниже речь пойдет о содержимом конфигурационного файла, тогда как о формате DNS-записей будет рассказываться в параграфе 16.11.

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

При переходе от BIND 4 к BIND 8 формат конфигурационного файла полностью поменялся и стал напоминать формат файла gated.conf. Имя файла также изменилось: в BIND 4 он назывался /etc/named.boot, а в BIND 8 и 9 — /etc/named.conf. Формат файлов кэша и файлов данных остался прежним.

Мы опишем конфигурационный файл пакетов BIND 8/9, проигнорировав BIND 4. Надеемся тем самым подстегнуть самых консервативных из наших читателей к переходу на новые версии пакета. Как и в случае со многими другими программами, старые версии BIND могут содержать "дыры" в системе защиты, которые давно устранены в современных версиях.

Файл named.conf состоит из набора инструкций, каждая из которых оканчивается точкой с запятой. Лексемы разделяются пробельными символами, к которым относится и символ новой строки. Иногда для группировки лексем применяются фигурные скобки. Формат файла очень "хрупкий" — достаточно одной пропущенной точки с запятой, чтобы все перестало работать.

Комментарии допускаются везде, где могут стоять пробелы. Распознаются комментарии в стиле языков С, С++ и командного интерпретатора:

 

/* Это комментарий,  который может занимать несколько строк.  */

// Все, что идет до конца строки, является комментарием.

# Все, что идет до конца строки, является комментарием.

 

 

Каждая инструкция начинается с ключевого слова, определяющего ее тип. Может присутствовать несколько инструкций одного типа, за исключением инструкций options и logging. Отдельные инструкции, а также их части могут отсутствовать; в этом случае будут приняты установки по умолчанию. В табл. 16.7 перечислены инструкции, включенные в BIND 9.

 

Таблица 16.7. Инструкции, используемые в файле named.conf

Инструкция

Функция

include

Вставляет дополнительный файл (чаще всего подключаются файлы с ключами шифрования, доступные только демону named)

options

Задает глобальные параметры конфигурации сервера имен, а также установки по умолчанию

server

Задает параметры конкретного сервера

key

Определяет аутентификационную информацию

acl

Формирует список управления доступом

zone

Определяет зону, для которой демон является авторитетным

trusted-keys

Задает заранее установленные ключи шифрования

controls

Определяет, как программа ndc будет управлять сервером имен

logging

Устанавливает категории регистрационных сообщений и каналы их распространения

view

Определяет представление пространства имен (только в BIND 9)

 

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

  • IP-адрес (например, 199.165.145.4.);
  • адрес сети, включающий маску CIDR (например, 199.165/16);
  • имя ранее определенного списка управления доступом (см. описание инструкции acl);
  • ключ аутентификации;
  • оператор отрицания !.

Списки соответствия адресов используются в качестве аргументов многих инструкций и опций. Приведем ряд примеров:

 

{  !  1.2.3.13;  1.2.3/24;   );

{  128.138/16;   198.11.16/24;  204.228.69/24;   127.0.0.1;   };

 

 

В первом из этих списков из числа адресов исключается узел 1.2.3.13. но разрешаются другие адреса в сети 1.2.3/24. Во втором списке указаны сети, закрепленные за университетом штата Колорадо. Фигурные скобки и завершающая точка с запятой не являются частью списка: они относятся к инструкции, в которой содержится список.

Когда IP-адрес или адрес сети проверяется на соответствие списку, содержимое списка просматривается по очереди до тех пор, пока не будет найдено совпадение. Порядок элементов списка важен, так как ищется первое совпадение. Например, если в первом из показанных выше списков поменять элементы местами, результат не будет достигнут, поскольку адрес 1.2.3.13 удовлетворит первому условию (сетевому адресу 1.2.3/14) и второе условие никогда не будет проверяться.

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

 

Инструкция include

 

Когда конфигурационный файл становится слишком большим, можно разбить его на части, поместив их в отдельные файлы. Дополнительные компоненты подключаются к файлу named.conf посредством инструкции

 

include:

include "путь";

 

 

Если указан относительный путь, то он добавляется к путевому имени, заданному в параметре directory (описан в следующем разделе). Очень часто инструкцию include применяют для подключения файлов, содержащих ключи шифрования. Эти данные должны быть доступны только демону named. Чтобы не запрещать доступ ко всему файлу named.conf, ключи хранят в отдельных файлах, которые может читать лишь демон named.

 

Инструкция options

 

Инструкция options задает глобальные параметры конфигурации, которые впоследствии могут быть переопределены для конкретных зон или серверов. Общий ее формат таков:

 

options  {

параметр;

параметр;

};

 

 

Если в файле named.conf нет инструкции options, принимаются установки по умолчанию.

В BIND 8 имеется около 30-ти параметров, а в BIND 9 — более 50-ти. Полный их список можно узнать в документации. Ниже мы опишем лишь те параметры, которые рекомендуется задавать. Значения по умолчанию указаны в квадратных скобках рядом с каждым параметром.

version "строка";   [реальный номер версии сервера]

 

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

Мы рекомендуем не сбрасывать строку версии. Для администратора будет очень полезной возможность запрашивать сервер имен, чтобы выяснить текущую версию пакета.

directory "путь";         [каталог, откуда был запущен сервер]

 

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

Лучше хранить все конфигурационные файлы пакета BIND (кроме named.conf и resolv.conf) в подкаталоге каталога /var (или любого другого каталога, где содержатся конфигурационные файлы других программ). В нашей системе это каталог /var/named.

 

notify yes  |  no;                 [yes]

also-notify адреса_серверов;       [пусто]

 

 

Если параметр notify равен yes, а демон named является главным сервером одной или нескольких зон, то демон будет автоматически уведомлять подчиненные серверы этих зон при изменении соответствующих баз данных. В ответ на полученное уведомление подчиненные серверы связываются с главным и обновляют свои копии зонных данных. Параметр notify может устанавливаться как на глобальном уровне, так и на уровне отдельных зон. Это позволяет быстрее обновлять зонные файлы при внесении изменений в DNS.

Демон named выясняет, какие компьютеры являются подчиненными серверами зоны, просматривая записи NS этой зоны. При наличии параметра also-notify будут также уведомляться дополнительные серверы, которые не зарегистрированы посредством записей NS. Подобный прием иногда необходим, если в организации имеются внутренние серверы. В списке also-notify не нужно указывать усеченные серверы. Поскольку их интересуют только записи NS, они могут участвовать в обычном цикле обновления.

 

Серверы BIND 4 не понимают уведомляющих сообщений. Они регистрируют ошибку и обновляют свою информацию только по истечении периода обновления, указанного в зонных данных (см. описание записи SOA в параграфе 16.11). Уведомления желательно также отключать для зоны обратного преобразования узла localhost.

 

recursion yes  |  no;                              [yes]

allow-recursion {список_соответствия_адресов};     [все узлы]

 

 

Параметр recursion указывает на то, является ли демон named рекурсивным сервером (см. параграф 16.6). Можно разрешить рекурсию для внутренних клиентов демона и отключить для внешних запросов.

Параметр allow-recursion позволяет точнее управлять рекурсией. В нем задается список узлов и сетей, от имени которых разрешается выполнять рекурсивные запросы.

use-id-pool yes  |  no;        [no (только в V8)]

 

В BIND 8 этот параметр заставляет демон named хранить идентификаторы исходящих запросов, что позволяет избегать их дублирования и незаконного использования. Когда параметр включен, демон использует больше памяти, но результат того стоит, поэтому мы рекомендуем всегда устанавливать значение yes. В BIND 9 параметр use-id-pool исчез, поскольку демон всегда сохраняет идентификаторы запросов.

maintain-ixfr-base yes  |  no;       [no (только в V8)]

 

При помощи механизма инкрементных зонных пересылок (см. RFC1995) серверы рассылают "заплаты" к зонным базам данных при наступлении изменений, благодаря чему устраняется необходимость в повторной отправке всей базы данных. Для такой зоны, как, например, "com", это очень важно. В текущей реализации BIND 8 разрешаются инкрементные пересылки для любой зоны, поддерживающей динамические обновления; когда параметр maintain-ixfr-base равен yes, ведется журнал транзакций. В BIND 9 журнальный файл присутствует постоянно.

check-names { master | slave | response действие };   [см. текст]

 

В BIND 8 появился модуль проверки правильности доменных имен. Под правильностью подразумевается не то, существует узел или нет, а то, следует ли данное имя правилам, определенным в RFC-спецификациях для доменных имен. Как ни странно, многие имена оказываются неправильными. Имя считается правильным, если оно содержит только буквы, цифры и дефисы длина каждого компонента (включая точку) ограничена 64-мя символами, а общая длина имени не превышает 256 символов. Правила именования и вопросы разграничения узловой и доменной частей имени обсуждаются до сих пор. Локализация системы DNS и поддержка специализированных кодировок символов могут привести к тому, что все правила придется менять.

Параметр check-names можно задавать глобально и отдельно для каждой зоны. Зонные спецификации перекрывают глобальную. Этот параметр может применяться к главным и подчиненным серверам, а также к ответам возвращаемым в результате запроса. Существует три возможных действия:

  • ignore — не выполнять проверку;
  • warn — регистрировать неправильные имена, но продолжать обработку
  • fail — зарегистрировать неправильное имя и отказаться его принять

 

Для главного сервера действием по умолчанию является fail, поскольку ошибки на главном сервере, скорее всего, возникают вследствие опечаток или ввода неприемлемых имен. Все это системный администратор должен устранить: организации не следует заниматься распространением неправильных имен. Для подчиненного сервера установка по умолчанию — warn, а для ответов на запросы — ignore. Стандартные установки вполне приемлемы, и менять их не нужно.

transfer-format one-answer | many-answers;   [см. текст]

 

Этот параметр влияет на то, каким образом записи базы данных DNS передаются от главного к подчиненным серверам. Раньше пересылка осуществлялась по одной записи за раз, что было очень медленно и неэффективно. Атрибут many-answers, позволяющий объединять несколько записей в один пакет, появился в BIND 8.1; он установлен по умолчанию в BIND 9. Задавать атрибут many-answers можно только в том случае, если на всех серверах, между которыми происходит обмен зонными данными, выполняется пакет BIND версии как минимум 8.1, поскольку серверы BIND 4 не понимают этот атрибут. При работе в смешанной среде глобальные установки можно переопределить для отдельных серверов.

 

transfers-in число;           [10]

transfers-out число;          [10 (только в V9)]

transfers-per-ns число;       [2]

transfer-source IP-адрес;     [зависит от системы]

serial-queries число;         [4 (только в V8)]

 

 

Эти параметры отвечают за работу механизма зонных пересылок. Их требуется настраивать в крупных серверах, управляющих очень большими зонами (в частности, зоной "com", база данных которой в настоящее время превышает 2 Гбайт) или обслуживающих тысячи зон. Параметры transfers-in и transfers-out ограничивают число входящих и исходящих зонных пересылок, которые могут происходить одновременно. Параметр transfers-per-ns задает предельное число входящих зонных пересылок, одновременно поступающих от одного удаленного сервера. В крупных серверах может потребоваться увеличить значения transfers-in и transfers-out, но будьте осторожны, иначе можно превысить допустимое число файловых дескрипторов для процесса named. Параметр transfers-per-ns обычно не требуется менять; его можно увеличить только в том случае, если все удаленные главные серверы готовы обрабатывать более двух одновременных зонных пересылок. Если уж что-то менять, то лучше делать это посредством предложения transfers инструкции server.

Параметр transfer-source позволяет указать IP-адрес сетевого интерфейса, используемого для приема входящих пересылок. Этот адрес должен совпадать с адресом, указанным в параметре allow-transfer главного сервера.

В BIND 8 можно ограничить число одновременных попыток выяснить порядковый номер зоны. Этой цели служит параметр serial-queries. При каждом подобном запросе сохраняется информация о локальном состоянии. Соответственно, если одновременно поступает тысяча запросов, данное ограничение поможет серверу не "захлебнуться". Стандартное значение — 4, что слишком мало для крупного сервера; можно повысить его до нескольких сотен или даже тысячи. В BIND 9 этот параметр пока что игнорируется; в будущем он будет заменен показателем частоты запросов.

При изменении любого из перечисленных параметров нужно внимательно следить за тем, чтобы производительность системы не ухудшилась. В этом вам помогут журнальные файлы.

files число;      [unlimited]

 

Параметр files задает максимальное число файлов, которые могут быть одновременно открыты на сервере. Значение по умолчанию, unlimited, не допускается в некоторых операционных системах. В таком случае нужно посредством параметра files сообщить демону named о том, какой предел установлен в операционной системе. Если параметр не указан, а в операционной системе ограничивается число открытых файлов, демон вызывает библиотечную функцию sysconf(), чтобы узнать существующий предел, и функцию setrlimit(), чтобы попытаться повысить его.

 

listen-on port порт список_соответствия_адресов; [53, все интерфейсы)

query-source address IP-адрес port порт;         [случайные значения]

 

 

Параметр listen-on определяет сетевые интерфейсы и порты, по которым демон named ожидает поступления запросов. Параметр query-source задает интерфейс и порт, через которые демон named будет опрашивать другие серверы имен. Если ни порт, ни IP-адрес не указаны, демон ведет себя следующим образом: прослушивает порт 53 по всем интерфейсам и посылает запросы по произвольному интерфейсу, используя непривилегированный UDP-порт, выбранный случайным образом.

Благодаря параметру listen-on можно запускать несколько серверов имен на одном узле. Это требуется, например, в тех случаях, когда не нужно, чтобы сервер BIND 4 или BIND 8 был одновременно и авторитетным, и кэширующим. В этих версиях пакета информация хранится в одной гигантской базе данных, поэтому демон named может столкнуться с нехваткой памяти, вследствие чего данные окажутся поврежденными. Чтобы не попасть в такую ситуацию, запустите два отдельных процесса named: один в качестве авторитетного сервера, а другой — кэширующего. Во втором случае в параметре listen-on должен быть указан другой виртуальный IP-адрес. Авторитетный и кэширующий серверы могут взаимодействовать так, будто они выполняются на разных компьютерах. В файле resolv.conf необходимо указывать IP-адрес только кэширующего сервера.

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

 

forwarders { входной_адрес; входной_адрес;  ...  };   [пустой список]

forward only  |  first;                               [first]

 

 

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

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

В параметре forwarders перечисляется список IP-адресов машин, являющихся переадресующими серверами. Они опрашиваются в указанном порядке. При использовании переадресующего сервера традиционная процедура поиска домена (сначала опрашивается корневой сервер, затем осуществляется проход по цепочке отсылок) нарушается. Поэтому нужно внимательно следить за тем, чтобы не возникало циклов переадресации.

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

Поскольку у параметра forwarders нет значения по умолчанию, переадресация не происходит, если она не была сконфигурирована сознательно. Включать переадресацию можно либо глобально, либо в пределах отдельных зон.

 

allow-query { список_соответствия_адресов };         [все узлы]

allow-transfer [ список_соответствия_адресов ];      [все узлы]

blackhole  [ список_соответствия_адресов ];          [пусто]

 

 

Эти параметры позволяют указывать, какие узлы (или сети) могут обращаться к данному серверу имен и запрашивать пересылки зонных данных. В списке blackhcle перечислены серверы, которые никогда не удостоятся внимания со стороны демона named: он не будет принимать от них запросы и обращаться к ним за ответом.

sortlist { список_соответствия_адресов };   [не должен использоваться]

 

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

Среди других параметров, нарушающих привычный порядок вещей, следует упомянуть параметр rrset-order, определяющий, в какой последовательности должны возвращаться множественные ответы: циклической, фиксированной или случайной. Имеется также параметр topology, посредством которого можно попытаться предугадать, как будет осуществляться выбор удаленных серверов. В большинстве случаев ни один из этих параметров использовать не нужно.

 

Инструкция acl

 

Список управления доступом — это просто именованный список соответствия адресов:

 

acl имя_списка {

список_соответствия_адресов

};

 

 

Заданное имя можно указывать везде, где требуется список соответствия адресов.

Инструкция acl должна стоять самой первой в файле named.conf, поэтому не пытайтесь размещать ее среди других объявлений. Файл named.conf читается за один проход, поэтому списки управления доступом должны быть определены до того, как на них встретится ссылка. Существует четыре предопределенных списка: any, localnets, localhost и none, относящихся соответственно ко всем узлам, всем узлам локальной сети, самому компьютеру и ни одному узлу. Сети, входящие в группу localnets, определяются адресами интерфейсов компьютера с учетом сетевых масок.

 

Инструкция server

 

Демон named потенциально способен общаться даже с такими серверами, которые используют не самую последнюю версию пакета BIND, а также с теми, что неправильно сконфигурированы. Инструкция server сообщает демону характеристики удаленных узлов.

 

server IP-адрес {

    bogus yes  |  no;                           [no]

    provide-ixfr yes  |  no;                    [yes  (только в V9)]

    request-ixfr yes  |  no;                    [yes  (только в V9)]

    support-ixfr yes  |  no;                    [no  (только в V8)]

    transfers число;                            [2   (только в V9)]

    transfer-format one-answer | many-answers;  [V8: один, V9: много]

    keys { ключключ;   ...  );

};

 

 

Посредством инструкции server можно переопределять значения конфигурационных параметров, относящихся к серверам. Просто укажите требуемые параметры и их новые значения.

Если для сервера задан атрибут bogus, демон named не будет посылать ему запросы. Этот атрибут устанавливается для серверов, которые не должны опрашиваться.

Предложения с суффиксами ixfr изменились при переходе от BIND 8 к BIND 9. В версии 8 присутствовало предложение support-ixfr, а в версии 9 его заменили предложения provide-ixfr и request-ixfr. Атрибут support-ixfr задается равным yes, если удаленный сервер понимает инкрементные зонные пересылки Сервер версии 9, являющийся главным сервером зоны, будет выполнять инкрементные зонные пересылки, если атрибут provide-ixfr равен yes. Точно также подчиненный сервер версии 9 будет запрашивать инкрементные зонные пересылки, если атрибут provide-ixfr равен yes.

Атрибут transfers ограничивает число одновременных входящих зонных пересылок от удаленного сервера. Это серверный эквивалент параметра transfers-in, но поскольку он применяется только к одному серверу, то, по сути, переопределяет параметр transfers-per-ns. Его имя изменено для сохранения совместимости с BIND 8.

Предложение transfer-format является эквивалентом одноименного параметра. Его приходится использовать, когда происходит взаимодействие серверов BIND 8/9 и BIND 4.

В предложении keys содержится идентификатор ключа, который ранее был определен в инструкции key для использования в сигнатурах транзакций TSIG (о них рассказывается в параграфе 16.13). К любому запросу, посылаемому удаленному серверу, будет добавлена сигнатура, зашифрованная посредством этого ключа. Запросы, поступающие от удаленного сервера, не обязаны иметь цифровую подпись, но если она есть, то будет проверена.

 

Инструкция logging

 

Демон named в настоящее время заслуживает награду "за наиболее конфигурируемую подсистему журнальной регистрации на Земле". Система Syslog предоставляет программистам контроль над приоритетами сообщений, а системным администраторам — контроль над местом хранения этих сообщений. Но в рамках заданного приоритета администратор не может сказать: "Это сообщение меня интересует, а это — нет". В BIND 8 были добавлены категории, позволяющие классифицировать сообщения по типам, и каналы, расширяющие возможности в плане хранения сообщений. Категории назначаются программистом, а каналы — администратором.

Поскольку вопросы журнальной регистрации лежат несколько в стороне от нашего повествования (особенно если учесть объем материала), мы рассмотрим их позднее, в параграфе 16.14.

 

Инструкция zone

 

Инструкции zone являются "сердцем" файла named.conf. Они сообщают демону named о зонах, для которых он авторитетен, и задают параметры управления каждой зоной. Инструкция zone также используется для предварительной загрузки "подсказок" с корневого сервера ("подсказки" — это имена и адреса корневых серверов, участвующих в инициализации процесса DNS-поиска).

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

 

Конфигурирование главного сервера зоны

 

Ниже показан формат инструкции zone для зоны, в которой демон named является главным сервером:

 

zone "имя_домена" {

     type master;

     file "путь";

     allow-query {список_соответствия_адресов};        [все узлы]

     allow-transfer {список_соответствия_адресов};     [все узлы]

     allow-update {список_соответствия_адресов};       [попе]

     ixfr-base "путь";    [имя_домена.ixfr  (только в V8)]

};

 

 

Доменное имя в спецификации зоны всегда дается в двойных кавычках.

Зонные данные хранятся на диске в текстовом файле, доступном для редактирования. Поскольку нет соглашения о наименовании этого файла, в объявлении зоны должна присутствовать директива file. Зонный файл представляет собой набор записей о DNS-pecypcax; его формат описан в параграфе 16.11.

Параметры, связанные с управлением доступом, не являются обязательными. Если для зоны поддерживаются динамические обновления, в предложении allow-update должен присутствовать список узлов, от которых разрешено принимать данные. Динамические обновления применимы только в отношении главных зон; предложение allow-update не может присутствовать в объявлении подчиненной зоны (в BIND 9). Убедитесь, что в списке имеются лишь локальные DHCP-серверы.

Если зона поддерживает инкрементные зонные пересылки, то в BIND 8 для нее создается журнал транзакций — файл имя_домена.ixfr в начальном каталоге демона named. Изменить имя файла можно посредством директивы ixfr-base. Этот файл ведется демоном named и не требует вмешательства со стороны администратора.

В BIND 9 журнал транзакций используется как для динамических обновлений, так и для инкрементных зонных пересылок. Его имя заканчивается на .jnl и не может быть изменено. Оба упомянутых механизма являются относительно новыми в BIND. Подробнее они описываются в параграфе 16.12.

При наличии различных зонных параметров (а мы не обо всех рассказали) конфигурация зоны начинает казаться довольно сложной. На самом же деле вполне допускается объявление главной зоны, состоящее из имени зонного файла. В BIND 4 больше ничего нельзя было задать. Ниже показан пример, взятый из документации и слегка модифицированный нами:

 

zone "example.com"  {

    type master;

    file "forward/example.com";

    allow-query { any;   };

    allow-transfer { my-slaves;  };

};

 

 

Имя my-slaves относится к списку управления доступом, определенному ранее.

 

Конфигурирование подчиненного сервера зоны

 

Формат инструкции zone для подчиненного сервера будет почти таким же, как и в случае главного сервера:

 

zone "имя_домена" {

     type slave | stub;

     file "путь";

     ixfr-base "путь";                               [только в V8]

     masters { IP-адрес; IP-адрес;  ...  };

     allow-query {список_соответствия_адресов};      [все узлы]

     allow-transfer {список_соответствия_адресов};   [все узлы]

};

 

 

Подчиненные серверы обычно хранят полную копию зонной базы данных. Но если тип сервера stub, а не slave, ему передаются только записи NS (описания серверов имен). Усеченные зоны позволяют демонам named родительской зоны автоматически узнавать, какие компьютеры предоставляют сервис DNS для дочерних зон. Это делается на тот случай, если администратор дочерней зоны забудет проинформировать родительскую зону об изменениях. Родительской зоне нужна эта информация, чтобы правильно делать отсылки либо рекурсивные запросы. Подробнее данная тема будет освещаться в конце параграфа 16.11.

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

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

 

128.138.243.151 .cs.colorado.edu.

anchor.cs.colorado.edu.cs.colorado.edu.

 

 

можно быть уверенным в том, что где-то пропущена завершающая точка.

В списке masters перечислены IP-адреса компьютеров, с которых можно получить зонную базу данных. Выше мы говорили о том, что лишь один компьютер может быть главным сервером зоны. Почему же допускается указывать более одного адреса? По двум причинам.

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

Во-вторых, демону named в действительности все равно, откуда поступают зонные данные. Он так же легко может извлечь базу данных с подчиненного сервера, как и с главного. Этой особенностью демона можно воспользоваться для того, чтобы сделать какой-нибудь подчиненный сервер, с которым легко устанавливается связь, резервной копией главного сервера. В любом случае IP-адреса проверяются по очереди до тех пор, пока не будет найден работающий сервер. Теоретически можно даже создать иерархию серверов, в которой главный сервер обслуживает несколько серверов второго уровня, а те, в свою очередь, обслуживают множество серверов третьего уровня.

Мы советуем указывать только адреса главного сервера в директиве masters.

 

Задание корневых 'подсказок'

 

Инструкция zone типа hint сообщает демону named местоположение файла, из которого он может загрузить имена и адреса корневых серверов имен, чтобы предварительно заполнить свой кэш:

 

zone " . " {

     type hint;

     file "путь";

};

 

"Подсказки" — это набор DNS-записей, в которых перечислены серверы корневого домена ("."). Они нужны для того, чтобы демон named знал, откуда начинать поиск доменов. Не имея "подсказок", демон знал бы только о тех доменах, которые сам обслуживает, а также о своих поддоменах.

Файл "подсказок" чаще всего называется root.cache. В нем содержатся результаты ответов, которые можно получить, если запросить у корневого сервера список серверов имен в домене “.”. Подробнее о создании файла "подсказок" речь пойдет в параграфе 16.15.

В BIND 9 "подсказки" корневого сервера встроены в скомпилированный код пакета, поэтому конфигурировать корневую зону не требуется. Но если все же задать файл "подсказок", то система примет его. Мы рекомендуем предоставлять явные "подсказки"; сегодня в область DNS начала вторгаться политика, поэтому корневые серверы имен и их IP-адреса стали больше подвержены изменениям.

 

Задание зоны переадресации

 

Зона типа forward переопределяет глобальные параметры переадресации демона named для конкретного домена:

 

zone "имя_домена" {

     type forward

     forward only | first;

     forwarders { IP-адрес; IP-адрес;  ... }

};

 

 

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

 

Инструкция key

 

Инструкция key задает именованный ключ шифрования, применяемый для аутентификации на конкретном сервере. Подробнее о механизмах аутентификации, используемых в пакете BIND, речь пойдет в параграфе 16.13. Здесь же мы лишь вкратце опишем суть процесса.

Для построения ключа нужно указать как алгоритм шифрования, так и совместный секретный ключ, представленный в виде строки, закодированной по основанию 64:

 

key идентификатор_ключа {

    algorithm строка;

    secret строка;

};

 

 

Как и в случае списков управления доступом, идентификатор ключа должен быть определен в файле named.conf до того, как будет произведена ссылка на ключ. Чтобы связать ключ с сервером, внесите идентификатор ключа в список keys соответствующей инструкции server. Ключ используется как для проверки запросов, поступающих от сервера, так и для подписи ответов на эти запросы.

 

Инструкция trusted-keys

 

Инструкция trusted-keys является частью механизма DNSSEC, описанного в документе RFC2065. Каждая запись состоит из пяти компонентов, идентифицирующих имя домена, флаги, протокол, алгоритм шифрования и ключ. Все это необходимо для безопасного взаимодействия с сервером имен домена. Формат инструкции таков:

 

trusted-keys {

      домен флаги протокол алгоритм ключ;

      домен флаги протокол алгоритм ключ;

};

 

 

Атрибуты флаги, протокол и алгоритм являются неотрицательными целыми числами. Атрибут ключ — это строка, закодированная по основанию 64.

Инструкция trusted-keys полезна в тех случаях, когда сама зона имеет цифровую подпись, а ее родительская зона — нет, поэтому нельзя быть уверенным в том, что открытый ключ, получаемый от DNS-сервера, действительно надежен. Подробнее о технологии DNSSEC рассказывается в параграфе 16.13.

 

Инструкция controls

 

Инструкция controls определяет, каким образом программа ndc будет управлять работой демона named. Эта программа может запускать и останавливать демон, выводить отчет о его состоянии, переводить демон в режим отладки и т.д. Будучи сетевой программой, ndc требует должной конфигурации, чтобы злоумышленники не могли через Internet влиять на работу сервера имен. Формат инструкции таков:

 

controls {

     inet IP-адрес port номер allow { список_соответствия_адресов I

                                      ключ ...};

unix режим_доступа владелец группа;        [0600 0 0]

};

 

 

Было бы рискованно в открытую указать IP-адрес и порт сервера имен. Лучше вообще опустить строку inet и обращаться к серверу только через UNIX-сокет (параметры задаются в строке unix). Другой вариант — управлять доступом посредством ключа аутентификации. Те, кто любит риск, могут попробовать оставить строку line, но настроить список allow так, чтобы допускались только подключения по адресу 127.0.0.1, а внешние адреса блокировались брандмауэром. Но это подразумевает выдачу всем локальным пользователям кредита доверия; предполагается, что они не будут делать ничего противоправного с сервером имен. Хотя любой из них может подключиться с помощью программы telnet к управляющему порту и ввести команду "stop". Поэтому по умолчанию строку inet удаляют.

Программа ndc может взаимодействовать с демоном named через именованный UNIX-сокет /var/run/ndc. В строке unix задаются режим доступа к этому сокету и его владельцы. Аргумент режим_доступа должен быть восьмеричным числом, определяющим значение umask. Аргументы владелец и группа должны содержать идентификаторы соответственно пользователя и группы, которым принадлежит сокет. По умолчанию сокет доступен только пользователю root, который имеет право чтения и записи.

 

Инструкция view

 

Представления — это новый элемент BIND 9, позволяющий показывать внутренним компьютерам такой образ иерархии имен DNS, который отличается от образа, доступного внешнему миру. Например, внутренние пользователи могут видеть все компьютеры зоны и лишь несколько разрешенных внешних серверов. Или другой вариант: внутреннее и внешнее представления одинаковы по охвату узлов, однако для внутренних пользователей предоставляются дополнительные (либо отличающиеся) записи.

Подобная конфигурация приобретает в последнее время все большую популярность. Раньше, чтобы ее реализовать, требовалось запускать разные серверы для внутренней и внешней версий. Локальные клиенты обращались к внутреннему серверу, занимавшемуся рассылкой внутренней версии зонной базы данных, а записи NS родительской зоны отправлялись на серверы, хранившие внешнюю ее версию. Инструкция view, появившаяся в BIND 9, упрощает эту конфигурацию, позволяя хранить оба набора данных в пределах одной копии демона named. На основании списка соответствия адресов демон выясняет, какие данные нужны тому или иному клиенту.

Инструкция view содержит список адресов, определяющий, кто имеет доступ к этому представлению, плюс ряд параметров, применимых ко всем зонам в представлении, и, наконец, определения самих зон. Синтаксис инструкции таков:

 

view имя_представления {

     match-clients ( список_соответствия_адресов );

     параметр_представления;   ...

     инструкция_zone;  ...

};

 

 

Представления просматриваются по порядку, поэтому представления с самыми большими ограничениями доступа должны идти впереди. Зоны в разных представлениях могут иметь одинаковые имена. Представления налагают следующее ограничение на структуру файла named.conf: если они присутствуют, в их состав должны входить все инструкции zone.

Ниже приводится взятый из документации к BIND 9 пример, имитирующий разделение пространства DNS-имен на внутреннее и внешнее. В обоих представлениях задаются одинаковые зоны, но с разными базами данных:

 

view "internal"  {

     match-clients {наши сети;};  // только внутренние сети

     recursion yes;               // только для внутренних клиентов

     zone "example.com"  {        // полное содержимое зоны

           type master;

           file "example-internal.db";

     };

};

view "external"  {

      match-clients {any};        // только внутренние сети

      recursion no;               // рекурсия отсутствует

      zone "example.com"  {       // только "общедоступные" узлы

           type master;

           file "example-external.db";

     };

};


 (голосов: 1)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page