Split dns что это

Настройка Split DNS на одном сервере Bind

Опубликовано: 05.12.2020

Используемые термины: DNS, Bind, CentOS, Ubuntu. В двух словах, Split DNS (или split-horizon, или split-brain) — это конфигурация, позволяющая отдавать разные записи зон DNS в зависимости от подсети источника запроса. Ее можно реализовать с применением нескольких разных серверов DNS, однако, Bind позволяет сделать нужную нам настройку на одном единственном сервере с помощью view. В данной инструкции мы рассмотрим пример настройки зоны dmosk.ru в 3-х направлениях. Команды будут применимы для Linux CentOS (Red Hat) и Ubuntu (Debian).

Настройка Bind

Первым делом настроим view. Открываем конфигурационный файл. В зависимости от типа операционной системы, его местоположение будет разным. а) в CentOS / Red Hat:

vi /etc/named.conf
б) в Ubuntu / Debian:
vi /etc/bind/named.conf.default-zones

* в вашей инфраструктуре для описания зон могут использоваться другие файлы. Стоит это учитывать при настройке view. Пример конфигурации для зон в 3-х представлениях — 2 внутренние сети и все остальные:

1. .
2. acl «internal-01» ;
3. acl «internal-02» ;
4. view «internal-01»
5. match-clients < "internal-01"; >;
6. zone «dmosk.ru» IN
7. type master;
8. file «master/dmosk.ru.in01»;
9. >;
10. >;
11. view «internal-02»
12. match-clients < "internal-02"; >;
13. zone «dmosk.ru» IN
14. type master;
15. file «master/dmosk.ru.in02»;
16. allow-transfer < 192.168.1.15; >;
17. >;
18. >;
19. view «external»
20. match-clients < "any"; >;
21. zone «dmosk.ru» IN
22. type master;
23. file «master/dmosk.ru.any»;
24. >;
25. >;

* для удобства восприятия, разные блоки конфигурации отмечены разными цветами. Рассмотрим их подробнее:

• 2, 3 — создаем 2 acl, в которых описываем подсети наших внутренних сетей. После мы их будем использовать для определения доступа к view.
• 5 — 12 — наш первый view для первой внутренней сети. В опции match-clients мы должны перечислить acl, для клиентов которой нужно отдавать записи зон, входящих в данный view.
• 14 — 22— view для второй внутренней сети. Обратите внимание, что здесь мы указали другие acl, файл с настройками зоны. Также для данной зоны мы разрешили трансфер на адрес 192.168.1.15.
• 24 — 31 — последняя view для всех остальных клиентов (как правило, из сети Интернет).

Особенности настройки

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

1. Any должен быть внизу.

Наши блоки view читаются системой сверху вниз. Если сервер DNS при поиске нужной зоны натыкается на подходящий вариант, он использует его. Таким образом, если view с match-clients < "any"; >; поместить в самый верх, будет использоваться только этот блок, а другие так и не задействуются.

2. Настройка зон внутри view.

Внутри view мы можем описывать зоны по-разному. Это могут быть различные настройки или разное количество зон, например, для одного из представлений мы можем создать только одну зону, когда в остальных их может быть больше. Другими словами, view не обязаны зеркалировать друг друга.

3. Вне view не должно быть зон.

Как только мы начали применять view, вне этих блоков не должно быть ни одной зоны. Мы не можем сделать общие настройки для одних зон, а другие поместить внутрь представлений. В противном случае, bind при попытке перезапуска выдаст ошибку.

Создание зон

В нашей конфигурации мы описали зону dmosk.ru в трех view. Соответственно, нам нужно создать 3 файла. В зависимости от типа операционной системы, их местоположение будет различаться.

а) CentOS / Red Hat:

б) Ubuntu / Debian:

* если мы еще не создавали зоны, то создаем данные каталоги.

Теперь можно создавать сами файлы для зон.

а) CentOS / Red Hat:

б) Ubuntu / Debian:

Пример файла с минимально необходимым набором записей:

dmosk.ru. IN SOA ns1.dmosk.ru. admin.dmosk.ru. (
2020120401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)

IN NS ns1.dmosk.ru.

@ IN A 192.168.0.20
ns1 IN A 192.168.0.2

* это файл для зоны dmosk.ru во view «internal-01». Он будет возвращать IP для записи 192.168.0.20. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 192.168.0.2.

Создаем описание для зоны в следующем view.

а) CentOS / Red Hat:

б) Ubuntu / Debian:

dmosk.ru. IN SOA ns1.dmosk.ru. admin.dmosk.ru. (
2020120401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)

IN NS ns1.dmosk.ru.

@ 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:

dmosk.ru. IN SOA ns1.dmosk.ru. admin.dmosk.ru. (
2020120401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)

IN NS ns1.dmosk.ru.

@ 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.

Проверка

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

* команда должна вернуть пустую строку.

После проверяем корректность настройки зон:

Команда должна вернуть что-то на подобие:

zone dmosk.ru/IN: loaded serial 2020120401
zone dmosk.ru/IN: loaded serial 2020120401
zone dmosk.ru/IN: loaded serial 2020120401

* в данном примере для зоны dmosk.ru проверены все файлы. Они корректны.

Теперь можно перезапустить сервер DNS.

а) CentOS / Red Hat:

systemctl restart named

б) Ubuntu / Debian:

systemctl restart bind9

Переходим на клиентский компьютер в первом сетевом сегменте (192.168.0.0/24). Для проверки работы нашего сервера вводим команду (на Linux или Windows клиенте):

nslookup dmosk.ru 192.168.0.2

Мы должны увидеть IP из нашей зоны во view internal-01:

Server: 192.168.0.2
Address: 192.168.0.2#53

Name: dmosk.ru
Address: 192.168.0.20

Переходим на другой компьютер в сетевом сегменте 192.168.1.0/24. Вводим:

nslookup dmosk.ru 192.168.1.2

В моем случае был получен уже другой ответ:

Server: 192.168.1.2
Address: 192.168.1.2#53

Name: dmosk.ru
Address: 192.168.1.20

Выполняем команду с компьютера вне диапазонов 192.168.0.0/24 или 192.168.1.0/24:

nslookup dmosk.ru 92.53.123.165

Server: 92.53.123.165
Address: 92.53.123.165#53

Name: dmosk.ru
Address: 92.53.123.166

Мы настроили Split DNS на Linux сервере с Bind.

Альтернативы

Немного слов о других реализациях, которые позволят развернуть Split DNS на едином устройстве/сервере.

• DNS сервер на Microsoft Windows Server 2016. Позволяет использовать ZoneScope для разделения ответов для одной и той же зоны в зависимости от источника запроса.
• Mac OS X Server. Но это тот же Bind.
• На роутерах Mikrotik (с версии прошивки 6.47).

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

Читайте также

Вам могут быть полезны следующие инструкции про DNS:

Mikrotik Split DNS

Есть у меня удаленный офис, к которому мой домашний MikroTik подключен постоянным VPN каналом. Это удобно, можно получать доступ к любому серверу, компьютеру или любому другому ресурсу удаленного офиса непосредственно со своего домашнего компьютера, ноутбука и планшета без дополнительных настроек или установки дополнительных программ, главное, чтобы они были подключены к домашней сети. Из неудобств было ходить на удаленные компьютеры по IP адресу, но в прошивке 6.47 в работе сервиса DNS роутера были добавлены новые функции, одна из них Split DNS или Forward Zone, данная функция позволяет перенаправлять DNS запросы клиента для определенной зоны на нужный сервер, в моем случае это DNS сервер удаленного офиса.

Настраивается в терминале одну команду:

/ip dns static add type=FWD forward-to=192.168.55.2 regexp=".*office\\.local"

• 192.168.55.2 — адрес DNS сервера удаленного офиса.
• office.local — просматриваемая зона.

Обратите внимание что в вводимой команде используется регулярное выражение!

Для проверки вводим в командной строке домашнего компьютера имя нужного сервера:

c:\>nslookup srvmain.office.local

Если все настроено верно, то в ответ получим что-то в виде:

╤хЁтхЁ: UnKnown Address: 172.16.1.1 Не заслуживающий доверия ответ: ╚ь : srvmain.office.local Address: 192.168.55.7

Теперь можно в RDP клиенте и других программах для доступа к удаленному серверу можно использовать DNS имя.

Записки IT специалиста

Настраиваем двойной горизонт DNS (Split DNS) на роутерах Mikrotik

• Автор: Уваров А.С.
• 22.02.2023

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Важно! В роутерах Mikrotik DNS over HTTPS (DoH) имеет приоритет над встроенным DNS-сервером и при его включении ничего из описанного ниже работать не будет!

