Active Directory

AD использует DNS не как телефонную книгу серверов, а как протокол обнаружения служб. Клиент ищет DC, Kerberos KDC, LDAP и GC через SRV-записи. Если имя домена «пингуется», это ещё не доказывает работоспособность AD: могут отсутствовать SRV-записи, неверно определяться сайт или быть недоступен нужный DC.

Клиент знает DNS suffix: skl.local
 |
_ldap._tcp.dc._msdcs.skl.local → DC01.skl.local
 |
LDAP/Kerberos/Netlogon → вход в домен

AD-integrated зона хранит данные зоны в каталоге и реплицируется вместе с AD, а не через отдельные zone transfer. Выберите область репликации осознанно: все DNS-серверы леса, все DNS-серверы домена или конкретный application partition. Для внутренней зоны включайте только secure dynamic updates: объект получает право обновлять собственную запись через AD-аутентификацию.

AD DS replication
 ├─ DomainDnsZones.skl.local → DNS домена
 └─ ForestDnsZones.skl.local → _msdcs и данные леса

Dynamic update: computer account → A/PTR record

Статические записи нужны для инфраструктуры с фиксированным именем, но не заменяют корректную динамическую регистрацию. Настройте scavenging после измерения реальных сроков аренды DHCP: агрессивная очистка может удалить запись отключённого, но нужного устройства.

DC Locator сначала использует DNS-суффикс и SRV, затем сопоставляет IP клиента с подсетью AD Site. При наличии site-specific записи клиент выбирает локальный DC; при отсутствии подсети он может обращаться через WAN. Поэтому «медленный логон» часто начинается не с GPO, а с неописанной подсети.

10.20.0.0/16 → Site=Kazan
Client 10.20.5.8
 → _ldap._tcp.Kazan._sites.dc._msdcs.skl.local
 → DC03.skl.local

Нет matching subnet → общий SRV → возможно DC в Moscow

SRV имеют приоритет и вес; обычно их не редактируют вручную. Netlogon регистрирует записи при старте и может перерегистрировать их командой nltest /dsregdns.

На DC в качестве DNS-серверов NIC указывают только внутренние DNS-серверы, обслуживающие AD-зоны. В двух-DC среде обычно каждый DC указывает на другого как preferred, а на себя как alternate либо применяют согласованную, документированную схему запуска. Важнее всего: никаких внешних резолверов в настройках интерфейса DC и клиентов домена.

DC01 NIC DNS: 10.0.0.12 (DC02), 10.0.0.11 (DC01)
DC02 NIC DNS: 10.0.0.11 (DC01), 10.0.0.12 (DC02)
Client DNS: 10.0.0.11, 10.0.0.12
Internet DNS: только через DNS forwarder

Многосетевые DC требуют особого контроля: не регистрируйте в DNS адреса резервных, изолированных или management-интерфейсов и если клиенты по ним не должны ходить. Иначе Locator выдаст недостижимое имя.

Внутренний DNS должен быть авторитетен за внутренние зоны и пересылать внешние запросы через forwarders: корпоративный резолвер, шлюз безопасности или разрешённый рекурсивный DNS. Это сохраняет единый контроль, журналирование, фильтрацию. Root hints — резервный путь при отсутствии forwarder но обычно не желаемый маршрут в корпоративной сети.

Conditional forwarder направляет только определённый namespace: запросы к partner.example — на DNS партнёра, остальные — на обычные forwarders. Если требуется доверие между лесами, DNS-разрешение namespace — обязательная предпосылка, а не побочная настройка.

Зона _msdcs.имя-леса содержит критические записи леса: GUID-алиасы DC, SRV Locator и CNAME, используемые репликацией. Её потеря или неверная делегация проявляются как ошибки репликации и поиск неправильных DC. Не удаляйте «странные» записи в _msdcs ради уборки.

Split-brain (split-horizon) DNS — намеренное существование внутренней, внешней версии одного namespace. Он допустим, если внутренним клиентам нужны внутренние адреса, а внешним — публичные. Но записи надо сопровождать как две независимые зоны и тестировать с обеих сторон.

www.example.com
 internal DNS → 10.10.5.20
 public DNS → 203.0.113.20

_msdcs.skl.local
 internal only → GUID DC, LDAP/Kerberos SRV

Диагностируйте цепочку, а не один симптом: NIC клиента → доступность внутреннего DNS → A-запись DC → SRV нужной службы → сайт и подсеть → Netlogon/репликация. Кэш очистите только после фиксации наблюдений, иначе вы уничтожите полезный след.

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.skl.local
nltest /dsgetdc:skl.local
dcdiag /test:dns /v
repadmin /replsummary
ipconfig /flushdns
ipconfig /registerdns

