Как известно, основное предназначение службы DNS, на которой базируются современные сети, — разрешение имен компьютеров (хостов) в IP-адреса. Но помимо этой задачи служба DNS выполняет еще и обратную процедуру, т. е. так называемую обратную проверку (reverse lookup), а именно определяет по IP-адресу имя компьютера. Данная операция используется для проверки компьютера, выполняющего подключение к какому-либо сетевому приложению, и это сетевое приложение может запросить у службы DNS разрешение IP-адреса, с которого выполняется подключение, в имя. Поскольку в современных сетях при формировании запроса можно указать любое имя, но указать чужой IP-адрес в большинстве случаев не получится, данный способ проверки обладает определенной степенью надежности. Ведь привязать имя к IP-адресу так, чтобы служба DNS разрешила этот IP-адрес именно в это имя, может только тот, кто официально владеет данным IP-адресом.
Примером приложения, использующего обратную проверку, может служить почтовый сервер Microsoft Exchange Server, причем любая его версия. Мы рассмотрим Exchange Server 2003. В указанном продукте обратная проверка, т. е. разрешение IP-адреса в имя, применяется сервером Exchange для формирования списков SMTP-серверов, от которых нельзя принимать подключения (см. экран 1), а также при настройке ограничений на сервере пересылки почты (open relay; см. экран 2).
В этих механизмах обратная проверка позволяет принимать решение на основе того, к какому DNS-домену принадлежит компьютер, выполняющий подключение. Так, например, подключение сервера может быть принято, если он принадлежит домену nwtraders.com, и наоборот, подключение может быть отклонено, если компьютер зарегистрирован в домене contoso.com. Кроме того, некоторые почтовые системы могут использовать механизм обратной проверки для проверки имени SMTP-сервера, которое тот указал в команде EHLO/HELO. Последняя возможность используется в качестве одного из элементов в системе противодействия рассылке спама, что весьма актуально при нынешней ситуации в почтовых системах. Однако для этого типа проверки обычно используются операции прямого просмотра (forward lookup), поскольку злоумышленник, рассылающий спам через свой почтовый сервер, скорее всего, имеет доступ к его общедоступному IP-адресу и серверу DNS и, следовательно, сможет менять имя, в которое разрешается его IP-адрес, по своему желанию. Поэтому тот же сервер Exchange, несмотря на то что параметр, включающий проверку имени из команды EHLO/HELO, называется Perform reverse lookup on incoming messages (см. экран 3), для проверки имени использует прямой просмотр.
Таким образом, использование обратной проверки предоставляет определенные возможности администраторам почтовых систем и налагает некоторые обязательства. Если администратор хочет избежать проблем при отправке почты, он должен в обратной зоне, к которой принадлежит IP-адрес его почтового сервера, создать запись типа PTR. В этой записи нужно привязать IP-адрес почтового сервера к имени, которое сервер использует в команде EHLO. Однако при выполнении всех этих настроек администратор столкнется с рядом сложностей, о которых и пойдет речь ниже.
Обратные зоны для бесклассовых диапазонов
Классические обратные зоны DNS-серверов позволяют оперировать только классовыми диапазонами IP-адресов. Соответственно, минимальным диапазоном, для которого можно создать обратную зону, является класс C. Однако большинство предприятий использует гораздо меньшие диапазоны — 4, 8, 16 IP-адресов. В этом случае поддержку обратных зон Internet-провайдеру приходится брать на себя. Тем самым снижается гибкость в управлении адресами для потребителей и повышается нагрузка на администраторов провайдера. Для делегирования пользователям полномочий управления обратным разрешением их IP-адресов в имена требуется использовать бесклассовые обратные зоны.
В первую очередь нужно сказать, что DNS явно не поддерживает создание и делегирование бесклассовых обратных зон. Для решения этой задачи будут использоваться стандартные механизмы сервера DNS, но нестандартным способом. Кроме того, объем работы по созданию бесклассовых обратных зон будет достаточно громоздким, но позволяет достичь цели — разделить диапазон IP-адресов обратной зоны на подсети и делегировать их на другие серверы DNS.
Второй аспект — обратные зоны работают с теми же доменами, что и прямые зоны, только домены обратных зон похожи на IP-адреса, но именно похожи. Поэтому уточним задачу: необходимо разделить обратную зону для диапазона 192.168.1.0 между двумя клиентами пополам.
Первым делом на серверах DNS клиентов создадим обратные зоны для доменов subnet1.1.168.192.in-addr.arpa., на одном сервере для первого клиента, и subnet2.1.168.192.in-addr.arpa., на втором сервере DNS для второго клиента.
Затем на сервере DNS провайдера в домене 1.168.192.in-addr.arpa создадим делегирование для этих дочерних доменов на серверы DNS клиентов.
Далее в зоне домена 1.168.192.in-addr.arpa создадим записи типа CNAME для каждого адреса хоста, который будет ссылаться на запись PTR в дочернем домене, делегированном клиенту. Имя компьютера, указанное в этой записи, и будет возвращаться в ответ на запрос, а указывать имя будет администратор компании-клиента.
Сама запись будет выглядеть так:
1 CNAME 1.subnet1.1.168.192.in-addr.arpa
На сервере DNS клиента в зоне, поддерживающей дочерний домен subnet1, создадим обычную запись PTR, например:
1 PTR server.domain.ru
Основная сложность заключается в том, что нужно будет создать псевдонимы для всех адресов, поэтому проще эту задачу выполнять, редактируя файлы зон напрямую.
Теперь давайте рассмотрим пример практической реализации изложенных принципов посредством графического интерфейса сервера DNS из состава операционной системы Windows Server.
Первый шаг: создаем обычную обратную зону для диапазона 192.168.1.0/24, как показано на экране 4.
Затем командой New Alias (CNAME) из контекстного меню зоны или меню Action в этой зоне создаем псевдонимы (см. экран 5).
В результате получаем описание зоны, представленное на экране 6.
Далее командой New Delegation из контекстного меню обратной зоны 192.168.1.0/24 выполняем делегирование для дочернего домена subnet1 на сервер DNS клиента (экраны 7 и 8). На экране 9 показано, как теперь будет выглядеть сама обратная зона для диапазона 192.168.1.0/24.
Все, что осталось, так это на сервере DNS клиента создать обратную зону для домена subnet1.1.168.192.in-addr.arpa. Для этого запускаем обычный мастер создания обратных зон, но в окне Reverse Lookup Zone Name выбираем переключатель, позволяющий непосредственно указать имя новой обратной зоны (см. экран 10). В результате получаем на сервере клиента такую обратную зону, как показано на экране 11.
Цель достигнута, теперь администратор клиента может создавать на своем сервере DNS обычные обратные записи (PTR) для IP-адресов своих компьютеров, например так, как на экране 12.
Если теперь попробовать разрешить IP-адрес в имя, используя сервер DNS, на котором находится обратная зона диапазона 192.168.1.0/24, то результат будет, как на экране 13.
Как и было сказано выше, делегирование обратных зон для бесклассовых диапазонов выполняется посредством нестандартного использования обычных возможностей сервера DNS. Фактически предложенный метод выполняет делегирование каждого отдельно взятого IP-адреса. Для каждого адреса администратор сервера DNS провайдера посредством псевдонима должен указать, где искать имя, соответствующее данному IP-адресу. Каких-либо расчетов, связанных с идентификаторами сети и идентификаторами хоста в делегируемых IP-адресах, выполнять нет никакой необходимости, поскольку диапазон адресов в этом методе не делится, просто перебираются все IP-адреса и каждому вместо имени ставится в соответствие ссылка на другой сервер DNS. Ну а если какие-то адреса остаются у провайдера, то он для них создает традиционные обратные записи вместо псевдонимов. Дочерние домены, в данном примере subnet1 и subnet2, как раз представляют собой ссылки на серверы DNS клиентов, которым выделяются бесклассовые диапазоны IP-адресов. Когда какому-то клиенту выделяются те или иные адреса, для него в обратной зоне соответствующего классового диапазона создается дочерний домен, который делегируется на сервер DNS клиента, с именем, например, subnetN, где N — номер клиента, и IP-адресам, выделенным этому клиенту, ставятся в соответствие псевдонимы, ссылающиеся на этот домен. А в созданном дочернем диапазоне клиент становится полновластным хозяином и самостоятельно решает, в какие имена будут разрешаться его адреса.
Дмитрий Иванов (DmitriyI@hq.a-sys.ru ) — преподаватель сертифицированного учебного центра Microsoft «Академия корпоративных систем», специализация Microsoft Exchange Server