Из всех вопросов по работе брандмауэра ISA, вопрос, заставляющий людей попотеть — разделение DNS. Никогда не мог постичь, почему у многих возникает напряжение, когда речь заходит о разделении DNS. Может потому, что все думают, что придется переименовывать домены внутренней сети или потому, что это представляется ударом по безопасности. А может из-за того, что понятие DNS слишком сложно для понимания и идея дальнейшего его усложнения доводит людей до предела?
Какой бы ни была причина, факт состоит в том, что DNS может сделать Вашу жизнь и жизнь Ваших пользователей гораздо проще. Когда у Вас есть разделенная структура DNS, можно добиться следующего:
- Пользователям не нужно помнить об использовании различных имен, в зависимости от его местоположения
- Клиентским приложениям не понадобится переконфигурация от местоположения пользователя.
- Внутренние хосты не будут пускать трафик через корпоративный брандмауэр, чтобы получить доступ к внутрикорпоративным ресурсам, а будут к ним подключаться напрямую
- Можно не изменять название домена Службы каталогов — разделенный DNS не требует переименования внутренних узлов.
- Любые версии клиента Outlook MAPI (97/98/200/2002/2003) будут просто работать. Пользователь может находиться в офисе, временно выключить свой лэптоп, а затем включить его снова в номере отеля в 5000 км от офиса. Outlook же автоматически подключится к корпоративному серверу Exchange.
В этой статье я расскажу, как создать разделенный DNS для организаций, в которых используются недопустимые домены верхнего уровня, то есть такие, которые недопустимы в Интернет и не могут быть зарегистрированы.
Примеры недопустимых доменов верхнего уровня (будем их далее для краткости обозначать TLD): .local, .home, .lan, .private, .blah и .whateveryoulike.
Список разрешенных доменов верхнего уровня на момент написания статьи можно посмотреть здесь:
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
Также можно использовать принципы, описываемые здесь для создания разделенной структуры DNS, даже если у Вас в сети нет недопустимых TLD. Например, если есть желание разместить общедоступные ресурсы на remotecorp.com, а внутренние — на internalcorp.net.
Как работает разделенный DNS
Разделенный DNS делает ресурсы доступными, прозрачными и независимыми по расположению для внешних и для внутренних пользователей. Что имеется в виду под прозрачностью? Под прозрачностью понимается, что пользователю не нужно использовать различные имена или перенастраивать клиентские приложения на использование разных имен в зависимости от его местоположения в настоящий момент. Например, если пользователь находится во внутренней сети и ему необходим доступ к серверу SharePoint Portal через sps.domain.com, то ему необходима также возможность доступа к серверу SharePoint Portal через sps.domain.com и через Интернет.
Другой пример — для Outlook Web Access (OWA). Если пользователь подключен к внутренней сети и использует owa.domain.com для доступа к сайту OWA, он должен иметь возможность доступа к этому сайту через Интернет абсолютно таким же способом.
Разделение DNS работает потому, что на самом деле есть 2 или больше доступных серверов DNS, предназначенных для этого имени домена.
1 или больше серверов отвечают за разрешение имен для хостов внутренней сети и другие (1 или больше) сервера отвечают за разрешение имен для хостов в Интернет.
Сервер DNS, ответственный за разрешение имен во внутрикорпоративной сети содержит записи DNS, которые отображают имена серверов в их внутренние IP адреса, которые и используются во внутренней сети. DNS сервер, ответственный за разрешение имен для внешних пользователей, отображает имена во внешние IP адреса, обеспечивая доступ к корпоративным ресурсам снаружи.
Например, представьте себе, что Ваша Служба каталогов носит имя domain.local. это обычная ситуация для малого бизнеса. Так как .local является недопустимым доменом верхнего уровня, нельзя зарегистрировать такой домен у регистратора имен. Однако можно зарегистрировать другой домен, например, mydomain.net и использовать его в качестве части разделенного DNS.
Создается новая DNS зона на внутреннем сервере DNS для mydomain.net и после этого домен регистрируется.
Затем на обоих (внутреннем и внешнем) DNS серверах создаются записи, доступные как внутренним, так и внешним пользователям.
Вот примеры некоторых ресурсов, доступных изнутри и снаружи:
- Сайты Outlook Web Access
- Сайты Sharepoint Portal Server
- Другие сайты с корпоративной информацией
- Клиентский доступ Exchange MAPI
- POP3 сервера
- SMTP сервера
- IMAP4 сервера
- NNTP сервера
- Терминалы
- Шлюзы SSL VPN
Предположим, у Вас во внутренней сети есть сервера Microsoft Exchange и Microsoft SharePoint Portal. На внутреннем DNS сервере создайте две записи (A) в зоне mydomain.net:
owa.mydomain.net (отображается на IP адреса внутренней сети)
sps.mydomain.net (отображается на IP адреса внутренней сети)
На внешнем сервере DNS сервере тоже создайте две записи (А) для mydomain.net:
owa.mydomain.net (отображает на внешние IP адреса доступные внутрикорпоративные ресурсы)
sps.mydomain.net (отображает на внешние IP адреса доступные внутрикорпоративные ресурсы)
Внутренняя сеть использует DHCP для назначения хостам IP адресов. Внутренние DNS сервера управляют обоими доменными именами (domain.local и mydomain.net). Когда внутренние пользователи соединяются owa.mydomain.net, они попадают прямо на сайт OWA в корпоративной сети, минуя брандмауэр и другие устройства, обеспечивающие общий доступ к сайту OWA.
Когда пользователи перемещаются из внутренней сети во внешнюю, то получает информацию об IP адресах через DHCP. Внешний хост получает адрес от DNS сервера, который разрешает имена узлов Интернет. Когда внешний пользователь соединяется с owa.mydomain.net, внешний DNS сервер предоставляет ему внешний адрес, который сконфигурирован для этого ресурса на внешнем DNS сервере для домена mydomain.net.
Рисунок ниже отображает DNS подключение как для внутреннего, так и для внешнего хостов с использованием разделенной DNS инфраструктуры.
Ключевые моменты и заблуждения относительно разделенной DNS инфраструктуры
Перед тем, как углубиться в детали внедрения разделенной DNS инфраструктуры, рассмотрим некоторые основные моменты и заблуждения относительно ее. Вот несколько фактов, которые следует знать и которые развеют всякие неправильные представления по поводу распределенной DNS инфраструктуры:
- Разделенный DNS не требует смены имен внутреннего и внешнего домена
- Разделенный DNS не несет никакого риска в части безопасности внутренних доменов
- Разделенный DNS не усложнит управление
- Внешний DNS сервер в разделенном DNS никогда не состоит в отношениях типа хозяин/слуга с внутренним DNS сервером
ФАКТ: Разделенный DNS не требует смены имен внутреннего и внешнего домена
Это основная мысль статьи. Можно продолжать пользоваться текущим доменом Службы каталогов и использовать разделенный DNS для поддержания соединений с ресурсами, доступ к которым разрешен и изнутри, и снаружи.
Внутридоменные коммуникации будут походить также как и раньше. Добавление новой зоны для поддержания разделенной инфраструктуры никак не повлияет на обычные внутридоменные соединения Службы каталогов.
Это справедливо, используете ли Вы недопустимые имена доменов первого уровня или нет. Может быть, уже используется домен с допустимым именем в разделенной инфраструктуре, и просто есть необходимость добавить еще один, например, для поддержки ресурсов, к которым требуется доступ как снаружи, так и изнутри. Это делается без проблем. Добавление нового домена не повлияет на существующее положение вещей.
ФАКТ: Разделенный DNS не несет никакого риска в части безопасности внутренних доменов
Существует заблуждение, что разделенный DNS представляет какую-то опасность корпоративной сети. Никогда не понимал, на чем основано это заблуждение. Но очень похоже, что люди, думающие так, не до конца понимают как работает разделенный DNS. А может быть они располагают части записей разделенного DNS на той же машине, где расположены внутренние записи? Правда в том, что правильно внедренная разделенная инфраструктура никогда не подвергнет корпоративную сеть той опасности, которая исходит от злоумышленников, добравшихся до информации об именовании компьютеров в сети. Помните, что есть 2 группы DNS серверов, участвующих в разделенной инфраструктуре: внешние (открытые) и внутренние (закрытые) сервера. Внешние никогда не контактируют с внутренними и наоборот.
Подозреваю, что это заблуждение может относиться к неправильному внедрению разделенной инфраструктуры, в контексте использования одинаковых имен для сети Службы каталогов, а также для открытых и закрытых ресурсов. Я предпочитаю использовать одинаковые имена для внутренней сети и для доступа внешних пользователей к внутренним ресурсам, используя такое же имя. Однако необходимо правильно настроить конфигурацию. Иначе есть риск того, что для внешних пользователей будет открыта лишняя информация.
Чтобы полностью развеять миф об угрозе безопасности от разделенной инфраструктуры, взглянем на пример неправильно сконфигурированного разделенного DNS (которая вовсе не является разделенной инфраструктурой).
Предположим, что имя домена Службы каталогов во внутренней сети split.com. Вам надо внедрить разделенную инфраструктуру. Что можно сделать, но ни в коем случае не следует, так это держать записи на внутреннем сервере для внешних и внутренних ресурсов одновременно. Например, на DNS сервере Службы каталогов находятся записи для всех машин и устройств внутренней сети. Вдобавок к этому, создаются записи, которые могут использовать все пользователи (внутренние и внешние):
owa.split.com
sps.split.com
rpc.split.com
Когда создаются эти записи (А), они отображаются на внешние адреса, которые внешние пользователи используют для доступа к сайтам (обычно через брандмауэр ISA firewall Web или правила опубликования Server Publishing Rule). Потом открывается внутренний сервер, который несет эти записи. Это просто, так как Вы только что настроили IP адрес, который публикует внутренний сервер DNS в Интернет, как сервер DNS для такого домена.
Вот некоторые проблемы такой конфигурации:
- Внутренние и внешние записи хранятся на одном DNS сервере. Это нарушает базовый принцип разделенной инфраструктуры: внешние пользователи никогда не получают доступ к внутреннему DNS серверу и наоборот.
- Так как внутренний сервер DNS имеет внешнюю адресацию, которая отображает внутренние ресурсы как для внутренних, так и для внешних пользователей, внутренние узлы будут пускать трафик через ISA брандмауэр или другое устройство, обеспечивающее внешним узлам доступ к внутренним ресурсам.
- Если администратор, открывая внутренний DNS сервер для внешних пользователей, использует простое соединение NAT один-к-одному, или не понимает протокола DNS или конфигурации сервера, он может подвергнуть внутренний сервер DNS запросу на изменение зоны для сервера (ТСР порт 53). Это даст злоумышленникам возможность доступа снаружи ко всем внутренним записям DNS через совместный запрос на изменение зоны.
Как видно, чтобы создать угрозу безопасности с помощью разделенной инфраструктуры, надо совершить несколько ошибок, которые нарушают базовый принцип разделенной инфраструктуры
ФАКТ: Разделенный DNS не усложнит управление
Может быть, в случае разделенной инфраструктуры придется поработать чуть больше, но каких-то других сложностей в работе не возникнет. Причина этого в том, что Вы на зеркалируете внутренние DNS сервера во внешние и не включаете внутренние ресурсы в разделенную инфраструктуру.
Записи, которые надо включить в разделенную инфраструктуру — только о серверах, которые должны быть доступны и снаружи и изнутри.
Сколько Вы над этим проработаете, зависит только от Вас. Можно создать столько записей (А), сколько нужно. Например, если есть внешний сервер Exchange, можно создать следующие записи:
smtp.mydomain.net
pop3.mydomain.net
owa.mydomain.net
rpc.mydomain.net
imap4.mydomain.net
Все они отображаются на один IP адрес во внутреннем DNS (который отображает на внутренний адрес, используемый внешним сервером Exchange) и на один адрес внешнего DNS (который отображает на внешний адрес, используемый для доступа к внутренним ресурсам снаружи). Или же можно создать одну запись:
mail.mydomain.net
Главное создать записи на обоих серверах. Записи должны иметь одинаковые имена, но разные IP адреса. Так как и внутренние, и внешние адреса меняются редко, изменения в разделенной инфраструктуре также поводятся редко.
ФАКТ: Внешний DNS сервер в разделенном DNS никогда не состоит в отношениях типа хозяин/слуга с внутренним DNS сервером.
Это одно из основных заблуждений. Оно ведет к беспокойству в вопросах безопасности и сложности. Я прочитал много рассылок, новостей и форумов, на которых администраторы высказывали мнение, что им придется выполнить перенос пространств между внутренним и внешним серверами, разделенной инфраструктуры. Это явно ошибочное мнение. Оно нарушает основные принципы разделенной инфраструктуры.
Нет причины выполнять такую операцию, потому что нет никаких взаимоотношений между внутренней и внешней DNS зонами, кроме имен доменов и узлов. Следовательно, изменения в одной зоне не повлияют на другую.
Редко когда надо сменить запись (А) на обоих серверах одновременно. Может, в случае, когда компания сразу меняет внутренние адреса и провайдера Интернет.
Пример: настройка разделенной инфраструктуры для домена ISASERVER.LOCAL
Чтобы понять, как можно применить такое решение при организации доступа к внутренним ресурсам снаружи в организации, использующей брандмауэр ISA, рассмотрим пример, как компания, использующая запрещенные имена доменов первого уровня может использовать разделенную инфраструктуру, чтобы поддержать прозрачность доступа к внутренним ресурсам изнутри и снаружи.
Компания использует имя домена ISASERVER.LOCAL для Службы каталогов. Это имя с запрещенным доменом первого уровня, и компания не может его использовать для внешних подключений. Также она не имеет намерений менять это запрещенное имя. Все, что им остается, использовать разделенную инфраструктуру и имя isaexternal.com для нее, чтобы обеспечить доступ и изнутри и снаружи через это имя.
Компании следует организовать удаленный защищенный доступ к следующим ресурсам Exchange Server 2003:
- Сервер Outlook Web Access
- RPC через HTTPдля клиентов Outlook 2003
- SMTP
- POP3S и IMAP4S
- Exchange ActiveSync и Outlook Mobile Access
Рисунок ниже показывает основные детали сети компании для сценария 1, где у компании есть свой собственный DNS сервер для внешних ресурсов. Во Внутренней Сети по умолчанию за брандмауэром ISA расположены наружный и внутренний Exchange Server и контроллер домена Службы каталогов Windows Server 2003. На контроллере стоит встроенный DNS сервер Службы каталогов, работающий и для внутреннего домена ISASERVER.LOCAL, и для внешнего isaexternal.com. внешние пользователи будут получать доступ к ресурсам внутреннего сервера Exchange через соединение с открытыми ресурсами на isaexternal.com. обратите внимание, что внешний и внутренний сервера принадлежат домену ISASERVER.LOCAL. Политики настроены так, что пользователи могут посылать и получать информацию через домен isaexternal.com.
В зоне DMZ за брандмауэром ISA два сервера DNS работают как первичный и вторичный для внешнего домена isaexternal.com. Эти DNS сервера доступны в Интернет при помощи двух Правил публикации серверов. Каждый открытый IP адрес, используемый внешним интерфейсом брандмауэра ISA для Правил публикации серверов DNS регистрируется открытым регистратором DNS как адрес DNS сервера для домена isaexternal.com.
Следующий рисунок показывает процесс для сценария 2, где компания открывает хостинг открытых DNS ресурсов с помощью провайдера или хостера DNS, или провайдера динамического DNS. В этом сценарии компания решает держать открытые зоны в другом месте. Это (другое место) может представлять собой DNS сервера провайдера, выделенный сервер (например, www.eservicesforyou.com) или ресурсы провайдера динамических DNS (например, www.tzo.com).
Динамический DNS полезно использовать компаниям, которые не имеют выделенных IP адресов для внешнего интерфейса брандмауэра ISA. Однако провайдеры DDNS также могут предоставлять выделенные DNS сервера для тех компаний, которые используют выделенные открытые IP адреса.
Можно использовать следующие процедуры для наладки такого решения:
- Создать зону isaexternal.com на внутреннем DNS сервере. Прежде всего, следует создать внутреннюю часть разделенной инфраструктуры на внутреннем DNS сервере. Доменная зона службы каталогов уже указана во внутреннем DNS и там менять ничего не нужно. После создания внутренней части разделенной инфраструктуры на внутреннем сервере необходимо внести соответствующие записи в DNS.
- Зарегистрировать домен isaexternal.com у открытого регистратора и настроить адреса DNS сервера или воспользоваться услугами хостера DNS или DDNS. Внешняя часть разделенной инфраструктуры должна быть настроена или на открытый доступный DNS сервер, или на DNS сервер вне внутренней сети.
- Открыть доступ к внешним DNS серверам, если ресурсы расположены на Ваших серверах. Если Вы планируете расположить их у себя, необходимо поместить их в DMZ с анонимным доступом и опубликовать их при помощи правил публикации серверов.
Создание внутренней части разделенной инфраструктуры DNS на DNS сервере внутренней сети
Первый шаг — создать внутреннюю часть разделенной инфраструктуры. Разместим внутреннюю зону разделенного домена на сервере Службы каталогов на контроллере домена Службы каталогов внутренней сети. Имя внутренней зоны разделенной инфраструктуры — isaexternal.com
Проделайте следующее, чтобы создать зону DNS:
- Нажмите Start, выберите Администрирование(Administrative Tools) и щелкните DNS.
- В консоли DNS, разверните имя сервера и Forward Lookup Zones (просматриваемые зоны). Щелкните на Forward Lookup Zones правой кнопкой мыши. Выберите Новая зона (New Zone).
- Щелкните Далее (Next) на первой странице мастера.
- На странице Тип зоны (Zone Type), выберите Основная зона (Primary zone) и нажмите Далее (Next).
- На странице Имя зоны (Zone Name) введите имя зоны разделенного домена. В данном примере это isaexternal.com. Нажмите Далее (Next).
- На странице Имя файла просто нажмите Далее (Next).
- На странице Динамическое обновление (Dynamic Update), оставьте настройки по умолчанию.
- На странице Завершение работы мастера нажмите Готово (Finish).
После создания внутренней части разделенной DNS зоны на внутреннем DNS сервере ее необходимо дополнить записями.
Помните, что сюда надо включать лишь записи о тех ресурсах, доступ к которым нужен как изнутри, так и снаружи.
Не забудьте, что мы хотели сделать доступ отовсюду к следующим службам Exchange Server:
- Outlook Web Access
- RPC over HTTP для клиентов Outlook 2003
- SMTP
- POP3S и IMAP4S
- Exchange ActiveSync и Outlook Mobile Access
The OWA, RPC over HTTP, Exchange ActiveSync и Outlook Mobile Access могут быть на одном сайте и привязаны к одному IP адресу на внешнем сервере Exchange. Однако так как нет возможности использовать аутентификацию брандмауэра ISA с использованием единственного прослушивателя для OWA и всех остальных служб, придется использовать 2 IP адреса для внешнего интерфейса брандмауэра ISA.
Один для OWA, а другой для всех остальных служб.
SMTP, POP3S и IMAP4S могут быть привязаны и опубликованы через один IP адрес на внешнем Exchange сервере, так как они прослушиваются по разным сокетам.
Можно использовать IP адрес приложения Web listener.
Чтобы организовать поддержку публикации (с разделенной инфраструктурой) служб сервера Exchange, следует создать такие записи DNS на внутреннем сервере:
owa.isaexternal.com A 10.0.0.2
rpc.isaexternal.com A 10.0.0.2
eas.isaexternal.com A 10.0.0.2
oma.isaexternal.com A 10.0.0.2
pop.isaexternal.com A 10.0.0.2
imap.isaexternal.com A 10.0.0.2
smtp.isaexternal.com A 10.0.0.2
Лучше создавать для каждой службы отдельную запись. Они редко меняются, а потраченные несколько минут сэкономят время в дальнейшем при расширении списка.
В следующем примере мы создадим две из этих записей:
- Нажмите Start, выберите Администрирование(Administrative Tools) и щелкните DNS.
- В консоли DNS, разверните имя сервера и Forward Lookup Zones (просматриваемые зоны). Щелкните на Forward Lookup Zones. Выберите зону isaexternal.com и щелкните на ней правой кнопкой мышки. Выберите пункт Новый хост.
- В диалоге Новый хост введите owa в поле Имя. Введите IP адрес внешнего сервера Exchange. Поставьте галочку «Создать связанный указатель» (Create associated pointer (PTR)). Нажмите «Добавить».
- Нажмите ОК в диалоговом окне, информирующем о том, что операция прошла успешно.
- В диалоге Новый хост введите rpc в поле Имя. Введите IP адрес внешнего сервера Exchange. Поставьте галочку «Создать связанный указатель» (Create associated pointer (PTR)). Нажмите «Добавить».
- Нажмите ОК в диалоговом окне, информирующем о том, что операция прошла успешно.
- Нажмите Готово в диалоге «Новый Хост».
Зона isaexternal.com должна выглядеть, как показано на рисунке ниже после добавления двух записей. Остальные записи создаются аналогично.
Помните, что записи надо создавать только для тех ресурсов, доступ к которым нужен как изнутри, так и снаружи.
Регистрация открытого домена у регистратора или провайдера динамического DNS
Теперь все готово к регистрации домена.
После регистрации домена у вашего регистратора появится WEB страница по крайней мере с двумя IP адресами. Если у вас есть собственные DNS сервера, введите IP адреса на внешнем интерфейсе брандмауэра ISA, которые будут использоваться правилами публикации серверов для организации внешнего доступа к сегменту DMZ.
Если используются средства провайдера или услуги выделенного DNS, скорее всего Ваш провайдер сам зарегистрирует Ваш домен или сообщит правильные адреса DNS серверов внешней части разделенной инфраструктуры.
При использовании DDNS все что нужно, это зарегистрировать домен у провайдера DDNS и установить клиентское ПО на любую машину внутренней сети, использующей брандмауэр ISA в качестве шлюза по умолчанию. Клиентское ПО автоматически определит внешний IP адрес внешнего интерфейса брандмауэра ISA, назначенный сервером DHCP провайдера. Заметьте, будет необходимо создать определения протокола (Protocol Definitions) и Правила доступа (Access Rules) для поддержки работы клиентского ПО. На сайтах провайдеров услуг DDNS обычно достаточно информации по этому поводу.
Ключ к успешной настройке внешней части разделенной инфраструктуры — указать те же имена серверов, что и для внутренней части, но с открытыми адресами.
После регистрации DNS серверов открытой части разделенной инфраструктуры необходимо сделать соответствующие записи. В обсуждаемом сценарии можно создать следующие записи:
owa.isaexternal.com A 2.2.2.1
rpc.isaexternal.com A 2.2.2.2
eas.isaexternal.com A 2.2.2.2
oma.isaexternal.com A 2.2.2.2
pop.isaexternal.com A 2.2.2.2
imap.isaexternal.com A 2.2.2.2
smtp.isaexternal.com A 2.2.2.2
ns1.isaexteranl.com A 2.2.2.1
ns2.isaexternal.com A 2.2.2.2
Пара замечаний:
- OWA имеет отличный от остальных IP адрес. Это для того, чтобы обеспечить аутентификацию на (почему, см. выше).
- Обратите внимание на записи для ns1.isaexternal.com и ns2.isaexternal.com. они требуются только в случае использования собственных DNS серверов для создания разделенной инфраструктуры.
Создание двух правил публикации серверов (в случае использования собственных DNS серверов для создания разделенной инфраструктуры)
Если планируется использование собственных DNS серверов для создания разделенной инфраструктуры, необходимо создать два правила публикации серверов с использованием 2 IP адресов на внешнем интерфейсе брандмауэра ISA. Крайне рекомендуется расположить эти два DNS сервера в DMZ зоне анонимного доступа. Хосты этой зоны не должны иметь никакого доступа к внутренним сетям. Также не должно быть никаких первичных исходящих соединений из этой зоны. Единственным исходящим трафиком из этой зоны (по крайней мере, от DNS серверов) должен быть ответный трафик на запросы DNS, сделанные по правилам публикации DNS серверов.
Обратите особое внимание на настройку этих серверов. Несколько настроек имеют большое значение для защиты внешней части разделенной инфраструктуры:
-
Настройте DNS на защиту от засорения КЭШа (настроено по умолчанию в серверах Windows Server 2003)
Запретите рекурсию на серверах. Не нужно, чтобы эти сервера разрешали имена хостов в других доменах.
- Отключите динамическое обновление для этих зон. Не следует позволять захватчикам использовать такое преимущество.
- Отключите перенос зон с сервера DNS. Это можно сделать в диалоге Свойства закладки «Переносы зон» (Zone Transfers)
- Включите только порт UDP 53 для правил публикации DNS серверов. Это предотвратит попытки переноса зон с открытого DNS сервера, так как перенос зоны будет содержать слишком много записей, чтобы уместиться в одну датаграмму UDP.
Применив такие настройки DNS Вы значительно снизите риск потенциальной угрозы атак на DNS сервера.
Заключение
В статье рассмотрены принципы разделенной инфраструктуры DNS и вопросы ее использования с запрещенными именами доменов верхнего уровня. Дополнительно эти принципы можно использовать для обеспечения прозрачности доступа к ресурсам через альтернативное имя домена даже при использовании разрешенного имени домена первого уровня для Службы каталогов внутренней сети.