Зоны-заглушки DNS в Windows Server 2003
Зоны-заглушки — это новая функция DNS в Windows Server 2003, которую можно использовать для упрощения разрешения имен, особенно в сценарии с разделенным пространством имен. Они также помогают уменьшить объем DNS-трафика в вашей сети, повышая эффективность DNS, особенно на медленных каналах глобальной сети. В этой статье будет подробно рассмотрено, что такое зоны-заглушки, как они работают и когда их использовать. Я также покажу вам процесс создания зоны-заглушки, чтобы упростить поиск имен между двумя отдельными лесами. Но сначала необходимо немного узнать о зонах DNS, чтобы увидеть, как зоны-заглушки вписываются в общую картину.
Типы DNS-зон
Зона — это непрерывная часть пространства имен DNS, управляемая одним или несколькими серверами имен. Зоны содержат ресурсные записи, которые определяют имя полномочного DNS-сервера для зоны (запись SOA), имена и IP-адреса всех серверов имен в зоне (записи NS), имена и IP-адреса других хостов (записи A)., псевдонимы для хостов (записи CNAME) и так далее.
В исходной реализации DNS, найденной в RFC 1034 и 1035, были определены два разных типа зон:
- Первичные зоны, которые хранят информацию о своей зоне в доступном для записи текстовом файле на сервере имен.
- Вторичные зоны, которые хранят информацию о своей зоне в текстовом файле, доступном только для чтения, на сервере имен.
При реализации DNS в Windows NT эти два типа зон назывались стандартными зонами. Типичный сценарий для компании, в которой развернут один домен Windows NT, включает в себя настройку двух серверов имен в сети, один из которых содержит стандартную первичную зону ( первичный сервер имен для домена), а другой содержит стандартную вторичную зону (основной сервер имен для домена). вторичный сервер имен ). Всякий раз, когда в сеть добавлялся новый хост (например, файловый сервер), оба этих сервера имен должны были обновляться, чтобы клиенты могли найти новый хост с помощью DNS. Для этого администратор должен создать новую запись A на первичном сервере имен, поскольку можно изменить только первичную зону. Затем первичный сервер имен уведомлял вторичный сервер об изменении его записей, а вторичный сервер извлекал обновленную информацию о зоне из первичного, пока не получил идентичную копию первичной зоны. С точки зрения вторичного сервера имен первичный сервер имен представляет собой главный сервер имен для этой зоны.
Основная проблема с этим расположением заключалась в том, что если первичный сервер имен вышел из строя, в записи ресурсов нельзя было внести никаких изменений, поскольку вторичные серверы имен содержали информацию о зоне, доступную только для чтения. Кроме того, это означало, что все изменения, которые вы вносили в DNS, должны были выполняться на одном сервере имен (основном), что могло быть неудобно, если компания располагалась в нескольких местах.
Windows 2000 предоставила решение этих проблем, представив интегрированные зоны Active Directory, которые хранили информацию о своих зонах в Active Directory, а не в текстовых файлах. Преимущества этого нового типа зоны заключаются в использовании репликации Active Directory для переноса зоны и возможности добавления или изменения записей ресурсов на любом контроллере домена, на котором работает DNS. Другими словами, все зоны, интегрированные с Active Directory, всегда являются первичными зонами, поскольку они содержат доступные для записи копии базы данных зоны.
Интегрированные зоны Active Directory хорошо работают в большинстве сетей на базе Windows 2000, но у них есть некоторые проблемы. Одним из ограничений является то, что вы имеете дело с двумя отдельными лесами (несоединенными пространствами имен), что является распространенным сценарием, когда компании сливаются или образуют часть конгломерата. Например, предположим, что компания А имеет тесные деловые связи с компанией Б, а сотрудникам компании А нужен доступ к ресурсам во внутренней сети компании Б. Обычный способ предоставления им этого доступа — администратор DNS компании А должен добавить стандартную вторичную зону на каждый из серверов имен компании А. Затем эти вторичные зоны будут указывать на серверы имен в сети компании B в качестве своих главных серверов имен и будут получать свои записи ресурсов путем передачи зон с серверами имен компании B. Хотя это работает, это излишне по нескольким причинам. Во-первых, он генерирует большой трафик передачи зон между серверами имен в компании A и компании B, что может создать проблему, если компании связаны друг с другом медленным подключением к глобальной сети. Во-вторых, если компания B решит вывести из эксплуатации один из своих серверов имен, не сообщив об этом администратору компании A, некоторые из вторичных зон на серверах имен компании A могут внезапно оказаться без главного, и после истечения срока действия их записей клиенты компании A, которые используют они больше не смогут получить доступ к ресурсам в компании B.
Что делают тупиковые зоны
Введите тупиковые зоны на помощь. Зона-заглушка похожа на вторичную зону в том смысле, что она получает свои записи ресурсов от других серверов имен (одного или нескольких главных серверов имен). Зона-заглушка также доступна только для чтения, как и дополнительная зона, поэтому администраторы не могут вручную добавлять, удалять или изменять записи ресурсов в ней. Но на этом различия заканчиваются, так как зоны-заглушки существенно отличаются от вторичных зон в нескольких существенных аспектах.
Во-первых, в то время как вторичные зоны содержат копии всех записей ресурсов в соответствующей зоне на главном сервере имен, зоны-заглушки содержат только три типа записей ресурсов:
- Копия записи SOA для зоны.
- Копии записей NS для всех серверов имен, уполномоченных для зоны.
- Копии записей A для всех серверов имен, уполномоченных для зоны.
Вот и все — никаких записей CNAME, записей MX, записей SRV или записей A для других хостов в зоне. Таким образом, в то время как вторичная зона может быть довольно большой для сети крупной компании, зона-заглушка всегда очень мала, всего несколько записей. Это означает, что репликация информации о зоне из главной зоны в зону-заглушку практически не добавляет DNS-трафик в вашу сеть, поскольку записи для серверов имен редко изменяются, если только вы не выведете из эксплуатации старый сервер имен или не развернете новый. Кроме того, в то время как большинство DNS-серверов можно настроить для предотвращения передачи зон во вторичные зоны, зоны-заглушки запрашивают только записи SOA, NS и A для серверов имен, все из которых предоставляются без ограничений любым сервером имен, поскольку эти записи необходимы. для правильной работы разрешения имен. Наконец, поскольку зоны-заглушки могут быть интегрированы в Active Directory (дополнительные зоны не могут), они могут использовать репликацию Active Directory для распространения своей информации на все контроллеры домена в вашей сети.
В нашем предыдущем сценарии вместо вторичных зон можно использовать зоны-заглушки, чтобы уменьшить объем трафика передачи зон по каналу WAN, соединяющему две компании. Для этого администратор компании A просто войдет в систему на одном из контроллеров домена, откроет консоль DNS и создаст новую зону-заглушку, которая использует один или несколько серверов имен компании B в качестве главных серверов имен. Если сделать эту зону-заглушку зоной, интегрированной с Active Directory, то зона-заглушка будет автоматически реплицирована на все другие контроллеры домена в сети компании А. Теперь, когда клиент в сети компании A хочет подключиться к ресурсу в сети компании B, клиент отправляет DNS-запрос ближайшему контроллеру домена компании A, который затем перенаправляет запрос на один из серверов имен компании B для разрешения.
Как создать тупиковую зону
Давайте посмотрим, как это работает на практике. В моей лаборатории настроено два леса: один для компании A, работающей под управлением Windows 2003 Server, и названный test2003.local, а другой — для компании B, работающей под управлением Windows 2000, и названный test2000.local. Контроллер домена для корневого домена компании A называется SRV220, а контроллеры домена для корневого домена компании B — SRV210, SRV211 и SRV212. Салли является сотрудником компании A, и ее настольный компьютер называется DESK231, и ей необходимо получить доступ к общему ресурсу CATALOG, расположенному на SRV210 в компании B. Для этого она нажимает «Пуск», выбирает «Выполнить» и вводит \srv210.test2000.local. catalog и выдает ошибку:
Это связано с тем, что ее команда отправляет DNS-запрос к ее серверу имен SRV220, в базе данных DNS которого нет информации о test2000.local, корневом домене компании B:
Чтобы разрешить пользователям в компании A доступ к ресурсам в компании B, администратор компании A решает создать зону-заглушку для домена компании B. Для этого щелкните правой кнопкой мыши «Зоны прямого просмотра» на рисунке выше и выберите «Новая зона». Это запустит мастер создания новой зоны:
При нажатии кнопки «Далее» открывается экран «Тип зоны», здесь мы выбираем «Зона-заглушка» и устанавливаем флажок, чтобы создать зону-заглушку, интегрированную в Active Directory:
Нажмите «Далее», и отобразится экран «Область репликации зоны Active Directory», который мы оставим по умолчанию для автоматической репликации информации о зоне-заглушке на все контроллеры домена в домене test2003.local.
При нажатии кнопки «Далее» отображается экран «Имя зоны», и здесь мы вводим test2000.local в качестве имени зоны-заглушки, поскольку это имя целевого домена в сети компании B:
При нажатии кнопки «Далее» отображается экран «Основные DNS-серверы», и мы вводим IP-адрес 172.16.11.210 для одного из серверов имен в сети компании B:
Нажатие Далее, а затем Готово запускает мастер и создает новую зону-заглушку, которая здесь выделена в консоли DNS, подключенной к SRV220 в сети компании А:
Обратите внимание на приведенном выше рисунке, что, как и ожидалось, зона-заглушка содержит только запись SOA, запись NS для каждого сервера имен в домене и запись A для каждого сервера имен в домене. Теперь, когда Салли нажимает «Пуск», выбирает «Выполнить» и вводит \srv210.test2000.localcatalog, открывается окно, отображающее содержимое общего ресурса CATALOG на SRV210 в удаленном лесу:
Резюме
Зоны-заглушки легко создать, и они могут повысить эффективность разрешения имен между лесами, но у них есть и другие применения. Например, тупиковые зоны могут позволить серверам имен выполнять рекурсию без необходимости запрашивать корневые серверы имен Интернета или внутренние корпоративные корневые серверы, тем самым уменьшая количество переходов между серверами имен и повышая эффективность разрешения имен. Еще одно применение зон-заглушек — поддерживать актуальность информации о делегированных зонах и не допускать, чтобы неудачные делегирования нарушали разрешение имен в лесу, и это могло бы стать хорошей темой для будущей статьи. Обе эти темы — хорошие темы для будущих статей, так что следите за новостями о тупиковых зонах позже.