BIND 8 на марше

Константин Пьянзин

Возможности новых версий BIND. Тенденции развития доменной системы DNS.

Может быть, я несовершенен,

но отдельные мои части прекрасны.

Эшли Бриллиант

Журнал LAN уже неоднократно обращался к теме доменной системы Internet (Domain Name System, DNS). В частности, в статьях «Система доменов Internet» (LAN №2 за 1997 г.) и «Настройка серверов имен DNS» (LAN №3 за 1997 г.) читатели могли познакомиться со структурой и принципами настройки сервиса DNS.

Наибольшей популярностью в Internet пользуется спецификация Berkeley (Berkeley Internet Name Domain, BIND), она-то и была взята за основу многих реализаций сервиса DNS. Хотя за последнее время на сцену вышли и другие спецификации, среди которых особого внимания заслуживает Microsoft DNS Server, реализации на базе BIND преобладают во всемирной сети прежде всего благодаря тому, что они предоставляются бесплатно. К тому же они имеются не только для многочисленных версий UNIX, но и для Windows NT, NetWare, VMS, MVS и т. д.

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

Целью данного обзора является сравнение восьмой и четвертой версий BIND. Вместе с тем мы рассмотрим также отдельные характеристики BIND версий 4.9.3 и выше, поскольку появившиеся в последних реализациях BIND 4 возможности в дальнейшем были в полном объеме внедрены в BIND 8. На момент написания статьи самой последней версией была BIND 8.2.2, онато и была взята нами за основу для сравнения. Программное обеспечение BIND выпускается организацией Internet Software Consortium (ISC), и его можно бесплатно получить на сервере http://www.isc.org. Следует иметь в виду, что данная статья отнюдь не претендует на то, чтобы быть учебником по BIND 8, и в ней перечисляются только самые принципиальные изменения в спецификации. Более подробную информацию по BIND читатель может почерпнуть в третьем издании прекрасной книги «DNS and BIND» издательства O?Reilly & Associates, а также в справочных руководствах по BIND, входящих в состав UNIX.

У читателей может возникнуть справедливый вопрос: почему к теме BIND 8 было решено вернуться только сейчас, тогда как первые реализации появились уже более двух лет? Во-первых, BIND 8 все еще находится в стадии разработки. Некоторые уже давно объявленные характеристики были реализованы лишь недавно, а некоторые остались нереализованными до сих пор. Во-вторых, BIND 8 достаточно медленно внедряется в сети Internet. Очень многие серверы DNS до сих пор используют BIND 4. Логика администраторов вполне понятна. Зачем менять неплохо работающий сервис на что-то иное ради каких-то «эфемерных» возможностей? Но это ошибочный подход. BIND 4 имеет несколько принципиальных ограничений в области защиты, что дает потенциальным злоумышленникам неплохие шансы не только на успешное проведение атак по принципу «отказ в обслуживании», но и на получение несанкционированного доступа к ресурсам сети. Кстати говоря, в свое время LAN уделил много внимания атакам на сервис DNS («DNS под прицелом» в сентябрьском номере LAN за 1997 г. и «Атака и защита DNS» в ноябрьском номере LAN за 1997 г.). Некоторые из упоминаемых там атак на BIND 8 провести невозможно.

НОВЫЙ СИНТАКСИС

Наиболее очевидным и бросающимся в глаза изменением в BIND 8 стал новый синтаксис конфигурационного файла. К тому же и имя конфигурационного файла было изменено. В BIND 4 конфигурационный файл носит имя /etc/named.boot, тогда как в BIND 8 — /etc/named.conf.

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

Для примера мы рассмотрим самые популярные директивы конфигурационного файла BIND 8, а также то, как они соотносятся с директивами BIND 4. Кстати говоря, с точки зрения администратора, спецификация BIND — это спецификация конфигурационного файла. Руководящие документы RFC не оговаривают конкретную реализацию DNS, а лишь описывают формат и структуру сообщений DNS. Поэтому хотя BIND и, скажем, Microsoft DNS Server поддерживают одни и те же стандарты RFC, конфигурируются они по-разному. С другой стороны, конкретные реализации DNS могут не предусматривать поддержки отдельных стандартов RFC, в частности Microsoft DNS Server не обеспечивает аутентификацию и шифрование в соответствии с RFC 2065, тогда как BIND 8 игнорирует многие последние RFC.

Следует отметить, что в BIND 8 термины «первичный» (primary) и «вторичный» (secondary) для серверов имен более не используются. Вместо них предложены определения «основной» (master) и «вспомогательный» (slave). Этим авторы спецификации стараются показать, что, с точки зрения клиентов DNS (resolver), серверы имен абсолютно взаимозаменяемы. Никакой «неполноценности» вспомогательные серверы в себе не несут. Разница заключается лишь в том, что для удобства администрирования редактируемые файлы базы DNS размещаются на основном сервере, а вспомогательные серверы считывают с него информацию. Хотя составители спецификации BIND не рекомендуют устанавливать несколько основных серверов, внедрению подобной схемы ничто не препятствует.

Для более подробного рассмотрения директивы BIND 8 мы возьмем конфигурационный файл /etc/named.boot спецификации BIND 4 для первичного сервера, приведенный в LAN №3 за 1997 г. (см. Распечатку 1) и для вторичного сервера (см. Распечатку 2). На Распечатках 3 и 4 приведены аналогичные конфигурационные файлы для серверов BIND 8. В комплект поставки BIND 8 входит специальная утилита named-bootconf для конвертации файла /etc/named.boot BIND 4 в файл /etc/named.conf BIND 8. Однако для тонкой настройки DNS, а также для инициализации новых возможностей BIND 8 администратору может потребоваться отредактировать конфигурационный файл вручную.

; Файл /etc/named.boot
directory        /etc
primary          comp1.msk.ru	              named.data
primary	        12.170.194.in-addr.arpa	     named.rev1
primary	        13.170.194.in-addr.arpa	     named.rev2
primary	        0.0.127.in-addr.arpa	     named.local
; выход в Internet
cache	        .	                       named.ca

В BIND 8 было решено отказаться от старого стиля комментариев, но взамен введено три новых:

/* Комментарии в стиле Си */

// Комментарии в стиле Си++

# Комментарии в стиле оболочки shell.

// Файл /etc/named.conf
options {
	directory ?/etc?;
};
zone ?comp1.msk.ru? in {
	type master;
	file ?named.data?;
};
zone ?12.170.194.in-addr.arpa? in {
	type master;
	file ?named.rev1?;
};
zone ?13.170.194.in-addr.arpa? in {
	type master;
	file ?named.rev2?;
};
zone ?0.0.127.in-addr.arpa? in {
	type master;
	file ?named.local?;
};
// выход в Internet
zone ?.? in {
	type hint;
	file ?named.ca?;
};a

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

Директива zone определяет доменную зону, за которую отвечает данный сервер. Другими словами, директивы BIND 4 primary, secondary и cache заменены одной директивой zone.

Стоящее после директивы zone и имени домена слово in показывает, что данный домен принадлежит к классу Internet (DNS кроме TCP/IP поддерживает также сети Chaosnet и Hesiod). Далее указывается, к какому типу относится данный сервер имен. Кроме основного (master) и вспомогательного (slave) это может быть тип hint (существует также тип stub). Тип hint играет роль директивы cache в BIND 4 и служит для ссылки на корневой домен Internet.

Параметр file указывает, где хранится файл базы DNS, отвечающей за текущую доменную зону.

Разумеется, выше мы перечислили лишь немногие из используемых директив и параметров. Например, директива zone может иметь около десятка различных параметров и настроек. С некоторыми из них мы познакомимся поближе при рассмотрении конкретных возможностей BIND 8.

СООБЩЕНИЯ ОБ ИЗМЕНЕНИЯХ В ЗОНЕ

Несмотря на большое количество нововведений, самыми яркими особенностями BIND 8 являются поддержка рассылки сообщений об изменении в зоне (DNS NOTIFY), динамическое обновление DNS и списки контроля доступа (Access Control List, ACL).

В версии BIND 4 вторичные серверы имен проверяли обновление информации в доменной зоне по расписанию, через определенные интервалы времени, называемые временем обновления (refresh time). Параметр refresh time задается в записи SOA первичного сервера зоны, кроме него в записи SOA указывается серийный номер версии зоны (serial), а также ряд других параметров, описывающих режим обращения вторичных серверов к первичным.

После того как вторичный сервер имен считал информацию по зоне с первичного сервера, он начинает отсчет времени. По истечении времени, равного величине refresh time, вторичный сервер обращается к первичному и проверяет серийный номер версии зоны. Если номер увеличился, то вторичный сервер инициализирует так называемую пересылку зоны (zone transfer), т. е. заново считывает информацию по всей зоне и после этого возобновляет отсчет времени с нуля.

Минусы данного подхода известны очень давно. Если параметр refresh time задать небольшим, то вторичные серверы (а их может быть довольно много) перегружают линии связи ненужными запросами. К тому же серверы имен нередко обслуживают десятки, сотни и даже тысячи доменных зон. Если же refresh time слишком велико, то хранящаяся на вторичных серверах информация часто оказывается рассогласованной с находящимся на первичном сервере.

16.12.1999г