Имя домена Active Directory задаёт пространство DNS, в котором компьютеры находят контроллеры и службы каталога. Оно связано с инфраструктурой на годы: его используют серверы, приложения и средства администрирования. При этом DNS-имя домена AD, короткое имя NetBIOS, пользовательский логин UPN, почтовый адрес и имя сайта решают разные задачи и не обязаны совпадать.
Разберём, как выбрать имя для нового леса, какие зависимости проверить в существующем и почему для компании, владеющей example.com, часто удобен поддомен corp.example.com. На примерах покажем, как возникают конфликты с .local, как работает split DNS и когда задачу можно решить настройкой UPN или клиентских имён сервиса без переименования всего каталога.
1. Как собрать требования к имени домена
Пример: почему ограничения .local проявились после расширения сети
Администратор разворачивает каталог для небольшой компании: десять пользователей, файловый сервер и принтер. Компьютеры находят контроллер, пользователи входят, имя кажется внутренней технической мелочью. Затем компания подключает ноутбуки Mac, добавляет почту и хочет единый удобный логин. Теперь имя участвует сразу в нескольких независимых механизмах.
.local используется multicast DNS: устройства обнаруживают локальные имена через другой механизм, чем обычный запрос к корпоративному DNS. Конкретное поведение зависит от клиента и его конфигурации. Поэтому существующий AD с таким суффиксом может работать, но при проектировании нового каталога появляется лишняя неоднозначность. Назначение .local описано в RFC 6762.
Как собрать требования в действительности? Не записывать абстрактное «имя должно быть красивым», а заполнить карточку решения и проверить источники:
| Вопрос | Где проверить | Пример конкретного ответа | Что меняет решение |
|---|---|---|---|
| Какие публичные домены принадлежат компании? | Кабинет регистратора, договор, ответ владельца DNS | example.com, продление закреплено за компанией | Нельзя строить внутреннюю инфраструктуру на чужом имени |
| Кто может менять DNS и выпускать сертификаты? | Ответственные за DNS и PKI | DNS ведёт подрядчик; DNS-01 согласуется через заявку | Нужен понятный процесс изменения записей |
| Как пользователи должны входить? | Требования поддержки, SSO, Microsoft Entra и приложений | ivanov@example.com | Это проект UPN, а не требование назвать AD example.com |
| Какие клиенты будут в сети? | Инвентаризация рабочих мест | Windows, macOS, Linux и телефоны | Проверяется DNS, mDNS и интеграция каждого класса |
| Есть ли Exchange, AD CS и федерация? | Реестр сервисов и владельцы приложений | Exchange существует; CA выдаёт машинные сертификаты | Ограничения миграции и имена сертификатов проверяются заранее |
| Возможны ли покупка компании и переименование бренда? | План развития и владелец инфраструктуры | Бренд может меняться | Имя каталога выбирают долговечным; почтовый бренд меняют отдельно |
Итог встречи — заполненные поля, ответственные и открытые вопросы. Если владение доменом не подтверждено, этот вопрос остаётся незакрытым; его не заменяют придуманным company.local.
Зафиксируйте зарегистрированные домены, юридическую стабильность бренда, географию, облачные сервисы, существующие DNS-зоны, слияния и требования приложений. Имя подразделения или города быстро устаревает.
Разделите четыре имени, которые часто смешивают
В примере организация владеет example.com. Forest root и AD DNS-domain — corp.example.com; NetBIOS — CORP; UPN пользователей — ivanov@example.com; FQDN контроллера — dc01.corp.example.com. Эти значения связаны, но не обязаны совпадать. Имя почтового домена и UPN могут совпадать для удобства, однако изменение UPN не переименовывает домен AD.
Домен безопасности содержит каталог, политики, Kerberos и доверия. DNS-зона помогает находить службы, но создание зоны corp.example.com без AD DS не создаёт каталог. Для компании с одним управляемым пространством часто достаточно одного леса и домена, а офисы разделяют Sites/OUs по реальным требованиям. Дополнительные домены не следует создавать лишь ради названий отделов.
2. Разделяем имя каталога, логин, почту и сертификаты
Домен каталога, сайт, почта и сертификат не обязаны называться одинаково
При настройке почтового сервиса администратор пытается включить внутреннее имя в публичный сертификат. Публичный центр сертификации не выдаёт сертификаты на произвольные внутренние имена. Но отсюда не следует, что надо переименовать весь каталог. Внешнее клиентское имя почтового сервиса может быть mail.example.com, хотя AD называется иначе. Для внутренних имён может использоваться корпоративный CA, если клиенты доверяют ему.
| Слой | Пример | Для чего используется |
|---|---|---|
| DNS-имя домена AD | corp.example.com | Поиск контроллеров, записи службы каталога |
| NetBIOS-имя | CORP | Старый формат входа CORP\ivanov |
| UPN пользователя | ivanov@example.com | Логин пользователя в поддерживающих его системах |
| Основной SMTP-адрес | i.ivanov@example.com | Доставка почты; может отличаться от логина |
| Имя клиентского почтового сервиса | mail.example.com | HTTPS-подключение клиента и проверка сертификата |
| Имя контроллера | dc01.corp.example.com | Конкретный компьютер и его сервисные имена |
Имя в сертификате сравнивается с именем, по которому подключается клиент. Наличие mail.example.com в сертификате не делает сертификат подходящим для dc01.corp.example.com. UPN-суффикс также не создаёт DNS-зону и не перенастраивает SMTP. Microsoft о сертификатах Exchange.
Для нового леса запишите эти шесть строк до запуска мастера. Пример решения: каталог corp.example.com, NetBIOS CORP, пользовательский UPN example.com, сайт www.example.com, почта mail.example.com. Все доменные имена здесь учебные; используйте собственное зарегистрированное пространство.
Если организации принадлежит example.com, внутренний AD можно назвать corp.example.com или другим стабильным поддоменом. Это снижает риск конфликта с чужими именами и позволяет выпускать публично доверенные сертификаты для допустимых имён.
Почему стабильный поддомен принадлежащего имени удобен
Поддомен corp.example.com отделяет AD-зону от внешних www, MX и других публичных записей example.com. Владелец контролирует делегирование и может подтвердить права на DNS-namespace. Имя нужно удерживать в собственности на весь срок инфраструктуры, даже если бренд меняется.
Регистрация домена не обязывает публиковать внутренние DC в публичном DNS. A/AAAA/SRV контроллеров обычно обслуживаются внутренним AD DNS. Публичный сертификат на допустимое принадлежащее имя требует самостоятельного подтверждения CA и политики; регистрация сама по себе не выдаёт сертификат. Для внутренних AD-служб часто используется корпоративная PKI, поэтому выбор имени согласуйте с её политикой.
3. Имена .local, single-label и чужие домены
Какие старые советы требуют уточнения
Исходная история закончилась категорическим «никогда не называйте домен как сайт». Точнее так: совпадение зон требует управляемого split DNS. Это допустимая архитектура, если все необходимые внутренним клиентам записи поддерживаются внутри и понятна схема обновления. Для небольшой команды отдельный corp.example.com обычно сокращает объём дублирования.
Single-label имя вроде MEGAKONTORA не следует выбирать DNS-именем нового AD. NetBIOS MEGAKONTORA и DNS corp.example.com — разные поля; короткое имя не заменяет полное. Современные требования и ограничения перечислены в рекомендациях Microsoft по именованию.
Не используйте чужой зарегистрированный домен даже для «только внутренней сети». При изменении маршрутизации, VPN или использовании публичного DNS клиент может попасть в чужое пространство. Не выбирайте имя, требующее пробелов, кириллицы или специальных символов ради маркетингового написания бренда: отображаемые названия организации задаются отдельно от инфраструктурных имён.
Нерегистрируемый суффикс, чужой домен или случайное короткое слово могут конфликтовать с mDNS, VPN, слиянием и облачными сервисами. Microsoft рекомендует зарегистрировать создаваемое DNS-имя, если оно может понадобиться за пределами изолированной сети.
.local, single-label и чужой DNS
.local имеет специальное назначение mDNS; клиенты macOS/Linux и мобильные устройства могут разрешать его иначе. Single-label домен CORP не равен короткому NetBIOS-имени: как DNS-домен он требует особых настроек и создаёт проблемы обнаружения служб. Чужой зарегистрированный namespace несёт риск коллизий при VPN, слиянии и доступе к интернет-сервисам.
Если действующий AD уже называется company.local, не объявляйте его автоматически сломанным и не меняйте registry name на месте. Зафиксируйте зависимости, добавьте подходящий UPN для облачной идентичности при необходимости и отдельно оцените миграцию. Хорошая рекомендация для нового леса не означает разрешение переименовать работающий лес без тестов.
4. Split DNS: почему внутренний сервер не ищет запись у внешнего
Пример: имя внутреннего домена совпало с именем сайта
После выбора example.com в качестве имени домена AD внутренний DNS стал авторитетным за эту зону. Внешний провайдер DNS тоже обслуживает зону example.com, но содержит другой набор записей. Когда внутренний клиент спрашивает www.example.com, внутренний сервер отвечает по своей зоне. Если записи нет, он не обязан идти к внешнему одноимённому серверу в надежде найти другую версию ответа.
Рекурсивный forwarder помогает для пространств, за которые сервер не авторитетен. Он не превращает неполную локальную зону в автоматически дополняемую внешнюю. Это причина, почему добавление публичного DNS «вторым» на сетевой карте не решает архитектуру: клиент может получать непредсказуемые ответы, а публичный сервер не знает внутренних SRV-записей AD.
Практическое сравнение из разрешённой административной сети:
Resolve-DnsName www.example.com -Type A -Server 10.20.0.10
Resolve-DnsName www.example.com -Type A -Server 1.1.1.1
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.com -Type SRV -Server 10.20.0.10Адрес 10.20.0.10 замените внутренним DNS. Запрос публичному резолверу используйте только для публичного имени, если это допускает политика компании. Внутренние имена туда отправлять не требуется. Первый и второй запросы могут давать разные адреса по проекту; это ещё не неисправность. Третий должен вернуть контроллеры из вашего каталога, а не www или почтовый сервер.
Если сайт переехал на CDN, не копируйте сегодняшние IP навсегда. Уточните, должен ли внутренний ответ быть CNAME, кто следит за изменениями и как учитывается TTL. Для публичного apex и CNAME существуют отдельные ограничения DNS; нельзя механически копировать схему www в корень зоны. Проектирование DNS-пространства Microsoft.
Внутренние и внешние клиенты могут получать разные ответы для одного публичного домена. Split-brain DNS требует аккуратного управления зонами и записей для внешних сервисов. Поддомен corp.example.com часто проще, чем копия всей зоны example.com.
Split DNS и выбор резолвера на клиентах
AD-клиентам нужны DNS-серверы, которые знают SRV-записи AD. Публичный 8.8.8.8 в качестве «запасного» DNS на сетевом интерфейсе может вызвать случайные ошибки поиска DC: клиент не обязан использовать его только после полного отказа первого. Для внешних запросов на AD DNS настраивают согласованные forwarders, а не подменяют клиентский список публичными серверами.
Если внутренняя зона совпадает со всей example.com, её авторитетность означает, что отсутствующая внутренняя запись www.example.com не будет автоматически найдена у внешнего authoritative DNS. Нужны внутренние записи/продуманная схема split DNS. При отдельной зоне corp.example.com эта обязанность обычно не распространяется на родительский внешний namespace. Это уменьшает объём ручной синхронизации, но не отменяет проектирование DNS.
5. Проект имени для реальной инфраструктуры
Пример принятого решения с критериями проверки
Пусть у компании две площадки, 150 Windows-ПК, 20 Mac и облачная почта. Она владеет example.com; сайт администрирует агентство, каталог — внутренняя ИТ-служба. Решение: один лес corp.example.com, площадки представлены AD Sites, отделы — OU, удобный UPN — example.com. Отдельные домены sales.corp.example.com и office2.corp.example.com не создаются только потому, что отделы и здания разные.
Согласуйте, какие контроллеры отвечают в каждой площадке, их подсети и доступность DNS через VPN. Выбор имени леса не определяет автоматически количество доменов или контроллеров. OU служит для делегирования и групповых политик; Sites описывают сетевую топологию. Требования изоляции и организационные границы оцениваются отдельно, а не кодируются случайными суффиксами.
Оформите запись решения: выбранные имена, обоснование, владелец DNS, процесс продления публичного домена, клиентские платформы, ожидаемые интеграции и план проверки. Это конкретный результат «сбора требований», по которому следующий администратор понимает, почему каталог назван именно так.
DNS labels используют буквы, цифры и дефис; избегайте underscore и сложной транслитерации. Не делайте иерархию глубже без причины. Имя должно пережить смену бренда отдела и офиса.
Согласуйте формат до первой установки DC
Выберите стабильную ASCII-метку, без underscore и пробелов, с допустимой длиной DNS-label. Для совместимости используйте буквы, цифры и дефис внутри метки; не начинайте/заканчивайте метку дефисом. NetBIOS выбирайте отдельно, уникальным и до 15 символов. Сверьте список reserved names и требования приложений.
Проверка на бумаге включает forest root, домены, имена будущих DC, UPN suffixes, Sites и владельца публичной регистрации. Филиал завтра может сменить город/бренд; отражайте такие изменения в OU/Sites, а не в фундаментальном имени леса. Не используйте в рабочем развёртывании буквально example.com: это документационный домен.
6. NetBIOS и инвентаризация существующего леса
NetBIOS используется старыми сценариями DOMAIN\user и ограничен 15 символами для совместимости. Выберите короткое уникальное значение и проверьте конфликты с компьютерами, довериями и соседними лесами.
Resolve-DnsName corp.example.com -ErrorAction SilentlyContinue
Get-ADForest
Get-ADDomainКоманды AD выполняются только в существующей тестовой среде; для нового леса сначала составьте проект.
Read-only инвентаризация действующей среды
На управляемом Windows-сервере/администраторской станции установите RSAT Active Directory через штатное управление optional features/roles. Это разрешение на инструмент, не на развёртывание нового леса. Затем в PowerShell с достаточными правами чтения:
Import-Module ActiveDirectory
Get-ADForest | Select-Object Name,RootDomain,Domains,UPNSuffixes,ForestMode
Get-ADDomain | Select-Object DNSRoot,NetBIOSName,DomainMode,DistinguishedName
Get-ADDomainController -Filter * |
Select-Object HostName,IPv4Address,Site,IsGlobalCatalogОжидается DNSRoot вродеcorp.example.com и NetBIOS CORP. В лесу может быть несколько доменов; команду Get-ADDomain нужно выполнять с явным -Identity для интересующего. Ошибка обнаружения сервера может быть DNS/правами/сетью, а не доказательством отсутствия домена. Сохраните результат внутри компании, не публикуйте перечень DC в открытой статье.
7. UPN и проверка пилотного пользователя
Пилот смены UPN: как избежать ложного успеха
Сначала выберите одного тестового пользователя и сохраните его ObjectGUID, текущий UPN и список затрагиваемых приложений. Проверьте вход в Windows, VPN, почту, SSO и приложения, где имя записано вручную. Изменение UPN не должно по предположению менять почтовый адрес или создавать новый аккаунт в стороннем сервисе.
После изменения тестируют новый вход в отдельном сеансе. Уже открытая сессия может продолжать работать за счёт старых билетов или токенов; это не подтверждение корректности нового имени. Для возврата используют сохранённый исходный UPN того же объекта, а не создают второго пользователя с похожим логином. Синхронизация в облако имеет собственные задержки и правила сопоставления.
Вход user@example.com удобнее длинного AD DNS-имени и может совпадать с корпоративной почтой. Добавьте проверенный UPN suffix после подтверждения владения доменом и согласуйте его с Entra ID.
Добавление UPN-suffix и точечное изменение пользователя
Сначала подтвердите владение example.com и требования Entra/синхронизации. В GUI Active Directory Domains and Trusts откройте свойства верхнего узла и добавьте suffix. PowerShell-альтернатива изменяет лес, поэтому требует согласованных прав и backup:
# Выполнять только после согласования; example.com заменить принадлежащим доменом
Set-ADForest -Identity 'corp.example.com' -UPNSuffixes @{Add='example.com'}Для пилота выберите одного тестового пользователя, запишите исходный UPN, проверьте отсутствие конфликта и только потом изменяйте:
$Pilot = Get-ADUser -Identity 'pilot.user' -Properties UserPrincipalName
$OldUpn = $Pilot.UserPrincipalName
Get-ADUser -Filter "UserPrincipalName -eq 'pilot.user@example.com'"
# При отсутствии чужого совпадения и после согласования:
Set-ADUser -Identity $Pilot.DistinguishedName -UserPrincipalName 'pilot.user@example.com'Не продолжайте при найденном конфликте. Переменную OldUpn дополнительно сохраните в защищённый журнал изменений: новый сеанс PowerShell её не помнит. Проверьте вход пилота, Kerberos, VPN/Wi-Fi и синхронизацию. Для возврата восстановите исходный UPN этого пользователя, а suffix удаляйте только после проверки всех зависимостей. Почтовый SMTP-адрес этим автоматически не меняется.
8. Проверяем имя до создания леса
Составьте перечень сертификатов, Exchange, Microsoft 365, Linux/Kerberos, Wi-Fi 802.1X, VPN, файловых путей, приложений и резервного копирования. Проведите лабораторный forest с выбранным именем.
Лабораторный лес и проверка готовности
Для нового развёртывания возьмите отдельную VM с поддерживаемым Windows Server, фиксированной согласованной адресацией, DNS-планом и консолью. Убедитесь, что namespace не пересекается с production. Установка AD DS — отдельное необратимое в рамках одного command-session изменение роли; ниже только проверка предпосылок после установки соответствующей роли на стенде:
Import-Module ADDSDeployment
$DsrmPassword = Read-Host 'DSRM password for isolated lab' -AsSecureString
Test-ADDSForestInstallation -DomainName 'corp.example.com' -DomainNetbiosName 'CORP' -InstallDns -SafeModeAdministratorPassword $DsrmPasswordЭтот тест проверяет prerequisites, но не создаёт лес и не доказывает совместимость всех приложений. Пароль DSRM хранится в защищённом хранилище, не в статье. Нельзя отключать проверки через SkipPreChecks, чтобы скрыть ошибки. После согласованного отдельного развёртывания проверьте DNS, DC и приложения. Microsoft — установка AD DS.
9. DNS-записи, контроллеры и интерпретация результата
Как читать ответы SRV и DC Locator
Учебный ответ SRV может содержать NameTarget=dc01.corp.example.com, Port=389, Priority=0, Weight=100. Он объявляет endpoint LDAP, но не проверяет успешный bind, наличие репликации и здоровье базы каталога. Далее имя контроллера должно разрешиться в ожидаемый внутренний адрес. Порт 389 в SRV не означает, что все приложения должны посылать пароль без защиты.
Resolve-DnsName dc01.corp.example.com -Type A -Server 10.20.0.10
nltest /dsgetdc:corp.example.com
repadmin /replsummarynltest проверяет нахождение контроллера через механизм DC Locator. repadmin требует подходящих инструментов и прав; в лесу с одним DC отсутствие партнёра репликации не является доказательством отказа. Ошибка одного запроса SRV может возникать из-за неправильного DNS на клиенте, отсутствия записи или проблемы сервера — эти слои проверяют отдельно.
Зафиксируйте forest root, domain DNS/NetBIOS names, UPN suffixes, sites, подсети, forwarders, scavenging, владельцев зон и резервное копирование System State. Не публикуйте внутреннюю топологию без необходимости.
SRV, DC locator и DNS-приёмка
На доменном клиенте запросите внутренний DNS; адрес 10.20.0.10 замените адресом своего AD DNS:
Resolve-DnsName '_ldap._tcp.dc._msdcs.corp.example.com' -Type SRV -Server 10.20.0.10
Resolve-DnsName 'dc01.corp.example.com' -Type A -Server 10.20.0.10
nltest /dsgetdc:corp.example.comSRV должен возвращать имена соответствующих DC и порт 389 для LDAP; A — ожидаемый адрес. nltest проверяет DC locator в контексте клиента. На DC в согласованном диагностическом окне:
dcdiag /test:dns /v
repadmin /replsummaryПервый тест проверяет DNS-инфраструктуру AD, второй показывает сводку репликации; в лесу с одним DC смысл репликационной проверки ограничен. Ошибки требуют анализа, а не переименования зоны. В DNS-документе зафиксируйте динамические обновления, forwarders, backup/System State и восстановление. Не включайте scavenging с произвольными сроками без сопоставления с DHCP и временем обновления записей.
10. Что делать с существующим доменом
Если неправильное имя уже используется
Составьте карту зависимостей: доменные компьютеры, SPN сервисов, LDAP-адреса, сертификаты, Exchange, CA, GPO, скрипты, VPN, синхронизация и резервное восстановление каталога. Для каждой зависимости укажите владельца и способ проверки. Это работа до выбора метода, а не список, который заполняют после запуска переименования.
Смена UPN, изменение публичного имени приложения, split DNS, поддерживаемое переименование домена и миграция в новый лес решают разные проблемы. Не выбирайте самое масштабное действие ради одного сертификата. Наличие Exchange или иной интеграции может исключить поддержку выбранной процедуры. DNS-псевдоним сам по себе не меняет AD-домен и не исправляет SPN.
Имя нового домена выбирают с учётом DNS, идентификации пользователей, сертификатов и жизненного цикла инфраструктуры. В существующем каталоге сначала установите, какая именно зависимость мешает работе. Перед переименованием проверьте, решается ли задача отдельной настройкой UPN, DNS или клиентского имени сервиса, и испытайте восстановление каталога.
Если старое имя неудобно, часто безопаснее добавить UPN suffix или построить новый forest и выполнить миграцию. Domain rename имеет ограничения и требует тестов всех приложений. Решение принимают после инвентаризации, резервной копии и репетиции возврата.
Переименование — самостоятельный проект
CNAME для нового имени DC не переименовывает forest/domain и не исправляет автоматически SPN, Kerberos и сертификаты. Domain rename имеет продуктовые ограничения, особенно при Exchange и других тесно интегрированных системах. Для неудобного пользовательского входа достаточно сначала рассмотреть UPN; для конфликта безопасности/namespace может понадобиться новый лес и контролируемая миграция.
Инвентаризируйте trust, GPO, сервисные учётные записи, SPN, PKI, Wi-Fi802.1X, VPN, файловые пути и облачную синхронизацию. Репетируйте восстановление System State и сценарий возврата по поддерживаемой процедуре; snapshot DC не считается универсальным rollback. Итог выбора имени — проверенный namespace и DNS/UPN-план, а не запущенная на production команда rendom.
Документация команд: Set-ADForest, Test-ADDSForestInstallation.
Источники: Microsoft Learn — правила именования AD, Microsoft Learn — планирование DNS namespace, Microsoft Learn — disjoint namespace.