Этот документ MSFT описывает базовую настройку в описанном вами сценарии субдомена: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10)
Вам не нужно «сообщать» своим контроллерам домена, что они подчинены вышестоящей зоне. Просто установите роль AD и DNS, укажите полное доменное имя домена, и во время установки подзона будет настроена как уполномоченная на контроллерах домена.
Программа установки выдаст вам предупреждение, если у вас есть клиент DNS, настроенный на сетевом адаптере контроллера домена с внешним адресом хоста DNS, потому что он попытается зарегистрировать свое новое имя DNS. Но игнорируйте это, вышестоящему DNS не нужно знать об этом.
Для ресурсов, размещенных внутри, к которым необходимо получить доступ из Интернета, вы должны выделить общедоступный IP-адрес и общедоступное DNS-имя для своего внутреннего ресурса, например, веб-сайта или VPN, и добраться до него таким образом, а не открывать/делегировать частное пространство имен. вообще - этого определенно следует избегать, если это вообще возможно. Это сценарий, описанный в документе MSFT. Что касается пункта 4, вам не нужно беспокоиться об отключении динамических регистраций у вашего провайдера DNS, поскольку я сомневаюсь, что они вообще включены.
Основное решение будет заключаться в том, как вы выполняете разрешение внешних имен для членов вашего домена. Разумеется, участники должны использовать контроллеры домена в качестве своих DNS-хостов. Контроллеры домена должны будут разрешать имена в Интернете. В идеале контроллеры домена должны пересылать запросы определенному провайдеру DNS — это облегчает жизнь, когда дело доходит до брандмауэра. Пункт 5 в статье, на которую я ссылаюсь, обсуждает варианты.
Я думаю, что в вашем сценарии вы бы использовали DNS вашего интернет-провайдера, однако вы делаете это сейчас. Стоит обратить внимание на поставщиков услуг DNS, таких как OpenDNS или Cloudflare, которые обеспечивают безопасность DNS, если ваш текущий поставщик этого не делает — дополнительная защита от фишинговых сайтов и т. д. отличная, и эти услуги могут быть бесплатными или совсем недорогими. Просто убедитесь, что тот, который вы выбираете, имеет местные точки присутствия (по крайней мере, национальные), если вы идете по этому маршруту. Запасной вариант — позволить контроллерам домена использовать корневые подсказки, но это означает, что им нужно выполнять запросы по всему Интернету, и я бы, конечно, предпочел OpenDNS и т. д. этому варианту. Вы должны определить несколько серверов пересылки, если только вы не знаете, что IP-адрес сервера пересылки на самом деле является VIP с несколькими хостами под ним.
Документация MSFT также содержит ряд других глав, которые, возможно, стоит просмотреть. Однако такие вещи, как внутренний корневой сервер DNS, не имеют значения, если вы не собираетесь раскрывать свое внутреннее пространство имен и делегировать его от своего вышестоящего регистратора DNS. Опять же, это сценарий, которого вы хотите избежать.
Кроме того, после установки вашего первого контроллера домена в конфигурации сети не забудьте проверить, что его собственный IP-адрес является основным хостом DNS, а также 127.0.0.1. Если сервер пересылки DNS настроен на ретрансляцию запросов к вашему внешнему DNS, я не думаю, что он также должен быть определен в конфигурации сети (конечно, проверьте, может ли контроллер домена разрешать внешние имена).
Для последующих контроллеров домена перед установкой ADDS настройте сеть так, чтобы первый контроллер домена был ее основным DNS, затем сам, затем 127.0.0.1. После завершения настройки на втором контроллере домена и завершения репликации убедитесь, что первый контроллер домена может разрешить ее, и настройте его сетевую конфигурацию, чтобы второй контроллер домена был первым узлом DNS (сохранив другие записи).
