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 администратору может потребоваться отредактировать конфигурационный файл вручную.

Распечатка 1. Конфигурационный файл первичного сервера BIND 4.

; Файл /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.

Распечатка 2. Конфигурационный файл вторичного сервера BIND 4.

// Файл /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 слишком велико, то хранящаяся на вторичных серверах информация часто оказывается рассогласованной с находящимся на первичном сервере.

В BIND 8 было найдено оптимальное решение этой проблемы. Во-первых, ради совместимости она поддерживает старый порядок обновления информации по зоне. Такой порядок сохраняется в сетях, где наряду с серверами BIND 8 присутствуют и серверы BIND 4. Во-вторых, BIND 8 поддерживает рассылку сообщений об изменениях в зоне. В случае изменения информации по зоне (при увеличении серийного номера зоны) основной сервер рассылает всем вспомогательным серверам сообщения об изменении (запрос NOTIFY). В свою очередь, вспомогательные серверы отвечают основному серверу откликом NOTIFY. Далее вспомогательные серверы запрашивают информацию по серийному номеру зоны, и если он увеличился, то инициируется операция пересылки зоны. Согласно RFC 1996, при получении запросов NOTIFY вспомогательные серверы обязаны также пересылать запросы NOTIFY другим серверам, однако BIND 8 такой режим не поддерживает.

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

В BIND 8 рассылка сообщений об изменениях в зоне активизирована по умолчанию. Однако ее можно отменить (например, в случае наличия серверов BIND 4) с помощью директивы options:

options {


directory ?/etc?;


notify no;


};

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

zone ?comp1.msk.ru? in {


	type master;


	file ?named.data?;


	notify no;


};

Кстати говоря, рассылку сообщений NOTIFY поддерживает не только BIND 8, но и Microsoft DNS Server.

ДИНАМИЧЕСКОЕ ОБНОВЛЕНИЕ DNS

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

BIND 8 поддерживает динамическое обновление баз DNS в соответствии с RFC 2136. Этот режим позволяет на лету добавлять, изменять и удалять записи ресурсов для зоны, которой управляет сервер DNS. Обновление затрагивает не только ресурс, где описываются доменные имена или IP-адреса, но и любые другие, в том числе на основе «набора записей ресурсов» (set of resource records).

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

Из соображений безопасности в BIND 8 динамическое обновление баз DNS по умолчанию отменено. Это вызвано тем, что в противном случае любой желающий может удаленно изменить информацию по DNS. Активизация динамического обновления DNS осуществляется посредством параметра allow-update директивы zone, аргументом которого является список IP-адресов машин, откуда разрешается обновлять DNS. В частности, если DNS разрешается обновлять на основном сервере зоны comp1.msk.ru (см. Распечатку 3),

Распечатка 3. Конфигурационный файл основного сервера BIND 8.

// Файл /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

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

zone ?comp1.msk.ru? in {


	type master;


	file ?named.data?;


	allow-update { 194.170.12.2; };


};

Microsoft DNS Server для Windows NT 4.0 не поддерживает режим динамического обновления, однако в следующей версии (для Windows 2000) такой режим уже будет поддерживаться.

СПИСКИ КОНТРОЛЯ ДОСТУПА

Самой большой проблемой BIND 4 была недостаточная защищенность сервиса от атак злоумышленников. До версии BIND 4.9.3 любой клиент мог обратиться к любому серверу DNS и прочитать любую информацию, а также инициировать такую ресурсоемкую операцию, как пересылка зоны. Таким образом, он мог без особого труда «повесить» сервер или узнать структуру внутренней сети с тем, чтобы в дальнейшем провести более изощренные атаки. Некоторые механизмы защиты были введены уже в BIND 4.9.3, но, к сожалению, они имеют ряд ограничений. Разработчики BIND 8 продолжили работу по повышению защищенности сервиса, а также упорядочили структуру конфигурационного файла.

В основу концепции контроля доступа, применяемой в BIND 8, положены так называемые «списки соответствия адресов» (Address Match Lists, AML). Список соответствия адресов представляет собой перечень IP-адресов, префиксов IP-адресов, именованных списков контроля доступа ACL и имен ключей шифрования (каждый из этих параметров является необязательным). Кроме того, AML может содержать ряд зарегистрированных аргументов (none, any и т. д.). AML регламентирует режим доступа к конкретным ресурсам DNS. В частности, при описании параметра allow-update при динамическом обновлении DNS в качестве аргумента используются именно AML.

IP-адреса в списке AML — это обычные адреса хостов, разделенные знаком ?;?. Префиксы IP-адресов позволяют с помощью одной записи перечислить целые сети и даже группы IP-сетей. Префикс IP-адресов имеет формат, характерный для спецификации бесклассовой междоменной маршрутизации (Classless Inter-Domain Routing, CIDR):

