BIND (Berkeley Internet Domain Name System)
BIND (Berkeley Internet Domain Name System) — это созданное консорциумом ISC открытое программное обеспечение, реализующее протокол DNS для операционных систем Linux, UNIX, Mac OS и Windows. Существует три основные версии пакета BIND: BIND 4, BIND 8 и BIND 9. Система BIND 10 в настоящее время еще разрабатывается консорциумом ISC. В этом примере мы рассмотрим только пакет BIND 9.
Определение версии
Довольно часто поставщикам не приходит в голову явно указать, какую версию пакета они реализовали в своей системе, поэтому приходится изощряться, чтобы точно выяснить, с каким именно программным обеспечением мы имеем дело. Иногда номер версии можно определить с помощью хитроумного запроса на основе утилиты dig, которая является частью пакета BIND. Команда $ dig @сервер version.bind txt chaos возвращает номер версии, содержащийся в конфигурационном файле пакета BIND. Сначала определим имя сервера имен для исследуемого домена $ dig домен ns и затем выполним запрос version.bind. Например, вот как эта команда работает с сайтом isc.org. $ dig @ns-ext.isc.org version.bind txtx chaos version.bind. 0 CH TXT "9.5.1" Однако она не работает с сайтом cs.colorado.edu.
$ dig @mroe.cs.colorado.edu version.bind txt chaos
version.bind. 0 CH TXT "wouldn't you like to know..."17
Некоторые организации так конфигурируют систему BIND, чтобы замаскировать номер версии, исходя из того, что это как бы обеспечивает определенную степень “безопасности, обеспечиваемой неясностью”. Мы не одобряем этого, но иногда таким образом можно отразить атаки взломщиков-дилетантов. Более подробно этот вопрос обсуждается немного ниже
Этот запрос работает и с другим программным обеспечением DNS. Например, запрос
$ dig @k.root-servers.net version.bind txt chaos version.bind. 0 CH TXT "NSD 2.3.7"
показывает, что на корневом сервере имен К выполняется система NSD
сервера. Однако если вы только что послали серверу запрос, значит, вы должны знать его имя, не так ли? На самом деле некоторые очень загруженные серверы (например, корневые серверы имен) представляют собой множество машин, распределенных по земному шару и объединенных одним именем сервера и IP-адресом. Эта схема репликации называется “альтернативной маршрутизацией” (“antcast routing”). Система маршрутизации находит по вашему запросу “ближайший” экземпляр. Если вы — системный администратор, пытающийся решить проблему, то может оказаться важным идентифицировать сервер, к которому вы получили доступ. Например, можно выполнить такие команды.
$ dig @k.root-servers.net hostname.bind txt chaos hostname.bind. 0 CH TXT "k2.nap.k.ripe.net" или $ dig @k.root-servers.net id.server txt chaos id.server.
Сообщество IETF пытается стандартизовать эти странные имена класса CHAOS в формах, которые не зависели бы от реализации version.server или id.server, но только форма id.server прошла всю процедуру до конца. Форма version.server существует в виде черновика и никогда не была описана документом RFC. Система NSD использует все четыре формы, а пакет BIND — только три одобренные.
В качестве системного администратора вы можете запустить сервер имен (named или nsd) с флагом -f, чтобы он напечатал номер своей версии в стандартном виде, и выйти. В системе Linux вы можете запросить у своего менеджера пакетов номер инсталлированной версии. Кроме того, вы обычно можете узнать номер версии системы BIND, заглянув в файлы регистрации в каталоге /var/log или их эквивалент. Сервер имен системы BIND регистрирует свой номер версии в системе syslog при загрузке. Команда grep в системе BIND выводит на экран примерно такие строки.
Jul 13 07:19:55 nubark named[757] : starting BIND 9.5.0-P2 -u named
Если эти попытки не принесли результаты, следует помнить, что номер версии команды dig обычно совпадает с номером версии сервера named, причем утилита dig часто устанавливается даже тогда, когда сервер named не инсталлирован. Первая строка вывода утилиты dig содержит номер версии в качестве комментария.
Большинство поставщиков вносят исправления, касающиеся безопасности, в старые версии вместо обновления последней версии, поступившей от консорциума ISC, поэтому номера версий могут вводить в заблуждение. Легко убедиться, что многие версии являются довольно старыми, поэтому первейшей задачей системного администратора DNS является обновление программного обеспечения.
Компоненты системы BIND В пакет BIND входит четыре основных компонента: • демон сервера имен named, отвечающий на запросы; • библиотечные функции, контактирующие с серверами распределенной базы данных DNS от имени пользователей; • утилиты nslookup, dig и host, позволяющие выполнять DNS-запросы из командной строки; • программа rndc для дистанционного управления демоном named. Главнейшей задачей системного администратора, работающего с пакетом BIND, является упорядочение многочисленных опций и функциональных возможностей, предоставляемых пакетом BIND, а также выбор наиболее подходящих для текущей ситуации.
Файлы конфигурации
Полная конфигурация демона named включает его конфигурационный файл, файлы данных зоны, содержащие адресные привязки для каждого узла, и файл подсказок для корневого сервера имен. Авторитетные серверы должны иметь файл конфигурации и файлы данных зоны для каждой зоны, относительно которых они являются главными серверами. Кеширующие серверы должны иметь файл конфигурации и файл подсказок для корневого сервера имен. Файл конфигурации демона named имеет специфический 644 Часть II. Работа в сети формат; все остальные файлы представляют собой коллекции отдельных записей данных DNS, рассмотренных в разделе 17.8.
В конфигурационном файле named.conf демона named задается роль узла (главный, подчиненный, тупиковый или только кеширующий) и определяется способ, которым он должен получать копию записей о данных каждой зоны, которую он обслуживает. Здесь же приводятся всевозможные параметры — как глобальные, связанные с работой самого демона named, так и локальные, связанные с серверами и зонами и относящиеся только к части трафика DNS.
Файл конфигурации состоит из набора инструкций, каждая из которых оканчивается точкой с запятой и описывается в последующих разделах книги. К сожалению, формат файла довольно “хрупкий”: достаточно одной пропущенной точки с запятой, чтобы все перестало работать.
К счастью, в пакете BIND имеются удобные средства проверки синтаксиса конфигурационного файла (named-checkconf) и зонных файлов (named-checkzone). Эти утилиты ищут не только синтаксические ошибки, но и очевидные пропуски. Например, утилита named-checkzone выдаст предупреждение, если в файл не включена директива $TTL. Но в каждой бочке меда есть ложка дегтя. Например, не выявляются пропущенные связующие записи (см. раздел 17.8), хотя их отсутствие приводит к повышению нагрузки на корневые серверы и серверы организационных доменов gTLD.
Комментарии допускаются везде, где могут стоять пробелы. Поддерживаются комментарии в стиле языков С, C++ и командного интерпретатора, но лучше выбрать один стиль и придерживаться только его.
/* Это комментарий, который может занимать несколько строк. */
// Весь текст до конца строки является комментарием.
# Весь текст до конца строки является комментарием.
Каждая инструкция начинается с ключевого слова, определяющего ее тип. Может присутствовать несколько инструкций одного типа, за исключением options и logging. Отдельные инструкции, а также их части могут отсутствовать; в этом случае будут приняты установки по умолчанию. Список поддерживаемых инструкций приведен в табл. 17
Инструкции, используемые в файле named.conf
---------------------------------------------------------------------------------
Инструкция Назначение
---------------------------------------------------------------------------------
include Подключает внешний файл
options Задает глобальные параметры конфигурации сервера имен, а также установки по умолчанию
acl Формирует списки управления доступом
key Определяет параметры аутентификации
trusted-keys Задает заранее установленные ключи шифрования server Задает параметры сервера masters Определяет список главных серверов для тупиковых и подчиненных зон
logging Устанавливает категории журнальных сообщений и каналы их распространения
statistics-channels Выводит текущую статистику в виде XML-файла zone Определяет зону записей о ресурсах
controls Определяет, как утилита ndc будет управлять сервером имен named
view Определяет представление данных зоны
lwres Конфигурирует сервер имен named в качестве упрощенного распознавателя
Прежде чем приступать к описанию этих инструкций и их использования для конфигурирования демона имен named, необходимо рассказать о специальной структуре данных, используемой во многих инструкциях, — список соответствия адресов (address match list). Этот список является обобщением понятия IP-адреса и может включать:
• IP-адрес, либо v4, либо v6 (например, 199.165.145.4);
• адрес сети с маской CIDR18 (например, 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.0/24. Во втором списке указаны сети, закрепленные за университетом штата Колорадо. Фигурные скобки и завершающая точка с запятой не являются частью списка; они относятся к инструкции, в которой содержится список. Когда IP-адрес или адрес сети проверяется на соответствие списку, содержимое списка просматривается по очереди до тех пор, пока не будет найдено совпадение. Порядок элементов списка важен, так как ищется первое совпадение. Например, если в первом из показанных выше списков поменять элементы местами, результат не будет достигнут, поскольку адрес 1.2.3.13 удовлетворит первому условию (сетевому адресу 1.2.3.0/24) и второе условие никогда не будет проверяться.