Серверы условной пересылки dns для чего
В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.
Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.
Содержание:
(анкеров нет, поэтому содержание без ссылок)
1. Основные сведения
DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:
А — то самое сопоставление символьного имени домена его IP адресу.
АААА — то же что А, но для адресов IPv6.
CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.
MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.
NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.
SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.
SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.
Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.
Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):
Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.
Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.
Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.
В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.
В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.
Итеративный и рекурсивный запросы.
DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.
Клиент обращается к держателю зоны ru с тем же запросом.
DNS яндекса возвращает нужный адрес.
Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.
Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».
Заголовок состоит из следующих полей:
Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.
Флаги — 16-битовое поле, поделенное на 8 частей:
Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.
3. TCP и UDP
Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.
4. DNS в Windows Server 2008 и 2012
В Windows 2008 появились следующие возможности:
Фоновая загрузка зон
- определяются все зоны, которые должны быть загружены;
- из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
- загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
- начинается обработка запросов и удаленных вызовов процедур (RPC);
- создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.
Поскольку задача загрузки зон выполняется отдельными потоками, DNS-сервер может обрабатывать запросы во время загрузки зоны. Если DNS-клиент запрашивает данные для узла в зоне, который уже загружен, DNS-сервер отправляет в ответ данные (или, если это уместно, отрицательный ответ). Если запрос выполняется для узла, который еще не загружен в память, DNS-сервер считывает данные узла из доменных служб Active Directory и обновляет соответствующим образом список записей узла.
Поддержка IPv6-адресов
Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.
Изменения DNS-клиента
Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.
Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.
5. DNS и Active directory
Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.
Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.
SRV записи регистрируемые службой Net Logon:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:
_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;
_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
_kpassword — идентифицирует серверы изменения паролей kerberos в сети;
_gc — запись, относящаяся к функции глобального каталога в Active Directory.
В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.
Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.
DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.
Как происходит процесс поиска DC
Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.
Служба посылает один или несколько запросов с помощью API функции DsGetDcName()
DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.
Все доступные контроллеры доменов отвечают на этот запрос, сообщая о своей работоспособности.
После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.
Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).
Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.
Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)
В этой статье мы рассмотрим два способа организации условного разрешения имен в DNS сервере на Windows Server 2016: DNS conditional forwarding и DNS policy. Эти технологии позволяют настроить условное разрешение DNS имен в зависимости от запрошенного имени, IP адреса и местоположения клиента, времени суток и т.д.
Настройка DNS Conditional Forwarder в Windows Server
- Запустите консоль управления DNS ( dnsmgmt.msc );
- Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
- В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
- В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
- Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
- Выберите правило репликации записи conditional forwarding (All DNS servers in this forest, All DNS servers in this domain или All domain controllers in this domain).
Настройка DNS Conditional Forwarding с помощью PowerShell
Вы можете создать правило Conditional Forward для определенной DNS зоны с помощью PowerShell. Воспользуйтесь командлетом Add-DnsServerConditionalForwarderZone:
Чтобы вывести список DNS Conditional Forwarders на определенном сервере, выполните следующий PowerShell скрипт:
$DNSServer = "DC01"
$Zones = Get-WMIObject -Computer $DNSServer -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Zone"
$Zones | Select-Object Name,MasterServers,DsIntegrated,ZoneType | where | ft -AutoSize
Фильтрация запросов DNS, политики разрешения имен в Windows Server 2016
В Windows Server 2016 появилась новая фича в службе DNS сервера – DNS политики. DNS политики позволяют настроить DNS сервер так, чтобы он возвращал различные ответы на DNS запросы в зависимости от местоположения клиента (с какого IP адреса или подсети пришел запрос), интерфейса DNS сервера, времени суток, типа запрошенной записи (A, CNAME, PTR, MX) и т.д. DNS политики в Windows Server 2016 позволяют реализовать сценарии балансировки нагрузки, фильтрации DNS трафика, возврата DNS записей в зависимости от геолокации (IP адреса клиента) и многие другие сложные сценарии.
Вы можете создать политику как на уровне DNS сервера, так и на уровне всей зоны. Настройка DNS политик в Windows Server 2016 возможна только из командной строки PowerShell.
Я создал 3 подсети для разных офисов компании:
Add-DnsServerClientSubnet -Name "MSK_DNS_Subnet" -IPv4Subnet "192.168.1.0/24"
Add-DnsServerClientSubnet -Name "EKB_DNS_Subnet" -IPv4Subnet "192.168.11.0/24"
Add-DnsServerClientSubnet -Name "SPB_DNS_Subnet" -IPv4Subnet "192.168.21.0/24"
Чтобы вывести список всех IP подсетей клиентов, выполните:
Теперь нужно для каждого офиса создать отдельную DNS область:
Следующие команды добавят 3 DNS записи с одним именем, но указывающие на разные IP адреса в разных областях DNS:
Вы можете вывести все ресурсные DNS записи для области с помощью команды:
Теперь нужно создать DNS политики, которые свяжут IP подсети, DNS области и A записи.
- -Action ALLOW
- -Action DENY
- -Action IGNORE
Можно использовать следующие параметры в фильтре DNS:
-InternetProtocol "EQ,IPv4,NE,IPv6"
-TransportProtocol "EQ,UDP,TCP"
-ServerInterfaceIP "EQ,192.168.1.21"
-QType "EQ,A,AAAA,NE,PTR"
-TimeOfDay "EQ,9:00-18:00"
Вывести список всех DNS политик для DNS зоны на сервере можно так:
Теперь с устройств из различных офисов проверьте, что DNS сервер на один и тот же запрос возвращает различные IP адреса прокси:
Можно запретить DNS серверу возвращать DNS адреса для определенного пространства имен (домена):
Azure AD DS включает DNS-сервер, обеспечивающий разрешение имен для управляемого домена. Этот DNS-сервер содержит встроенные записи DNS и обновления для ключевых компонентов, обеспечивающих функционирование службы.
Если вы используете собственные приложения и службы, вам может потребоваться создать записи DNS для компьютеров, не присоединенных к домену, настроить виртуальные IP-адреса для подсистем балансировки нагрузки или внешние DNS-серверы пересылки. Пользователи, принадлежащие к группе администраторов контроллера домена AAD, получают права администратора DNS в управляемом домене Azure AD DS и могут создавать и изменять пользовательские записи DNS.
В гибридной среде зоны и записи DNS, настроенные в других пространствах имен DNS, например в локальной среде AD DS, не синхронизируются с управляемым доменом. Чтобы разрешить именованные ресурсы в других пространствах имен DNS, создайте и используйте серверы условной пересылки, указывающие на существующие DNS-серверы в вашей среде.
В этой статье показано, как установить средства DNS-сервера, а затем использовать консоль DNS для управления записями и создания серверов условной пересылки в Azure AD DS.
Создание или изменение корневых указаний или серверов пересылки DNS на уровне сервера не поддерживается и приведет к проблемам с управляемым доменом Azure AD DS.
Перед началом
Для работы с этой статьей требуются следующие ресурсы и разрешения:
Установка средств DNS-сервера
Чтобы создать и изменить записи DNS в управляемом домене, необходимо установить средства DNS-сервера. Их можно установить как компонент Windows Server. Подробнее об установке средств администрирования на клиенте Windows см. в статье об установке средств удаленного администрирования сервера (RSAT).
Войдите на виртуальную машину управления. Инструкции по подключению с помощью портала Azure см. в статье Подключение к виртуальной машине Windows Server.
Если диспетчер сервера не открывается по умолчанию при входе в виртуальную машину, откройте меню Пуск, а затем выберите Диспетчер сервера.
На панели управления в окне диспетчера серверов щелкните Добавить роли и компоненты.
На странице Перед началом работы в мастере добавления ролей и компонентов щелкните Далее.
В разделе Тип установки оставьте флажок Установка ролей или компонентов и щелкните Далее.
На странице Роли сервера нажмите кнопку Далее.
На странице Компоненты разверните узел Средства удаленного администрирования сервера, а затем узел Средства администрирования ролей. Из списка средств администрирования ролей выберите компонент Средства DNS-сервера.
На странице Подтверждение щелкните Установить. Установка средств DNS- сервера может занять одну или две минуты.
Когда установка компонента завершится, нажмите кнопку Закрыть, чтобы выйти из мастера добавления ролей и компонентов.
Вызов консоли управления DNS для администрирования DNS
После установки средств DNS-сервера можно приступать к администрированию записей DNS в управляемом домене.
Для администрирования DNS в управляемом домене необходимо войти в учетную запись пользователя, принадлежащую к группе Администраторы контроллера домена AAD.
На начальном экране выберите Администрирование. Отобразится список доступных средств управления, включая DNS, установленные в предыдущем разделе. Выберите DNS, чтобы запустить консоль управления DNS.
Консоль DNS подключится к указанному управляемому домену. Разверните пункт Зоны прямого просмотра или Зоны обратного просмотра, чтобы создать необходимые записи DNS или изменить существующие записи по мере необходимости.
При управлении записями с помощью средств DNS-сервера убедитесь, что встроенные записи DNS, используемые Azure AD DS, не удаляются и не изменяются. Встроенные записи DNS включают в себя записи DNS домена, записи сервера имен и другие записи, используемые для обнаружения контроллера домена. Изменение этих записей приведет к нарушению работы доменных служб в виртуальной сети.
Создание серверов условной пересылки
Зона DNS Azure AD DS должна содержать только зону и записи для самого управляемого домена. Не создавайте дополнительные зоны в управляемом домене для разрешения именованных ресурсов в других пространствах имен DNS. Вместо этого используйте серверы условной пересылки в управляемом домене, чтобы указать DNS-серверу, куда следует обращаться за разрешением адресов этих ресурсов.
Чтобы создать сервер условной пересылки в управляемом домене, выполните следующие действия.
Выберите Серверы условной пересылки, щелкните правой кнопкой мыши и нажмите Создать сервер условной пересылки.
Установите флажок Сохранять условную пересылку в Active Directory и реплицировать ее следующим образом: , а затем выберите параметр Все DNS-серверы в этом домене, как показано в следующем примере:
Если сервер условной пересылки хранится в лесу, а не в домене, его работа будет завершаться ошибкой.
Чтобы создать сервер условной пересылки, нажмите кнопку ОК.
Теперь имена ресурсов в других пространствах имен с виртуальных машин, подключенных к управляемому домену, должны разрешаться правильно. Запросы для домена DNS, настроенного на сервере условной пересылки, передаются соответствующим DNS-серверам.
Дальнейшие действия
Дополнительные сведения об управлении DNS см. в статье о средствах DNS на сайте TechNet.
До сих пор мы рассматривали свойства зон DNS. Настал черед и непосредственно свойствам DNS сервера, и какими возможности по настройки он нам предоставляет. Для этого мы станем на сам сервер (в нашем случае это сервер под именем SERVER 1) и правой кнопкой мыши щелкнем по «Свойства». Откроется окно с вкладками показанное на рисунке 1.
Давайте для начала активируем вкладку "Интерфейсы". По сути на данной вкладке показаны базовые адреса наших сетевых карт. Но правильно считается если мы не говорим конкретно непосредственно о сетевой карте, а рассматриваем сетевую карту в контексте с операционной системой то правильно надо говорить - сетевой интерфейс. Так как любая машина в сети может иметь не одну а несколько сетевых карт, или уже начнем говорить сетевых интерфейсов, то естественно данная вкладка называется "интерфейсы", так как она показывает все наши адреса сетевых карт или сетевые интерфейсы. Как видно из рисунка 1 данный сервер имеет два сетевых интерфейса, а именно в нашем случае это 192.168.0.1 и 192.168.131.66.
На данной вкладке вы всегда получите все ваши сетевые интерфейсы. Если мы прочтем внимательно что там написано то нам станет ясно что запросы DNS будут обслуживается через тот интерфейс который мы укажем. В зависимости от конфигурации нашей сети, мы на данной вкладке можем добавить или убрать сетевые интерфейсы которые мы не хотим, или хотим что бы обслуживал наш DNS сервер.
Если мы выберем опцию "по всем IP адресам" - то обмен информацией с DNS сервером будет происходить именно через все эти сетевые адреса указанные на вкладке.
Если мы выберем опцию "только по указанным IP адресам" - то обмен информацией с DNS сервером будет происходить только через данные сетевые интерфейсы и никак иначе.
Думаю что здесь все понятно.
Перейдем на другую вкладку, а именно на вкладку "Пересылка". О пересылки мы уже говорили (смотри здесь) но остановимся еще раз.
Пересылка и условная пересылка или переадресация.
Внимательно читаем что там написано на самом верху вкладки, (смотрите рисунок 1).
По умолчанию на данной вкладке в поле "Домен DNS", будет только одна запись - Все другие DNS домены. То есть что это значит. Когда клиент DNS делает запрос серверу DNS и тот после поиска разрешения имени в своем кэше а потом в файлах зоны, он посылает запрос на другие DNS серверы, а также пользуется корневыми ссылками. Думаю что пока понятно.
А вот представьте ситуацию когда у нашей фирмы допустим пять деревьев в единственном лесу. А каждое дерево это филиал фирмы в другой географической местности, смотрите рисунок 3. Также каждый домен имеет свое пространство имен, что в принципе видно на рисунке.
Учитывая что между контроллерами домена должна быт репликация, то эти контроллеры домена должны находить друг друга не только в своем домене, а так же и в других доменах. Не нужно так же забывать пользователей которые в командировке в другом филиале, и они должны входить в свой домашний домен, независимо в какой сети фирмы он осуществляет вход.
Что мы в таком случае должны сделать? Как вы догадались - использовать условную пересылку!
Служба DNS Windows Server 2003 позволяет настроить пересылку чувствительно к имени домена. Все перечисленные выше требования нашей фирмы с доменами показанные на рисунке 3, явно подразумевают что информация DNS должна быть общедоступной для всех наших доменов.
В этом случае каждый DNS сервер в каждом домене могут быть сконфигурированы с условной пересылкой, переадресующий запросы на один или более серверов DNS в других доменах. Когда один из серверов DNS разрешает имя из другого домена, он может использовать только ту пересылку (ретранслятор), который сконфигурирован для этого домена.
И еще не забудьте. если вы создали допустим один полномочный DNS сервер, а потом прописали какие - то условные пересылки, то DNS сервер сперва проверить свои зонные файлы, и если он определит что является полномочным сервером для указанных в пересылки доменах, то естественно никаких запросов он посылать не будет.
В некоторых случаях необходим DNS-сервер, использующий только пересылку и не использующий корневые ссылки. Чтобы сконфигурировать такой сервер, выберите опцию "He использовать рекурсию для этого домена" смотрите рисунок 2. Если выбрана данная опция то DNS-сервер сначала будет пытаться разрешить любые запросы с помощью своей местной зонной или кэшированной информации, посылая рекурсивные запросы каждому из своих DNS серверов указаных в поле "Домен DNS" (рисунок 2). Если указаны для пересылки DNS сервера не смогут обеспечить необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту информацию, и сообщит клиенту DNS, пославший запрос что хост не может быть найден.
Рассмотрим следующею вкладку свойств DNS сервера, а именно "Корневые ссылки" смотрите рисунок 4.
О корневых ссылках мы упоминали и раньше.
Корневые ссылки это ссылки на корневой домен пространства имен DNS. Про корневой домен или домен высшего уровня, обозначенный " . " смотрите здесь. Все остальное пространства имен располагается ниже данного домена. Естественно что информация о корневом домене будет хранится не на одном сервере и на большем количестве. Поэтому на вкладке "Корневые ссылки" и даются эти сервера владеющие информацией о корневом домене, а так же их IP адреса.
Корневые ссылки используются низкоуровневыми DNS серверами в том случае если необходимая информация отсутствует в собственном кэше или в зонных файлах.
Когда мы устанавливаете DNS-сервер в среде Windows Server 2003, имеющий доступ к интернету, он автоматически конфигурируется со стандартным списком корневых серверов.
Корневые серверы - это серверы, которые являются полномочными для корня в пространстве имен интернета.
Если DNS-сервер получает запрос о зоне DNS, для которой он не является полномочным, сервер посылает итерационный запрос одному из корневых серверов. Итерационные запросы будет инициироваться до тех пор, пока нужное имя не будет разрешено или пока сервер не подтвердит, что оно не может быть разрешено.
Примечание. Корневые серверы, которые автоматически указываются на DNS-сервере при его конфигурировании, копируются из файла Cache.dns, который поставляется с файлами установки DNS-сервера (с установочного диска). О файле Cache.dns смотрите здесь.
Вы можете добавлять дополнительные DNS-серверы к списку корневых ссылок, включая в него DNS-серверы, имеющиеся в вашей внутренней сети.
По умолчанию DNS-серверы Windows Server 2003 используют корневые ссылки и пересылку, когда они пытаются разрешать имена. Если сервер конфигурирован с пересылкой, он сначала отправит рекурсивные запросы всем серверам указанные в "пересылке". Если ни один из серверов указанных в пересылке не может обеспечить необходимую информацию, то DNS-cepвер начнет посылать повторяющиеся запросы серверам, сконфигурированным как корневые ссылки. Как уже писалось выше мы это можем запретить если выберем опцию "He использовать рекурсию для этого домена" не вкладке "Пересылка".
Оставшиеся вкладки мы уже их рассматривали. Эту информацию смотрите здесь.
Думаю что со службой DNS пока закончили и и в следующих темах вернемся к основной теме - Active Directory.
Читайте также: