Евгений

DNS запись просто говорит на какой IP адрес идти запросу, перенаправлением занимается сервер, куда вы направите CNAME
конкретно, в приведенном вами случае, mail.enclav.ru. сделал запись CNAME на domain.mail.yandex.net, Яндекс получив запрос с хостнеймом mail.enclav.ru перенаправил его туда, куда надо, потому что так настроено в яндекс почта для домена
Если ваш "mail.домен.ру" не настроен (или неверно настроен) на принимающей стороне (в случае с enclav - это яндекс) то "магии" и не состоится

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

Соответственно в DNS сервере(серверах) должны быть настроены форвардеры на DNS провайдера + какой-нибудь публичный
На территории РФ я бы рекомендовал Яндекс, а за пределами - google или cloudflare. Что прописывать в форвардерах - ваше решение, можете хоть всё туда вбить вне зависимости от местонахождения
Внутренним ПК необходимо отдавать адрес только AD контроллера(ов) и следить за работоспособностью DNS службы на серверах

про sysvol и netlogon

1.
не совсем ясно как организована ваша инфраструктура
Судя по тому, что у вас есть вариант "назначить публичные IP и рулить публичными ДНС именами" - все располагается в default vpc и это не best practice.
Рекомендуется размещать инстансы, к которым не нужен доступ из интернета (те, которые хостят ваши сервисы, обслуживающие только ваши другие сервисы в том же VPC) в приватных подсетях VPC.
Вообще рекомендуется ВСЕ сервисы размещать в приватных подсетях а доступ из интернета к ним организовывать, используя прокси. AWS предоставляет ALB(ELB\NLB в зависимости от ваших потребностей), или же вы можете поднять свой прокси (HAProxy, NGINX или другие) на ec2 инстансе, расположенном в публичной подсети
2.
Route53 private zone
Если ваши сервисы находятся в приватной подсети и вам необходимо работать с ними по DNS именам: можно регистрировать инстансы в Route53 private zone или же поднять свой приватный DNS на любом ПО которое вы умеете(в таком случае необходима перенастройка параметров VPC в котором вы работаете, чтобы все сервисы могли работать с вашим DNS)
Так же можно использовать service discovery ПО, которое обеспечит разрешение имен DNS (например consul, но это потребует поднятия отдельного сервиса на ec2\ecs для обслуживания service discovery), или использовать service discovery предлагаемый AWS: Cloud Map - он использует route53 private zone для регистрации сервисов и разрешения имен.
3.
Сертификаты
Для сервисов, которые доступны публично - ничего сложного: используйте Certificate Manager для выпуска сертификатов на ALB или же LetsEncrypt если вы используете собственное ПО для прокси
Для сервисов, находящихся в приватных подсетях и недоступных публично:
- Можно забить и работать без TLS - сеть приватная, защищать или не защищать общение между сервисами в приватной подсети зависит от уровня вашей паранойи.
- ACM Private CA про который вы уже знаете
- В случае использования service discovery ПО можно использовать функционал предлагаемый решениями для service mesh, например consul connect service mesh: ваше приложение общается с прокси консула, а тот, обеспечивая TLS между нодами, направляет трафик приложения на нужный сервис

P.S. совершенно неясно зачем в тегах микротик

Статья в помощь по написанию батника для смены IP
geektimes.ru/post/125836