Split dns что это
Тем не менее, в контексте Exchange Server нас будет интересовать немного другой сценарий, о котором читайте ниже.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Пример элемента управления выборочного рекурсии DNS
Ниже приведен пример использования политики DNS для выполнения ранее описанного сценария выборочного рекурсии DNS.
Этот раздел содержит следующие подразделы.
В примере развертывания с разделением DNS один и тот же DNS-сервер отвечает как на внешние, так и на внутренние клиенты и предоставляет им разные ответы.
Для некоторых развертываний DNS может потребоваться тот же DNS-сервер для выполнения рекурсивного разрешения имен для внутренних клиентов в дополнение к роли доверенного сервера имен для внешних клиентов. Это обстоятельство называется элементом управления выборочной рекурсией DNS.
В предыдущих версиях Windows Server включение рекурсии означало, что она была включена на всем DNS-сервере для всех зон. Так как DNS-сервер также прослушивает внешние запросы, рекурсия включена как для внутренних, так и для внешних клиентов, что делает DNS-сервер открытым сопоставителя.
DNS-сервер, настроенный в качестве открытого сопоставителя, может быть уязвим к исчерпанию ресурсов и может злоупотреблять вредоносными клиентами для создания атак отражения.
На следующем рисунке показан этот сценарий.
Альтернативы
Немного слов о других реализациях, которые позволят развернуть Split DNS на едином устройстве/сервере.
Наверняка, есть и другие реализации, которые позволят настроить сервер DNS с разделяемыми ответами для одних и тех же зон.
Архив номеров / 2007 / Выпуск №5 (54) / Split DNS: заставим BIND работать на два фронта!
Яков Коваленко
Split DNS: заставим BIND работать на два фронта!
Вы системный администратор организации, которая использует много внешних адресов и свои DNS-серверы? У вас единое адресное пространство для внешних и внутренних серверов? Вы используете разные DNS-серверы для внутренней и внешней сети? Не стоит так усложнять себе жизнь. Есть способ заставить BIND работать на два фронта!
BIND – DNS-сервер для UNIX. Для воплощения в жизнь информации из этой статьи вам потребуются знания UNIX и BIND на уровне продвинутого пользования.
Что такое Split DNS-конфигурация? Конфигурация BIND, позволяющая использовать различные настройки DNS в зависимости от адреса источника запроса.
Получается, что внутренние компьютеры и внешние серверы объединены общим именным пространством. Это, на первый взгляд, очень удобно при администрировании, но несет в себе дополнительные трудозатраты при администрировании, проблемы с безопасностью и дополнительные финансовые затраты.
Я знаю несколько системных администраторов, которые покупали и настраивали совершенно отдельные DNS-серверы, один для интернет-сервисов, другой для внутренних сервисов. Схема их сети была такой, как на рис. 1. Как видим – DNS разделен на внутренние серверы, которые обеспечивают разрешение имен внутренних сервисов, кэшируют запросы, разрешают имена и делают прочую полезную работу.
Рисунок 1. Модель обычной расстановки DNS-серверов без использования Split DNS
Вполне логичная и безопасная схема, но экономически не эффективна и усложнена для администрирования.
Давайте попробуем разобраться, каким образом, используя всего одну пару DNS-серверов, отдавать в Интернет только то, что положено – www-сервер с внешним адресом, DNS-сервер, почтовые серверы, а внутренним клиентам – адреса внутренних серверов и клиентских компьютеров, так называемое «затененное пространство имен», которое показывать в Интернете минимум опасно.
Расщепление пространства имен. Виды
Примечание: все доменные имена и IP-адреса вымышлены, совпадения случайны.
21600 ; refresh (6 hours)
1200 ; retry (20 minutes)
86400 ; expire (1 day)
432000 ; minimum (5 days)
www IN A 194.0.1.1
ns1 IN A 194.0.1.3
ns2 IN A 194.0.1.4
mx1 IN A 194.0.1.3
mx2 IN A 194.0.1.4
21600 ; refresh (6 hours)
1200 ; retry (20 minutes)
86400 ; expire (1 day)
432000 ; minimum (5 days)
www IN A 192.168.1.1
ns1 IN A 192.168.1.3
ns2 IN A 192.168.1.4
mx1 IN A 192.168.1.3
mx2 IN A 192.168.1.4
dev IN A 192.168.1.10
gate IN A 192.168.1.11
filesrv IN A 192.168.1.12
dhcp IN A 192.168.1.13
bender IN A 192.168.1.20
panikovsky IN A 192.168.1.21
funt IN A 192.168.1.22
shura IN A 192.168.1.23
Итак, мы создали 2 разных файла для зоны, теперь осталось научить BIND отдавать информацию из этих файлов дифференцированно. Зоны обратного отображения тоже должны быть разными.
Для начала разберемся с конфигурацией наших DNS-серверов.
У нас 2 сервера, master и slave. Ns1 и ns2 соответственно. Они по совместительству являются почтовыми серверами, ничто им не мешает заниматься еще и почтой.
В каждом сервере по два сетевых интерфейса. Один имеет внешний IP-адрес (194.0.1.3 для ns1 и 194.0.1.4 для ns2), второй интерфейс имеет адрес из внутренней сети (192.168.1.3 и 192.168.1.4 соответственно).
О конфигурации с одним интерфейсом с внутренним адресом (например, если у вас DMZ) будет сказано в конце статьи.
В BIND 9 есть замечательная возможность создавать Views (виды). В одном View мы расположим зону для Интернета, а в другом – зону для внутренней сети. Назовем их external и internal.
Файл конфигурации named.conf для master-сервера:
// Создадим ACL, в котором укажем, что внутренние адреса – подсеть 192.168.1
// Объявляем вид – internal зоны для внутренней сети
// Этот вид разрешено просматривать только внутренним клиентам
// Обозначим slave-сервер. Только ему разрешим скачивать зону
// Наш сервер рекурсивен для внутренних клиентов, сам будет узнавать адрес для клиента
zone "hornsandhooves.ru" in
zone "1.168.192.in-addr.arpa" in
zone "localhost" IN
zone "0.0.127.in-addr.arpa" IN
// Объявляем вид для внешних запросов
// К этому виду имеют доступ все
// Наш сервер не рекурсивен для Интернета
// Укажем внешний адрес slave-сервера
zone "hornsandhooves.ru" in
zone "1.0.194.in-addr.arpa" in
// Файл можно сгенерировать командой rndc-confgen -a -c /etc/rndc.key
Теперь давайте разберемся со slave-сервером.
Я не буду рассказывать, зачем нужен slave-сервер, но расскажу, как нужно его настроить специальным образом, для того чтобы он правильно синхронизировал зоны.
Специальная настройка заключается в указании серверу, с какого интерфейса надо запрашивать каждый вид. Делается это для того, чтобы сервер не перепутал виды и не скачал внутреннюю зону во внешний View.
Конфигурационный файл named.conf для slave-сервера:
query-source address 192.168.1.4 port 43303;
// Здесь мы как раз указываем, с какого интерфейса запрашиваем передачу зоны.
// В данном случае – с внутреннего, так как на внутреннем виде, на мастере,
// трансфер разрешен для внутреннего интерфейса
zone "hornsandhooves.ru" in
zone "localhost" IN
zone "0.0.127.in-addr.arpa" IN
zone "1.168.192.in-addr.arpa" in
query-source address 194.0.1.4 port 43303;
// Здесь мы указываем, что забираем зону с внешнего интерфейса –
// только для него на мастере внешняя зона отдается
zone "hornsandhooves.ru" in
zone "1.0.194.in-addr.arpa" in
Что получилось в результате?
На рис. 2 схематично представлено, что примерно должно получиться.
Рисунок 2. Модель расстановки DNS-серверов при использовании Split DNS
В результате мы добились экономической эффективности, легкости в администрировании, надежности и безопасности.
Во-первых, вместо четырех серверов у нас всего два.
Во-вторых, изменения нужно вносить только в master-сервер, на slave будут корректно синхронизироваться зоны.
В-третьих, у нас два сервера, полностью взаимозаменяющие друг друга. Если даже один из них сломается, второй полностью возьмет на себя его функцию.
В-четвертых, адреса внутренних ресурсов не видны, так как ограничен просмотр видов и четко определен slave-сервер, которому разрешается скачивать зону.
Такая схема вполне подойдет для малых и средних компаний. На внешних серверах нужно соответствующим образом настроить врапперы и внутренние брандмауэры, дабы усложнить взломщикам жизнь.
Крупным компаниям рекомендуется использовать DMZ для интернет-серверов. С DMZ схема будет немного другая, так как не будет внешнего и внутреннего интерфейса, будет всего один.
Конфигурация с DMZ
Если ваши серверы находятся в DMZ, то у них используются только внутренние DMZ-IP-адреса, которые DMZ-маршрутизатором транслируются во внешние. Как решить проблему скачивания зон на slave-сервере?
Очень просто – поднимите дополнительный интерфейс на slave-сервере (можно alias, например eth0:1) и укажите его как transfer-source для одного из видов. На master-сервере для выбранного вида поставьте разрешение на скачивание, а для второго вида поставьте отказ в доступе. Делается это через acl.
Здесь 192.168.1.5 – дополнительный интерфейс, которым мы будем скачивать external view. Ему не разрешено скачивать internal view (перед адресом стоит восклицательный знак).
Вот такое решение.
Если отбросить UNIX и BIND составляющую прочитанной вами статьи, кстати, спасибо, что дочитали, то информацию можно применить к любому DNS-серверу на любой платформе.
Комментарии и предложения, а также просьбы о разъяснениях непонятных вам деталей, принимаются на электронную почту.
Здравствуйте. у меня к вам такой вопрос (немного туповатый) но если я хочу использовать DNS только в локальной сети без віхода в интернет то мне надо регить доменное имя или я могу использовать любое ?
Любое использовать не стоит, могут быть проблемы. Обычно используется домен local, т.е. компьютеры будут называться vasya.local, petya.local и т.д. Регистрировать ничего не нада.
Сергей, привет -) Я понимаю год почти прошел с твоего письма. Да и статья уже 9 лет назад как вышла. Пиши если вопрос вдруг еще актуален :)
Добавление записей в области зоны
Следующим шагом является добавление записей, представляющих узел веб-сервера, в две области зоны — внешние и по умолчанию (для внутренних клиентов).
Записи (как в области внутренней зоны по умолчанию, так и в области внешней зоны) будут автоматически реплицироваться по домену с соответствующими областями зоны.
Для добавления записей в области зоны на DNS-сервере можно использовать следующую команду.
Параметр –ZoneScope не включается при добавлении записи в область зоны по умолчанию. Это действие аналогично добавлению записей в обычную зону.
Дополнительные сведения см. в разделе Add-DnsServerResourceRecord.
Проверка
Настройки завершены. Чтобы убедиться в их корректности, первым делом, проверяем конфигурационный файл командой:
* команда должна вернуть пустую строку.
После проверяем корректность настройки зон:
Команда должна вернуть что-то на подобие:
Теперь можно перезапустить сервер DNS.
а) CentOS / Red Hat:
systemctl restart named
б) Ubuntu / Debian:
systemctl restart bind9
Переходим на клиентский компьютер в первом сетевом сегменте (192.168.0.0/24). Для проверки работы нашего сервера вводим команду (на Linux или Windows клиенте):
Мы должны увидеть IP из нашей зоны во view internal-01:
Переходим на другой компьютер в сетевом сегменте 192.168.1.0/24. Вводим:
В моем случае был получен уже другой ответ:
Выполняем команду с компьютера вне диапазонов 192.168.0.0/24 или 192.168.1.0/24:
Мы настроили Split DNS на Linux сервере с Bind.
Теория
В Exchange Server почти для каждого виртуального каталога вы можете задать два имени — отдельно для внутренних и внешних клиентов. Например:
Если клиент обращается из локальной сети, то он это должен делать по адресу в InternalUrl. Если из интернета, то через ExternalUrl. Это «расщепление» путей накладывает ряд неудобств, связанных не только с использованием разных имен для одного объекта.
Примечание: например если раньше в сертификаты публичных ЦС можно было засунуть имена локальных доменов, то с осени 2015 года это сделать нельзя — лавочку прикрыли (и правильно).
Пример Split-Brain DNS в Active Directory
Сайт имеет две версии, одну для внутренних пользователей, где доступны внутренние публикации заданий. Этот внутренний сайт доступен по локальному IP-адресу 10.0.0.39.
Вторая версия — это общедоступная версия того же сайта, которая доступна по общедоступному IP-адресу 65.55.39.10.
В отсутствие политики DNS администратор должен разместить эти две зоны на отдельных DNS-серверах Windows и управлять ими отдельно.
Теперь с помощью политик DNS эти зоны можно разместить на том же DNS-сервере.
Администратор DNS настраивает интерфейсы DNS-сервера со следующими IP-адресами.
- Сетевой адаптер с выходом в Интернет настраивается с общедоступным IP-адресом 208.84.0.53 для внешних запросов.
- Сетевой адаптер для интрасети настраивается с частным IP-адресом 10.0.0.56 для внутренних запросов.
На следующем рисунке показан этот сценарий.
Создание политик DNS
После определения интерфейсов сервера для внешней сети и внутренней сети и создания областей зоны необходимо создать политики DNS, которые подключают внутренние и внешние области зоны.
В этом примере интерфейс сервера используется в качестве критериев для различения внутренних и внешних клиентов. Другим способом различения внешних и внутренних клиентов является использование клиентских подсетей в качестве критериев. Если вы можете определить подсети, к которым принадлежат внутренние клиенты, можно настроить политику DNS для различения на основе подсети клиента. Сведения о настройке управления трафиком с помощью условий подсети клиента см. в статье Использование политики DNS для управления трафиком на основе Geo-Location с основными серверами.
Когда DNS-сервер получает запрос в частном интерфейсе, ответ запроса DNS возвращается из внутренней области зоны.
Для сопоставления области зоны по умолчанию не требуются политики.
В следующем примере команды 10.0.0.56 является IP-адресом частного сетевого интерфейса, как показано на предыдущем рисунке.
Exchange Server и Split DNS
В статье планирую рассказать не только про реализацию Split DNS, но и про изменения на Exchange Server, которые вам предстоит сделать после.
Создание политик DNS
Определив серверные интерфейсы для внешней сети и внутренней сети и создав области зоны, необходимо создать политики DNS, которые подключают внутренние и внешние области зоны.
В этом примере в качестве критериев для различения внутренних и внешних клиентов используется интерфейс сервера (параметр -ServerInterface в приведенной ниже команде). Другим способом отличия внешних и внутренних клиентов является использование клиентских подсетей в качестве критериев. Если можно определить подсети, к которым принадлежат внутренние клиенты, можно настроить политику DNS для различения на основе подсети клиента. Сведения о настройке управления трафиком с помощью условий подсети клиента см. в статье "Использование политики DNS для управления трафиком на основе Geo-Location с основными серверами".
После настройки политик при получении ЗАПРОСА DNS в общедоступном интерфейсе ответ возвращается из внешней области зоны.
Для сопоставления области внутренней зоны по умолчанию не требуются политики.
208.84.0.53 — это IP-адрес общедоступного сетевого интерфейса.
Теперь DNS-сервер настраивается с необходимыми политиками DNS для сервера имен с разделенным мозгом с интегрированной зоной DNS Active Directory.
Вы можете создать тысячи политик DNS в соответствии с требованиями к управлению трафиком, и все новые политики применяются динамически без перезапуска DNS-сервера в входящих запросах.
Создание областей зоны
Область зоны — это уникальный экземпляр зоны. Зона DNS может иметь несколько областей зоны с каждой областью, содержащей собственный набор записей DNS. Одна и та же запись может присутствовать в нескольких областях с разными IP-адресами или одинаковыми IP-адресами.
Так как вы добавляете эту новую область зоны в интегрированную зону Active Directory, область зоны и записи внутри нее будут реплицироваться через Active Directory на другие серверы реплики в домене.
Для создания области зоны на DNS-сервере можно использовать следующую команду.
Дополнительные сведения см. в разделе Add-DnsServerZoneScope.
Особенности настройки
Мы создали конфигурацию для нашего сервера DNS. Давайте попробуем разобраться, какие три нюанса нужно учитывать.
1. Any должен быть внизу.
Наши блоки view читаются системой сверху вниз. Если сервер DNS при поиске нужной зоны натыкается на подходящий вариант, он использует его. Таким образом, если view с match-clients < "any"; >; поместить в самый верх, будет использоваться только этот блок, а другие так и не задействуются.
2. Настройка зон внутри view.
Внутри view мы можем описывать зоны по-разному. Это могут быть различные настройки или разное количество зон, например, для одного из представлений мы можем создать только одну зону, когда в остальных их может быть больше. Другими словами, view не обязаны зеркалировать друг друга.
3. Вне view не должно быть зон.
Как только мы начали применять view, вне этих блоков не должно быть ни одной зоны. Мы не можем сделать общие настройки для одних зон, а другие поместить внутрь представлений. В противном случае, bind при попытке перезапуска выдаст ошибку.
Настройка политики DNS для Split-Brain DNS в Active Directory
Чтобы настроить развертывание Split-Brain DNS с помощью политики DNS, необходимо использовать следующие разделы, в которых приведены подробные инструкции по настройке.
Добавление записей в области зоны
Следующим шагом является добавление записей, представляющих узел веб-сервера, в две области зоны — внутренние и стандартные (для внешних клиентов).
Параметр –ZoneScope не указан в следующих примерах команд при добавлении записи в область зоны по умолчанию. Это похоже на добавление записей в зону ванили.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"
Дополнительные сведения см. в разделе Add-DnsServerResourceRecord.
Настройка элемента управления выборочной рекурсии DNS
Чтобы настроить управление выборочным рекурсией DNS с помощью политики DNS, необходимо выполнить следующие действия.
Создание областей рекурсии DNS
Области рекурсии — это уникальные экземпляры группы параметров, управляющих рекурсией на DNS-сервере. Область рекурсии содержит список переадресаторов и указывает, включена ли рекурсия. DNS-сервер может иметь множество областей рекурсии.
Устаревший параметр рекурсии и список переадресаторов называются областью рекурсии по умолчанию. Невозможно добавить или удалить область рекурсии по умолчанию, определяемую точкой имени (".").
В этом примере параметр рекурсии по умолчанию отключен, а новая область рекурсии для внутренних клиентов создается, где включена рекурсия.
Дополнительные сведения см. в разделе Add-DnsServerRecursionScope
Создание политик рекурсии DNS
Вы можете создать политики рекурсии DNS-сервера, чтобы выбрать область рекурсии для набора запросов, соответствующих определенным критериям.
Если DNS-сервер не является заслуживающим доверия для некоторых запросов, политики рекурсии DNS-сервера позволяют управлять разрешением запросов.
В этом примере внутренняя область рекурсии с включенной рекурсией связана с частным сетевым интерфейсом.
Для настройки политик рекурсии DNS можно использовать следующую команду.
Теперь DNS-сервер настраивается с необходимыми политиками DNS для сервера имен с разделением мозга или DNS-сервера с выборочным элементом управления рекурсией, включенным для внутренних клиентов.
Вы можете создать тысячи политик DNS в соответствии с требованиями к управлению трафиком, и все новые политики применяются динамически без перезапуска DNS-сервера в входящих запросах.
Этот раздел можно использовать для использования возможностей управления трафиком политик DNS для развертываний с разделением мозга с интегрированными зонами DNS Active Directory в Windows Server 2016.
В Windows Server 2016 поддержка политик DNS распространяется на интегрированные зоны DNS Active Directory. Интеграция Active Directory предоставляет возможности высокого уровня доступности с несколькими основными серверами.
Ранее этот сценарий требовал, чтобы администраторы DNS поддерживали два разных DNS-сервера, каждый из которых предоставляет службы для каждого набора пользователей, внутренних и внешних. Если только несколько записей внутри зоны были разделены мозгом или оба экземпляра зоны (внутренние и внешние) были делегированы одному родительскому домену, это стало загадкой управления.
- При наличии двух версий одной зоны, одной версии для внутренних пользователей в интрасети организации и одной версии для внешних пользователей , которые обычно являются пользователями в Интернете.
- В разделе "Использование политики DNS для Split-Brain развертывании DNS" объясняется, как использовать политики DNS и области зоны для развертывания системы DNS с разделенным мозгом на одном Windows Server 2016 DNS-сервере.
Создание зон
а) CentOS / Red Hat:
б) Ubuntu / Debian:
* если мы еще не создавали зоны, то создаем данные каталоги.
Теперь можно создавать сами файлы для зон.
а) CentOS / Red Hat:
б) Ubuntu / Debian:
Пример файла с минимально необходимым набором записей:
@ IN A 192.168.0.20
ns1 IN A 192.168.0.2
Создаем описание для зоны в следующем view.
а) CentOS / Red Hat:
б) Ubuntu / Debian:
@ IN A 192.168.1.20
ns1 IN A 192.168.1.2
* файл для зоны во view «internal-02». Он будет возвращать IP для записи 192.168.1.20. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 192.168.1.2.
Наконец, создаем последний файл.
а) CentOS / Red Hat:
б) Ubuntu / Debian:
@ IN A 92.53.123.166
ns1 IN A 92.53.123.165
* файл для зоны во view «external». Он будет возвращать IP для записи 92.53.123.166. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 92.53.123.165.
Настройка развертывания Split-Brain DNS
Чтобы настроить развертывание DNS Split-Brain с помощью политики DNS, выполните следующие действия.
В следующих разделах приведены подробные инструкции по настройке.
В следующих разделах приведены примеры Windows PowerShell команд, содержащих примеры значений для многих параметров. Перед выполнением этих команд замените примеры значений на значения, подходящие для развертывания.
Добавление интегрированной зоны Active Directory
Дополнительные сведения см. в разделе Add-DnsServerPrimaryZone.
Принцип работы политики DNS для Split-Brain DNS в Active Directory
Если DNS-сервер настроен с необходимыми политиками DNS, каждый запрос разрешения имен оценивается по политикам на DNS-сервере.
В этом примере интерфейс сервера используется в качестве критериев для различия между внутренними и внешними клиентами.
Если серверный интерфейс, по которому получен запрос, соответствует любой из политик, связанная область зоны используется для ответа на запрос.
Настройка Bind
Первым делом настроим view. Открываем конфигурационный файл. В зависимости от типа операционной системы, его местоположение будет разным.
а) в CentOS / Red Hat:
б) в Ubuntu / Debian:
* в вашей инфраструктуре для описания зон могут использоваться другие файлы. Стоит это учитывать при настройке view.
Пример конфигурации для зон в 3-х представлениях — 2 внутренние сети и все остальные:
- .
- acl "internal-01" ;
- acl "internal-02" ;
- view "internal-01"
- match-clients < "internal-01"; >;
- zone "dmosk.ru" IN
- type master;
- file "master/dmosk.ru.in01";
- >;
- >;
- view "internal-02"
- match-clients < "internal-02"; >;
- zone "dmosk.ru" IN
- type master;
- file "master/dmosk.ru.in02";
- allow-transfer < 192.168.1.15; >;
- >;
- >;
- view "external"
- match-clients < "any"; >;
- zone "dmosk.ru" IN
- type master;
- file "master/dmosk.ru.any";
- >;
- >;
* для удобства восприятия, разные блоки конфигурации отмечены разными цветами. Рассмотрим их подробнее:
- 2, 3 — создаем 2 acl, в которых описываем подсети наших внутренних сетей. После мы их будем использовать для определения доступа к view.
- 5 - 12 — наш первый view для первой внутренней сети. В опции match-clients мы должны перечислить acl, для клиентов которой нужно отдавать записи зон, входящих в данный view.
- 14 - 22— view для второй внутренней сети. Обратите внимание, что здесь мы указали другие acl, файл с настройками зоны. Также для данной зоны мы разрешили трансфер на адрес 192.168.1.15.
- 24 - 31 — последняя view для всех остальных клиентов (как правило, из сети Интернет).
Создание областей зоны
Область зоны — это уникальный экземпляр зоны. Зона DNS может иметь несколько областей зоны, при этом каждая область зоны содержит собственный набор записей DNS. Одинаковая запись может присутствовать в нескольких областях с разными IP-адресами или одинаковыми IP-адресами.
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"
Дополнительные сведения см. в разделе Add-DnsServerZoneScope
Частые ошибки
Вторая ошибка — недостаточная проработка вопроса и подготовка к изменениями. Как следствие — юзеры, бегающие в панике с криками о неработающей почте. Изменения виртуальных каталогов, SCP и Outlook Anywhere являются достаточно серьезными, чтобы вот так сразу все менять посередине рабочего дня. Продумайте все изменения заранее и протестируйте на лабе. Технические работы проводите в выходные дни. Если не уверены, то почитайте первые шаги сразу после установки Exchange 5 , они помогут последовательно продиагностировать работоспособность сервиса и освежить в голове логику работы и взаимосвязи всех компонентов.
В этом разделе вы узнаете, как настроить политику DNS в Windows Server® 2016 для развертываний DNS с разделением мозга, где существует две версии одной зоны — одна для внутренних пользователей в интрасети организации, а другая — для внешних пользователей, которые обычно являются пользователями в Интернете.
Сведения об использовании политики DNS для развертывания DNS с разделением мозга с интегрированными зонами DNS Active Directory см. в статье "Использование политики DNS для Split-Brain DNS в Active Directory".
Ранее этот сценарий требовал, чтобы администраторы DNS поддерживали два разных DNS-сервера, каждый из которых предоставляет службы для каждого набора пользователей, внутренних и внешних. Если только несколько записей внутри зоны были разделены мозгом или оба экземпляра зоны (внутренние и внешние) были делегированы одному родительскому домену, это стало загадкой управления.
Другой сценарий конфигурации для развертывания с разделением мозга — выборочное управление рекурсией для разрешения DNS-имен. В некоторых случаях ожидается, что Enterprise DNS-серверы будут выполнять рекурсивное разрешение через Интернет для внутренних пользователей, а также должны выступать в качестве полномочных серверов имен для внешних пользователей и блокировать рекурсию для них.
В этом разделе содержатся следующие подразделы.
Принцип работы элемента управления выборочной рекурсией DNS
Поскольку эти запросы не попадают под ни одну зону, политики уровня зоны (как определено в примере с разделением мозга) не оцениваются.
DNS-сервер оценивает политики рекурсии, а запросы, полученные в частном интерфейсе, соответствуют SplitBrainRecursionPolicy. Эта политика указывает на область рекурсии, в которой включена рекурсия.
Если запрос получен во внешнем интерфейсе, политики DNS не совпадают и применяется параметр рекурсии по умолчанию, который в данном случае отключен.
Это не позволяет серверу выступать в качестве открытого сопоставителя для внешних клиентов, хотя он выступает в качестве сопоставителя кэширования для внутренних клиентов.
Пример развертывания Split-Brain DNS
Ниже приведен пример того, как можно использовать политику DNS для выполнения ранее описанного сценария dns с разделением мозга.
Этот раздел содержит следующие подразделы.
Сайт имеет две версии, одну для внутренних пользователей, где доступны внутренние публикации заданий. Этот внутренний сайт доступен по локальному IP-адресу 10.0.0.39.
Вторая версия — это общедоступная версия того же сайта, доступная по общедоступному IP-адресу 65.55.39.10.
В отсутствие политики DNS администратор должен разместить эти две зоны на отдельных DNS-серверах Windows и управлять ими отдельно.
Теперь с помощью политик DNS эти зоны можно разместить на том же DNS-сервере.
На следующем рисунке показан этот сценарий.
Настройка DNS
К этому моменту вы уже должны были определиться с доменными именами, которые у вас будут использоваться. В моем случае это:
Далее на любом КД открывайте оснастку DNS и приступайте к созданию зон прямого просмотра. Все настройки оставляйте по умолчанию, а в имени зоны вписывайте fqdn. Например:
Далее в каждой зоне создайте А-запись с пустым именем и адресом вашего сервера Exchange (если серверов несколько, создавайте записи для каждого, у вас получится DNS RR):
Далее запустите nslookup и попробуйте разрешить записи со стороны клиентов, чтобы убедиться в корректности работы.
Принцип работы развертывания Split-Brain DNS
Если DNS-сервер настроен с необходимыми политиками DNS, каждый запрос на разрешение имен вычисляется по политикам на DNS-сервере.
В этом примере интерфейс сервера используется в качестве критериев для различения внутренних и внешних клиентов.
Если интерфейс сервера, по которому получен запрос, соответствует любой из политик, связанная область зоны используется для ответа на запрос.
Высокий уровень доступности политик
Политики DNS не интегрированы в Active Directory. Из-за этого политики DNS не реплицируются на другие DNS-серверы, на которых размещена та же интегрированная зона Active Directory.
Политики DNS хранятся на локальном DNS-сервере. Политики DNS можно легко экспортировать с одного сервера на другой с помощью следующих Windows PowerShell команд.
Дополнительные сведения см. в следующих Windows PowerShell справочных разделах.
Настройка Exchange
На этом этапе крайне желательно, чтобы у вас на серверах Exchange уже был установлен сертификат со всеми нужными именами.
Примечание: если ваш сертификат получен с локального ЦС, то возможно вам понадобится предварительно распространить его по всем клиентам. Сделать это можно через GPO, а как именно, читайте в статье Сертификат Exchange 2013.
Виртуальные каталоги
Итак, начнем настраивать Exchange с изменения виртуальных каталогов. Для каждого каталога существует собственный набор командлетов, поэтому получается немного громоздко:
Если есть желание изменить каталоги вручную, можно это сделать в EAC — Серверы — Виртуальные каталоги. Изменить домен внешнего доступа можно, нажав на соответствующую кнопку:
Примечание: несмотря на доступность веб-интерфейса для администрирования, я рекомендую выполнять все команды в EMS. Это быстрее, легче документируется, проще дебажится.
Для Autodiscover имена должны быть пустыми 1 .
Если вдруг появились вопросы, настоятельно рекомендую обратиться к официальной документации 2 .
Обратите особое внимание на Mapi 3 , ведь протокол может не использоваться в вашей инфраструктуре, поскольку он появился только в Exchange Server 2013 SP1 4 и если вы мигрировали с 2010 версии, то по умолчанию он не будет активирован. Настройка Mapi — это отдельная тема, которую я не планирую рассматривать в рамках этой статьи.
Изменения виртуальных каталогов вступят в силу не сразу. Можете форсировать процесс перезапуском IIS.
Следующий этап — настройка SCP. Многие забывают про этот момент, хотя он очень важен для доменных клиентов внутри локальной сети, ведь они первым делом ломятся именно к SCP. Изменим SCP командой:
Все просто, идем дальше.
Outlook Anywhere
На этом настройки завершены, на клиентской стороне как минимум потребуется перезапустить Outlook.
Читайте также: