Пакет BIND
Категория: Система доменных имен | Автор: admin | 10-04-2010, 02:43 | Просмотров: 4765

BIND (Berkeley Internet Name Domain — система доменных Internet-имен реализации университета Беркли) — это открытый программный пакет, предлагаемый организацией ISC. Он реализует протокол DNS и функционирует в качестве сервера имен на платформах UNIX (с недавнего времени также в Windows NT).

 

Версии пакета BIND

 

Имеются три основные разновидности пакета: BIND 4, BIND 8 и BIND 9. Первая из них существовала с конца 80-х гг. (ее выпуск примерно соответствует появлению документов RFC1034 и RFC1035). Вторая была выпущена в 1997 г., а третья — в середине 2000 года. Версий 5, 6 и 7 никогда не было. Существовала красивая легенда, будто версия 8 содержала в себе столь значительные изменения, что авторы решили увеличить ее номер в два раза по сравнению с предшественницей. Это, конечно же, не так. Просто пакет BIND 8 предназначался для 4.4BSD, где номера версий многих программных продуктов были доведены до восьми (то же самое произошло с системой sendmail, которая также "перескочила" через несколько номеров).

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

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

Многие организации затягивают с обновлением версий, поскольку им не хочется менять работу полностью функционирующей системы. Те, кто до сих пор работает с BIND 4, могут воспользоваться Perl-сценарием named-boot-conf.pl, входящим в дистрибутивы версий 8 и 9. Он преобразует конфигурационный файл из формата версии 4 в эквивалентный формат версии 8 или 9. Записи самой базы данных DNS менять не требуется. Конечно, преобразованный конфигурационный файл не будет поддерживать новые свойства версий 8 и 9, но зато он послужит отправным пунктом для начала расширения системы.

 

Определение текущей версии

 

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

dig @сервер version.bind txt chaos

 

возвращает номер версии при условии, что эта информация не была удалена из конфигурационного файла. К примеру, данная команда выдает нужный результат для сервера vix.com:

% dig @ЬЬ.rc.vix.com version.bind txt chaos

VERSION.BIND.       OS CHAOS TXT "8.2.3-T4B"

 

но в случае сервера cs.colorado.edu она бессильна:

% dig 6mroe.cs.colorado.edu version.bind txt chaos

VERSION.BIND.      OS CHAOS TXT "wouldn't you like to know..."

 

Некоторые администраторы конфигурируют пакет BIND так, чтобы номер его версии нельзя было узнать посредством такого рода запросов. Считается, что это повышает безопасность системы. Мы не одобряем подобную практику, хотя она действительно способна поумерить пыл некоторых юных хакеров Подробнее о задании версии речь пойдет в параграфе 16.9.

Обычно можно узнать версию BIND, просматривая журнальные файлы в каталоге /var/log или его эквивалентах. Например, демон named при запуске регистрирует свой номер версии через систему Syslog (средство "daemon"). Поиск посредством команды grep дает такие результаты:

Dec 13 16:32:27 disaster named[2399]: starting,  named 4.9.7 Wed Sep 2

09:39:12 GMT 1998 PHNE_14618

Dec 13 16:35:13 suod named[9325]: starting,  named 8.2.2-P3 Wed Nov 10

17:27:59 MST 1999 millert@haxrus /nfs/depot/src/cs/Bind/bind-

8.2.2-P3/obj/sun4+SunOS4/bin/named

 

 

Первая строка получена в HP-UX 11.00 (дистрибутивный вариант системы), вторая — в SunOS (система некоторое время была в эксплуатации). Во втором случае данные немного не верны, поскольку "заплата" 4 для BIND 8.2.2 по какой-то причине не повысила отображаемый уровеь: "заплаты". В действительности полная версия пакета — 8.2.2-Р4.

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

В табл. 16.4 указано, какие версии BIND входят в состав наших тестовы систем. В версиях ниже 8.2.2-РЗ имеются проблемы с безопасностью.

Таблица 16.4. Версии BIND в различных операционных системах

Система

Версия ОС

Версия BIND

Solaris

7 или 8

8.1.2

HP-UX

11.00

4.9.7

Red Hat

6.1

6.2

8.2

8.2.2-Р5

FreeBSD

3.4 или 4.0

8.2.2-Р5

 

Известно, что в Red Hat номера версий фиксируются и не меняются при последующей установке "заплат". Поэтому при поиске номера может отображаться недостоверная информация, как в показанном выше примере. В Red Hat внутренние номера версий добавляются к именам файлов, содержащих исходные тексты пакета, и иногда к ним присоединяется внутренний номер исправления или "заплаты". Например, bind-8.2-7.arch.rpm — это седьмое исправление исходной версии 8.2.

 

Компоненты пакета BIND

 

В пакет BIND входят три компонента:

  • демон named, отвечающий на запросы;
  • библиотечные подпрограммы, контактирующие с серверами распределенной базы данных DNS;
  • программы nslookup, dig, host, позволяющие выполнять DNS-запросы из командной строки.

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

 

