Public DNS on domain-joined PCs
I have a two-controllers AD domain, and all domain-joined PCs have their addresses as primary and secondary DNS servers.
I wonder if I should configure a tertiary public DNS. The reasoning is that many PCs are located in smaller remote networks and they reach both domain controllers via a central VPN tunnel. If the VPN tunnel goes down, both DCs would be unavailable and the remote PCs will be unable to resolve any addresses, preventing them for surfing the internet/checking email/etc.
Adding a DC in each network is out of question (they are of 5/10 PCs), and the same can be said about creating a direct VPN tunnel from the remote network to the secondary DC site (due to hardware capacity).
A tertiary, public DNS server would prevent this, but I wonder if it can cause problems (ie: if it is, for some reason, selected as the preferred DNS, the PC would be "disconnected" from the domain).
So: it is ok to use a tertiary public DNS on a domain-joined PC, or it will cause problems? Anything to be aware of?
Для корректной работы домена компьютеры Windows должны иметь возможность выполнять поиск в DNS-зоне, используемой для AD.
Если клиенты направлены на сервер, который не дает правильных ответов для этой зоны AD, то эти системы, вероятно, в какой-то момент выйдут из строя.
Важно понимать, что если клиент выполнил DNS поиск записи типа _gc._tcp.yourdomain.example.org или другой внутренней записи на этом третьем внешнем сервере, то этот сервер ответит с ошибкой, которая не найдена. Ваш клиент не будет повторять этот запрос к вашим контроллерам домена. Ответ "не найден" вполне корректен.
Если вам нужна дополнительная избыточность для DNS на ваших внешних сайтах, я бы посмотрел на любое устройство, на котором запущен этот VPN, или на устройство, действующее в качестве маршрутизатора/брандмауэра. Посмотрим, может ли одно из этих устройств действовать в качестве кэширующего DNS сервера. Возможно, вы сможете заставить его пересылать внутренние DNS запросы на контроллеры домена, а не внешние запросы - на весь мир. Или, возможно, запустить DNS сервер в облаке, который будет пересылать все внутренние запросы на ваши контроллеры домена, и использовать любой метод рекурсии для других запросов.
.То, что я делаю в нашей сети (много крошечных офисов, все соединены звездообразно с нашими центральными DC), это имею пару маленьких дешевых Raspberry Pi серверов в каждом офисе. Я использую два для отказоустойчивости. Эти вторичные наши AD DNS домены от первичных DNS/AD серверов, но также знают, как добраться до остальной части мировой DNS без прохождения через DC вообще.
Если VPN офиса падает, то Pi серверы продолжают обслуживать DNS, и только наши внутренние системы через VPN становятся временно недоступными. Все остальное остается незатронутым.
Кэширования DNS с использованием DC в качестве первичного источника и публичного DNS в качестве вторичного может быть недостаточно, так как он все равно будет использовать публичный DNS для всей рекурсии, отвечая с помощью NXDOMAIN для некэшированных внутренних адресов, когда нет связи между сайтами. Вот почему решение @roaima, будь то Raspberry Pi, любая рабочая станция, преобразованная в BIND сервер или встроенный DNS сервер на вашем VPN маршрутизаторе, было бы идеальным: я бы порекомендовал передавать полные зоны на все сайты. Для этого сервера публичная DNS может быть форвардером для остальных, но я бы никогда не стал переадресовывать ее непосредственно клиентам.
Это нечто большее, чем просто локальная DNS в качестве преобразователя для AD домена.
Если ваша VPN-сеть site-to-site должна работать в обоих направлениях, разделение может временно приостановить динамическое DNS-обновление. Способен ли локальный DHCP кэшировать их, или как это устроено, потому что клиентский компьютер не перерегистрирует автоматически свое DNS имя по окончании разделения.
Правильный профиль брандмауэра Windows (домен / частный / публичный) основан на возможности аутентифицироваться с контроллером домена. Если клиент запускается во время разделения, он может иметь неправильный профиль до следующего переподключения или перезагрузки, что может быть хуже, чем проблема
NXDOMAIN.Если удаленный сайт имеет довольно неограниченное подключение к основному сайту, то разделение туннеля в целом может сделать вашу сеть уязвимой, если только ваш VPN маршрутизатор не является также расширенным брандмауэром / UTM. Разумный выбор маршрутизатора может на самом деле упростить настройку DNS, поскольку такие решения, скорее всего, будут иметь встроенный полнофункциональный DNS-сервер. Более того, настройки проще разворачивать на всех сайтах по сравнению с настройками, построенными с нуля.