WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |

«DNS and BIND Fourth Edition PaulAlbitz and Cricket Liu O'REILLY DNS и BIND Четвертое издание ПолАльбитц и Крикет Ли Пол Альбитц, Крикет Ли DNS и BIND Перевод М Зислиса Главный редактор А Галунов ...»

-- [ Страница 6 ] --

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

Синтаксис предписания statistics-interval идентичен синтаксису пред писаний для прочих служебных интервалов:

По умолчанию интервал длится те же 60 минут, а установка нулевого значения отключает периодическое создание статистических отчетов.

Поскольку BIND 9 не производит записи статистики в log-файл syslog, в нем отсутствует и изменяемый интервал создания статистических отчетов.

352 Глава 10. Дополнительные возможности Значения TTL Какое-то время BIND производил усечение значений TTL для кэширо ванных записей - до разумных значений. В BIND 8 и 9 это разумное значение поддается настройке.

В BIND 8.2 и DNS-серверах более поздних версий TTL для кэширован ных отрицательных ответов можно ограничить с помощью предписа ния max-ncache-ttl оператора options. Эта возможность является сво его рода страховкой для тех, кто произвел обновление до версии 8.2, в которой применяется новая схема отрицательного кэширования (до кумент RFC 2308 и все прочее, подробности приводятся в главе 4). На чиная с этой версии, отрицательная информация кэшируется DNS сервером в соответствии со значением последнего поля SOA-записи зо ны, а многие зональные администраторы до сих пор используют это поле в качестве значения TTL по умолчанию для зоны - оно, скорее всего, великовато для отрицательной информации. Поэтому преду смотрительные администраторы DNS-серверов могут воспользоваться вот такой конструкцией:

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

DNS-серверы BIND 9 позволяют также изменять верхний предел до пустимого значения TTL для кэшируемых записей - с помощью пред писания max-cache-ttl. Время по умолчанию - одна неделя. DNS-серве ры BIND 8 также ограничивают максимальное время жизни одной не делей, но не позволяют изменять этот предел.

Наконец, существует нечто, называемое некорректное TTL, которое, вообще говоря, вовсе не TTL. Это длительность интервала времени, в течение которого DNS-сервер помнит, что удаленный DNS-сервер не является авторитативным для зоны, которая ему делегирована. Это позволяет сэкономить драгоценное время, избегая запросов к DNS серверу, который все равно ничего не знает об интересующих нас до менных именах. DNS-серверы BIND 8, начиная с версии 8.2, а также BIND 9 более поздние, чем 9.1.0, позволяют изменять некорректное TTL с помощью предписания lame-ttl оператора options. По умолча нию это значение составляет 600 секунд (10 минут), а предельное зна чение - 30 минут. Кэширование информации о DNS-серверах с некор Совместимость рентным делегированием можно отключить, установив нулевое значе ния, хотя нам это кажется Исключительно Дурным Тоном.

Совместимость Подводя итоги, рассмотрим некоторые предписания настройки, свя занные с совместимостью DNS-сервера с клиентами и другими DNS серверами.

Предписание rfc2308-type 1 позволяет управлять форматом отрица тельных ответов, посылаемых DNS-сервером. По умолчанию DNS-cep веры BIND 8 и 9 включают в отрицательный ответ только SOA-запись зоны. Второй допустимый вариант формата включает также и NS-за писи зоны, но некоторые из старых версий DNS-серверов неправильно интерпретируют такие ответы - считая их перенаправлениями. Если, по какой-то странной причине (странной, потому что нам не удается придумать хотя бы одну) появилась необходимость включать в отри цательные ответы NS-записи, воспользуйтесь такой конструкцией:

Впервые поддержка предписания rfc2308-type 1 появилась в BIND 8.2;

в BIND 9 она отсутствует.

При посылке кэшированных отрицательных ответов более старым DNS-серверам могут возникать определенные проблемы. Во времена, когда отрицательное кэширование не существовало, все отрицательные ответы, разумеется, были авторитативными. Но некоторые разработчи ки DNS-серверов добавляли в код проверку: приниматься должны толь ко авторитативные отрицательные ответы. Затем появилось отрица тельное кэширование и неавторитативные отрицательные ответы. Ой!

Предписание auth-nxdomain оператора options позволяет устанавли вать бит авторитативности для ответов, извлекаемых DNS-сервером из кэша, чтобы любой из древних DNS-серверов остался доволен. По умолчанию в серверах BIND 8 auth-nxdomain устанавливается в значе ние on (режим включен);

в BIND 9 режим по умолчанию выключен.

И наконец, когда безрассудно смелые люди портировали BIND 8.2. на систему Windows NT, они обнаружили, что DNS-сервер должен ре агировать на символы возврата каретки и начала новой строки, встре чающиеся в концах строк (последовательность, определяющая конец строки в системах Windows) так же, как на просто символ новой стро ки (конец строки в системах Unix). Чтобы использовать такой режим, воспользуйтесь конструкцией:

354 Глава 10. Дополнительные возможности В BIND 9 предписание игнорируется, поскольку эта версия DNS-серве ра считает оба варианта признаком конца строки.

Основы адресации в IPv Прежде чем рассмотреть следующие две темы, а именно отображение доменных имен в IPv6-адреса и обратное, мы опишем представление и структуру адресов IPv6. Как, вероятно, известно читателям, адреса IPv6 имеют длину 128 битов. Предпочтительное представление IPv6 адреса - восемь групп четырехзначных шестнадцатеричных цифр, разделяемых двоеточиями. Пример:

Первая группа шестнадцатеричных цифр (в нашем примере - 0123) представляет четыре наиболее значимых (старших) бита адреса.

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

Но каждая группа должна содержать по меньшей мере одну цифру;

в противном случае следует использовать запись ::. Запись через :: поз воляет производить сжатие последовательных групп нулей. Это удоб но, если необходимо указать только IPv6-префикс. Например:

определяет первые 32 бита IPv6-адреса в виде dead:beef, а остальные 96 - в виде групп нулей.

Пара символов :: может использоваться в начале IPv6-адреса для ука зания суффикса. К примеру, адрес loopback-интерфейса в IPv6 обычно записывается как:

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

Сокращение :: может использоваться в пределах адреса лишь единож ды, во избежание неоднозначностей.

Префиксы IPv6 записываются в формате, сходном с CIDR-записью в IPv4. Значимые биты префикса записываются в стандартном формате IPv6 и отделяются от десятеричного показателя числа значимых битов символом слэша. Таким образом, три приводимых ниже специфика Основы адресации в IPv6 ции префиксов абсолютно эквивалентны (хотя, очевидно, и не одина ково лаконичны):

Адреса IP версии 4 имеют иерархическую структуру, которая отражает природу IPv4-сетей: отдельные сети подключены через провайдеров ус луг Интернета, а те, в свою очередь, подключены к другим провайде рам, либо к несущим магистралям сети Интернет. Каждый провайдер отвечает за несколько битов результирующего 32-битного IP-адреса:

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

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

В сердце интернет-сети IPv6 - агрегаторы высшего уровня (Top-Level Aggregators, TLAs). Это сети, которые подключены напрямую к несу щим информационным магистралям сети и обеспечивают подключе ние для агрегаторов следующего уровня (Next-Level Aggregators, NLAs). NLA-сети обеспечивают подключение сетей отдельных площа док к интернет-сети IPv6 (рис. 10.5).

Как и в случае с IPv4-ceтями, каждая из организаций заведует опреде ленными битами IPv6-адреса. Чтобы помочь читателям представить Рис. 10.5. Структура интернет-сети IPv I 356 Глава 10. Дополнительные возможности иерархию адресации IPv6, мы приводим диаграмму для наиболее распро страненной структуры IPv6-адреса, описанной в документе RFC 2374:

FP - это префикс формата (Format Prefix), который занимает первые три бита адреса и определяет формат оставшейся части. Форматный префикс для данного конкретного формата, который называется (вдох ните поглубже) IPv6 Aggregatable Global Unicast Address Format (IPv6 формат для индивидуальных (юникастовых) адресов), имеет значение 001. Следующие 13 битов определяют агрегатор высшего уровня. Во семь зарезервированных битов имеют нулевые значения, и еще 24 бита определяют агрегатор следующего уровня. Оставшиеся биты использу ются конкретной площадкой: Site-Level Aggregator ID (идентификатор агрегатора уровня площадки) или SLA ID - по сути дела эквивалентен битам подсети в IPv4-адресе, a Interface ID (идентификатор интер фейса) уникальным образом определяет отдельный интерфейс сети площадки.

В описанном формате адреса каждый идентификатор присваивается сущностью, которая расположена уровнем выше в иерархии. Так, единственный регистратор адресов высшего уровня присваивает TLA идентификаторы агрегаторам высшего уровня. TLA, в свою очередь присваивают NLA-идентификаторы своим клиентам, а те - SLA-иден тификаторы своим. NLA-идентификаторы должны быть уникальны ми только в пределах родительского TLA-идентификатора, как и SLA идентификаторы в пределах отдельных NLA-идентификаторов.

Адреса и порты DNS-серверы BIND 9 умеют использовать в качестве транспорта про токолы IPv4 и IPv6;

то есть могут посылать и получать запросы и отве ты через IPv4 и IPv6. DNS-серверы BIND 8 поддерживают в качестве транспорта только IPv4. Однако обе версии сервера поддерживают по хожие предписания, предназначенные для выбора сетевых интерфей сов и портов, для которых ведется прослушивание.

Настройка для транспорта IPv С помощью предписания listen-on можно определить прослушиваемые сетевые интерфейсы для DNS-сервера BIND 8 или BIND 9. В простей шей форме listen-on принимает в качестве аргумента список отбора ад ресов:

Адреса и порты DNS-сервер производит прослушивание любых сетевых интерфейсов локального узла, адреса которых входят в список отбора адресов. Что бы указать альтернативный порт (с номером, отличным от 53) прослу шивания, можно воспользоваться модификатором port:

В BIND 9 существует возможность определять порт для каждого от дельного сетевого интерфейса:

Обратите внимание, что большинство клиентов не может быть настро ено на отправку запросов DNS-серверу через альтернативный порт, по этому такой DNS-сервер будет полезен гораздо меньше, чем может по казаться. Но он может выполнять передачу зон, поскольку в предписа нии masters может быть указан альтернативный порт:

Если у DNS-сервера BIND 9 несколько основных DNS-серверов, каж дый из которых производит прослушивание собственного порта, мож но воспользоваться такой конструкцией:

BIND 9 даже позволяет посылать NOTIFY-сообщения на альтернатив ные порты. Чтобы предписать DNS-серверу уведомлять вторичные DNS-серверы через один и тот же нестандартный порт, можно восполь зоваться предписанием:

Чтобы посылать уведомления через различные порты:

Если DNS-сервер должен работать с определенным локальным сете вым интерфейсом для отправки запросов, - например, потому, что 358 Глава 10 Дополнительные возможности один из основных DNS-серверов опознает лишь один из его многочис ленных адресов, - воспользуйтесь предписанием query-source:

Обратите внимание, что в качестве аргумента фигурирует не список отбора адресов, а единственный IP-адрес. Можно также указать кон кретный исходный порт для запросов:

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

Обратите внимание, что query-source относится только к UDP-запро сам;

для TCP-запросов выбор исходного адреса всегда происходит на основе таблицы маршрутизации;

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

Существует аналогичное предписание transfer-source, позволяющее определять исходный адрес, используемый для передачи зон. В BIND эта настройка относится также к SOA-запросам, поступающим от вто ричных DNS-серверов, а также к ретранслированным динамическим обновлениям:

Как и в случае query-source, в качестве аргумента фигурирует единст венный IP-адрес, но отсутствует ключевое слово address. В BIND 8 мо дификатор port отсутствует. В BIND 9 можно указать и исходный порт:

Это определение исходного порта действует только для UDP-сообще ний (то есть SOA-запросов и ретранслированных динамических обнов лений).

transfer-source может также использоваться в качестве предписания оператора zone, и в этом случае относится только к случаям передачи Адреса и порты (BIND 9 - еще и к SOA-запросам и динамическим обновлениям) этой зоны:

И наконец, в BIND 9.1.0 существует предписание, позволяющее опре делять, с какого адреса посылаются NOTIFY-сообщения, а именно notify-source. Такая возможность находит применение на узлах, состо ящих в нескольких сетях одновременно, поскольку вторичные DNS серверы принимают NOTIFY-сообщения для зоны только с IP-адресов, перечисленных в предписании masters для этой зоны. Синтаксис no tify-source схож с синтаксисом прочих source-предписаний. Пример:

Как и в случае transfer-source, в notify-source может быть определен исходный порт, а само предписание может использоваться в операторе zone с целью частной настройки параметров для конкретной зоны:

Настройка для транспорта IPv По умолчанию DNS-сервер BIND 9 не производит прием IPv6-запросов.

Чтобы настроить DNS-сервер на прослушивание локальных сетевых IPv6-интерфейсов, следует воспользоваться предписанием listen-on-v6:

В отличие от своего IPv4-собрата, предписание liten-on-v6 в качестве аргумента принимает только ключевые слова any и попе. Тем не ме нее, можно настроить DNS-сервер BIND 9 на прослушивание альтер нативного порта - либо нескольких альтернативных портов - с по мощью модификатора port:

360 Глава 10. Дополнительные возможности По умолчанию номер порта, разумеется, 53.

Также существует возможность определять используемый в исходя щих запросах IPv6-адрес, а также порт с помощью предписания trans fer-source-v6:

или:

По умолчанию используется исходный адрес, соответствующий сети, в которую посылается ответ, и случайный порт с минимальными при вилегиями. Как и в случае transfer-source, предписание transfer-sour ce-v6 может использоваться в операторе zone. Определение исходного порта влияет только на SOA-запросы и ретранслируемые динамичес кие обновления.

И наконец, BIND 9.1.0 и более поздних версий позволяет определить, какой IPv6-адрес будет использоваться для отправки NOTIFY-сообще ний а-ля предписание notify-source. Соответствующее предписание IPv6 называется, само собой, notify-source-v6:

Как и в случае transfer-source-v6, может быть указан исходный порт, а само предписание может использоваться в операторе zone.

IPv6: прямое и обратное отображение Понятно, что существующие А-записи не справятся со 128-битными IPv6-адресами;

BIND ожидает, что в части данных А-записи присутст вует 32-битный адрес в восьмибитной нотации.

Организация IETF разработала простое решение этой проблемы, опи санное в документе RFC 1886. 128-битные IPv6-адреса хранятся в но вой адресной записи - АААА, а для целей обратного отображения со здан новый домен ip6.int. Это простое решение было реализовано в BIND 4.9. Однако простое решение понравилось далеко не всем, поэто му было придумано гораздо более сложное. Это решение, о котором мы скоро расскажем, связано с новыми типами записей - А6 и DNAME, а также требует полной ревизии кода DNS-сервера для реализации.

Использование старой записи АААА и домена ip6.int в настоящее вре мя не поощряется, но существует достаточное число IPv6-программ, IPv6: прямое и обратное отображение которые все еще используют именно это, а не более новое решение, так что важно понимать суть обоих вариантов.

АААА и ip6.int Итак, простой способ решить задачу описан в документе RFC 1886 и связан с использованием адресной записи, в четыре раза более длинной, чем А-запись. Речь идет о записи АААА (четыре А). Данные в АААА записи представляются в формате IPv6-адреса, описанном ранее. По этому можно встретить АААА-записи примерно следующего вида:

RFC 1886 также определяет ip6.int, новое пространство имен для об ратного отображения IPv6-адресов. Каждый уровень поддоменов в пределах ip6.int представляет четыре бита 128-битного адреса в шест надцатеричной системе счисления - в том же формате, что и компо ненты адреса в АААА-записи. Наименее важные (младшие) биты на чинают доменное имя. В отличие от формата адресов, принятого для АААА-записей, формат доменного имени не позволяет опускать нули из квартетов, поэтому в доменном имени ip6.int, соответствующем полному IPv6-адресу, всегда присутствует 32 шестнадцатеричных цифры и 32 уровня поддоменов. Вот доменное имя, которое соответст вует адресу из последнего примера:

Для этих доменных имен существуют PTR-записи, как и в случае до менных имен зоны in-addr.arpa:

Аб, DNAME-записи, бит-строковые метки и ip6.arpa Мы описали простой способ. Более сложный - и принятый в качестве официального - способ реализации прямого и обратного отображения IPv6 связан с использованием записей типов А6 и DNAME. Записи А и DNAME описаны в документах RFC 2874 и RFC 2672, соответственно.

Впервые поддержка записей этих типов появилась в BIND версии 9.0.0.

АААА-записи и обратное отображение в ip6.int были заменены новы ми механизмами, прежде всего, по той причине, что затрудняли пере нумерацию сетей. К примеру, если организация меняет агрегаторы следующего уровня, ей придется изменить все АААА-записи в файлах данных зон, поскольку 24 бита каждого IPv6-адреса идентифицируют NLA-агрегатор.1 Или представьте смену агрегатора высшего уровня И разумеется, новый NLA-агрегатор может быть подключен через другой TLA-агрегатор, а это означает изменение еще 16 битов...

362 Глава 10 Дополнительные возможности для NLA-агрегатора. Зональные данные клиентов в этот момент поте ряли бы всякий смысл.

Записи А6 и прямое отображение В целях упрощения перенумерации в записях А6 разрешается указы вать лишь часть IPv6-адреса, к примеру, последние 64 бита (иденти фикатор интерфейса), связанные с сетевым интерфейсом узла, а остав шуюся часть адреса определять строковым доменным именем. Таким образом, администраторы могут указывать только часть адреса, кото рую непосредственно контролируют. Чтобы создать полный адрес, клиент или DNS-сервер должен разобрать цепочку записей А6 начи ная с доменного имени узла и заканчивая идентификатором агрегато ра высшего уровня. Цепь может иметь ветвления, если сеть площадки подключена к нескольким NLA-агрегаторам или NLA-агрегатор под ключен к нескольким TLA-агрегаторам.

К примеру, следующая запись А6:

определяет последние 64 бита IPv6-адреса узла drunkenmaster.mo vie.edu (число 64 в данном случае определяет число битов префикса, не приводимых в данной Аб-записи) и говорит, что оставшиеся 64 бита могут быть найдены с помощью поиска Аб-записи в subnet1.v6.mo vie.edu.

subnetl.v6.movie.edu, в свою очередь, определяет 16 последних битов 64-битного префикса (SLA-идентификатора), который был опущен в адресе А6 для drunkenmaster.movie.edu, в также доменное имя для по иска следующей записи А6:

Первые 48 битов префикса данных для subnetl.v6.movie.edu установле ны в нули, поскольку они не значимы в данном контексте.

По сути дела, эти записи предписывают нам произвести поиск двух за писей А6 на следующем шаге, одну для movie-u.nla-a.net, а одну для movie.nlab.net. Это происходит потому, что Университет кинематогра фии подключен к двум NLA-агрегаторам, NLA А и NLA В. В зоне NLA А мы находим следующее:

восемь битов идентификатора площадки в пределах идентификатора NLA, установленные NLA-агрегатором А для сети Университета кине матографии. Дело в том, что поле NLA-идентификатора тоже имеет IPv6: прямое и обратное отображение иерархическое деление и состоит из идентификатора NLA, присвоен ного TLA-агрегатором, и собственного идентификатора нашей сети.

Поскольку NLA-агрегатор присваивает только идентификатор нашей площадки, а оставшаяся часть лежит на совести соответствующего TLA-агрегатора, мы и ожидаем увидеть только идентификатор пло щадки в зональных данных NLA-агрегатора. Оставшаяся часть NLA идентификатора содержится в записи А6 соответствующей TLA-зоны.

В зоне NLA В мы обнаруживаем вот эту запись, которая также содер жит идентификатор площадки для нашей сети:

В зонах TLA присутствуют такие данные:

и:

И наконец, в зоне регистрации IPv6-адресов высшего уровня мы нахо дим следующие записи, которые отражают TLA-идентификаторы для TLA1 и TLA2:

Следуя по цепи записей А6, DNS-сервер может собрать все 128 битов двух IPv6 адресов drunkenmaster.movie.edu. Результаты:

Для первого адреса используется маршрут через TLA 1 и NLA А в сеть Университета, а для второго - маршрут через TLA 2 и NLA В. (Мы под ключены к двум NLA-агрегаторам для надежности.) Обратите внима ние, что если TLA 1 изменит NLA-значение для NLA А, потребуется изменить только запись А6 для nla-a.tla-l.net в данных соответствую щей зоны;

это изменение будет «каскадировано» во все цепи А6, про ходящие через NLA А. Таким образом, управление адресацией в IPv6 сетях становится очень удобным, как и смена NLA-агрегаторов.

Если DNS-сервер встречается в NS-записи и владеет одной или несколькими записями А6, эти Аб-записи должны со держать полные 128-битные IPv6-адреса. Это позволяет избежать тупиковой ситуации, когда DNS-клиент или DNS-сервер должен связаться с удаленным DNS-сервером в целях разрешения части IPv6-адреса этого DNS-сервера.

364 Глава 10. Дополнительные возможности DNAME-записи и обратное отображение Изучив, как работает прямое отображение для записей А6, перейдем к обратному отображению для IPv6-адресов. Как и в случае с записями А6, процесс гораздо сложнее, чем при использовании зоны ip6.int.

Обратное отображение IPv6-адресов связано с использованием записей типа DNAME, который описан в документе RFC 2672, а также бит строковых меток, описанных в документе RFC 2673. DNAME-записи немного похожи на CNAME-записи с масками. Они используются для замены одного доменного суффикса другим. К примеру, если мы рань ше использовали доменное имя movieu.edu, а затем сменили его на тпо vie.edu, то старую зону movieu.edu можно заменить такой:

Данная DNAME-запись в зоне movieu.edu сопоставляется с любым до менным именем, которое кончается на movieu.edu, кроме собственно имени movieu.edu. DNAME-записи, в отличие от CNAME-записей, мо гут сосуществовать с другими записями для того же доменного имени, если это не CNAME- или DNAME-записи. При этом владелец DNAME записи не может включать поддомены.

Когда DNS-сервер movieu.edu получает запрос для любого доменного имени, которое кончается на movieu.edu, допустим, cuckoosnest.movi eu.edu, запись DNAME предписывает «синтезировать» псевдоним, связывающий cuckoosnest.movieu.edu и cuckoosnest.movie.edu, заменив movieu.edu на movie.edu:

Действие DNAME-записи отчасти схоже с действием команды s (sub stitute, замена) редактора sed. DNS-сервер movieu.edu возвращает дан ную CNAME-запись. Если запрос поступил от более нового сервера, DNAME-запись также возвращается в ответном сообщении, так что впо следствии получатель может самостоятельно синтезировать CNAME записи на основе кэшированной DNAME-записи.

Второй ингредиент волшебства обратного отображения для IPv6 бит-строковые метки, которые являются способом более компактной записи длинных последовательностей двоичных (однобитовых) меток IPv6: прямое и обратное отображение доменного имени. Предположим, необходимо разрешить делегирова ние между двумя произвольными битами IP-адреса. Это может заста вить нас представлять каждый бит адреса в виде доменного имени. Но для доменного имени, представляющего IPv6-адрес, потребуется меток! Ух!

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

Строка помещается в лексемы "\[" и "]", чтобы ее можно было отли чать от традиционных меток, и начинается с буквы, которая определя ет основание строки: Ъ для двоичного основания, о для восьмеричного и х для шестнадцатеричного.

Вот бит-строковые метки, соответствующие двум IPv6-адресам drun kenmaster.movie.edu:

Обратите внимание, что строка начинается со старшего бита, как и в текстовом представлении адреса IPv6, но метки следуют в порядке, об ратном принятому в домене in-addr.arpa. Несмотря на это, две приве денные бит-строковые метки представляют в несколько иной кодиров ке доменные имена, которые начинаются следующим образом:

Также отметим, что присутствуют все 32 шестнадцатеричные цифры адреса - нули нельзя удалять, поскольку отсутствуют двоеточия, раз деляющие группы цифр.

Бит-строковые метки могут также использоваться для представления фрагментов IPv6-адресов, и в этом случае следует указывать число значащих битов строки, отделяя его от строки символом слэша. Иден тификатор для TLA 1 - \[х0222/16].

DNAME-записи и бит-строковые идентификаторы используются для сопоставления отдельных частей доменных имен, кодирующих IPv6 адреса, и итеративного изменения доменного имени от имени, для ко торого производится поиск, до имени из зоны, которая управляется организацией узла с указанным IPvб-адресом.

Представим себе, что мы производим обратное отображение для \[x024200196642000102104bfffe10d24].ip6.arpa, доменного имени, которое соответствует сетевому интерфейсу drunkenmaster.movie.edu (при доступе через TLA 2 и NLA В). Корневые DNS-серверы, вероятно, отправят наш DNS-сервер к DNS-серверам зоны ip6.arpa, содержащей следующие записи:

366 Глава 10. Дополнительные возможности Первая из них соответствует началу доменного имени, для которого производится поиск, поэтому DNS-серверы ip6.arpa возвращают наше му серверу псевдоним, который выглядит следующим образом:

Первые четыре шестнадцатеричные цифры (наиболее значимые 16 би тов) адреса удалены, а суффиксом для адреса в правой части записи псевдонима теперь является ip6.tla-2.net, поскольку известно, что этот адрес принадлежит к TLA 2. В ip6.tla-2.net мы находим:

Доменное имя в следующем запросе:

превращается в:

Затем наш DNS-сервер посылает запрос для нового доменного имени DNS-серверам ip6.nlab.net. В зоне ip6.nlab.net присутствует такая за пись:

которая превращает искомое доменное имя в:

Наконец, зона ip6.movie.edu содержит PTR-запись, которая позволяет получить окончательное доменное имя узла:

К счастью, администраторы зоны чаще всего будут сталкиваться толь ко с сопровождением PTR-записей, подобных тем, что присутствуют в ip6.movie.edu. Даже если администратор работает в агрегаторе высшего уровня или NLA-агрегаторе, создание DNAME-записей, «извлекаю щих» соответствующий NLA-идентификатор или идентификатор пло щадки из адресов клиентов, не столь уж непосильная задача. В резуль тате можно будет использовать единственный файл для хранения ин формации, связанной с обратным отображением, даже несмотря на то, что каждый из узлов может иметь несколько адресов. Помимо этого, появляется возможность менять NLA-агрегаторы, не изменяя файлы данных зон.

• TSIG ^Л ^Л • Обеспечение безопасности В В DNS-cepeepa В В • DNS и брандмауэры сети ^^Ьш ^^^в Интернет • Расширения системы безопасности DNS Безопасность - Надеюсь, волосы у тебя сегодня хорошо приклеены? спросил Рыцарь, когда они тронулись в путь.

- Не лучше, чем всегда, - с улыбкой отвечала Алиса.

- Этого мало, - встревожился Рыцарь.

- Ветер тут в лесу такой сильный, что прямо рвет волосы с корнем!

-А вы еще не придумали средства от вырывания волос? - спросила Алиса.

- Нет, но зато я придумал средство от выпадения, отвечал Рыцарь.

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

В июле 1997 года, в течение двух периодов по несколько дней каждый, пользователи сети Интернет, набиравшие в своих броузерах адрес www.internic.net с целью попасть на веб-сайт организации InterNIC, по падали на сайт, принадлежащий организации AlterNIC. (AlterNIC уп равляет альтернативным набором корневых DNS-серверов, которые де легируют авторитативность дополнительным доменам высшего уровня, с именами вроде med и porn.) Как это произошло? Евгений Кашпурев (Eugene Kashpureff), работавший в то время в организации AlterNIC, выполнил программу, которая «отравила» кэши крупных DNS-серве ров по всему миру, заставив их думать, что адресом для имени www.in ternic.net в действительности является адрес веб-сервера AlterNIC.

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

веб сайт, на который попадали пользователи, был, вне всяких сомнений сайтом AlterNIC, а не InterNIC. А теперь вообразите, что некто отра вил кэш вашего DNS-сервера, и имя www.amazon.com или www.well sfargo.com приводит теперь на чужой веб-сервер, который находится вне юрисдикции местных законов. Теперь представьте, что ваши поль 368 Глава 11. Безопасность зователи при посещении сайта вводят номера и даты истечения действия своих кредитных карт, и вам все станет ясно.

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

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

TSIG В BIND версии 8.2 появился новый механизм обеспечения безопаснос ти для сообщений DNS, который носит название транзакционных подписей, сокращенно TSIG (transaction signatures). В TSIG использу ется механизм общих секретов и вычислительно необратимой хеш функции для проверки подлинности сообщений DNS, в особенности ответов и обновлений.

Механизм TSIG, описанный в документе RFC 2845, относительно прост в настройке, не создает дополнительных сложностей для DNS клиентов и DNS-серверов, а также достаточно гибок, чтобы обеспечить безопасность в контексте сообщений DNS (включая процесс передачи зоны) и динамических обновлений. (Прямая противоположность рас ширениям системы безопасности DNS, которые мы обсудим в конце этой главы.) При настроенном и работающем механизме TSIG DNS-сервер или ав тор обновления добавляет TSIG-запись в раздел дополнительных дан ных сообщения DNS. TSIG-запись является «подписью» сообщения DNS и подтверждает, что отправитель сообщения обладает общим с получателем криптографическим ключом и что сообщение не изменя лось после того, как было отправлено. Апологеты от криптографии могут, конечно, заявить, что TSIG-«подписи» не являются подписями в криптографическом смысле, поскольку не позво ляют производить подтверждение авторства. Поскольку любой владелец разделяемого ключа может создать подписанное сообщение, получатель подписанного сообщения не может утверждать, что оно отправлено дейст вительным автором (поскольку сам вполне способен его подделать).

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

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

В механизме TSIG применяется вычислительно необратимая хеш функция, которая называется MD5. В частности, разновидность MD5, которая называется HMAC-MD5. HMAC-MD5 работает в режиме учета ключей, то есть вычисляемое 128-битное хеш-значение зависит не только от исходных данных, но еще и от ключа.

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

Но следует знать, что TSIG-запись содержит хеш-значение, вычислен ное для полного сообщения DNS и некоторых дополнительных полей.

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

Дополнительные поля TSIG-записи включают время подписи сообще ния DNS. Это позволяет отражать атаки [повторного] воспроизведения (replay attacks), суть которых заключается в том, что взломщик пере хватывает авторизованную транзакцию с подписью (например, дина мическое обновление или удаление важной RR-записи) и воспроизво дит ее позже. Получатель подписанного сообщения DNS проверяет 370 Глава 11. Безопасность время подписи, чтобы убедиться, что это время находится в пределах допустимого (допустимое время определяется отдельным полем TSIG записи).

Настройка TSIG Прежде чем начать использовать TSIG для идентификации, необходи мо создать один или несколько TSIG-ключей для сторон, обмениваю щихся данными. Так, если необходимо с помощью TSIG обезопасить передачу зоны с DNS-мастер-сервера movie.edu на вторичный, следует настроить оба сервера на использование общего ключа:

terminator-wormhole.movie.edu., аргумент оператора key в приведенном примере, является в действительности именем ключа, хотя выглядит как доменное имя. (Имя ключа кодируется в сообщениях DNS так же, как и обычные доменные имена.) В документе RFC пo TSIG предлага ется давать ключу имя, отражающее пару узлов, которые пользуются ключом. Помимо этого рекомендуется применять различные ключи для различных пар узлов.

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

В настоящее время значение алгоритма всегда hmac-md5. Секрет пред ставляет собой ключ в кодировке Base 64, созданный с помощью про граммы dnssec-keygen, входящей в состав пакета BIND 9, либо с помо щью программы dnskeygen, входящей, в состав пакета BIND 8. Ниже приводится пример создания ключа с помощью dnssec-keygen, которая проще в применении:

Настройка -а позволяет задать имя алгоритма, с помощью которого должен быть создан ключ. (Это необходимо, поскольку dnssec-keygen умеет создавать ключи другого типа, как мы увидим в разделе, посвя щенном DNSSEC.) Параметр -b принимает в качестве аргумента длину TSIG ключа;

соответствующий документ RFC рекомендует использовать ключи длиной в 128 битов. Параметр -п в данном примере принимает в качестве аргумента HOST, тип генерируемого ключа. (В DNSSEC ис пользуются ключи типа ZONE.) Последний аргумент программы имя ключа.

dnssec-keygen и dnskeygen создают в своих рабочих каталогах файлы, содержащие созданные ключи, dnssec-keygen печатает основу имен файлов на стандартный вывод. В приведенном примере программой dnssec-keygen были созданы файлы Kterminator-wormhole.movie.edu.+ 157+28446.key и Kterminator-wormhole.movie.edu.+157+28446.private.

Ключ можно извлечь из любого файла. Если вы задаетесь вопросом, что это за забавные цифры - 157 и 28446, отвечаем: это номер алгорит ма DNSSEC для ключа (157 соответствует алгоритму HMAC-MD5) и карта (fingerprint, «отпечатки пальцев») ключа (28446), хеш-значе ние, вычисленное для ключа с целью его последующей идентифика ции. Карта ключа не особенно полезна в контексте TSIG, но в DNSSEC реализована поддержка нескольких ключей для зоны, поэтому важно иметь возможность идентифицировать ключ по его карте.

Файл Kterminator-wormhole.movie.edu.+157+28446.key содержит стро ку:

А вот содержимое Kterminator-wormhole.movie.edu.+157+28446.private:

Можно также выбрать свой собственный ключ и перекодировать его в Base 64 с помощью программы mmencode:

Поскольку реальный двоичный ключ, как подразумевается предписа нием, является секретом, следует проявлять осторожность при пере носе его на DNS-серверы (например, пользоваться ssh) и проследить за тем, чтобы ключ не мог прочесть любой желающий. Последнее дости гается установлением для файла named.conf прав доступа, исключаю щих чтение файла пользователями, не входящими во владеющую группу, либо применением оператора include для чтения оператора key из другого файла, для которого установлены описанные права доступа:

Существует еще одна проблема, которая часто встречается при исполь зовании TSIG: синхронизация времени. Отметка времени в TSIG-запи си полезна для предотвращения атак, основанных на воспроизведе 372 Глава 11. Безопасность нии, но работоспособность этого свойства изначально уменьшается тем фактом, что часы DNS-серверов не синхронизированы. Это приво дит к получению сообщений об ошибках примерно такого вида:

Мы быстро избавились от этой проблемы, используя NTP (Network Ti me Protocol) - сетевой протокол времени. TSIG в работе Теперь, уже совершив подвиг создания ключей TSIG для наших серве ров, мы, вероятно, должны настроить серверы на практическое приме нение этих ключей. В BIND 8.2 и более поздних версий существует возможность обеспечить безопасность запросов, ответов, процесса пе редачи зоны и динамических обновлений с помощью TSIG.

Основой настройки является предписание keys инструкции server, ко торое сообщает DNS-серверу, что необходимо подписывать обычные запросы и запросы на передачу зоны, направляемые определенному удаленному DNS-серверу. К примеру, следующее предписание говорит локальному DNS-серверу, wormhole.movie.edu, что следует подписы вать все запросы подобного рода, посылаемые по адресу 192.249.249. (узлу terminator.movie.edu) ключом terminator-wormhole.movie.edu:

На узле terminator.movie.edu мы можем ограничить передачу зоны до пакетов, подписанных ключом terminator-wormhole.movie.edu:

terminator.movie.edu также подписывает этим ключом пакеты при пе редаче зоны, что позволяет серверу wormhole.movie.edu проверять их аутентичность.

Существует также возможность ограничить динамические обновле ния с помощью TSIG, используя предписания allow-update и update-po licy, как мы показывали в предыдущей главе.

Более подробная информация по NTP доступна на веб-сайте Time Synchro nization Server по адресу http://www.eecis.udel.edu/-ntp.

Обеспечение безопасности DNS-сервера Программы nsupdate, которые входят в состав пакета BIND версии 8. и более поздних, поддерживают посылку динамических обновлений с TSIG-подписями. Если ключевые файлы, созданные программой dns sec-keygen все еще существуют, имя любого из них можно указать в ка честве аргумента ключа -к программы nsupdate. В следующих коман дах используется nsupdate из пакета BIND версии 9:

или:

В BIND версии 8.2 и более поздних синтаксис применения nsupdate несколько отличается, -k в качестве аргументов принимает имя ката лога и ключа, разделенные двоеточием:

Если файлов под рукой нет (возможно, что nsupdate выполняется на другом узле), можно указать имя ключа и секрет в командной строке nsupdate из пакета BIND 9:

Первым аргументом -у является имя ключа, за ним следует двоеточие, а затем секрет в кодировке Base 64. Нет необходимости маскировать символы секрета, поскольку кодировка Base 64 не содержит метасим волы командного интерпретатора, но при желании это можно делать.

Net::DNS, модуль Perl, разработанный Майклом Фером также позво ляет посылать динамические обновления и запросы передачи зоны с TSIG-подписью. Более подробно модуль Net::DNS описан в главе «Программирование с использованием библиотечных функций».

Итак, у нас есть удобный механизм обеспечения безопасности транзак ций DNS, и мы переходим к вопросам безопасности собственно DNS сервера.

Обеспечение безопасности DNS-сервера В BIND версии 4.9 появились важные возможности, связанные с обес печением защиты DNS-сервера. В BIND 8 и 9 эта традиция продолжи лась добавлением новых возможностей, связанных с безопасностью.

Они особенно важны, если DNS-сервер работает в сети Интернет, но также полезны для чисто внутренних DNS-серверов.

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

374 Глава 11 Безопасность Версия BIND Один из наиболее логичных способов обезопасить свой DNS-сервер воспользоваться относительно свежей версией пакета BIND. Все вер сии BIND до 8.2.3 уязвимы по меньшей мере для нескольких из широ ко распространенных вариантов атак. Самая последняя информация по уязвимостям различных версий BIND доступна по адресу http:// www.isc.org/products/BIND/bind-security.html.

Не ограничивайтесь новой версией пакета: новые атаки изобретаются постоянно, поэтому придется как следует постараться, чтобы совмес тить минимальную уязвимость и использование самой последней из безопасных версий BIND. Существенным подспорьем в процессе до стижения этой цели является регулярное чтение конференции comp.protocols.dns.bind.

Существует еще один аспект связи версии пакета BIND с безопаснос тью: если взломщик способен легко выяснить, какую версию BIND вы применяете, он, вполне возможно, скорректирует свои атаки, исходя из уязвимых мест конкретно этой версии. Если читатели не в курсе, поясним: начиная примерно с BIND версии 4.9, DNS-серверы отвеча ют на определенный запрос информацией о своей версии. Если запро сить ТХТ-записи класса CHAOSNET для доменного имени versi on.bind, BIND с удовольствием вернет примерно следующий ответ:

Чтобы решить эту проблемы, в BIND версии 8.2 и более поздних ре ализована возможность настраивать ответ DNS-сервера на запрос ver sion.bind:

Естественно, получение ответа «NE TVOE DELO» покажет вниматель ному взломщику, что используется версия 8.2 или более поздняя, но не даст ему никакой конкретики.

Обеспечение безопасности DNS-сервера Ограничение запросов До появления BIND версии 4.9 у администраторов не было возможнос ти проконтролировать, кто посылает запросы DNS-серверам. И это имело определенный смысл: основная идея разработки DNS заключа лась в том, чтобы сделать информацию легко доступной по всей сети Интернет.

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