Если SRV отсутствует, проверяйте службу Netlogon, журналы DNS Server/System, права secure update и состояние репликации разделов DNS. Если SRV есть, но выбран далёкий DC, проверяйте подсети и site links, а не меняйте записи вручную.

Минимальный устойчивый дизайн: два доступных внутренних DNS на DC, AD-integrated зоны с безопасными обновлениями, документированные области репликации, forwarders для внешнего мира, все подсети назначены сайтам и регулярная проверка DNS/AD репликации. DNS восстанавливают как часть плана восстановления леса.

DNS-дизайн начинается с перечня пространств имён: внутренний AD namespace, публичный namespace, зоны партнёров, обратные зоны и зоны приложений. Имя домена AD выбирают как долгоживущий идентификатор, а не как временное название проекта. Допустимы выделенный внутренний namespace или поддомен публичного имени; важнее заранее определить, кто владеет внешними записями, сертификатами, почтой и split-brain логикой.

Прямая зона отвечает «какой адрес у имени», обратная — «какое имя у адреса». PTR не является механизмом безопасности, но необходим для диагностики, журналирования, некоторых сервисов. Для DHCP-клиентов заранее решите, кто регистрирует A, PTR: клиент или DHCP-сервер. При защищённых обновлениях это решение связано с учётной записью и от имени которой выполняется обновление.

Прямое разрешение: app01.skl.local → 10.10.4.21
Обратное разрешение: 10.10.4.21 → app01.skl.local

10.10.4.0/24
 зона: 4.10.10.in-addr.arpa
 PTR: 21 → app01.skl.local

DNS — критическая зависимость входа, поэтому его доступность проектируют отдельно от удобства администрирования. Минимум два внутренних DNS-сервера должны быть доступны из каждой клиентской сети; предпочтительно они работают на разных DC, хостах, стойках и, где это оправдано, площадках. Но географическое разнесение не заменяет локальный сервис при недоступном WAN: требования к филиалу определяют наличие local DC/DNS или RODC.

Защищённые динамические обновления предотвращают захват имён неавторизованными клиентами. Контролируйте ACL зоны и application partitions: право создавать записи не должно быть эквивалентно праву изменить записи DC. Включайте журналирование достаточно подробно для расследования, но учитывайте объём и доступ к журналам. Рекурсию ограничивайте внутренними клиентами; открытый рекурсивный DNS становится инструментом усиления атак.

Клиенты ─┬─ DNS/DC01 ─ AD-integrated zone
 └─ DNS/DC02 ─ AD-integrated zone

Внешний запрос:
клиент → внутренний DNS → approved forwarder → Internet
Internet ─X→ внутренний рекурсивный DNS

DNS-инцидент нужно классифицировать до исправления. Ошибка одной записи отличается от отказа рекурсии, отсутствия SRV, сломанной репликации зоны, неверного suffix search list и выбора не того сайта. Начинайте с конкретного клиента и фиксируйте IP, DNS-адреса, суффикс, результат запроса и выбранный DC. Затем проверяйте тот же запрос на каждом DNS-сервере. Такой порядок отделяет проблему данных от проблемы пути.

ipconfig /all
Resolve-DnsName dc01.skl.local -Server 10.10.0.11
Resolve-DnsName _kerberos._tcp.dc._msdcs.skl.local -Type SRV
Resolve-DnsName 10.10.4.21 -Type PTR
Get-DnsServerZone
dcdiag /test:dns /e /v

При отсутствии DC Locator не удаляйте и не создавайте SRV вручную первым действием. Проверьте здоровье AD репликации, Netlogon, права зоны и корректность DNS-серверов на DC. Ручная запись может кратко скрыть симптом, но не восстановит регистрацию после следующего изменения. После устранения причины перерегистрируйте записи и сверяйте результат с несколькими DNS.

Проблема: клиент не входит в домен
1. Внутренний DNS в NIC? нет → исправить DHCP/NIC
2. A-запись DC отвечает? нет → зона/сеть
3. SRV _ldap отвечает? нет → Netlogon/репликация
4. Сайт соответствует подсети? нет → Sites and Services
5. LDAP/Kerberos доступны? нет → DC/Firewall/время

Проектирование DNS-зон, SRV-регистрации, forwarders и клиентского locator должно быть доказуемым. Сначала собирают факты: владельцев сервисов, перечень зависимых систем, сетевые ограничения, требования к доступности, срокам восстановления, аудиту. Затем формулируют несколько вариантов, выбирают минимально сложный, записывают измеримые критерии успеха. Формулировка «так исторически сложилось» не является требованием и не должна переживать пересмотр дизайна.

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

Методика проверки

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

Требование → вариант → риск → владелец
 ↓ ↓ ↓
 тестовый проверка решение об
 сценарий отказа эксплуатации

Документация обновляется после проверки,
а не до того, как факт подтверждён.

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.skl.local
dcdiag /test:dns /v
ipconfig /registerdns