Итак, двойной горизонт DNS, что это такое и для чего нужно? Давайте представим себе простую ситуацию, во внутренней сети у нас есть сервер, который одновременно доступен снаружи по публичному доменному имени. И есть мобильные клиенты, которые могут подключаться к этому серверу как снаружи, так и внутри периметра. Так как имя сервера разрешается во внешний IP-адрес, то для нормальной работы внутри периметра обычно настраивается Hairpin NAT, который позволяет обеспечить правильное прохождение пакетов от клиента к серверу вне зависимости от его расположения.

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

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

Как реализовать это в роутерах Mikrotik? Переходим в IP — DNS — Static и добавляем запись типа A в которой указываем внешнее доменное имя сервера и его внутренний адрес.

Либо выполните в терминале:

/ip dns static
add address=192.168.100.10 name=srv.example.com

Это самый простой вариант системы с двойным горизонтом, но Mikrotik позволяет реализовывать и более сложные схемы, связанные с пересылкой запросов к разным доменам на разные DNS-сервера.

Допустим у нас есть локальный домен interface31.lab, который обслуживает DNS-сервер 192.168.72.8, и мы хотим все запросы к адресам локального домена направлять ему, а остальное — вышестоящим DNS-серверам (публичным или провайдерским).

Снова переходим в IP — DNS — Static и добавляем запись типа FWD со следующим содержимым:

В терминале это можно сделать следующей командой:

/ip dns static
add forward-to=192.168.72.8 regexp=".*\\.interface31\\.lab\$" type=FWD

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

А как быть, если нам нужно перенаправить запрос только к единственному доменному имени? Просто впишите его в поле Name:

Команда для терминала:

/ip dns static
add forward-to=192.168.72.8 name=srv.example.com type=FWD

Стоп, скажет внимательный читатель, а чем это отличается от A-записи, которую мы добавляли в начале статьи? По сути ничем, но позволяет реализовать централизованный подход к управлению пространством имен. Если вы решили изменить внутренний IP-адрес для узла srv.example.com, то это нужно будет сделать на единственном вышестоящем сервере. В противном случае вам придется изменять настройки на каждом из роутеров.

Теперь о приоритетах. Любая A-запись имеет больший приоритет, чем FWD. Любая запись с использованием регулярных выражений имеет приоритет над записью с простым указанием имени. Т.е. сначала обрабатываются A-записи с Regexp, потом A c Name, потом FWD с Regexp и уже после них FWD с Name. Учитывайте это при создании записей.

Это же позволяет исключить отдельные имена из перенаправления по регулярному выражению — просто создайте для них A-записи.

Надеемся это материал окажется вам полезен и позволит в полной мере раскрыть все возможности вашего роутера Mikrotik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Mikrotik

1. Оборудование MikroTik класса SOHO. Общий обзор и сравнение возможностей
2. Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование
3. Базовая настройка роутера MikroTik
4. Расширенная настройка DNS и DHCP в роутерах Mikrotik
5. Автоматическое резервное копирование настроек Mikrotik на FTP
6. Проброс портов и Hairpin NAT в роутерах Mikrotik
7. Настройка IPTV в роутерах Mikrotik на примере Ростелеком
8. Настройка VPN-подключения в роутерах Mikrotik
9. Настройка черного и белого списков в роутерах Mikrotik
10. Настройка выборочного доступа к сайтам через VPN на роутерах Mikrotik
11. Настройка OpenVPN-сервера на роутерах Mikrotik
12. Безопасный режим в Mikrotik или как всегда оставаться на связи
13. Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik
14. Настраиваем Port Knocking в Mikrotik
15. Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
16. Настраиваем родительский контроль на роутерах Mikrotik
17. Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
18. Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа
19. Mikrotik CHR — виртуальный облачный роутер
20. Настройка контроллера CAPsMAN (бесшовный Wi-Fi роуминг) на Mikrotik
21. Настройка VPN-подключения на роутерах Mikrotik если подсети клиента и офиса совпадают
22. Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
23. Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik
24. Установка Mikrotik CHR на виртуальную машину Proxmox
25. Защита RDP от перебора паролей при помощи оборудования Mikrotik
26. Настройка SSTP VPN-сервера на роутерах Mikrotik
27. Настройка выборочного доступа к сайтам через VPN с автоматическим получением маршрутов по BGP на роутерах Mikrotik
28. Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов
29. Настройка туннелей GRE и IPIP на роутерах Mikrotik
30. Правильное использование Fast Path и FastTrack в Mikrotik
31. DHCP Snooping — настройка защиты от неавторизованных DHCP-серверов на оборудовании Mikrotik
32. Работа оборудования Mikrotik в режиме беспроводной станции (клиента)
33. Используем режим ARP reply-only для повышения безопасности сети на оборудовании Mikrotik

