Split 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 в Windows Server® 2016 для раздельных развертываний dns, где есть две версии одной зоны — одна для внутренних пользователей в интрасети организации, а другая — для внешних пользователей, которые обычно являются пользователями в интернете.
Сведения о том, как использовать политику DNS для раздельного развертывания DNS с помощью Active Directory интегрированных зоны DNS, см. в статье Использование политики DNS для Split-Brain DNS в Active Directory.
Ранее этот сценарий требовал, чтобы администраторы DNS поддерживали два разных DNS-сервера, каждый из которых предоставляет службы каждому набору пользователей, внутренним и внешним. Если несколько записей в зоне были обделены, или оба экземпляра зоны (внутренние и внешние) были делегированы в один и тот же родительский домен, это стало загадка управления.
Еще один сценарий настройки для развертывания с разделением-мозгом — выборочный контроль рекурсии для разрешения DNS-имен. в некоторых обстоятельствах Enterprise DNS-серверы должны выполнять рекурсивное разрешение для внутренних пользователей, в то время как им также необходимо действовать как полномочные серверы имен для внешних пользователей и блокировать рекурсию для них.
В этом разделе содержатся следующие подразделы.
Пример развертывания Split-Brain DNS
Ниже приведен пример того, как можно использовать политику DNS для выполнения описанного выше сценария «разделение-DNS».
Этот раздел содержит следующие подразделы.
Вторая версия — это общедоступная версия того же сайта, которая доступна по общедоступному IP-адресу 65.55.39.10.
в отсутствие политики DNS администратору необходимо разместить эти две зоны на отдельных DNS-серверах Windows Server и управлять ими отдельно.
С помощью политик DNS эти зоны теперь можно размещать на одном DNS-сервере.
Этот сценарий показан на следующем рисунке.
Как работает развертывание Split-Brain DNS
Если DNS-сервер настроен с использованием требуемых политик DNS, каждый запрос разрешения имен оценивается по политикам на DNS-сервере.
В этом примере интерфейс сервера используется в качестве критерия для различения внутренних и внешних клиентов.
Если серверный интерфейс, на котором получен запрос, соответствует любой из политик, то соответствующая область зоны используется для ответа на запрос.
Настройка развертывания Split-Brain DNS
Чтобы настроить развертывание Split-Brain DNS с помощью политики DNS, необходимо выполнить следующие действия.
В следующих разделах приведены подробные инструкции по настройке.
в следующих разделах приведены примеры Windows PowerShell команд, которые содержат примеры значений для многих параметров. Перед выполнением этих команд обязательно замените примеры значений в этих командах значениями, подходящими для вашего развертывания.
Создание областей зоны
Область зоны — это уникальный экземпляр зоны. Зона DNS может иметь несколько областей зоны, при этом каждая область зоны содержит собственный набор записей DNS. Одна и та же запись может присутствовать в нескольких областях с разными IP-адресами или IP-адресами.
Дополнительные сведения см. в разделе Add-днссерверзонескопе .
Добавление записей в области зоны
Следующим шагом является добавление записей, представляющих узел веб-сервера, в две области зоны — внутренние и по умолчанию (для внешних клиентов).
При добавлении записи в область зоны по умолчанию в следующих примерах команд отсутствует параметр – зонескопе . Это похоже на добавление записей в зону обычный.
Дополнительные сведения см. в разделе Add-днссерверресаурцерекорд.
Создание политик DNS
После определения интерфейсов сервера для внешней сети и внутренней сети, а также для создания областей зоны необходимо создать политики DNS, которые соединяют внутренние и внешние области зоны.
В этом примере серверный интерфейс используется в качестве критерия для различения внутренних и внешних клиентов. Другим способом различения внешних и внутренних клиентов является использование подсетей клиента в качестве критерия. Если вы можете определить подсети, к которым принадлежат внутренние клиенты, можно настроить политику DNS, чтобы отличать их от подсети клиента. Сведения о настройке управления трафиком с помощью критериев подсети клиента см. в статье Использование политики DNS для управления трафиком на основе Geo-Location с серверами-источниками.
Когда DNS-сервер получает запрос к частному интерфейсу, ответ на запрос DNS возвращается из внутренней области зоны.
Для сопоставления области зоны по умолчанию не требуются никакие политики.
В следующем примере команда 10.0.0.56 является IP-адресом частного сетевого интерфейса, как показано на предыдущем рисунке.
Пример управления выборочной рекурсией DNS
Ниже приведен пример того, как можно использовать политику DNS для выполнения описанного выше сценария управления селективной рекурсией DNS.
Этот раздел содержит следующие подразделы.
В примере развертывания DNS Split-мозгового сервера тот же DNS-сервер отвечает как внешним, так и внутренним клиентам и предоставляет им разные ответы.
Некоторые развертывания DNS могут потребовать, чтобы один и тот же DNS-сервер выполнял рекурсивное разрешение имен для внутренних клиентов, помимо того, чтобы выступать в роли полномочного сервера имен для внешних клиентов. Это называется контролем выборочной рекурсии DNS.
в предыдущих версиях Windows Server включение рекурсии означало, что оно было включено на всем DNS-сервере для всех зон. Так как DNS-сервер также прослушивает внешние запросы, рекурсия включается как для внутренних, так и для внешних клиентов, что делает DNS-сервер открытым сопоставительом.
DNS-сервер, настроенный как открытый сопоставитель, может быть уязвим для исчерпания ресурсов и может быть заражен вредоносными клиентами для создания атак с отражением.
Этот сценарий показан на следующем рисунке.
Как работает управление селективной рекурсией DNS
Поскольку эти запросы не попадают ни в одну зону, политики уровня зоны (как определено в примере Split-мозговой области) не оцениваются.
DNS-сервер оценивает политики рекурсии, а запросы, получаемые в частном интерфейсе, соответствуют сплитбраинрекурсионполици. Эта политика указывает на область рекурсии, в которой включена рекурсия.
Если запрос получен на внешнем интерфейсе, политики DNS не совпадают, и параметр рекурсии по умолчанию, который в данном случае отключен , применяется.
Это не позволяет серверу выступать в качестве открытого сопоставителя для внешних клиентов, пока он выступает в качестве сопоставителя кэширования для внутренних клиентов.
Настройка управления выборочной рекурсией DNS
Чтобы настроить управление выборочной рекурсией DNS с помощью политики DNS, необходимо выполнить следующие действия.
Создание областей рекурсии DNS
Области рекурсии являются уникальными экземплярами группы параметров, которые управляют рекурсией на DNS-сервере. Область рекурсии содержит список серверов пересылки и указывает, включена ли рекурсия. DNS-сервер может иметь много областей рекурсии.
Устаревший параметр рекурсии и список серверов пересылки называются областью рекурсии по умолчанию. Невозможно добавить или удалить область рекурсии по умолчанию, определяемую именем Dot (".").
В этом примере параметр рекурсии по умолчанию отключен, а также создается новая область рекурсии для внутренних клиентов, где включена рекурсия.
Дополнительные сведения см. в разделе Add-днссерверрекурсионскопе .
Создание политик рекурсии DNS
Можно создать политики рекурсии DNS-сервера, чтобы выбрать область рекурсии для набора запросов, соответствующих указанным условиям.
Если DNS-сервер не является полномочным для некоторых запросов, политики рекурсии DNS-сервера позволяют управлять способом разрешения запросов.
В этом примере внутренняя область рекурсии с включенной рекурсией связана с частным сетевым интерфейсом.
Для настройки политик рекурсии DNS можно использовать приведенный ниже пример команды.
Теперь DNS-сервер настроен с использованием требуемых политик DNS для сервера доменных имен с разделением или DNS-сервера, для которого включено выборочное управление рекурсией для внутренних клиентов.
Вы можете создавать тысячи политик DNS в соответствии с требованиями к управлению трафиком, а все новые политики применяются динамически, без перезапуска DNS-сервера во входящих запросах.
Тем не менее, в контексте Exchange Server нас будет интересовать немного другой сценарий, о котором читайте ниже.
Exchange Server и Split DNS
В статье планирую рассказать не только про реализацию Split DNS, но и про изменения на Exchange Server, которые вам предстоит сделать после.
Теория
[PS] C:\Windows\system32>Get-OwaVirtualDirectory | fl *ternalUrlНастройка DNS
К этому моменту вы уже должны были определиться с доменными именами, которые у вас будут использоваться. В моем случае это:
Далее на любом КД открывайте оснастку DNS и приступайте к созданию зон прямого просмотра. Все настройки оставляйте по умолчанию, а в имени зоны вписывайте fqdn. Например:
Далее в каждой зоне создайте А-запись с пустым именем и адресом вашего сервера Exchange (если серверов несколько, создавайте записи для каждого, у вас получится DNS RR):
Далее запустите nslookup и попробуйте разрешить записи со стороны клиентов, чтобы убедиться в корректности работы.
Настройка Exchange
На этом этапе крайне желательно, чтобы у вас на серверах Exchange уже был установлен сертификат со всеми нужными именами.
Примечание: если ваш сертификат получен с локального ЦС, то возможно вам понадобится предварительно распространить его по всем клиентам. Сделать это можно через GPO, а как именно, читайте в статье Сертификат Exchange 2013.Виртуальные каталоги
Итак, начнем настраивать Exchange с изменения виртуальных каталогов. Для каждого каталога существует собственный набор командлетов, поэтому получается немного громоздко:
Для Autodiscover имена должны быть пустыми 1 .
Если вдруг появились вопросы, настоятельно рекомендую обратиться к официальной документации 2 .
Изменения виртуальных каталогов вступят в силу не сразу. Можете форсировать процесс перезапуском IIS.
Все просто, идем дальше.
Outlook Anywhere
На этом настройки завершены, на клиентской стороне как минимум потребуется перезапустить Outlook.
Частые ошибки
Чтобы почтовая инфраструктура Exchange функционировала должным образом, корректная конфигурация пространства имен является обязательным атрибутом. В этой статье рассмотрено создание DNS Split зоны, а также настройка URL адресов в веб-каталогах Exchange сервера. Вопросы планирования были рассмотрены в предыдущей статье:
Настройка DNS Split зоны
Задача Split DNS зоны в единообразном представлении сетевых имен узлов (FQDN) во внутренней и внешней сети. Другими словами, например, FQDN autodiscover.ait.in.ua будет доступен в частной и публичной сети, но разрешаться в разные IP адреса.
Чтобы ее создать, потребуется открыть консоль DNS и выбрать создание новой DNS зоны:
Консоль DNS Management
Откроется мастер создания новой DNS зоны:
Создание новой DNS Split зоны
Для DNS Split зоны не требуется дополнительные DNS сервера. Допускается ее создание на DNS серверах контроллеров домена Active Directory. Оставляем тип зоны Primary и место хранения в директории:
Выбор типа DNS Split зоны
Так как DNS зона будет хранится и реплицироваться средствами Active Directory, указываем соответствующие контроллеры домена (в переделах текущего домена или всего леса Active Directory) на которых она будет доступна:
Задание типа репликации DNS Split зоны
Указываем домен под который будет создана DNS Split зона.
Указание имени DNS Split зоны
Динамические обновления зоне не нужны, и их стоит отключить.
Динамические обновления DNS Split зоны
Работа мастера завершена:
Завершение создания DNS Split зоны
Создаем минимум 2 записи A указывающие на IP адрес Exchange сервера. Они будут следующие:
Для высокодоступной схемы Exchange без применения балансировщика сетевой нагрузки, необходимо повторить процес создания записей и для второго сервера Exchange. Это обеспечит работу Round robin DNS.
В случае применения балансировщиков сетевой нагрузки, созданные записи должны указывать на него.
Настройка веб-каталогов Exchange сервера
Читайте также: