Windows dns сервер условной пересылки dns

В этой статье мы рассмотрим два способа организации условного разрешения имен в DNS сервере на Windows Server 2016: DNS conditional forwarding и DNS policy. Эти технологии позволяют настроить условное разрешение DNS имен в зависимости от запрошенного имени, IP адреса и местоположения клиента, времени суток и т.д.

Условная пересылка DNS (Conditional Forwarding) позволяет перенаправить DNS запросы об определенном домене на определенные DNS-сервера. Обычно Conditional Forwarders используется, когда нужно настроить быстрое разрешение имен между несколькими внутренними приватными доменами, или вы не хотите, чтобы DNS запросы с вашего сервера пересылались через публичную сеть Интернет. В этом случае вы можете создать на DNS сервере правило DNS пересылки DNS запросов для определенной доменной зоны (только !!!) на определенный DNS сервер.

Настройка DNS Conditional Forwarder в Windows Server

Попробуем настроить условное перенаправление DNS запросов для определенной доменной зоны на Windows Server 2016. Например, я хочу, чтобы все DNS запросы к зоне corp.winitpro.ru пересылались на DNS сервер 10.1.10.11.

1. Запустите консоль управления DNS (
   dnsmgmt.msc
   );
2. Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
3. В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
4. В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
5. Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
6. Выберите правило репликации записи 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:

Add-DnsServerConditionalForwarderZone -Name dmz.winitpro.ru -MasterServers 192.168.1.11,192.168.101.11 -ReplicationScope Forest

Чтобы вывести список 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 {$_.ZoneType -eq "4"} | 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.

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

Я создал 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"

Эти команды придется выполнить на всех DNS серверах, на которых должна работать условная политика DNS. Эти записи не реплицируются в DNS и хранятся локально в реестре DNS сервера. Вы можете указать имя сервера с помощью параметра
-ComputerName dc01
.

Чтобы вывести список всех IP подсетей клиентов, выполните:

Get-DnsServerClientSubnet

Теперь нужно для каждого офиса создать отдельную DNS область:

Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “MSKZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “EKBZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “SPBZoneScope”

Следующие команды добавят 3 DNS записи с одним именем, но указывающие на разные IP адреса в разных областях DNS:

Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.1.10” -ZoneScope “MSKZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.11.10” -ZoneScope “EKBZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.21.10” -ZoneScope “SPBZoneScope”

Теперь нужно создать DNS политики, которые свяжут IP подсети, DNS области и A записи.

Add-DnsServerQueryResolutionPolicy -Name “MSKResolutionPolicy” -Action ALLOW -ClientSubnet “eq,MSK_DNS_Subnet” -ZoneScope “MSKZoneScope,1” -ZoneName “winitpro.ru” –PassThru
Add-DnsServerQueryResolutionPolicy -Name “EKBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,EKB_DNS_Subnet” -ZoneScope “EKBZoneScope,1” -ZoneName “winitpro.ru” -PassThru
Add-DnsServerQueryResolutionPolicy -Name “SPBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,SPB_DNS_Subnet” -ZoneScope “SPBZoneScope,1” -ZoneName “winitpro.ru” –PassThru

Вывести список всех DNS политик для DNS зоны на сервере можно так:

Get-DnsServerQueryResolutionPolicy -ZoneName winitpro.ru

Теперь с устройств из различных офисов проверьте, что DNS сервер на один и тот же запрос возвращает различные IP адреса прокси:

nslookup proxy.winitpro.ru

Можно запретить DNS серверу возвращать DNS адреса для определенного пространства имен (домена):

Add-DnsServerQueryResolutionPolicy -Name 'BlockFidhingPolicy' -Action IGNORE -FQDN "EQ,*.cberbank.ru"

Во многих организациях используется два и более сервера DNS — один для внутренних пользователей, а другой, доступный через Интернет, для всех остальных. Для облегчения управления серверами используются интегрированные в Active Directory зоны DNS. Иногда бывает необходимо обрабатывать запросы, направляемые к этим серверам DNS, по-разному, в зависимости от расположения запрашивающего. Это называется расщепление DNS. Запросы к внутреннему серверу DNS обрабатываются иначе, чем к внешнему, а управление этим процессом осуществляется с помощью Windows Server 2003.

Давайте посмотрим, как осуществляется расщепление DNS в интегрированных с Active Directory зонах в Windows 2003.

В каких ситуациях происходит расщепление DNS?

Расщепление DNS может представлять определенные трудности для организаций, использующих несколько внутренних доменных имен, например, sales.company.com и research.company.com. В таких условиях необходимо, чтобы в каждом домене DNS корректно работал с Active Directory. Когда пользователь из домена research.company.com пытается получить доступ к веб-странице или компьютеру в домене sales.company.com, могут возникнуть сложности при обработке этого запроса локальным сервером DNS. Запрос направляется на сервер DNS данного домена, а тот передает его публичному серверу DNS компании. В такой ситуации ресурс, к которому направлен запрос, должен быть доступен из Интернета, чтобы сервер мог его найти. Однако на практике этот ресурс находится в другом внутреннем домене, поэтому внешний сервер DNS не сможет его найти по стандартному сценарию.

Windows Server 2003 позволяет решить эту проблему с помощью условных пересылкок. Условные пересылки направляют запросы определенного характера не на публичные серверы, а непосредственно на нужный внутренний сервер. Таким образом, при попытке обратиться к ресурсу в домене sales.company.com из домена research.company.com, полученный локальным сервером запрос направляется сразу на сервер DNS другого домена. Все это происходит незаметно для пользователей и обеспечивает быстрый доступ к нужным ресурсам.

Как настроить условные пересылки?

Условные пересылки как один из атрибутов DNS настраиваются следующим образом:

1. Откройте консоль DNS на контроллере домена Windows Server 2003.
2. Нажмите правой кнопкой на сервере DNS, который хотите настроить, и выберите пункт «Свойства» (Properties).
3. Откройте вкладку «Пересылка» (Forwarders) в окне свойств выбранного сервера.
4. Нажмите кнопку «Создать» (New) справа от списка доменов DNS.
5. Введите имя домена, для которого хотите использовать условные пересылки (к примеру, sales.company.com), и нажмите «OK».
6. Нажмите на новой пересылке домена, которую только что добавили в список доменов DNS, и введите IP-адрес основного сервера DNS для данного домена в поле «Список IP-адресов пересылки для выбранного домена» (Selected Domains Forwarder IP Address List).
7. Нажмите кнопку «Добавить» (Add).
8. Нажмите «OK», чтобы закрыть окно свойств DNS.

Условная пересылка готова к использованию. Стоит перезапустить службу DNS, чтобы убедиться, что изменения вступили в силу.

Обратите внимание: для успешного использования условных пересылок необходимо, чтобы на всех серверах DNS в среде Active Directory, была установлена Windows Server 2003.

Эта простая конфигурация позволяет использовать множественные субдомены в среде Active Directory.

Автор: Derek Schauland
Перевод: SVET

Оцените статью: Голосов

Время на прочтение
11 мин

Количество просмотров 98K

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

Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.

Содержание:

1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации

(анкеров нет, поэтому содержание без ссылок)

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-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru

Клиент обращается к DNS yandex.ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

2. Немного о формате сообщения DNS

Сообщение состоит из 12-байтного заголовка, за которым идут 4 поля переменной длины.

Заголовок состоит из следующих полей:

Формат DNS-сообщения

Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.

Флаги — 16-битовое поле, поделенное на 8 частей:

• QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
• opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
• AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
• TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
• RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
• RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).
• 0 — Это 3-битовое поле должно быть равно 0.
• rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Пример (получен с помощью WinDump при выполнении команды ping www.ru):

IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

В очень крупных организациях с крайне большими зонами, использующих для хранения данных DNS доменные службы Active Directory, перезапуск DNS-сервера может длиться час или более, пока данные DNS извлекаются из службы каталогов. При этом DNS-сервер недоступен для обслуживания клиентских запросов все время, пока длится загрузка зон доменных служб Active Directory.
DNS-сервер с ОС Windows Server 2008 теперь во время перезагрузки загружает данные зоны из доменных служб Active Directory в фоновом режиме, благодаря чему может при этом обрабатывать запросы данных из других зон. При запуске DNS-сервера выполняются следующие действия:

• определяются все зоны, которые должны быть загружены;
• из файлов или хранилища доменных служб 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)

Источники информации:

www.hardline.ru/4/49/1236/1630-25.html

www.inadmin.ru/2010/02/26/dns-internet-domain

minergimn.ru/statii/16-adwin2003132

technet.microsoft.com/ru-ru/library/cc728909.aspx

support.microsoft.com/kb/247811/en-us?fr=1