The Dude

1. The Dude. Установка и быстрое начало работы
2. Централизованное управление обновлением RouterOS при помощи The Dude
3. Централизованный сбор логов Mikrotik на сервер The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Exchange Server и Split DNS

Split DNS, также известный в терминологии Microsoft как Split-Brain DNS, используется для реализации выдачи разных DNS-ответов в зависимости от расположения клиента. В классическом виде это делает один и тот же сервер DNS, анализируя с какой подсети пришел запрос и на основе существующих политик возвращает определенный ответ. На общеизвестном сервере Bind это делается путем создания разных представлений (Views) и сопоставления их со списками доступа (ACL). В Windows Server этот функционал ранее отсутствовал и появился только с выходом версии 2016.

Тем не менее, в контексте Exchange Server нас будет интересовать немного другой сценарий, о котором читайте ниже.

Хочется задать вопросы или поделиться знаниями? Приходи в наш закрытый Telegram-чат.

Exchange Server и Split DNS

В статье планирую рассказать не только про реализацию Split DNS, но и про изменения на Exchange Server, которые вам предстоит сделать после.

Теория

В Exchange Server почти для каждого виртуального каталога вы можете задать два имени – отдельно для внутренних и внешних клиентов. Например:

[PS] C:\Windows\system32>Get-OwaVirtualDirectory | fl *ternalUrl
InternalUrl : https://exch01.bq.local/owa
ExternalUrl : https://owa.bq-srv.ru/owa

Зону bq.local обслуживает ваш внутренний сервер DNS, чаще всего контроллер домена. Зону bq-srv.ru – DNS-сервер третьей стороны, вероятно ваш регистратор.

Если клиент обращается из локальной сети, то он это должен делать по адресу в InternalUrl. Если из интернета, то через ExternalUrl. Это “расщепление” путей накладывает ряд неудобств, связанных не только с использованием разных имен для одного объекта.

Примечание: например если раньше в сертификаты публичных ЦС можно было засунуть имена локальных доменов, то с осени 2015 года это сделать нельзя – лавочку прикрыли (и правильно).

Чтобы обойти проблему, можно использовать одну хитрость – создать на вашем внутреннем сервере DNS записи зоны bq-srv.ru и сделать так, чтобы они разрешались во внутренние имена серверов Exchange. В таком случае клиенты что внутри сети, что снаружи смогут обращаться по одинаковому URL. Публичные имена зоны bq-srv.ru будут обслуживать все те же внешние серверы DNS, а ваши записи будут актуальны только для клиентов внутри периметра локальной сети.

Настройка DNS

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

• autodiscover.bq-srv.ru
• mail.bq-srv.ru

Далее на любом КД открывайте оснастку DNS и приступайте к созданию зон прямого просмотра. Все настройки оставляйте по умолчанию, а в имени зоны вписывайте fqdn. Например:

Примечание: да, я не ошибся, надо вписывать именно домен третьего уровня, но не bq-srv.ru. Почему, я рассажу в последней главе.

Далее в каждой зоне создайте А-запись с пустым именем и адресом вашего сервера Exchange (если серверов несколько, создавайте записи для каждого, у вас получится DNS RR):

Далее запустите nslookup и попробуйте разрешить записи со стороны клиентов, чтобы убедиться в корректности работы.

Настройка Exchange

На этом этапе крайне желательно, чтобы у вас на серверах Exchange уже был установлен сертификат со всеми нужными именами.

Примечание: если ваш сертификат получен с локального ЦС, то возможно вам понадобится предварительно распространить его по всем клиентам. Сделать это можно через GPO, а как именно, читайте в статье Сертификат Exchange 2013.

Виртуальные каталоги

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

PowerShell

Get-EcpVirtualDirectory | Set -EcpVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/ecp’ -InternalUrl ‘https://mail.bq-srv.ru/ecp’

Get-OwaVirtualDirectory | Set -OwaVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/owa’ -InternalUrl ‘https://mail.bq-srv.ru/owa’

Get-WebServicesVirtualDirectory | Set -WebServicesVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/EWS/Exchange.asmx’ -InternalUrl ‘https://mail.bq-srv.ru/EWS/Exchange.asmx’