Демон named: сервер имен пакета BIND

 

Демон named отвечает на запросы об именах компьютеров и их IP-адресах. Если демону не известен ответ на какой-нибудь запрос, он опрашивает другие серверы и помещает результаты их ответов в кэш. Кроме того, этот демон осуществляет зонные пересылки, копируя данные между серверами домена. (Зона — это домен без своих поддоменов. Серверы имен работают именно с зонами, но часто говорится "домен", хотя на самом деле подразумевается "зона".)

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

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

 

Таблица 16.5. Таксономия серверов имен

Тип сервера

Описание

Авторитетный главный

подчиненный усеченный

внутренний

Официальный представитель зоны

Основное хранилище зонных данных; получает информацию из дискового файла

Копирует свои данные с главного сервера

Напоминает подчиненный сервер, но копирует данные только о серверах имен (записи NS)

Сервер, доступный только в пределах домена1 (также называется невидимым сервером)

Неавторитетный2

 

кэширующий переадресующий

Отвечает на запросы, пользуясь данными из кэша; не знает о том, являются ли эти данные корректными.

Кэширует данные, полученные от предыдущих запросов; обычно не имеет локальных зон

Выполняет запросы от имени многих клиентов; формирует большой кэш

Рекурсивный

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

Нерекурсивный

Отсылает клиента к другому серверу, если не может получить ответ на запрос

 

Авторитетные и кэширующие серверы

 

Главный, подчиненный и кэширующий серверы различаются только двумя характеристиками: откуда поступают данные и авторитетен ли сервер для данного домена. В каждой зоне есть один основной сервер имен. На нем хранится официальная копия зонных данных (в файле на диске). Системный администратор модифицирует информацию, касающуюся зоны редактируя файлы главного сервера.

Подчиненный сервер копирует свои данные с главного сервера посредством операции, называемой зонной пересылкой. В зоне может быть несколько подчиненных серверов; обязательный минимум — один. Усеченный сервер — это особая разновидность подчиненного сервера, загружающего с главного сервера только записи NS (описания серверов имен). О том, зачем нужно создавать такой сервер, речь пойдет в параграфе 16.11. Один и тот же компьютер может быть главным сервером для одних зон и подчиненным — для других.

 

 

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

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

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

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

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

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

 

Рекурсивные и нерекурсивные серверы

 

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

У нерекурсивных серверов обычно есть веские причины не выполнять дополнительную работу. Например, все корневые серверы и серверы доменов верхнего уровня являются нерекурсивными, поскольку им приходится выполнять до 10000 запросов в секунду.

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

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

Есть один побочный эффект при отслеживании отсылок: в кэше сервера имен накапливается информация о промежуточных доменах. При работе в локальной сети от этого обычно только польза, поскольку в последующих операциях поиска, инициируемых любым компьютером этой сети, можно будет пользоваться результатами предыдущих запросов. С другой стороны, сервер домена верхнего уровня (такого как "com" или "edu") не должен хранить информацию, запрашиваемую компьютером, который находится на несколько уровней ниже.

В ранних версиях BIND требовалось модифицировать исходный код и перекомпилировать пакет, чтобы изменить рекурсивность сервера. Затем появилась опция командной строки -r, которая теперь является параметров конфигурационного файла. Можно даже сконфигурировать сервер таким образом, что он будет рекурсивным для внутренних клиентов и нерекурсивным — для внешних.

Отсылки генерируются на иерархической основе. Если сервер, к примеру, не сможет узнать адрес узла lair.cs.colorado.edu, он выдаст отсылки к серверам доменов cs.colorado.edu, colorado.edu, "edu" или корневого домена. Отсылка должна содержать адреса серверов того домена, на который она указывает, поэтому выбор домена не случаен: сервер должен ссылаться на тот домен серверы которого ему уже известны.

Как правило, возвращается наиболее полный из известных доменов. В нашем примере в первую очередь были бы выданы адреса серверов домена cs.colorado.edu, при условии, что они известны. Если этот домен не известен но известен домен colorado.edu, были бы выданы адреса его серверов имен и т.д.

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

 

Модуль распознавания

 

Клиенты ищут соответствия между именами компьютеров и их IP-адресами, вызывая библиотечную функцию gethostbyname(). В исходной версии, этой функции имена искались в файле /etc/hosts. Для того чтобы такую информацию выдавала система DNS, функция должна делать запросы к модулю распознавания, который знает, как находить серверы имен взаимодействовать с ними.

В большинстве операционных систем функция gethostbyname() может черпать информацию из нескольких источников: обычных файлов (например, /etc/hosts), DNS и даже локальных административных СУБД, таких как NIS и NIS+. Иногда возможен четкий административный контроль над тем, какие источники опрашиваются и в каком порядке. Подробнее об этом рассказывается в параграфе 18.3, а также в параграфе 16.16 применительно к нашим тестовым системам.

 

Выполнение запросов из командной строки

 

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


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


 
Логин
Пароль
 

 
Locations of visitors to this page