Cлужба доменных имен Domain Name System (DNS) — один из важнейших компонентов любой ИТ-среды. От DNS зависят все пользователи Internet. Если вы, как и большинство администраторов, применяете в своей сети службу Active Directory (AD), ваши пользователи тоже задействуют DNS при поиске в сети ресурсов, таких как контроллеры доменов (DC). Если пользователи будут искать контроллер домена без помощи DNS, они не смогут даже зарегистрироваться в сети.
Разделение DNS — это метод конфигурации, обеспечивающий корректное разрешение имен (например, имени example.com) для пользователей, находящихся как в локальной сети, так и вне ее. Используется данный метод почти в каждой организации. Но, хотя он и получил широкое распространение, мне регулярно приходится сталкиваться с администраторами, которые по той или иной причине с ним не знакомы. Давайте рассмотрим ситуацию, в которой целесообразно использовать разделенную DNS, а затем я покажу, как можно установить такую систему в своей организации.
Представим себе такую весьма неприятную ситуацию. Администратор небольшой организации только что завершил установку нового Web-сервера. Этот сервер присоединен к домену AD (mydomain.local), и администратор опубликовал его в Internet через брандмауэр. Имя сервера — WEB01, поэтому полное доменное имя Fully Qualified Domain Name (FQDN) формулируется так: web01.mydomain.local. Администратор присвоил серверу статический IP-адрес 192.168.123.10.
Внешние записи DNS хранятся у провайдера, поэтому администратор выбирает неиспользуемый общедоступный IP-адрес из назначенного пула и затем просит провайдера настроить запись А для www.mydomain.com, которая разрешалась бы в данный общедоступный IP-адрес. Затем в офисе администратор вводит в адресную строку браузера адрес www.mydomain.com, но сайт не загружается. Он связывается с провайдером, и там подтверждают, что запись А создана корректно. В чем же дело?
Представьте себя в подобной ситуации. Если вы настроили сервер AD DNS так, чтобы запросы, на которые он не может ответить, перенаправлялись на другой сервер DNS, который сможет на них ответить (например, на серверы DNS вашего провайдера), вы, вероятно, полагаете, что эта страница должна успешно загружаться и в офисном браузере. Корпоративный сервер AD DNS содержит только зону mydomain.local, поэтому запрос для www.mydomain.com перенаправляется на серверы DNS провайдера, которые и должны возвратить корректные результаты. Мы знаем, что серверы DNS провайдера располагают корректной информацией, потому что ваши коллеги могут обратиться к Web-узлу. Однако сервер провайдера отвечает на ваш запрос с общедоступным IP-адресом вашего сайта.
«Ну и что же, — возможно, скажете вы самому себе, — все должно получиться. Мой компьютер соединится с этим IP-адресом, и все будет в порядке!» Но ничего не получается. Дело в том, что пограничный маршрутизатор или брандмауэр настроен таким образом, что, когда он видит, что одна из соединенных с ним сетей пытается передать информацию самой себе, устройство отбрасывает пакеты и ваша работа полностью парализована, потому что сайт не загружается.
Решение понятно: нужно сделать так, чтобы внутренние серверы DNS отвечали на запросы для www.mydomain.com со статическим IP-адресом 192.168.123.10.
Разделение DNS обеспечивает выполнение следующего сценария: когда пользователи офиса в локальной сети вводят с клавиатуры адрес www.mydomain.com, возвращаемая запись DNS содержит внутренний частный IP-адрес созданного Web-сайта. Но когда пользователи, работающие за пределами локальной сети офиса, пытаются обратиться к сайту www.mydomain.com, возвращаемая запись DNS содержит внешний общедоступный IP-адрес Web-сайта. На рисунке представлен общий обзор маршрутов, по которым запросы следуют после завершения этой настройки.
DNS двойного назначения
Серверы AD DNS в состоянии обслуживать зоны DNS, не являющиеся в то же время доменами AD. Более того, эти зоны могут быть интегрированы в AD, не будучи при этом доменами AD!
В нашем примере, однако, мы настроим новую основную зону DNS на AD DNS-сервере Windows Server 2003 Standard Edition. Для начала нужно открыть оснастку DNS Management консоли Microsoft Management Console (MMC) и развернуть узел интересующего нас сервера. Правой кнопкой мыши щелкните на пункте Forward Lookup Zones, после чего запустите мастер New Zone Wizard, щелкнув на пункте New Zone. На странице приветствия следует нажать кнопку Next, и вы окажетесь на второй странице мастера. Вы увидите варианты для создания зоны Primary, зоны Secondary или зоны Stub, а также устанавливаемый по умолчанию флажок, позволяющий сохранять новую зону в каталоге AD (см. экран 1). Выберите зону Primary и сбросьте флажок сохранения зоны в AD, поскольку в данном примере мы хотим сохранить созданную зону в обычном файле.
На следующей странице мастера следует ввести имя зоны mydomain.com. Нажмите Next; система предложит изменить имя файла, используемого сервером DNS для хранения записей зоны. В данном примере можно использовать имя, предлагаемое мастером по умолчанию. На экране 2 показана страница мастера Dynamic Update, где нужно будет принять решение: разрешить зоне принимать как защищенные, так и незащищенные обновления или не позволять ей принимать какие-либо динамические обновления. Мы не создаем записей, которые следует обновлять динамически, поэтому нужно выбрать пункт Do not allow dynamic updates. На последней странице мастера кратко описано, что произойдет после нажатия кнопки Finish.
Теперь, если открыть пункт Forward Lookup Zones, вы увидите запись для mydomain.com. На этой записи нужно щелкнуть правой кнопкой мыши и в открывшемся меню выделить пункт New Host (A). Появится диалоговое окно, подобное тому, что показано на экране 3. Так же, как и в рассмотренном выше примере с Web-сервером, введем www в качестве имени и 192.168.123.10 — в качестве IP-адреса. Флажок Create associated pointer (PTR) record устанавливать не надо, поскольку мы не хотим настраивать обратную запись DNS для данной машины; обратные DNS обеспечивают разрешения IP-адресов в имена, а нам требуется только осуществлять разрешение имени в IP-адрес. Щелкните на пункте Add Host. Задача решена.
Теперь вы можете протестировать разделенную конфигурацию со своей рабочей станции. Но перед этим нужно обязательно очистить кэш DNS. Для этого требуется в командной строке ввести следующую команду: ipconfig/flushdns. В браузере следует ввести адрес www.mydomain.com, и ваш сайт должен загрузиться.
Можно добавить ко вновь созданной зоне дополнительные хосты для любого нового ресурса, например для почтового сервера или сервера терминалов, к которому должны обращаться по одному и тому же имени пользователи, находящиеся как в сети, так и за ее пределами.
Разделяй и властвуй
Можно модифицировать представленное выше решение таким образом, чтобы ваши внутренние серверы AD DNS отвечали лишь на запросы, касающиеся ресурсов AD, и направляли все остальные запросы на другую группу внутренних серверов DNS. Это другое подмножество серверов будет содержать ваши частные записи IP для mydomain.com и рекурсивно отвечать на запросы по всем другим доменам. Такое разделение поможет, с одной стороны, снизить риск, а с другой — осуществить делегирование административных полномочий, поскольку серверы AD DNS будут отделены от DNS-серверов, используемых для разделенного разрешения имен.
В качестве метода, альтернативного разделению DNS, можно использовать на периметре сети одно из решений от независимых поставщиков, которое сможет переписывать IP-адреса, возвращаемые в пакетах, содержащих данные DNS. Так, в выпускаемых компанией Cisco устройствах PIX и ASA реализована функция DNS Doctoring, которая обеспечивает такую модификацию адресов. Все эти методы реализуются довольно просто, но тем не менее их следует для начала испытать в тестовой сети и лишь после этого переносить в производственную сеть. Успехов в обработке запросов!
Майкл Дрегон (mike@mikerochip.com) — редактор Windows IT Pro и системный инженер из Нью-Йорка. Имеет сертификаты MCDST и MCSE