IP-адрес в десятично-точечном формате/количество бит в сетевой маске.

Таким образом, для сети, включающей адреса хостов от 194.170.12.192 до 194.170.12.255, префикс будет иметь вид 194.170.12.192/26. Разумеется, один список AML может содержать несколько префиксов IP-адресов, разделенных символом ?;?, впрочем, как и другие параметры.

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

В качестве примера директивы acl мы приведем настройку динамического обновления DNS:

acl ?main-server? {


	{ 194.170.12.2; };


};


zone ?comp1.msk.ru? in {


	type master;


	file ?named.data?;


	allow-update { ?main-server?; };


};

Здесь списку ACL присвоено имя ?main-server?, именно оно используется в директиве zone.

Для AML зарезервированы четыре специальных параметра:

None — ни одному из IP-адресов не разрешается доступ к ресурсу;
Any — любой хост имеет право доступа к ресурсу;
Localhost — только сам сервер имеет право доступа к ресурсу;
Localnets — любой хост, входящий в одну из сетей, к которой сервер DNS подключен напрямую, имеет право доступа к ресурсу.

К сожалению, система безопасности с доверительными отношениями на базе IP-адресов имеет много слабых мест. С помощью подделки IP-адресов (IP-spoofing) злоумышленник может провести опасные атаки по типу «отказ в обслуживании» и даже получить несанкционированный доступ к конфиденциальной информации DNS. Гораздо более надежную защиту дает использование методов шифрования и аутентификации на основе криптографических алгоритмов. В BIND 8 для этого введены новые директивы (key, trusted-keys), а также объявления о поддержке ключей шифрования в директивах acl (в том числе и в списке соответствия адресов AML), server, zone.

Однако одно дело объявить, и совсем другое — реализовать. До появления версии BIND 8.2 никаких возможностей по шифрованию и аутентификации не поддерживалось в принципе, за исключением разве что лексического анализа директив. Начиная с BIND 8.2 средства криптографии наконец-то появились, но пока в очень ограниченном количестве.

Кроме того, применение средств шифрования в DNS вступает в некоторое противоречие с российским законодательством (см. статью «Защита информации по-российски» в июньском номере LAN за 1999 год). Еще одним недостатком применения надежных алгоритмов шифрования в DNS является потеря гибкости при управлении доменным сервисом. На уровне глобальных или распределенных сетей такие механизмы защиты вряд ли займут сколько-нибудь заметное место, ведь сервис DNS изначально предназначался для предоставления услуг максимально возможному количеству пользователей.

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

ЗАЩИТА СЕРВЕРОВ DNS

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

В BIND 4.9.3 была введена специальная запись ресурса TXT под названием secure_zone; эта запись помещается в файл базы DNS, отвечающий за конкретную зону. Запись secure_zone позволяет ограничить круг обслуживаемых клиентов DNS для данной зоны. Поле данных записи ресурса имеет один из следующих форматов:

?<адрес>:<маска>? — устанавливает IP-сеть, хосты которой будут обслуживаться сервером. Адрес и маска должны задаваться в десятично-точечном виде;
?<адрес>:H? — указывает конкретный хост, имеющий право на обслуживание со стороны сервера.

Таким образом, если требуется, чтобы хосты сетей класса C с адресами 194.170.12.0 и 194.170.14.0, а также отдельный хост 194.170.15.2 имели доступ к серверу зоны comp1.msk.ru, то в файле базы зоны (named.data — для данного случая) необходимо указать:

secure_zone IN TXT ?194.170.12.0:255.255.255.0?

secure_zone IN TXT ?194.170.14.0:255.255.255.0?

secure_zone IN TXT ?194.170.15.2:H?.

Однако в таком формате ограничения доступа относятся к конфигурации, а совсем не к ресурсам зоны.

Поэтому в BIND 8 был введен специальный параметр allow-query, помещаемый либо в директиву zone, либо в директиву options, причем в качестве аргументов параметра указывается список AML. Если параметр allow-query поместить в директиву zone

zone ?comp1.msk.ru? in {
	type slave;
	file ?named.data.bak?;
	masters { 194.170.12.2; };
	allow-query { 194.170.12.192/26; 194.170.15.2; };
};

то доступ к дополнительному серверу зоны comp1.msk.ru будет ограничен хостами подсети 194.170.12.192/26 и отдельно стоящим хостом 194.170.15.2.

В случае, когда параметр allow-query помещается в директиву options, ограничения в отношении обслуживания клиентов DNS со стороны конкретного сервера распространяются на все зоны. Хочу подчеркнуть, что в данном случае ограничения действуют даже на зоны, не подконтрольные серверу, в том числе и на зоны, к которым клиенты обращаются с рекурсивными запросами.