Get-ActiveSyncVirtualDirectory | Set -ActiveSyncVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/Microsoft-Server-ActiveSync’ -InternalUrl ‘https://mail.bq-srv.ru/Microsoft-Server-ActiveSync’

Get-OabVirtualDirectory | Set -OabVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/OAB’ -InternalUrl ‘https://mail.bq-srv.ru/OAB’

Get-PowerShellVirtualDirectory | Set -PowerShellVirtualDirectory -ExternalUrl ‘http://mail.bq-srv.ru/powershell’ -InternalUrl ‘http://mail.bq-srv.ru/powershell’

Get-MapiVirtualDirectory | Set -MapiVirtualDirectory -ExternalUrl ‘https://mail.bq-srv.ru/mapi’ -InternalUrl ‘https://mail.bq-srv.ru/mapi’

Если есть желание изменить каталоги вручную, можно это сделать в EAC – Серверы – Виртуальные каталоги. Изменить домен внешнего доступа можно, нажав на соответствующую кнопку:

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

Для Autodiscover имена должны быть пустыми 1 .

Если вдруг появились вопросы, настоятельно рекомендую обратиться к официальной документации 2 .

Обратите особое внимание на Mapi 3 , ведь протокол может не использоваться в вашей инфраструктуре, поскольку он появился только в Exchange Server 2013 SP1 4 и если вы мигрировали с 2010 версии, то по умолчанию он не будет активирован. Настройка Mapi – это отдельная тема, которую я не планирую рассматривать в рамках этой статьи.

Изменения виртуальных каталогов вступят в силу не сразу. Можете форсировать процесс перезапуском IIS.

SCP

Следующий этап – настройка SCP. Многие забывают про этот момент, хотя он очень важен для доменных клиентов внутри локальной сети, ведь они первым делом ломятся именно к SCP. Изменим SCP командой:

PowerShell

Get-ClientAccessService | Set -ClientAccessService -AutoDiscoverServiceInternalUri ‘https://mail.bq-srv.ru/Autodiscover/Autodiscover.xml’

Все просто, идем дальше.

Outlook Anywhere

Остался последний штрих – настройка Outlook Anywhere. Протокол (RPC over HTTP) позволяет клиентам Outlook подключаться к Exchange, находясь за пределами периметра локальной сети. Задать домены для подключения можно командой, но только с дополнительными настройками безопасности и аутентификации:

PowerShell

Get-OutlookAnywhere | Set -OutlookAnywhere -ExternalHostname ‘mail.bq-srv.ru’ -ExternalClientsRequireSsl $true -ExternalClientAuthenticationMethod Negotiate -InternalHostname ‘mail.bq-srv.ru’ -InternalClientsRequireSsl $false

На этом настройки завершены, на клиентской стороне как минимум потребуется перезапустить Outlook.

Частые ошибки

Первая и главная ошибка – чаще всего админы создают DNS-зоны с доменом второго уровня, а уже внутри их плодят записи autodiscover.bq-srv.ru, mail.bq-srv.ru и т.п.. Это будет работать, но не забывайте, что при обращении к любым доменам третьего уровня ваши серверы DNS (они же КД) будут считать себя авторитативными, то есть, ответственными за эту зону. Чем это чревато? Если вы обратитесь к записи внешнего корпоративного ресурса, например, careers.bq-srv.ru и её не окажется на ваших КД, то на сайт вы не попадете. Другими словами – если эта зона в оригинале хостите на внешних серверах DNS, то вам придется дублировать все её записи на КД и поддерживать их в актуальном состоянии. Оно вам надо?

Вторая ошибка – недостаточная проработка вопроса и подготовка к изменениями. Как следствие – юзеры, бегающие в панике с криками о неработающей почте. Изменения виртуальных каталогов, SCP и Outlook Anywhere являются достаточно серьезными, чтобы вот так сразу все менять посередине рабочего дня. Продумайте все изменения заранее и протестируйте на лабе. Технические работы проводите в выходные дни. Если не уверены, то почитайте первые шаги сразу после установки Exchange 5 , они помогут последовательно продиагностировать работоспособность сервиса и освежить в голове логику работы и взаимосвязи всех компонентов.

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.

1. Busting The Set-AutodiscoverVirtualDirectory Myth↩
2. View or configure Outlook Web App virtual directories↩
3. Configure MAPI over HTTP in Exchange Server↩
4. MAPI over HTTP↩
5. Exchange Server post-installation tasks↩