Предписание allow-query, существующее в BIND 8 и 9, позволяет конт ролировать доступ на уровне IP-адресов, которым разрешается выпол нение запросов. Список управления доступом (access control list, ACL) может применяться к запросам данных из определенной зоны, либо к любым запросам, получаемым DNS-сервером. В частности, список уп равления доступом позволяет указать, каким IP-адресам разрешается посылка запросов DNS-серверу.

Ограничение для всех запросов Глобальное предписание allow-query выглядит следующим образом:

Так, чтобы разрешить нашему серверу отвечать только на запросы из трех основных сетей Университета кинематографии, мы воспользова лись следующей инструкцией:

Ограничение запросов для определенной зоны BIND 8 и 9 позволяют применить список управления доступом к опре деленной зоне. В этом случае следует просто использовать allow-query в качестве части оператора zone для зоны, которую необходимо защи тить:

376 Глава 11. Безопасность Авторитативный сервер любого типа, первичный или вторичный, мо жет использовать список доступа для ограничения доступа к зоне.

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

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

меха низм secure_zone распространяется только на зоны, в пределах авто ритативности DNS-серверов.

Чтобы воспользоваться механизмом secure_zone, необходимо вклю чить одну или несколько специальных ТХТ-записей в данные зоны на первичном DNS-мастер-сервере. Передача этих записей на дополни тельные DNS-серверы зоны произойдет автоматически. Разумеется, только вторичные серверы BIND 4.9 поймут смысл этих записей.

ТХТ-записи являются особенными, потому что они связываются с псевдоименем домена secure_zone, а формат данных этой RR-записи также является специальным:

или:

В первом варианте адрес - это IP-адрес в записи через точку для сети, которой следует разрешить доступ к данным зоны. Маска - это сетевая маска для сети, определяемой адресом. Чтобы разрешить всей сети 15/ доступ к данным зоны, следует использовать запись 15.0.0.0:255.0.0.0.

Для задания диапазона IP-адресов от 15.254.0.0 до 15.255.255. можно указать 15.254.0.0:255.254.0.0.

Второй вариант позволяет указать адрес отдельного узла, которому следует разрешить доступ к данным. Буква Н в данном случае являет ся эквивалентом маски 255.255.255.255;

иначе говоря, проверяется каждый бит 32-битного адреса. Таким образом, запись 15.255.152.4:Н дает узлу с IP-адресом 15.255.152.4 право получать данные из зоны.

Допустим, мы хотим ограничить получение информации из movie.edu узлами сетей Университета кинематографии, но при этом используем DNS-сервер BIND 4.9 вместо BIND 8 или 9. Мы могли бы добавить сле дующие строки к файлу db.movie.edu первичного мастер-сервера зоны movie.edu:

Обеспечение безопасности DNS-сервера Обратите внимание, мы включили в список доступа адрес loopback-ин терфейса (127.0.0.1), чтобы клиент, работающий на том же узле, что и DNS-сервер, мог посылать локальному DNS-серверу запросы.

Если бы забыли указать :Н, то увидели бы следующее сообщение в log файле демона syslog:

Помимо этого, обратите внимание, что записи secure_zone действуют только для зоны, в пределах которой определены, то есть для зоны то vie.edu в нашем примере. Чтобы предотвратить несанкционированный доступ к данным других зон на сервере, следует добавить записи secu re_zone в файлы данных этих зон на их первичных DNS-мастер-серве рах.

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

С помощью предписания allow-transfer в BIND 8 и 9 или с помощью инструкции xfrnets BIND 4.9 администратор может указать на необхо димость использования списка управления доступом при передаче зо ны, allow-transfer в пределах оператора zone ограничивает передачу для определенной зоны, а при указании в операторе options - для всех случаев передачи зоны. В качестве аргумента используется список ад ресов.

IP-адреса дополнительных DNS-серверов зоны movie.edu: 192.249.249. и 192.253.253.1 (wormhole.movie.edu), 192.249.249.9 и 192.253.253. (zardoz.movie.edu). Следующий оператор zone:

378 Глава 11. Безопасность разрешает получение зоны movie.edu с первичного DNS-мастер-серве ра только перечисленным вторичным серверам. Поскольку по умолча нию DNS-серверы BIND 8 и 9 разрешают получение зоны по запросам с любых IP-адресов, и поскольку взломщики могут с такой же легко стью произвести получение зоны с одного из дополнительных DNS серверов, следует добавить в файлы настройки вторичных серверов примерно такой оператор zone:

В BIND 8 и 9 существует возможность применять глобальный ACL список к передаче зоны. Это происходит по умолчанию для всех зон, не определяющих явным образом собственные списки управления до ступом в операторе zone. К примеру, мы могли бы ограничить переда чу зоны внутренними IP-адресами:

Инструкция BIND 4.9 - xfrnets также применяет список управления доступом ко всем случаям передачи зоны. В качестве аргументов xfr nets выступают сети или IP-адреса, которым разрешается получать зо ну с DNS-сервера. Сети определяются записью IP-адресов в десятич ной нотации. Например:

разрешает получение зоны узлам сети 15/8 или 128.32/16. В отличие от ТХТ-записи secure_zone, xfrnets накладывает ограничения на все зоны, для которых сервер является авторитативным.

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

Следующая инструкция xfrnets позволяет сократить число адресов из предыдущего примера до единственного IР-адреса15.255.152.4 и под сети 128.32.1/24:

Обеспечение безопасности DNS-сервера И наконец, как мы упоминали ранее, новомодные DNS-серверы BIND версии 8.2 и более поздних позволяют ограничить случаи передачи зо ны дополнительными DNS-серверами, которые включают в запрос на передачу правильную транзакционную подпись. На основном DNS сервере необходимо определить ключ в операторе key, а затем указать этот ключ в списке допустимых адресов:

На стороне дополнительного DNS-сервера следует предписать исполь зование подписи для запросов на передачу зоны. Ключ тот же:

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

Выполнение BIND с наименьшими полномочиями Если сетевой сервер вроде BIND работает от пользователя с высокими полномочиями, это представляет опасность;

а DNS-сервер BIND обычно работает от пользователя root. Если взломщик находит уязвимое место DNS-сервера, позволяющее ему читать и изменять файлы, то фактичес ки получает полный доступ к файловой системе. Если он сможет вос пользоваться недостатком, который позволяет ему выполнять команды на системе, то будет выполнять их в качестве пользователя root.

380 Глава 11. Безопасность В BIND версии 8.1.2 и более поздних содержится код, который позво ляет изменять группу и пользователя, от которого работает DNS-cep вер. Это позволяет запускать DNS-сервер с наименьшими полномочи ями: то есть с минимальным набором прав, который необходим серве ру для выполнения работы. В такой ситуации, если взломщик проник нет в систему через DNS-сервер, он не будет иметь полномочий администратора системы.

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

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

-и Указать имя пользователя или идентификатор пользователя, кото рый DNS-серверу следует применять при работе. Пример: named -и bin.

-g Указать имя группы или идентификатор группы, который DNS серверу следует применять при работе. Пример named -g other. Ес ли указать только имя или идентификатор пользователя, DNS-сер вер использует основную группу этого пользователя. DNS-серверы BIND 9 всегда используют основную группу пользователя, поэтому в них не поддерживается ключ -g.

-t Указать каталог, которым с помощью chroot() ограничивается DNS-сервер.

Приняв решение о применении ключей -и и -g следует понять, какого пользователя и какую группу указать. Лучше всего - создать специ ального нового пользователя и новую группу для работы DNS-сервера, например named. Поскольку DNS-сервер производит чтение файла па med.conf прежде чем перестать работать от пользователя root, нет не обходимости изменять права доступа для этого файла. Однако, вполне возможно, потребуется изменить права доступа и владельца для фай лов данных зоны, чтобы DNS-сервер, работая от пользователя с пони женными полномочиями, мог их прочитать. Если применяется дина мическое обновление, придется дать DNS-серверу права на запись в файлы динамически обновляемых зон.

Если DNS-сервер настроен таким образом, что сообщения записывают ся в файлы (а не в log-файл демона syslog), убедитесь, что эти файлы Обеспечение безопасности DNS-сервера существуют и доступны для записи DNS-серверу, прежде чем запус кать сервер.

Применение ключа -t связано с некоторыми тонкостями настройки. В частности, следует убедиться, что все файлы, используемые named, присутствуют в каталоге, которым ограничивается DNS-сервер. При водимая ниже процедура позволяет правильным образом подготовить новую среду для сервера. Предположим, что речь идет о каталоге /var /named: 1. Если каталог /var/named не существует, создайте его. Создайте подкаталоги deu, etc, lib, usr и var. В подкаталоге usr создайте под каталог sbin. В подкаталоге var- подкаталоги named и run:

2. Скопируйте файл named.conf в /var/named/etc/named.conf:

3. Если вы работаете с BIND 8, скопируйте исполняемый файл named xfer в подкаталог usr/sbin/ либо etc (в зависимости от того, где этот файл существовал раньше, в /usr/sbin или /etc).

Как вариант можно поместить этот файл где угодно в пределах ка талога /var/named и использовать предписание named-xfer, чтобы объяснить серверу named, где искать этот файл. Помните, что необ ходимо удалить /var/named из пути к файлу, поскольку при чте нии файл named.conf /var/named будет являться корнем файловой системы. (Если вы используете BIND 9, пропустите этот шаг, по скольку в BIND 9 не применяется named-xfer.) 4. Создайте файл dev/null в новой «файловой системе»:

5. Если вы работаете с BIND 8 скопируйте стандартную разделяемую библиотеку С и загрузчик в подкаталог lib:

Пути могут изменяться в зависимости от используемой операцион ной системы. Серверы BIND 9 самодостаточны, им не нужны биб лиотеки.

6. Отредактируйте загрузочные файлы таким образом, чтобы демон syslogd запускался с дополнительным ключом и аргументом ключа:

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

382 Глава 11. Безопасность -a /var/named/dev/log. Во многих современных вариантах Unix за пуск демона syslogd производится из файла /etc/rc.d/init.d/syslog.

При следующем перезапуске демона syslogd будет создан файл /var /named/dev/log, в который named будет записывать сообщения.

Если демон syslogd не поддерживает ключ -а, воспользуйтесь опе ратором logging - который описан в главе 7 «Работа с BIND» - для записи сообщений в chroot-каталоге.

7. Если вы работаете с BIND 8 и используете ключ -и или -g, создайте в подкаталоге etc файлы passwd и group, чтобы обеспечить отобра жение аргументов ключей -и и -g в соответствующие числовые зна чения (как вариант можно просто использовать числовые значения в качестве аргументов ключей):

Затем добавьте эти записи в файлы /etc/passwd и /etc/group систе мы. Если речь идет о DNS-сервере BIND 9, можно обойтись добавле нием записей в системные файлы /etc/passwd и /etc/group, по скольку DNS-серверы BIND 9 производят чтение интересующей их информации перед вызовом chroot().

8. И наконец, отредактируйте загрузочные файлы, чтобы запускать named с ключом -t /var/named при загрузке системы. Как и в слу чае с демоном syslogd, во многих современных вариантах Unix за пуск named производится из файла /etc/rc.d/init.d/named.

Если вы привыкли использовать ndc для управления DNS-сервером BIND 8, можно продолжать пользоваться этой программой, указывая имя Unix-сокета в качестве аргумента ключа -с:

rndc будет работать с DNS-сервером BIND 9 как и раньше, поскольку общается с сервером через порт 953.

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

«Делегированный» DNS-сервер Некоторые из DNS-серверов отвечают на нерекурсивные запросы ДРУ" гих DNS-серверов сети Интернет, поскольку эти DNS-серверы встреча ются в NS-записях, делегирующих им ваши зоны. Такие DNS-серверы мы называем «делегированными».

Обеспечение безопасности DNS-сервера Существуют особые меры, которые можно принять в целях обеспече ния безопасности делегированных DNS-серверов. Но прежде необхо димо убедиться, что эти DNS-серверы не получают рекурсивных за просов (то есть ни один из клиентов не настроен на использование этих серверов и никакой DNS-сервер не использует их в качестве ретранс ляторов). Некоторые из принимаемых мер - скажем, предписание сер веру отвечать нерекурсивно даже на рекурсивные запросы - препятст вуют использованию этого сервера клиентами. Если какие-либо кли енты все-таки обращаются к делегированному DNS-серверу, имеет смысл задуматься о создании отдельного класса DNS-серверов, кото рые будут заниматься исключительно обслуживанием DNS-клиентов, либо об использовании варианта «Два сервера в одном», который опи сан далее в этой главе.

Убедившись, что DNS-сервер отвечает только на запросы других серве ров, можно выключить рекурсию. Это исключает крупное направление атак: большинство атак, связанных с подделкой IP-пакетов, основано на побуждении атакуемого DNS-сервера сделать запрос DNS-серверам, которые управляются взломщиком, путем отправки атакуемому сер веру рекурсивного запроса для доменного имени, входящего в зону, которая обслуживается серверами взломщика. Чтобы выключить ре курсию, воспользуйтесь следующим оператором для сервера BIND или 9:

либо, если используется BIND 4.9:

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

чтобы предотвратить эти действия и запретить DNS-серверу посылать собственные запросы, ис пользуйте следующую настройку DNS-сервера BIND 8 (в DNS-серве рах BIND 9 поиск связующих записей по умолчанию отключен):

либо, для DNS-сервера BIND:

384 Глава 11. Безопасность «Разрешающий» DNS-сервер Будем называть DNS-сервер, который обслуживает одного или не скольких клиентов или настроен в качестве ретранслятора для друго го DNS-сервера, - «разрешающим» DNS-сервером. В отличие от деле гированного DNS-сервера, разрешающий не может отказаться от вы полнения рекурсивных запросов. Как следствие, его относительно бе зопасная настройка выглядит иначе. Поскольку известно, что наш DNS-сервер должен принимать запросы только от наших собственных DNS-клиентов, мы можем настроить его таким образом, чтобы он от вергал запросы с любого адреса, который не принадлежит списку IP адресов наших клиентов.

Только в BIND 8 и 9 существует возможность ограничивать набор IP адресов, с которых принимаются произвольные запросы. (В DNS-cep верах BIND 4.9 существует лишь возможность ограничить набор IP адресов, с которых принимаются запросы для зон авторитативности сервера - посредством использования ТХТ-записей secure_zone;

но нас больше беспокоят рекурсивные запросы для всех прочих зон.) Следую щее предписание allow-query ограничивает отправителей запросов на шей внутренней сетью:

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

Существует еще одна настройка, позволяющая повысить безопасность DNS-сервера - use-id-pool:

Предписание use-id-pool появилось в BIND 8.2. Оно сообщает серверу, что следует проявлять особую изобретательность при генерации слу чайных чисел-идентификаторов Запросов. Обычно идентификаторы сообщений не являются в достаточной степени случайными, чтобы предотвратить прямолинейные атаки, которые заключаются в угады вании идентификаторов отправленных сервером запросов для созда ния поддельных ответов.

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

Обеспечение безопасности DNS-сервера Два сервера в одном Что делать в случае, когда есть только один сервер для обслуживания ваших зон и DNS-клиентов, а покупка второго компьютера для еще од ного DNS-сервера сопряжена с расходами, которые вы не можете себе позволить? Варианты по-прежнему существуют. Есть два решения, связанных с использованием одного сервера и возможностей настройки BIND 8 или 9. Один из вариантов - разрешить кому-угодно запраши вать информацию для зон, находящихся в пределах авторитативности DNS-сервера, но получение любой другой информации разрешить только внутренним клиентам. Удаленные клиенты смогут посылать DNS-серверу рекурсивные запросы, но эти запросы должны касаться информации из зон, для которых сервер является авторитативными, то есть они не будут приводить к созданию дополнительных запросов.

Вот файл named.conf для этого варианта настройки:

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

В случае использования BIND 8.2.1 или более поздней версии можно упростить настройку, используя предписание allow-recursion:

386 Глава 11 Безопасность Предписания allow-query уже не нужны: хотя DNS-сервер и может по лучать запросы, созданные за пределами внутренней сети, он будет считать их нерекурсивными во всех случаях. Как следствие, внешние запросы не заставят DNS-сервер создавать новые запросы. Этот вари ант настройки также избавлен от одного недостатка предыдущего: ес ли DNS-сервер является авторитативным для родительской зоны, то может получать запросы от удаленных DNS-серверов, которые пыта ются произвести разрешение доменного имени из поддомена этой зо ны. Решение с использованием allow-query привело бы к отказам вы полнять такие, вполне допустимые запросы, в отличие от варианта с allow-recursion.

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

Разумеется, если на узле присутствует более одного сетевого интер фейса, это не проблема. Даже если сетевой интерфейс всего один, опе рационная система может поддерживать псевдонимы IP-адресов.

Псевдонимы позволяют указать несколько IP-адресов для одного сете вого интерфейса. За каждым IP-адресом можно закрепить один про цесс named. И наконец, даже если в используемой операционной сис теме отсутствует реализация IP-псевдонимов, можно закрепить один сервер named за IP-адресом сетевого интерфейса, а второй - за адресом Обеспечение безопасности DNS-сервера loopback-интерфейса. Процесс, закрепленный за адресом обратной связи, сможет получать запросы только от локального узла, но это иде ально, если необходимо обслуживать только локальный DNS-клиент.

Сначала приведем файл named.conf для делегированного DNS-сервера, закрепленного за IP-адресом сетевого интерфейса:

А вот named.conf для разрешающего DNS-сервера, закрепленного за адресом обратной связи:

Обратите внимание, что список управления доступом для разрешаю щего DNS-сервера не нужен, поскольку этот сервер получает запросы только с loopback-адреса, но не с других узлов. (Если бы разрешающий 388 Глава 11. Безопасность DNS-сервер получал запросы через IP-псевдоним или второй сетевой интерфейс, можно было бы воспользоваться предписанием allow-qu ery, чтобы ограничить использование этого DNS-сервера.) На делеги рованном сервере мы отключили рекурсию, но на разрешающем она должна быть включена. Помимо этого, мы определили для каждого сервера отдельный PID-файл и отдельный рабочий каталог, чтобы не возникало конфликтов из-за использования файлов с одинаковыми именами при создании PID-файлов, файлов отладочной диагностики и файлов статистики.

Чтобы можно было использовать разрешающий DNS-сервер, прини мающий запросы через адрес обратной связи, файл resolv.conf на ло кальном узле должен содержать строку:

в качестве самой первой инструкции nameserver.

Если используется BIND 9, можно объединить настройки двух DNS серверов в один файл с помощью видов:

DNS и брандмауэры сети Интернет Достаточно простой вариант настройки: два вида, внутренний и внеш ний. Для внутреннего вида, который относится только ко внутренней сети, рекурсия включена. Внешний вид относится ко всем остальным, рекурсия выключена. Зоны movie.edu и 249.249.192.in-addr.arpa иден тичны в обоих видах. С помощью видов можно сделать гораздо больше скажем, определить различные версии зон для внутреннего и внешне го видов, но мы отложим такие варианты до следующего раздела.

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

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

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

Будет представлено решение, объединяющее преимущества внутрен них корневых серверов и ретрансляторов, - зоны ретрансляции. И на конец, мы рассмотрим расщепление пространства имен и настройку узла-бастиона, который является сердцем брандмауэра.

Типы программного обеспечения брандмауэров Прежде чем начать настройку BIND для работы с брандмауэром, необ ходимо понимать, на что способен сетевой экран. Потенциал брандма 390 Глава 11. Безопасность уэра влияет на выбор архитектуры DNS и определение способа ее ре ализации. Если вы не знаете ответов на вопросы, задаваемые в этом разделе, найдите в вашей организации человека, который знает, и спросите его. Более правильным вариантом является сотрудничество с администратором брандмауэра в процессе разработки архитектуры DNS, поскольку оно позволяет гарантировать, что созданная структу ра будет эффективно сосуществовать с брандмауэром.

Заметим, что приводимые сведения о брандмауэрах сети Интернет не являются полными. В нескольких параграфах мы описываем два на иболее распространенных типа брандмауэров, используя минимум подробностей, который необходим, чтобы показать различия в потен циале и влияние на DNS-серверы. Полное руководство по этой теме со держится в книге Е. Zwicky, S. Cooper и В. Chapman «Building Internet Firewalls» (O'Reilly). Пакетные фильтры Работа первого типа брандмауэров основана на фильтрации пакетов.

Брандмауэры, реализующие пакетные фильтры, работают преиму щественно на транспортном и сетевом уровнях стека TCP/IP (уровни третий и четвертый эталонной модели OSI, если вам это о чем-то гово рит). Решения о маршрутизации пакетов принимаются на основе кри териев пакетного уровня, скажем, в зависимости от применяемого транспортного протокола (TCP или UDP), IP-адреса отправителя и по лучателя, исходного и целевого порта (рис. 11.1).

Наиболее важной особенностью пакетных фильтров является тот факт, что их обычно можно настроить на избирательное пропускание Рис. 11.1. Пакетные фильтры работают на сетевом и транспортном уровнях стека Элизабет Цвики, Саймон Купер и Брент Чапмен «Создание защиты в Ин тернете», издательство «Символ-Плюс», I кв. 2002 г.

DNS и брандмауэры сети Интернет трафика DNS между узлами Интернета и узлами внутренней сети.

Иначе говоря, доступ к DNS-серверам Интернета можно ограничить произвольным набором узлов внутренней сети. Некоторые из таких брандмауэров даже предоставляют возможность разрешить DNS-сер верам внутренней сети делать запросы ко внешним DNS-серверам (но не наоборот). Все брандмауэры Интернета, созданные на основе марш рутизаторов, используют фильтрацию пакетов. Широко применяются коммерческие брандмауэры с фильтрацией пакетов - FireWall-1 от Checkpoint, PIX от Cisco и SunScreen от Sun.

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

Распространенный Firewall Toolkit (набор инструментов брандмауэра) от Trusted Information Systems (TIS в настоящее время является частью Network Associates) - это набор шлюзов для широко применяе мых протоколов Интернета, таких как Telnet, FTP и HTTP. Gauntlet от Network Associates и Eagle Firewall от Axent также основаны на шлюзах приложений.

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

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

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

К сожалению, это - по ряду причин - очень плохая идея:

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

Защищенность Даже если на определенном узле отсутствует DNS-сервер, взлом щик может воспользоваться тем преимуществом, что трафик DNS спокойно проходит через брандмауэр, и произвести атаку на этот узел. К примеру, соучастник заговора может установить на узле де мона Telnet, который будет принимать соединения через порт DNS, и взломщик получит возможность проникнуть через telnet.

394 Глава 11. Безопасность В оставшейся части главы мы постараемся подавать только хороший пример.

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

Рис. 11.3. Небольшая сеть, выставляющая узел-бастион Брандмауэр, основанный на фильтрации пакетов, может быть настро ен администратором таким образом, что произвольный набор внутрен них DNS-серверов сможет взаимодействовать с DNS-серверами Интер нета. Обычно это небольшое число узлов, на которых работают DNS серверы, находящиеся во власти администратора сети (рис. 11.4).

Дополнительная настройка внутренних DNS-серверов, которые могут напрямую посылать запросы внешним DNS-серверам, не требуется.

Файлы корневых указателей этих серверов содержат координаты кор невых серверов сети Интернет, что позволяет производить разрешение доменных имен сети Интернет. Внутренние серверы имен, которые не могут посылать запросы DNS-серверам в Интернет, должны пони мать, что неразрешенные запросы следует передавать другим DNS серверам, которые смогут это сделать. Специально для этих целей су ществует инструкция или предписание forwarders, которое рассмат ривается в главе 10 «Дополнительные возможности».

На рис. 11.5 представлен распространенный вариант настройки ре трансляции: внутренние DNS-серверы передают запросы DNS-серве ру, который работает на узле-бастионе.

Несколько лет назад мы установили в Университете кинематографии брандмауэр, чтобы защитить себя от Большого Злого Интернета. Наш DNS и брандмауэры сети Интернет брандмауэр реализует фильтрацию пакетов, и мы договорились с ад министратором сетевого экрана, что он разрешит двум нашим DNS Рис. 11.4. Небольшая сеть, выставляющая отдельные, внутренние DNS-серверы Рис. 11.5. Применение ретрансляторов 396 Глава 11. Безопасность серверам, terminator.movie.edu и wormhole.movie.edu, обмениваться DNS-трафиком с DNS-серверами Интернета. Все прочие DNS-серверы университета мы настроили следующим образом. Для серверов BIND и 9 были использованы такие настройки:

а для серверов BIND 4 - такие:

Мы изменяем порядок перечисления ретрансляторов, поскольку это способствует распределению нагрузки между ними. В случае DNS-cep веров BIND 8.2.3 в этом нет смысла, поскольку они выбирают ретранс лятор, исходя из времени передачи сигнала.

Когда внутренний DNS-сервер получает запрос для имени, разреше ние для которого не может произвести локально, к примеру, для до менного имени Интернет, то передает запрос одному из ретранслято ров, которые производят разрешение, посылая запросы DNS-серверам в сети Интернет. Все просто!

Проблемы с ретрансляцией К сожалению, все не настолько просто. Ретрансляция начинает ме шать при делегировании поддоменов или создании крупной сети. Что бы понять, о чем речь, взгляните на фрагмент файла настройки для zardoz.movie.edu:

zardoz.movie.edu является вторичным сервером зоны movie.edu и ис пользует два ретранслятора. Что случится, если zardoz.movie.edu полу чит запрос для имени в пределах fx.movie.edu? Будучи авторитативным сервером зоны movie.edu, zardoz.movie.edu хранит NS-записи, делеги рующие fx.movie.edu авторитативным серверам этой зоны. Но zar doz.movie.edu также настроен таким образом, что передает все запросы, которые не могут быть разрешены локально, узлам terminator.то vie.edu и wormhole.movie.edu. Какое решение примет DNS-сервер?

DNS и брандмауэры сети Интернет Оказывается, zardoz.movie.edu игнорирует информацию о делегирова нии и передает запрос узлу terminator.movie.edu. Все работает, по скольку terminator.movie.edu получает рекурсивный запрос и передает его по поручению DNS-сервера zardoz.movie.edu серверу для fx.mo vie.edu. Но это не очень эффективно, поскольку узел zardoz.movie.edu мог бы без проблем послать прямой запрос самостоятельно.

Теперь представим себе сеть гораздо большего масштаба: корпоратив ные тенета, охватывающие целые континенты, сеть, с десятками ты сяч узлов и сотнями или тысячами DNS-серверов. Вне внутренние DNS-серверы, не имеющего прямого подключения к сети Интернет, то есть, подавляющее большинство - используют небольшую группу ретрансляторов. Что здесь не так?

Низкая надежность Если ретрансляторы «сломаны», все DNS-серверы теряют способ ность производить разрешение как доменных имен сети Интернет, так и внутренних доменных имен, которые не кэшированы или не хранятся в виде данных авторитативности.

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

Низкая эффективность разрешения Представим себе два внутренних DNS-сервера, которые являются авторитативными для зон west.acmebw.com и east.acmebw.com соот ветственно;

оба сервера расположены в одном сегменте сети, в Боул дер-Сити, штат Колорадо. Оба настроены использовать корпоратив ный ретранслятор, расположенный в городе Бетесда, штат Мэри ленд. DNS-сервер west.acmebw.com в целях разрешения доменного имени из east.acmebw.com посылает запрос ретранслятору в Бетес де. Ретранслятор в Бетесде возвращает запрос в Боулдер-Сити, DNS-серверу east.acmebw.com, который является соседом узла, сде лавшего первоначальный запрос. DNS-сервер east.acmebw.com от правляет ответ в Бетесду, а оттуда ретранслятор посылает его снова в Боулдер-Сити.

В традиционном варианте настройки, когда используются корне вые DNS-серверы, DNS-сервер west.acmebw.com быстро узнал бы, что DNS-сервер east.acmebw.com стоит в соседней комнате, и отдал бы ему предпочтение (из-за меньшего времени передачи сигнала).

Использование ретрансляторов приводит к «короткому замыка нию» в обычно эффективном процессе разрешения.

Вывод следующий: использование ретрансляторов вполне оправданно для небольших сетей и простых пространств имен, но скорее всего не адекватно для крупных сетей и развесистых пространств имен. По ме 398 Глава 11. Безопасность ре роста сети Университета кинематографии мы узнали об этом на соб ственном опыте и были вынуждены искать альтернативу.

Зоны ретрансляции Проблемы можно решить с помощью зон ретрансляции, появившихся в BIND 8.2. Изменим настройки zardoz.movie.edu следующим образом:

Теперь, если zardoz.movie.edu получает запрос для доменного имени, заканчивающегося на movie.edu, но расположенного вне зоны то vie.edu (например, в зоне fx.movie.edu), то игнорирует ретрансляторы и посылает итеративные запросы.

Но при этом zardoz.movie.edu по-прежнему посылает ретрансляторам запросы для доменных имен из зон обратного отображения. Чтобы уменьшить нагрузку, можно добавить несколько операторов zone в файл named.conf:

DNS и брандмауэры сети Интернет Следует прокомментировать новые операторы zone: прежде всего, зо ны обратного отображения Университета кинематографии теперь яв ляются зонами-заглушками. Это значит, что DNS-сервер отслеживает NS-записи, периодически опрашивая основные DNS-серверы этих зон.

Инструкция forwarders выключает ретрансляцию для доменных имен в доменах обратного отображения. Теперь, вместо того чтобы передавать ретрансляторам запрос PTR-записи для 2.254.253.192.inaddr.arpa, гаг doz.movie.edu пошлет прямой запрос одному из серверов 254.253.192.in addr.arpa.

Подобные операторы zone понадобятся для всех наших внутренних DNS-серверов, а это значит, что для всех DNS-серверов придется ис пользовать версию BIND более позднюю, чем 8.2. Мы получаем достаточно надежную структуру для разрешения имен, которая минимизирует взаимодействие с сетью Интернет: посредст вом использования эффективного и надежного итеративного разреше ния имен для внутренних доменных имен, а ретрансляции - только в случае необходимости произвести разрешение доменного имени сети Интернет. Если ретрансляторы не работают, либо разорвано подклю чение к сети Интернет, мы утрачиваем способность производить разре шение для доменных имен сети Интернет.

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

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

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

400 Глава 11. Безопасность истекает интервал хранения NS-записей для внутренних зон высшего уровня. Если используются ретрансляторы, они могут получать до од ного запроса на каждый запрос разрешения имени, посылаемый обыч ным DNS-серверам.

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

Где располагать внутренние корневые DNS-серверы Поскольку DNS-серверы имеют привычку «фиксироваться» на наибо лее близко расположенных корневых серверах, предпочитая серверы с минимальным временем передачи сигнала, добавление внутренних корневых DNS-серверов окупается. Если сеть организации охватывает США, Европу и побережье Тихого океана, следует иметь по меньшей мере один внутренний корневой DNS-сервер на каждом континенте.

Если в Европе существует три крупных комплекса, следует создать в пределах каждого внутренний корневой DNS-сервер.

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

В сети Интернет эта информация отображалась бы в файлах данных серверов зоны edu. Понятно, что в сети movie.edu нет DNS-серверов edu, поэтому происходит прямое делегирование movie.edu от корня.

Обратите внимание, что записи не содержат делегирования для fx.mo vie.edu и всех остальных поддоменов movie.edu. DNS-серверы то vie.edu в курсе, какие DNS-серверы являются авторитативными для каждого из поддоменов movie.edu, и все запросы, касающиеся инфор мации из этих поддоменов, проходят через DNS-серверы movie.edu, по этому (конкретно здесь) нет необходимости в делегировании.

DNS и брандмауэры сети Интернет Делегирование in-addr.arpa Необходимо также произвести делегирование внутренними корневы ми серверами для зон in-addr.arpa, которые соответствуют универси тетским сетям:

Обратите внимание, что мы включили делегирование для зон 254.253.192.in-addr.arpa и 20.254.192.in-addr.arpa, несмотря на то, что они соответствуют зоне fx.movie.edu. Необходимости делегировать fx.movie.edu нет, потому что делегирование уже произведено для роди тельской зоны, movie.edu. Серверы movie.edu делегируют полномочия fx.movie.edu, так что, исходя из принципа транзитивности, корневые серверы также делегируют полномочия fx.movie.edu. При этом ни одна из зон in-addr.arpa не является родительской для 254..253.192.in addr.arpa или 20.254.192.in-addr.arpa, а значит, необходимо произво дить делегирование обеих зон от корня. Как говорилось ранее, нет не обходимости добавлять адресные записи для трех DNS-серверов фа культета Special Effects, bladerunner.fx.movie.edu, outland.fx.movie.edu и alien.fx.movie.edu, поскольку удаленный DNS-сервер может и без этого найти их адреса, следуя за делегированием от movie.edu.

Файл db.root Осталось лишь добавить SOA-запись для корневой зоны и NS-записи для этого и всех остальных внутренних корневых DNS-серверов:

402 Глава 11. Безопасность Внутренние корневые DNS-серверы работают на узлах rainman.mo vie.edu и awakenlngs.movie.edu. Не следует устанавливать корневой сервер на узел-бастион, поскольку если внешний DNS-сервер случайно запросит у этого сервера данные, для которых он не является автори тативным, то получит в ответ перечень корневых DNS-серверов - при чем внутренних!

Поэтому полный файл db.root (по договоренности, мы называем файл данных корневой зоны именем db.root) выглядит так:

Файл named.conf на узлах rainman.movie.edu и awakenings.movie.edu содержит следующие строки:

DNS и брандмауэры сети Интернет Либо для сервера BIND 4 и файла named.boot:

Они заменяют оператор zone типа hint или инструкцию cache - корне вому DNS-серверу не нужен файл корневых указателей, чтобы узнать координаты других корневых серверов, поскольку они и без того со держатся в файле db.root. Означает ли это, что каждый корневой DNS сервер является первичным мастером для корневой зоны? Нет, только в случае использования древней версии BIND. Все версии BIND, более поздние, чем 4.9, позволяют объявить DNS-сервер вторичным для корневой зоны, в то время как BIND 4.8.3 и более ранних версий на стаивает на том, что каждый корневой DNS-сервер должен являться первичным для корневой зоны.

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

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

DNS-серверы, работающие на узлах с подобным файлом корневых указателей, смогут производить разрешение доменных имен зоны то vie.edu и доменах in-addr.arpa Университета кинематографии, но не имен за пределами этих доменов.

щ 404 Глава 11. Безопасность Использование внутренних корневых серверов внутренними DNS-серверами Чтобы увязать схему воедино, рассмотрим пример разрешения на внутреннем DNS-сервере, который специализируется на кэшировании и обладает информацией о внутренних корневых DNS-серверах. Внут ренний DNS-сервер получает запрос для доменного имени из зоны то vie.edu, скажем запрос адреса для имени gump.fx.movie.edu. Если внут ренний DNS-сервер не может ответить кэшированной информацией, то посылает запрос одному из внутренних корневых DNS-серверов. Ес ли этот сервер уже контактировал с внутренними корневыми DNS-сер верами, то запомнил время передачи сигнала для каждого из них и те перь имеет возможность выбрать корневой сервер с наименьшим вре менем реагирования. Этому корневому серверу посылается нерекур сивный запрос адреса для имени gump.fx.movie.edu. Внутренний корневой сервер отвечает ссылками на DNS-серверы зоны movie.edu terminator.movie.edu, wormhole.movie.edu и zardoz.movie.edu. Кэширую щий DNS-сервер продолжает поиск, посылая следующий нерекурсив ный запрос адреса gump.fx.movie.edu одному из DNS-серверов то vie.edu. DNS-сервер movie.edu возвращает ссылки на DNS-серверы зоны fx.movie.edu. Кэширующий DNS-сервер посылает тот же нерекурсив ный запрос адреса gump.fx.movie.edu одному из DNS-серверов fx.mo vie.edu и, наконец, получает ответ.

Сравним такую настройку с работой варианта ретрансляции. Допустим, наш DNS-сервер, специализирующийся на кэшировании, настроен не на использование внутренних корневых DNS-серверов, а на передачу запросов сначала узлу terminator.movie.edu, а затем wormhole.movie.edu.

В этом случае наш сервер производит поиск адреса gump.fx.movie.edu в кэше и, не найдя его, передает запрос серверу terminator.movie.edu. За тем terminator.movie.edu посылает запрос к одному из DNS-серверов fx.movie.edu от имени кэширующего DNS-сервера и возвращает полу ченный ответ. Когда кэширующий DNS-сервер в следующий раз будет производить поиск для имени из зоны fx.movie.edu, то обратится к ре транслятору точно таким же образом, несмотря на то, что ответ на пре дыдущий запрос (адреса для gump.fx.movie.edu) скорее всего содержал имена и адреса DNS-серверов зоны fx.movie.edu.

Отправка почтовых сообщений в сеть Интернет Минутку! Это еще не все, что на что способны внутренние корневые DNS-серверы. Мы говорили об отправке почтовых сообщений в сеть Интернет, которая не связана с необходимостью изменять настройки программы sendmail по всей сети.

Заставить работать почту можно с помощью масок в записях, а именно масок в МХ-записях. Допустим, необходимо сделать так, чтобы почта, отправляемая в сеть Интернет, передавалась через узел postman rings2x.movie.edu, узел-бастион Университета кинематографии, кото DNS и брандмауэры сети Интернет рый напрямую подключен к сети Интернет. Добиться нужного резуль тата можно, добавив следующие записи в файл db.root:

МХ-запись с маской *.edu нужна в дополнение к записи с маской * из за существующих для масок правил вывода, о которых можно подроб нее прочитать в разделе «Маски» главы 16 «Обо всем понемногу». По существу, поскольку для зоны movie.edu существуют явно определен ные данные, первая маска не приведет к сопоставлению movie.edu или любого другого поддомена зоны edu. Нужна еще одна, явно определен ная запись с маской для edu, с которой будут сопоставляться поддоме ны edu помимо movie.edu.

Теперь почтовые программы, работающие на внутренних узлах зоны movie.edu, будут отправлять почту, адресованную доменным именам сети Интернет, узлу postmanrings2x.movie.edu для ретрансляции. К примеру, почтовые сообщения, адресованные домену nic.ddn.mil, бу дут сопоставлены с первой МХ-записью, включающей маску:

Почтовые сообщения, адресованные домену vangogh.cs.berkeley.edu, будут сопоставлены со второй МХ-записью:

Когда почтовые сообщения появятся на postmanrings2x.movie.edu, уз ле-бастионе, почтовая программа postmanrings2x.movie.edu произве дет поиск МХ-записей для конечных адресов. Поскольку узел post manrings2x.movie.edu будет производить разрешение доменных имен, используя пространство имен сети Интернет, а не пространство имен внутренней сети, будут найдены реальные МХ-записи, и почта будет доставлена адресатам. При этом нет необходимости изменять настрой ки sendmail.

406 Глава 11. Безопасность Отправка почтовых сообщений для конкретных доменных имен сети Интернет У схемы, построенной на основе внутренних корневых DNS-серверов, есть еще один плюс: она позволяет передавать почту, предназначенную различным доменам сети Интернет, через различные узлы-бастионы в случае, когда таких узлов несколько. К примеру, мы можем захотеть посылать почту, адресованную узлам в домене uk, нашему узлу-баоти ону, расположенному в Лондоне, который затем будет передавать поч товые сообщения в Интернет. Это может быть очень удобно, если мы хотим, чтобы почта ходила в сети максимально быстро, или же жела ем сократить расходы, связанные с использованием определенной се ти Великобритании.

Университет кинематографии связан собственным сетевым каналом с университетом-побратимом, который расположен в Лондоне, непода леку от киностудии Пайнвуд. Из соображений безопасности мы хо тим, чтобы почта для адресатов в Соединенном Королевстве, посыла лась через этот сетевой канал, и, затем, отправлялась дальше через узел студии Пайнвуд. Мы добавляем следующие записи с масками в файл db.root:

Теперь почта, адресованная пользователям в поддоменах домена uk будет отправляться узлу holygrail.movie.ac.uk, принадлежащему сети университета-побратима, в которой - как мы полагаем - существует возможность передать почтовые сообщения во все точки страны.

Проблемы внутренних корневых DNS-серверов К сожалению, не только у ретрансляции есть проблемы: архитектура на основе внутренних DNS-серверов также имеет ограничения. Самое большое из них - внутренние узлы не «видят» пространство имен сети Интернет. В некоторых сетях это не проблема, поскольку большинст во внутренних узлов не имеют прямого подключения к сети Интернет.

А на тех немногих узлах, что связаны с сетью Интернет напрямую, DNS-клиенты настроены на использование DNS-сервера узла-бастио на. На некоторых из этих узлов, вероятно, работают серверы-посред ники (proxy), позволяющие прочим внутренним узлам получать до ступ к службам сети Интернет.

Однако в других сетях используемый сетевой экран или другое про граммное обеспечение могут требовать от внутренних узлов способнос ти разрешать имена из пространства имен сети Интернет. В таких се тях архитектура, основанная на внутренних корневых DNS-серверах, работать не будет.

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

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

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

Поскольку в Университете кинематографии используется брандмауэр Интернет, который в значительной степени ограничивает доступ ко внутренней сети извне, мы приняли решение создать затененное про странство имен. Если речь идет о зоне movie.edu, то мы должны предо ставить только информацию о доменном имени movie.edu (SOA-запись и несколько NS-записей), об узле-бастионе (postmanrings2x.movie.edu) и о нашем новом внешнем DNS-сервере ns.movie.edu, который по со вместительству является внешним веб-сервером www.movie.edu. Адрес внешнего интерфейса на узле-бастионе - 200.1.4.2, адрес веб-сервера/ DNS-сервера - 200.1.4.3. Файл данных для затененной зоны movie.edu выглядит следующим образом:

408 Глава 11. Безопасность Обратите внимание, здесь не упомянут ни один из поддоменов зоны movie.edu, и нет никакой информации о делегировании DNS-серверам этих поддоменов. В этой информации просто нет необходимости, по скольку ресурсы этих поддоменов не могут быть использованы из сети Интернет, а входящая почта, адресованная узлам в этих поддоменах, сопоставляется с маской.

Файл db.200.1.4, который нужен для обратного отображения двух IP адресов Университета кинематографии, видимых узлам из сети Ин тернет, выглядит так:

Следует проявить осторожность и убедиться, что DNS-клиент узла бастиона не настроен на использование DNS-сервера ns.movie.edu. По скольку этот сервер не может видеть реально существующее для зоны movie.edu пространство имен, его использование приведет к тому, что узел postmanrings2x.movie.edu утратит способность производить отоб ражение внутренних доменных имен в адреса и внутренних адресов в имена.

DNS и брандмауэры сети Интернет Настройка узла-бастиона Узел-бастион представляет особый случай в схеме расщепленного про странства имен. Он работает одновременно в двух мирах: один сетевой интерфейс соединяет его с сетью Интернет, а второй - с внутренней сетью. Мы произвели расщепление пространства имен на два: как мо жет узел-бастион видеть и пространство имен сети Интернет, и кано ническое внутреннее пространство имен? Если при настройке этого уз ла поместить в файл корневых указателей координаты корневых сер веров сети Интернет, узел-бастион будет использовать информацию о делегировании, полученную от DNS-серверов зоны edu, для доступа к внешнему DNS-серверу movie.edu, обладающему затененными зональ ными данными. Узел-бастион будет слеп во всем, что касается внут реннего пространства имен, которое ему как раз необходимо видеть чтобы регистрировать соединения, доставлять входящую почту, и вы полнять другие рутинные задачи. С другой стороны, если настроить этот узел с использованием внутренних корневых DNS-серверов, он не будет видеть пространства имен сети Интернет, которое необходимо видеть, чтобы могли выполняться функции узла-бастиона. Как быть?

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

Если внутренние DNS-серверы не поддерживают работу с зонами ре трансляции, DNS-сервер на узле-бастионе следует настроить в качест ве вторичного для зоны movie.edu и всех зон in-addr.arpa, для которых он будет производить разрешение адресов. В этом случае, если сервер узла-бастиона получает запрос для доменного имени из movie.edu, он возьмет локальные авторитативные данные для разрешения имени.

(Если внутренние DNS-серверы поддерживают зоны ретрансляции, DNS-сервер узла-бастиона никогда не будет получать запросов для имен из movie.edu.) Если доменное имя находится в делегированном поддомене movie.edu, DNS-сервер использует NS-записи зоны и от правляет запрос для имени внутреннему DNS-серверу. То есть нет не обходимости настраивать этот сервер в качестве вторичного для како го-либо из поддоменов movie.edu (скажем, fx.movie.edu), а только для «самой верхней» зоны (рис. 11.6).

410 Глава 11. Безопасность Рис. 11.6. Расщепленная архитектура DNS Файл named.conf на нашем узле-бастионе может выглядеть следую щим образом:

DNS и брандмауэры сети Интернет Защита зональных данных узла-бастиона К сожалению, загрузка этих зон на узле-бастионе делает их данные по тенциально доступными узлам сети Интернет, а именно этого мы и пы тались избежать, расщепляя пространство имен. Если мы используем DNS-сервер BIND версии 4.9 или более поздней, то всегда способны за щитить зональные данные с помощью ТХТ-записи secure_zone или предписания allow-query (оба варианта рассмотрены ранее в тексте гла вы). С помощью allow-query мы можем связать глобальный список уп равления доступом с данными зоны. Вот новый оператор options из файла named.conf:

Используя механизм BIND 4.9 secure_zone, мы можем запретить внешний доступ к данным зоны, включив следующие ТХТ-записи в каждый файл данных:

Адрес loopback-интерфейса должен обязательно присутствовать в списке, иначе клиент узла-бастиона может столкнуться с трудностями при попытке получить ответ от локального DNS-сервера!

412 Глава 11. Безопасность Окончательная настройка В завершение необходимо принять прочие меры, которые мы обсужда ли ранее, для обеспечения безопасности DNS-сервера узла-бастиона. В частности, необходимо:

• Ограничить передачу зон.

• Использовать предписание use-id-pool (BIND 8.2 и последующие версии, но не BIND 9).

• (Необязательно) Выполнять BIND в chroot-среде с наименьшими полномочиями.

В конце концов, наш файл named.conf принял следующий вид:

DNS и брандмауэры сети Интернет Узел-бастион и виды Если бы на узле-бастионе использовался DNS-сервер BIND 9, мы мог ли бы применить виды - для безопасного представления затененной зоны movie.edu внешнему миру на том же сервере, который произво дит разрешение доменных имен Интернета. Это может устранить необ ходимость работы внешнего DNS-сервера на том же узле, на котором работает наш веб-сервер, www.movie.edu. В противном случае у нас бу дет два DNS-сервера для обслуживания видимой извне зоны movie.edu.

Эти настройки очень похожи на приводимые в разделе «Виды» главы 10:

414 Глава 11. Безопасность Обратите внимание, что внешний и внутренний виды представляют различные версии зоны movie.edu: один вид загружает данные зоны из файла db.movie.edu, второй - из файла db.movie.edu.external. Если бы внешний вид содержал больше зон, вероятно, пришлось бы использо вать отдельные подкаталоги для хранения файлов данных зон, види мых извне, и файлов данных «внутренних» зон.

Расширения системы безопасности DNS Транзакционные подписи (TSIG), описанные ранее в этой главе, хоро шо подходят для обеспечения безопасности обмена между двумя серве рами либо между DNS-сервером и клиентом, посылающим обновле ния. Однако транзакционные подписи не помогут, если защищенность одного DNS-серверов под вопросом: злоумышленник, проникший на узел, на котором работает один из DNS-серверов, может получить до ступ к TSIG-ключам. Более того, поскольку в TSIG применяются раз деляемые секреты, не очень практично использовать этот механизм для многих DNS-серверов. TSIG также невозможно применять для об Расширения системы безопасности DNS мена между администрируемыми DNS-серверами и произвольными DNS-серверами сети Интернет, поскольку невозможно распределять и сопровождать такое количество ключей.

Наиболее распространенный способ решения проблем, связанных с со провождением ключей, - применение шифрования с открытым клю чом. Расширения системы безопасности DNS, описанные в документе RFC 2535, позволяют администраторам зон использовать шифрование с открытым ключом для создания цифровых подписей зональных дан ных, таким образом подтверждая подлинность данных.

Примечание: мы опишем расширения системы безопас ности DNS (DNSSEC) в том виде, в котором они определя ются документом RFC 2535. Однако рабочий комитет DNSEXT организации IETF все еще продолжает работу над DNSSEC, и отдельные аспекты системы могут измениться, прежде чем она станет стандартом.

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

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

Это единственный простой способ найти два ключа, обладающих специ альной ассиметрией (при которой один из ключей может расшифровать зашифрованное вторым): вычисление одного из ключей по второму задача невероятно сложная. (В наиболее популярном ассиметричном алгоритме шифрования, RSA, такое вычисление связано с разложени ем на множители очень больших чисел.) При применении шифрования с открытым ключом прежде всего со здается пара ключей. Затем один ключ из пары делается свободно до ступным (к примеру, публикуется в каталоге), а второй сохраняется в секрете. Тот, кто хочет установить с создателем ключей безопасный контакт, может перед отправкой зашифровать свое сообщение, поль В частности, BIND 8 не умеет следовать по цепи доверия. Он может произ вести проверку SIG-записей только в зонах, для которых существует опера тор trusted-keys.

416 Глава 11 Безопасность зуясь открытым ключом. (Более того, сообщение можно даже помес тить в конференцию или на веб-сайт.) Если адресат хранит закрытый ключ в секрете, только он сможет расшифровать сообщение.

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

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

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

Запись KEY В DNSSEC, расширениях безопасности DNS, с каждой защищаемой зоной связывается пара ключей. Закрытый ключ зоны хранится в бе зопасном месте - часто в файле на узле DNS-сервера. Открытый ключ распространяется в составе RR-записи нового типа, которая связыва ется с доменным именем зоны. Речь идет о записи KEY.

Запись типа KEY в действительности является записью общего назна чения, как станет ясно из наших объяснений. Записи этого типа мож но использовать для хранения различных видов ключей шифрования, а не только открытых ключей для зон, защищаемых с помощью DNS SEC. Тем не менее, в этой книге мы будем изучать только то примене ние записи KEY, которое связано с хранением открытых ключей зон.

Запись KEY выглядит следующим образом:

Расширения системы безопасности DN5 Рис. 11.7. Подпись и проверка сообщения Запись принадлежит доменному имени зоны, связываемой с откры тым ключом. За полем типа следует поле флагов, в котором записано значение 256. Поле флагов имеет длину два байта и содержит набор од но- и двухбитовых значений:

418 Глава 11. Безопасность Если значение первого бита - нуль, ключ может использоваться для проверки подлинности. Само собой, ключ, который не может быть ис пользован для проверки подлинности, не особо полезен в DNSSEC;

так что этот бит всегда сброшен.

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

Запись KEY, в которой оба этих бита установлены, называется пус тым ключом. Позже мы расскажем, как пустые ключи используются в родительских зонах.

Значение третьего бита зарезервировано для будущих нужд. Четвер тый бит - это бит «расширения флага». Его существование позволяет обеспечить удлинение поля флагов. Если этот бит установлен, запись KEY должна содержать еще одно двухбайтовое поле после поля алго ритма (третье поле после типа записи и непосредственно перед откры тым ключом (который обычно записывается в четвертом поле). Значе ния битов дополнительного двухбайтого поля пока еще не определены, так что четвертый бит всегда сброшен. Пятый и шестой биты зарезер вированы, как и третий, и должны быть сброшены.

Седьмой и восьмой биты кодируют тип ключа:

00 Ключ пользователя. Почтовый клиент пользователя может ис пользовать ключ пользователя для шифрования почты, адресован ной этому пользователю. Этот тип ключа не используется в DNS SEC.

01 Открытый ключ зоны. Все ключи в DNSSEC имеют этот тип.

10 Ключ узла. В реализации IPSEC ключ узла может использоваться для шифрования всез IP-пакетов, посылаемых этому узлу. В DNS SEC ключ узла не используется.

11 Значение зарезервировано для будущих нужд.

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

В приведенной записи KEY поле флагов (первое после типа записи) го ворит о том, что эта KEY-запись является ключом зоны movie.edu и мо жет использоваться для проверки подлинности и сохранения конфи денциальности.

Следующее поле записи, в котором в нашем примере записано значе ние 3, носит название октета протокола. Поскольку KEY-записи мо гут использоваться в различных целях, следует указывать предназна чение каждого конкретного ключа. Определены следующие возмож ные значения:

Расширения системы безопасности DNS 0 Зарезервировано.

1 Этот ключ используется в системе TLS (Transport Layer Security, безопасность транспортного уровня), описанной в RFC 2246.

2 Этот ключ используется в контексте электронной почты, к приме ру, может являться ключом S/MIME.

3 Ключ используется в контексте DNSSEC. Очевидно, для всех клю чей DNSSEC октет протокола имеет значение 3.

4 Ключ используется в контексте IPSEC.

Ключ используется с любым протоколом, в котором реализована поддержка KEY-записей.

Все значения большие 4 и меньшие 255 доступны для использования в будущем.

Следующее (третье) поле записи KEY, которое в нашем примере содер жит значение 1, определяет номер алгоритма. DNSSEC может исполь зоваться совместно с несколькими алгоритмами шифрования на осно ве открытого ключа, поэтому следует указывать, какой алгоритм ис пользуется для зоны и с каким алгоритмом следует использовать дан ный ключ. Определены следующие значения:

0 Зарезервировано.

1 RSA/MD5. Документ RFC 2535 рекомендует, но не требует, исполь зование RSA/MD5. Однако алгоритм RSA является очень популяр ным, а патент на алгоритм недавно истек, поэтому ходят слухи о том, что использование RSA может стать обязательным.

2 Алгоритм Диффи-Хеллмана (Diffie-Hellman). Документ RFC допускает использование этого алгоритма.

3 DSA. Документ RFC 2535 предписывает обязательную поддержку (не использование) DSA. Но, как мы уже сказали, такое положение дел может измениться.

4 Зарезервировано для алгоритма шифрования на основе эллипти ческих кривых.

В наших примерах будут использоваться ключи RSA, поскольку они, скорее всего, станут стандартом.

Последнее поле KEY-записи содержит собственно открытый ключ в кодировке Base 64. DNSSEC поддерживает ключи различных длин, как мы скоро увидим при создании открытого ключа для movie.edu.

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

Пустые ключи не содержат открытых ключей, но для них присутству ют октеты протоколов и номера алгоритмов.

420 Глава 11. Безопасность Запись SIG Если открытый ключ зоны хранится в записи KEY, то должен сущест вовать и тип записей для хранения подписи соответствующего закры того ключа? Так и есть, тип записей называется SIG. В SIG-записи хра нится цифровая подпись закрытого ключа для структуры RRset. RR set - это набор RR-записей с общим владельцем, классом и типом;

так, все адресные записи wormhole.movie.edu составляют структуру RRset.

То же верно и для всех МХ-записей movie.edu.

Почему подписывается набор записей (RRset), а не отдельные записи?

Чтобы сэкономить время. Невозможно произвести поиск единствен ной адресной записи wormhole.movie.edu;

DNS-сервер возвращает всю группу. Так зачем подписывать каждую запись в отдельности, имея возможность подписать их все сразу?

Вот SIG-запись для адресных записей wormhole.movie.edu:

Имя владельца в данном случае wormhole.movie.edu, и оно совпадает с именем, к которому привязаны подписываемые записи. Первое после типа содержит тип покрытия (в данном случае А). Оно определяет ка кие именно записи wormhole.movie.edu подписываются;

в данном слу чае речь идет об адресных записях. Для каждого типа записей wormho le.movie.edu понадобится отдельная SIG-запись.

Второе поле, в котором записано значение 1, определяет номер алго ритма. Интерпретация поля такая же как для соответствующего поля записей KEY, так что значение 1 означает использование алгоритма RSA/MD5. При использовании ключа RSA для подписи зон, подписи, естественно, будут иметь тип RSA/MD5. Если для подписи зоны ис пользуются различные типы ключей, скажем, ключ RSA и ключ DSA, для каждого RRset-набора будет присутствовать отдельная SIG-за пись, первая с номером алгоритма 1 (RSA/MD5), а вторая с номером алгоритма 3 (DSA). Третье поле носит название поля метки. Оно отражает число меток в имени владельца подписанных записей. В имени wormhole.movie.edu, очевидно, три метки, поэтому поле содержит значение 3. В каком слу чае поле метки может не соответствовать числу меток в имени вла дельца SIG-записи? Когда SIG-запись создается для записи с маской. К Зона может быть подписана ключами двух различных алгоритмов, чтобы люди, программное обеспечение которых реализует только поддержку DSA, также были в состоянии производить проверку данных, а те, кому больше нравится RSA, могли использовать RSA.

Расширения системы безопасности DNS сожалению (или к счастью, чтобы мы не сошли с ума), BIND не под держивает записи с масками в защищенных зонах.

Четвертое поле содержит исходное значение TTL для записей в RRset наборе. (Предполагается, что записи набора имеют одинаковое время жизни.) Значение TTL должно храниться здесь, поскольку DNS-cep вер, кэширующий записи из RRset-набора, к которому относится эта SIG-запись, будет постепенно уменьшать TTL кэшируемых записей.

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

Следующие два поля содержат временные отметки истечения срока действия и создания подписи. Обе даты хранятся в виде числа секунд, прошедших с момента начала эпохи Unix, то есть с первого января 1970 года, но в текстовом представлении записей SIG они записывают ся в формате YYYYMMDDHHMMSS - для удобства. (Время устарева ния для приведенной ранее SIG-записи соответствует 11:54 2 января 2001 года.) Время создания подписи обычно совпадает со временем вы полнения программы, производящей подпись зоны. Время устарева ния подписи также выбирается во время запуска программы. После того как срок действия подписи закончился, SIG-запись более не мо жет использоваться для проверки RRset-набора. Неприятная новость:

это означает, что придется периодически повторно подписывать дан ные зоны, чтобы подписи могли использоваться. Приятная новость: по вторная подпись отнимает намного меньше времени, чем в первый раз.

Следующее (седьмое) поле SIG-записи, которое в нашем примере со держит число 27791, - это поле карты ключа. Карта ключа - это зна чение, полученное на основе открытого ключа, соответствующего за крытому ключу, которым подписана зона. Если для зоны существует более одного открытого ключа (а так оно и будет при смене ключей), в процессе проверки программное обеспечение DNSSEC использует кар ту ключа, чтобы определить, какой ключ следует использовать для проверки подписи.

Восьмое поле, содержащее значение movie.edu, - это поле автора. Как можно ожидать, оно содержит доменное имя открытого ключа, кото рый должен использовать проверяющий при оценке подлинности под писи. Это имя в паре с картой ключа определяет KEY-запись, которую следует использовать. В большинстве случаев имя автора содержит до менное имя зоны, которой принадлежат подписанные записи. Но в од ном варианте - о котором мы скоро расскажем - может содержать до менное имя родительской зоны.

Последнее поле - поле подписи. Оно содержит цифровую подпись за крытого ключа зоны для записей набора и собственно SIG-записи, за исключением самого поля. Как и ключ в KEY-записи, подпись пред ставляется в кодировке Base 64.

422 Глава 11. Безопасность Запись NXT В DNSSEC используется еще один тип записей - NXT. Сейчас мы объ ясним его предназначение.

Что происходит при поиске для доменного имени, которое не сущест вует в защищенной зоне? Если бы зона не была защищена, DNS-сервер просто вернул бы код ошибки «no such domain name» (доменное имя не существует). Но как подписать код ошибки? Если подписывать все от ветное сообщение, его будет проблематично кэшировать.

NXT-записи предназначены решить эту проблему. Они «заполняют» пробелы между двумя последовательно расположенными доменными именами зоны, позволяя определить, какое доменное имя следует за определенным доменными именем - отсюда и название записи («next» - следующий).

Но разве понятие «последовательно расположенных доменных имен» не подразумевает, что доменные имена в зоне должны располагаться в некоем каноническом порядке? Разумеется, так и есть.

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

Сортировка по меткам производится без учета регистра символов, в алфавитном (словарном) порядке, причем цифры предшествуют бук вам, а несуществующие метки - цифрам (другими словами, movie.edu предшествует 0.movie.edu). Таким образом, доменные имена зоны то vie.edu сортируются следующим образом:

Обратите внимание, как movie.edu предшествует bigt.movie.edu, так и fx.movie.edu предшествует имени bladerunner.fx.movie.edu.

Расширения системы безопасности DNS Когда зона приведена в канонический порядок, записи NXT приобрета ют смысл. Вот одна NXT-запись (по сути дела - первая) зоны movie.edu:

Эта запись говорит о том, что следующее после movie.edu доменное имя в зоне - bigt.movie.edu, как мы можем видеть по сортированному спис ку доменных имен. Помимо этого, здесь содержится информация о том, что для имени movie.edu существуют NS-записи, SOA-запись, МХ-записи, SIG-запись и NXT-запись.

Последняя NXT-запись зоны является особенной. Поскольку следую щее доменное имя не существует, последняя NXT-запись ссылается на первую запись зоны:

Другими словами, чтобы показать, что wormhole.movie.edu является последним доменным именем в зоне, мы говорим, что следующим до менным именем является movie.edu, первое доменное имя зоны.

Каким же образом NXT-записи позволяют производить проверку под линности для отрицательных ответов? Если бы мы произвели локаль ный поиск для www.movie.edu, то получили бы в ответ NXT-запись wormhole.movie.edu, сообщающую, что www.movie.edu не существует, поскольку в зоне не существует доменных имен после wormhole.mo vie.edu. Точно так же, если бы мы произвели поиск ТХТ-записей для movie.edu, то получили бы NXT-запись, которая приводится выше, со общающую, что для movie.edu не существует ТХТ-записей, хотя су ществуют записи NS, SOA, MX, SIG и NXT.

SIG-запись для этой NXT-записи сопровождает ее в ответном сообще нии, таким образом удостоверяя подлинность факта отсутствия иско мого доменного имени или типа данных.

Очень важно, что NXT-записи абсолютно конкретно сообщают, что имени не существует в зоне. Простая, универсальная запись, сообща ющая нам, что «это не существует», может быть перехвачена и повтор но послана впоследствии злоумышленником, вводя нас в заблуждение относительно существования доменных имен или записей.

Читатели могут не беспокоиться о перспективе ручного добавления и сопровождения этих записей (О-хо-хо, я добавил узел, теперь придет ся исправлять NXT-записи...) - в BIND существует инструмент, позво ляющий автоматически добавлять NXT- и SIG-записи.

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

Просто повторяйте мантру: «Моя зона защищена, но открыта для всех».

424 Глава 11. Безопасность Цепь доверия Еще один аспект теории DNSSEC, который нам следует обсудить, цепь доверия. (Не подумайте, что речь идет о деликатных психологи ческих упражнениях по созданию сплоченного коллектива!) До сих пор у каждого RRset-набора нашей защищенной зоны была соответству ющая SIG-запись. Чтобы дать возможность другим проверять SIG-за писи, наша зона раздает всему миру открытый ключ, инкапсулирован ный в KEY-записи. Но представим себе, что злоумышленник проник на первичный DNS-мастер-сервер. Что помешает ему создать собствен ную пару ключей? Он сможет изменить данные зоны, повторно подпи сать зону новым закрытым ключом и раздавать всему миру новый открытый ключ, инкапсулированный в KEY-записи.

Чтобы подобных проблем не возникало, открытые ключи подвергаются «сертификации» в более высоких инстанциях. Более высокая инстан ция подтверждает, что ключ movie.edu в KEY-записи принадлежит ор ганизации, которая владеет и управляет этой зоной, а не какой-то пер вой встречной свинье. Прежде чем дать такое подтверждение, инстан ция требует доказательства, что мы те, за кого себя выдаем, и что мы имеем надлежащие полномочия, чтобы администрировать movie.edu.

В нашем случае более высокой инстанцией является родительская зо на edu. Создав пару ключей и подписав зону, мы посылаем открытый ключ администраторам edu, наряду с удостоверениями личности и до казательствами того, что мы являемся Двумя Подлинными Админист раторами movie.edu.1 Администраторы родительской зоны подписали нашу KEY-запись закрытым ключом зоны edu и вернули ее нам, чтобы мы могли добавить ее к своей зоне. Вот наша KEY-запись и сопровож дающая ее SIG-запись:

Обратите внимание, что в поле имени автора SIG-записи содержится строка edu, а не movie.edu;

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

Что если кто-то сможет проникнуть на первичный DNS-мастер-сервер зоны edu? KEY-записи зоны edu подписываются закрытым ключом В настоящее время ни одна зона высшего уровня не производит подпись KEY-записей для порожденных зон, хотя некоторые европейские регистра торы, вполне вероятно, вскоре этим займутся.

Расширения системы безопасности DNS корневой зоны. А корневая зона? Дело в том, что открытый ключ кор невой зоны широко известен и доступен на каждом DNS-сервере, под держивающем DNSSEC. То есть открытый ключ корневой зоны будет доступен на каждом DNS сервере, как только DNSSEC получит широкое распространение. В настоящее же время ни корневая зона, ни зона edu не подписываются, и ни у одной из них нет собственной пары ключей. В ожидании широ кого распространения механизма DNSSEC его можно использовать частично.

Защищенные сегменты Предположим, мы начали использовать DNSSEC в Университете ки нематографии, чтобы повысить защищенность данных зоны. Мы под писали зону movle.edu, но не можем получить подпись зоны edu для нашей KEY-записи, поскольку эта зона еще не является защищенной и для нее не существует пара ключей. Как могут другие DNS-серверы в сети Интернет проверять подлинность наших данных? Да и вообще, как могут наши собственные DNS-серверы проверять подлинность на ших же данных?

В DNS-серверах BIND 9 существует механизм, позволяющий указать в файле named.conf открытый ключ, соответствующей определенной зо не. Речь идет об операторе trusted-keys. Вот оператор trusted-keys для movie.edu:

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.