Гораздо более важные последствия, чем ограничения в обслуживании обычных запросов со стороны клиентов DNS, имеет введение ограничений на пересылку зоны (zone transfer), поскольку это очень ресурсоемкий процесс.

Начиная с BIND 4.9.3 была введена директива xfrnets, аргументом которой является список сетей и хостов, имеющих право инициировать пересылку зоны. Например

xfrnets 194.170.12.0 194.170.13.0

ограничивает пересылку зоны сетями класса С с адресами 194.170.12.0 и 194.170.13.0. Директива xfrnets распространяется на зоны, подконтрольные данному серверу имен.

В BIND 8 было решено отказаться от директивы xfrnets в пользу параметра allow-transfer. Как и allow-query, он помещается либо в директиву zone, либо в директиву options. Данный параметр использует в качестве аргумента список AML, где перечислены адреса хостов и сетей, которым позволено инициировать пересылку зоны. Как и в других случаях, помещение параметра allow-transfer в директиву zone накладывает ограничения на пересылку зоны только для конкретной зоны, тогда как действие директивы options имеет глобальный характер.

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

ПАРАМЕТРЫ НАСТРОЙКИ ПЕРЕСЫЛКИ ЗОНЫ

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

Нагрузку на сервер можно уменьшить несколькими способами. Одним из них является введение ограничения на общее количество пересылок зоны. Этот параметр регламентирует, сколько процессов named сервер может запустить одновременно для пересылки зоны. По умолчанию таких операций сервер может выполнять не более десяти. Причем если какая-то операция завершена, то может запускаться новая. Тем не менее общее количество одновременных пересылок можно уменьшить (или увеличить). В BIND 4.9.3 это делается с помощью директивы limit с аргументом transfers-in и указанием количества пересылок. В частности, директива (размещенная в конфигурационном файле /etc/named.boot)

limit transfers-in 10

задает общее количество пересылок равным 10.

В BIND 8 аналогичная настройка осуществляется с помощью параметра transfer-in в директиве options:

options {
	transfers-in 10;
};

Вместе с тем в BIND 4.9 и BIND 8 можно ограничивать количество пересылок зоны в расчете на один удаленный сервер (вспомогательный/вторичный сервер). По умолчанию это количество ограничено двумя пересылками. В BIND 4.9.3 применяется директива

limit transfers-per-ns 2

В BIND 8 аналогичная настройка имеет вид

options {
	transfers-per-ns 2;
};

(цифра 2 указывает количество пересылок).

Кроме того, в BIND 8 можно задать количество пересылок зоны для одного конкретного сервера. Для этого используется специальная директива server с параметром transfers:

server 194.170.2.2 {
	transfers 2;
};

Директива server применяется не только для ограничения количества пересылок, но и для других целей. В директиве указывается IP-адрес сервера, на взаимодействие с которым накладываются ограничения.

До BIND 8 при пересылке зоны в каждый отклик сервер имен помещал описание какого-либо одного ресурса зоны. Как следствие, при пересылке зоны число откликов на один запрос достигало многих сотен. BIND 8 позволяет пересылать в каждом пакете отклика описание множества ресурсов. Однако ради сохранения совместимости с ранними версиями BIND такая возможность по умолчанию отключена. С помощью параметра transfer-format, помещаемого в директивы options и zone, администратор может ввести режим формирования отклика. Формат

transfer-format one-answer;

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

transfer-format many-answer;

в одном пакете помещаются описания нескольких ресурсов.

В BIND 8 введен новый параметр max-transfer-time-in, ограничивающий время пересылки зоны. Этот параметр помогает в случаях, когда удаленный сервер завис или работает некорректно. По умолчанию время пересылки ограничено 120 минутами. Параметр max-transfer-time-in может помещаться в директивах options и zone. Формат параметра по умолчанию имеет вид:

max-transfer-time-in 120;

УПРАВЛЕНИЕ СИСТЕМНЫМИ РЕСУРСАМИ СЕРВЕРА

Начиная с версии BIND 4.9.3 был введен ряд настроек, влияющих на потребление системных ресурсов сервера DNS. В BIND 8 были добавлены дополнительные настройки, позволившие еще более ужесточить контроль.

Так, параметр datasize директивы options в BIND 8 позволяет задать размер сегмента данных процесса named. Например, строки

options {
	datasize 64m;
};

определяют максимальный размер сегмента равным 64 Мбайт. В BIND 4.9.3 аналогичная настройка имеет вид

limit datasize 64m

В BIND 8 можно указать максимальный размер стека

