Stub zone dns что это
Stub zone dns что это
Служба DNS (Domain Name System) предназначена для преобразования имен узлов в IP-адреса. Для ее функционирования используется два компонента: DNS-клиент и DNS-сервер. В Windows, DNS-клиент является частью стека протоколов TCP/IP и устанавливается автоматически вместе с протоколом. DNS-сервер является отдельной службой, работающей только на серверах.
Основные сведения о DNS.
Прежде чем переходить к планированию, установке и непосредственно управлению DNS-сервером, вы должны познакомиться с основными понятиями и концепциями DNS.
Система доменных имен включает в себя пространство доменных имен, которое описывает древовидную структуру всех доменов. Каждый уровень структуры отделен от вышележащих и нижележащих уровней символом «точка», что позволяет определять местоположение уровня в дереве. Самый верхний уровень является корневым доменом и начинается с точки («.»).
Правила именования доменов.
При планировании пространства имен домена старайтесь придерживаться следующих правил.
DNS-сервер Microsoft поддерживает в доменных именах символы Unicode (согласно RFC 2044). Это позволяет использовать символы национальных алфавитов. Однако прибегнуть к этой возможности можно только в том случае, если все серверы и клиенты вашей сети поддерживают в доменных именах Unicode-символы.
Зоны позволяют разделить пространство имен домена на отдельные управляемые секции, например, чтобы разместить зону на нескольких серверах или распределить его администрирование.
Все DNS-зоны можно разделить на зоны прямого и обратного просмотра. Кроме того, каждая из них может быть одного из следующих типов:
Зона прямого просмотра
Зоны прямого просмотра (forward lookup zone) служат для преобразования доменных имен в IP-адреса. Для работы службы DNS-сервера на Windows Server 2003 необходимо наличие на нем как минимум одной такой зоны.
Зона обратного просмотра
Зоны обратного просмотра (reverse lookup zone) позволяют генерировать обратные запросы на поиск имени по IP-адресу. Эти зоны необязательны для функционирования системы DNS, но нужны для нормальной работы различных диагностических утилит (например, ping, tracert и т. п.). Зоны обратного просмотра регистрируются в домене in-addr.arpa. Поддоменам присваиваются имена, соответствующие IP-адресам сетей, причем порядок октетов в адресе изменяется на противоположный. То есть сети 192.168.0.0 соответствует домен 0.168.192.in-addr.arpa.
Дополнительная зона
Резервная копия существующей зоны. Для создания дополнительной зоны необходим сервер, обслуживающий основную зону. Дополнительные зоны также хранятся в текстовых файлах, но ими нельзя управлять, т. к. они являются автоматическими копиями основной зоны.
Сокращенная зона или зона-заглушка
Эта зона предназначена для упрощения разрешения имен между несколькими пространствами имен. По структуре сокращенная зона подобна дополнительной зоне, но отличается тем, что содержит только записи SOA, NS и записи узла A для сервера имен домена, а не все записи.
Динамическое обновление зоны.
Функция динамического обновления позволяет клиентам вносить изменения в зоны путем посылки определенных запросов DNS-серверу. В Windows динамическое обновление зон необходимо для нормальной работы Active Directory и автоматической регистрации DHCP-хостов в DNS. Динамические обновления должны поддерживаться обслуживающим зону сервером. Согласно стандарту RFC 2136, возможно изменение зоны не только вручную администратором сервера, но и автоматически, приложениями, поддерживающими этот стандарт. DNS-сервер из состава Windows Server 2003 поддерживает функцию Dynamic DNS (DDNS).
;
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 1
;
@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. (
1 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS mcio-08kwa653t4.fio.ru.
;
; Zone records
;
Файл зоны состоит из множества записей, причем одна запись обычно занимает одну строку. Строки, начинающиеся с точки с запятой, являются комментариями и не анализируются DNS-сервером.
Любой файл зоны должен содержать как минимум следующее:
Служба DNS в Windows Server 2003
Новые функции для работы с многодоменными лесами
В статье «Устраняем проблемы DNS», опубликованной в этом же номере, речь идет о том, как построить инфраструктуру DNS для двухдоменного леса Active Directory (AD). В ней отмечается, что, хотя DNS-серверы на базе Windows 2000 успешно работают в многодоменных лесах, некоторых функций в них все же недостает. Этот пробел можно восполнить с помощью DNS-серверов на базе Windows 2003.
В качестве простого примера в статье рассматривается лес с двумя доменами — один из них назван bigfirm.biz, а другой — bigfirm.com. В обоих доменах используется разделенная (split-brain) DNS; они должны взаимно разрешать имена и SRV-записи для поиска контроллеров домена (DC), чтобы системы и пользователи каждого домена могли быть идентифицированы в любом из них. Компания Bigfirm может выбрать один из двух подходов. Можно построить динамические зоны для каждого домена и не интегрировать их с AD. В этом случае администраторы должны проверить все DNS-серверы корпоративной сети и убедиться, что каждый из них является первичным или вторичным сервером как для зоны bigfirm.biz, так и для bigfirm.com.
Альтернативный подход — преобразовать bigfirm.biz и bigfirm.com в зоны, интегрированные с AD. Как правило, интегрированные с AD зоны — более подходящее решение для AD-зон, чем разделенная DNS. Но, к сожалению, DNS-серверы на базе Windows 2000 обмениваются DNS-информацией о зоне только с DC данной зоны. Например, если DNS-зона bigfirm.biz интегрирована с AD, то только DNS-серверы, которые одновременно являются контроллерами домена bigfirm.biz, смогут получить DNS-информацию о bigfirm.biz. Даже если изменить DNS-зону bigfirm.com, интегрировав ее с AD, DNS-серверы bigfirm.com получат информацию только о bigfirm.com, но не о bigfirm.biz, даже если оба домена находятся в одной сети. Чтобы устранить невосприимчивость DNS-серверов на базе Windows 2000 к любой AD-интегрированной информации вне своего домена, следует сделать эти DNS-серверы обычными вторичными серверами для других серверов в лесу.
Предположим, что у компании Bigfirm имеется несколько тысяч хост-машин и несколько десятков DNS-серверов. Каждый из этих DNS-серверов играет роль вторичного сервера по крайней мере в одной зоне. Поэтому каждый раз, когда в зоне происходят изменения, эту информацию приходится пересылать на все вторичные серверы компании, что создает большую нагрузку на каналы связи и процессор. Microsoft DNS не требует пересылки всей зоны при любом незначительном изменении (в отличие от некоторых старых программных решений DNS), но все же процедура пересылки данных зоны способом, описанным в документе RFC (Request for Comments), неэффективна. В случае интеграции с AD пересылка выполняется более эффективным механизмом репликации AD со сжатием трафика репликации между сайтами. В DNS-серверах Windows 2003 появились три усовершенствования по сравнению с Windows 2000: зоны-заглушки (stub zones), условная ретрансляция (conditional forwarding) и зоны, интегрированные с AD в масштабах всего леса.
Зоны-заглушки
Благодаря зонам-заглушкам программы DNS-серверов Windows 2003 формируют зоны, которые отличаются от размещаемых на стандартных первичных и вторичных DNS-серверах. В зонах на стандартных первичных и вторичных DNS-серверах содержится полный экземпляр файла зоны, а в зоне-заглушке хранится лишь минимальный файл зоны. Зона-заглушка вместо всех записей зоны хранит лишь записи Start of Authority (SOA) и Name Server (NS). Другими словами, единственная информация, которую можно получить от DNS-сервера с зоной-заглушкой для данной зоны, — это имена DNS-серверов и сведения о том, какой из них является первичным DNS-сервером зоны. IP-адрес определенной хост-машины в зоне из зоны-заглушки получить нельзя.
Чем может быть полезна зона, которая лишь сообщает, какие серверы являются серверами имен зоны? Предположим, что bigfirm.biz располагает большой зоной, содержащей тысячи записей, и разработчикам домена требуется множество DNS-серверов. Они создали первичный DNS-сервер и группу вторичных DNS-серверов. Но сетевые трассировки показывают, что DNS-серверы тратят больше времени на получение последней информации о зоне от первичного DNS-сервера (и тем самым замедляют работу первичного сервера и нагружают каналы связи), чем на рассылку ответов на запросы. Разработчики сетей должны разместить зону какого-нибудь типа для bigfirm.biz на каждом DNS-сервере сети Bigfirm, но обмен данными между первичными и вторичными серверами приводит к дополнительной трате ресурсов. Выход — в преобразовании некоторых вторичных DNS-серверов в DNS-серверы зоны-заглушки. Если эти DNS-серверы получают запрос относительно bigfirm.biz, то они не дадут ответа, но им известно, на какой сервер нужно направить запрос. Для этого не требуется проходить по всей иерархии DNS-серверов в поисках источника информации о bigfirm.biz. Затем запрашивающий DNS-сервер задает DNS-серверу зоны-заглушки вопрос относительно bigfirm.biz, и сервер зоны-заглушки передает ответ. Кроме того, серверы зоны-заглушки играют роль серверов кэширования (как практически все DNS-серверы), поэтому следующий компьютер, запросивший информацию о bigfirm.biz, получит ответ немедленно, так как сервер с зоной-заглушкой может предоставить ответ на запрос из своего кэша.
Маленькая зона-заглушка быстро обновляется, поэтому не создает серьезной нагрузки на оперативную память и процессор DNS-сервера. Часто простые серверы кэширования (DNS-серверы без зон) размещаются в сети для преобразования имен клиентов, но разделенная DNS требует, чтобы все DNS-серверы содержали экземпляр каждой AD-зоны леса. Применение зон-заглушек — самый простой способ выполнить это требование.
Условная ретрансляция
Как быть, если администраторы Bigfirm не хотят использовать DNS-серверы с зоной-заглушкой? Существует ли способ разместить в сети группу DNS-серверов, не назначая их вторичными серверами для bigfirm.biz и bigfirm.com? Да, поскольку DNS-служба Windows 2003 обеспечивает метод, называемый условной ретрансляцией.
Для стандартной ретрансляции DNS следует настроить конфигурацию DNS-сервера таким образом, чтобы при поступлении запроса, на который он не может ответить, сервер не обращался за ответом в общедоступную сеть Internet. Вместо этого DNS-сервер просит другой DNS-сервер найти ответ. Процедура, в ходе которой один DNS-сервер просит другой DNS-сервер выполнить поиск, называется ретрансляцией. Можно указать два или несколько ретрансляторов, но я приведу простой пример.
Для условной ретрансляции DNS-сервер настраивается таким образом, что при поступлении запроса о конкретном домене (например, bigfirm.biz), на который у сервера нет ответа, он просит другой DNS-сервер (ретранслятор) найти ответ. Следует обратить внимание на различие: стандартная ретрансляция — это передача безответных запросов о любом домене конкретному DNS-серверу, а условная ретрансляция заставляет передавать ретранслятору только запросы о конкретном домене.
Служба DNS Windows 2003 позволяет указать сервер или серверы, которые будут отвечать на запросы о конкретном домене. Поэтому если компания Bigfirm намерена развернуть 10 вторичных DNS-серверов для bigfirm.biz и bigfirm.com и еще 100 DNS-серверов для разрешения внутренних запросов разделенной DNS bigfirm.biz и bigfirm.com, то нужно просто настроить 100 этих серверов на условную ретрансляцию всех запросов bigfirm.biz на 10 вторичных серверов.
Конечно, различия между зонами-заглушками и условной ретрансляцией весьма тонки, но ими нельзя пренебрегать. Например, какой из этих методов автоматически обновляет информацию о зоне? Предположим, что в зону добавлен DNS-сервер. Как информировать сервер зоны-заглушки или сервер с условной ретрансляцией об этом событии? В случае с сервером зоны-заглушки делать ничего не потребуется — новый сервер появится в зоне-заглушке после репликации. Но если используется условная ретрансляция, то необходимо посетить каждый DNS-сервер и изменить список серверов, к которым следует обращаться в поисках записи bigfirm.com. Насколько я понимаю, составить сценарий для такой процедуры нельзя.
Еще одна проблема, возникающая при сравнении зон-заглушек с условной ретрансляцией, связана с полномочиями. Мы предполагаем, что bigfirm.biz и bigfirm.com — единая дружная компания, но что если между подразделениями существует соперничество? В этом случае размещать зоны-заглушки для серверов bigfirm.com на серверах bigfirm.biz можно лишь с разрешения администраторов bigfirm.com. Для того чтобы серверы bigfirm.biz получали при репликации DNS информацию от серверов bigfirm.com, серверы bigfirm.com должны дать согласие на передачу этой информации при пересылке зоны. По умолчанию DNS-серверы Windows 2000 передают данные любому запросившему их серверу. Но находящиеся в зоне DNS-серверы на базе Windows 2003 по умолчанию выполняют пересылки зоны только на серверы, имеющие в этой зоне NS-записи. Поэтому, прежде чем DNS-сервер bigfirm.biz с зоной-заглушкой bigfirm.com сможет обновить информацию о зоне с DNS-сервера bigfirm.com, этот сервер bigfirm.biz должен получить NS-запись в зоне bigfirm.com. Если кто-то захочет настроить свои DNS-серверы на пересылку всех запросов для сайтов microsoft.com на мой DNS-сервер, я не смогу этому помешать. Но вряд ли кто-нибудь сделает это, так как в результате существенно замедлится процесс разрешения имен для данного лица.
Последнее обстоятельство, которое следует учитывать при сравнении зон-заглушек с условной ретрансляцией, заключается в том, что, по данным Microsoft, DNS-сервер заново просматривает таблицы условной ретрансляции при каждом разрешении имен. Поэтому таблица условной ретрансляции любой длины может существенно замедлить процедуру разрешения имен DNS-сервером.
Зоны, интегрированные с AD в масштабах всего леса
Третий метод, с использованием зон, интегрированных с AD в масштабах всего леса, расширяет возможности DNS-зон, интегрированных с AD, по сравнению с Windows 2000. DNS-зоны, интегрированные с AD, тиражируют информацию DNS между DNS-серверами, которые также должны быть контроллерами домена (DC). Но на серверах Windows 2000 интегрированная с AD информация перемещается только внутри домена; DNS-серверы bigfirm.biz не могут видеть интегрированную с AD зону bigfirm.com, а DNS-серверы bigfirm.com не видят интегрированную с AD зону bigfirm.biz.
В Windows 2003 можно создать интегрированные с AD DNS-зоны, которые выполняют репликацию не только во всем домене, но и во всем лесу. Поэтому можно сначала сформировать bigfirm.biz и bigfirm.com, как описано в статье «Устраняем проблемы DNS», со стандартными первичным и вторичным серверами. Затем, после того как будут сформированы домены и лес AD, можно просто изменить несколько параметров и настроить все DNS-серверы bigfirm.biz и bigfirm.com на хранение информации в лесу. Впоследствии процесс репликации AD обеспечит синхронизацию всех DNS-серверов. Естественно, все DC должны работать на Windows 2003 — по крайней мере, на это указывают проведенные мною эксперименты.
Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com
Поделитесь материалом с коллегами и друзьями
Stub zone dns что это
Вопрос
Проконсультируйте пожалуйста, когда необходимо использовать дополнительные зоны DNS, а когда зоны-заглушки. Почему нельзя использовать только дополнительные зоны, ведь получается она содержит все записи и не надо делать лишних действий как в зоне-заглушки, ведь зона-заглушки содержит лишь только информацию о днс-серверах, т.е сначала клиент получит адрес днс-серверов указанных в зоне-заглушке, далее клиент обратиться к одному из серверов за информацией.
Единственный возможный плюс зон-заглушки это то, что они интегрированы в АД и реплицируются.
Ответы
Также посмотрите две статьи как раз по вашему вопросу:
Все ответы
Дополнительная зона
Если зона, хранящаяся на DNS-сервере, является дополнительной, DNS-сервер становится дополнительным источником сведений о зоне. Зона на этом сервере должна быть получена от другого удаленного компьютера DNS-сервера, который также хранит зону. Этот DNS-сервер должен иметь сетевой доступ к удаленному DNS-серверу, который будет обеспечивать этот сервер обновленными данными о зоне. Так как дополнительная зона является копией основной зоной, хранящейся на другом сервере, она не может быть размещена в доменных службах Active Directory.
В некоторый случаях Primary может обозначаться как Master, Secondary и все остальные как Slave зоны\ДНС сервера.
Зона-заглушка получается урезанная Secondary, содержащая ток адреса днс-серверов.
Например: имеется домен west.lan и домен work.local. В домене west.lan мы можем поднять дополнительную зону от work.local, где будут содержаться все записи или можем поднять зону-заглушку, где будут ток указаны записи днс серверов.Так же можно в данном случае настроить условную пересылку. Вот и возникает вопрос по какому сценарию действовать.
я бы сделал или Secondary или Условную пересылку.
Вам вообще для чего это? какая задача поставлена?
Просто возник вопрос в голове, как лучше настраивать в разных ситуациях. Почитал документацию, вроде бы то и то можно, между собой все способы как-то пересекаются, чем-то похожи, а вот именно как правильно настроить не знаю.
Почему зону-заглушку в данном случае не стали бы делать?
Опять же если есть условная пересылка, зачем нужна заглушка. В описании там и там говорится, что позволяют улучшить разрешение имен и т.д. на первый взгляд все схоже.
Также посмотрите две статьи как раз по вашему вопросу:
Извините, конечно за занудство и не понимание, но почему stub-зоны не обладают такой же функциональностью как делегирование?
Вот пример использования зоны-заглушки с https://msdn.microsoft.com/ru-ru/library/cc779197%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
Сценарий использования зоны-заглушки:
Удостоверяющий DNS-сервер для родительской зоны example.com делегировал поддомен widgets.example.com другим DNS-серверам. Вначале при делегировании домена widgets.example.com родительская зона содержала только две записи ресурсов имен (NS) удостоверяющих DNS-серверов для зоны widgets.example.com. Позднее администраторы дочерней зоны осуществили настройку дополнительных DNS-серверов в качестве удостоверяющих серверов для зоны, но не уведомили об этом администраторов DNS-сервера, на котором размещается родительская зона example.com. В результате у DNS-сервера родительской зоны example.com нет сведений о новых удостоверяющих DNS-серверах для дочерней зоны widgets.example.com и он продолжает отправлять запросы только на два удостоверяющих DNS-сервера, сведения о которых у него имеются.
Это можно исправить, настроив на удостоверяющем DNS-сервере для родительской зоны example.com зону-заглушку для делегированного домена widgets.example.com. Когда администратор удостоверяющего DNS-сервера example.com обновляет зону-заглушку, он отправляет на главные серверы зоны-заглушки запрос получения записей ресурсов удостоверяющих DNS-серверов для зоны widgets.example.com. В результате удостоверяющий DNS-сервер для родительской зоны получает данные о новых удостоверяющих DNS-серверах для дочерней зоны widgets.example.com и сможет выполнить рекурсию на все удостоверяющие DNS-серверы для дочерней зоны.
Здесь так же получается иерархическая структура, только в делегировании указаны те записи ns серверов, которые мы сами укажем, а в stub-зоне будут указаны все ns записи серверов.
Прочитал в нескольких книгах главы про DNS, везде отдается плюс stub-зоне, и поэтому осталось недопонимание.
Stub zone dns что это
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Ответы
У Stub Zone есть два основных назначения.
Все ответы
Зона-заглушка (Stub zone) является лишь частичной (неполной) копией существующей зоны. Позволяет «быть в курсе» изменений в IP адресах серверов имён, ответственных за DNS-зону. При делегировании DNS-зоны происходит полная передача полномочий на управление DNS-зоной на DNS сервер(а).
Может быть вопрос был про различия при использовании Stub zone и Conditional Forwarding?
У Stub Zone есть два основных назначения.
Натолкнулся на этот же вопрос, спасибо что уже ответили, но.
Я могу создать делегирование только до того как создам сам домен или зону к нему. Иначе он пишет что така зона уже существует.
Все домены (или поддомены), отображающиеся как часть применимого делегирования зоны, должны быть созданы в текущей зоне до выполнения описанной здесь процедуры делегирования. При необходимости с помощью консоли DNS сначала добавьте домены в зону. Все домены (или поддомены), отображающиеся как часть применимого делегирования зоны, должны быть созданы в текущей зоне до выполнения описанной здесь процедуры делегирования. При необходимости с помощью консоли DNS сначала добавьте домены в зону.
Не моли вы поясить что здесь имеется ввиду? Деиствительно ли нужно создавать новый дочерний домен и зону к нему до того как производится делегирование? Потому как после создания ничего уже делегировать не получается.
И ещё вопрос: каким образом изменения NS серверов обновляются в stub zone, ведь как я понимаю она одна и лежит на родительском сервере? Каким образом новые записи попадают в эту зону, там надо настраивать какие-то перемщения зон?
Вы просто стали жертвой терминологии и ее перевода
Другое дело, что в инфраструктуре Winsows 2000/2003 имена этих доменов совпадают.
Различие зоны DNS и домена DNS. Зона это административная единица обслуживаемая одним DNS сервером, которая включает домен DNS и может включать один или несколько его поддоменов.