options {
	stacksize 16m;
};

а также размер файла core

options {
	coresize 64m;
};

и даже максимальное количество файлов, открытых процессом

options {
	files 256;
};

ДРУГИЕ НОВАЦИИ BIND

Среди других важных новшеств BIND 8 можно отметить наличие хорошо продуманной системы протоколирования событий. Контроль за процессом протоколирования перенесен в конфигурационный файл /etc/named.conf и осуществляется специальной директивой logging. Эта директива дает возможность управлять множеством параметров, в том числе тем, какие события должны протоколироваться, где будут сохраняться протоколы событий, в каких режимах и т. д.

Для управления демоном named в комплект BIND включена утилита ndc. С ее помощью можно не только посылать системные вызовы в named, но и осуществлять отладку сервиса. Для настройки параметров ndc в конфигурационном файле /etc/named.conf используется директива controls.

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

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

В BIND 8 отменена поддержка инверсионных запросов (не путать с запросами к доменам in-addr.arpa). При таких запросах сервер имен должен осуществлять поиск доменных имен по ссылке (обратное преобразование имен). Например, если запись ресурсов выглядит как

comp1.msk.ru IN MX 10 mail.koka.ru,

то при обращении клиента DNS к серверу с запросом «почтовым ящиком какого домена является хост mail.koka.ru?» сервер должен ответить ?comp1.msk.ru?. Однако, как показала практика, инверсионные запросы совершенно неэффективны. Для этого клиент DNS должен наперед знать, к какому серверу он должен обратиться явным образом (рекурсия при инверсионных запросах не осуществляется), чтобы не получить ответа «не знаю». Да и индексирование всех данных на серверах DNS потребляет дополнительные ресурсы.

В старых версиях BIND при осуществлении рекурсии (т. е. кэширования информации) серверы могли только пассивно отслеживать состояние кэша. Если клиент обращался с рекурсивным запросом по удаленному домену, то при наличии в его кэше данных по домену сервер оценивал состояние данных на основании параметра «время жизни» (Time to Live, TTL). Если данные оказывались устаревшими, то сервер обращался к авторизованному серверу соответствующего домена. Таким образом, в кэше могли содержаться давным-давно устаревшие данные, к которым никто не обращался. Соответственно, такая схема вела к непроизводительному расходу значительных объемов оперативной памяти. В BIND 8 введен параметр времени очищения кэша clearning-interval, задаваемый в директиве options. По умолчанию clearning-interval равен 120 минутам, т. е. сервер проверяет кэш на наличие устаревших данных (окончился отсчет TTL) каждые 120 минут и, при обнаружении таковых, удаляет их из памяти.

Кроме того, в BIND 8 введены параметры interface-interval и topology директивы options, позволяющие гибко управлять настройками сервиса DNS в случае, когда сервер имеет несколько сетевых интерфейсов.

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

В BIND 8, как и в BIND 4.9, имеются хорошо продуманные средства организации серверов forward-only, stub, cache-only. Вдобавок в BIND 4.9 и BIND 8 используется концепция распределения нагрузки (Load Sharing), согласно которой любому доменному имени может быть присвоено несколько IP-адресов, например нескольким серверам Web можно назначить одно и то же имя. В этом случае нагрузку между серверами Web можно будет перераспределять циклически и притом динамически.

НОВЫЕ ВОЗМОЖНОСТИ КЛИЕНТОВ DNS

Начиная с версии 4.8.3 и особенно в 4.9.3 клиентские места DNS (в англоязычной литературе применяется термин resolver) подверглись значительным изменениям и дополнениям. Как известно, за настройку работы клиента DNS отвечает главным образом файл /etc/resolv.conf.

Директива domain в файле /etc/resolv.conf задает домен по умолчанию. До версии 4.9.3 использование пробелов после имени домена было запрещено. К сожалению, поскольку на клиентских местах DNS какие-либо средства отладки отсутствуют, обнаружить ошибку было нелегко. В новых версиях BIND проблема наличия пробелов после имени домена была устранена. Кстати, в документах BIND домен по умолчанию рекомендуется задавать не в resolv.conf, а с помощью утилиты hostname, поскольку в этом случае не будут возникать проблемы при использовании некоторых сетевых служб.

В BIND 4.9 и всех версиях BIND 8 порядок обработки директив domain и search претерпел серьезные изменения, причем теперь этот порядок в значительно большей степени соответствует логике работы сетевых служб.

Распечатка 4. Конфигурационный файл вспомогательного сервера BIND 8.

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

ЗАКЛЮЧЕНИЕ

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

Константин Пьянзин — обозреватель LAN. С ним можно связаться по адресу: koka@lanmag.ru