Как работает DNS в Windows 10 по отношению к контроллеру домена?

Как работает DNS в Windows 10 по отношению к контроллеру домена?

У меня локальная сеть, 10.10.10.1

Локальная сеть использует VPN для подключения к облачному контроллеру домена, работающему на DNS по адресу 172.16.0.1.

Для присоединения к домену и взаимодействия с ним Windows 10 требует, чтобы основной DNS был 172.16.0.1, а у меня вторичный DNS — 10.10.10.1

Настройки DNS

Мы добавили отказоустойчивое соединение, но не можем добавить второе VPN-соединение для отказоустойчивого соединения. DNS используется для входов в Windows и не более того. Отсутствие VPN для отказоустойчивого соединения не вызывает никаких проблем для компьютеров Windows.

Проблема в наших VOIP-телефонах и принтерах. Многие VOIP-телефоны имеют компьютеры, подключенные к ним через Ethernet, что делает VLAN несколько сложными.

Когда срабатывает аварийное переключение, телефоны и принтеры в течение минуты простаивают, пытаясь подключиться к DNS-серверу по адресу 172.16.0.1, и в конечном итоге снова начинают работать, используя вторичный DNS по адресу 10.10.10.1.

Насколько я понимаю, контроллер домена (в данном случае Linux) и/или Windows 10 требуют, чтобы основным DNS был контроллер домена.

Есть ли способ (групповая политика, редактирование реестра или скрипт), который заставляет Windows использовать вторичный DNS при попытке связаться с контроллером домена, чтобы я мог установить свой основной DNS как 10.10.10.1 для всего остального моего оборудования?

Если нет, то есть ли еще какие-то идеи, которые могли бы сработать?

решение1

Есть ли способ (групповая политика, редактирование реестра или скрипт), который заставляет Windows использовать вторичный DNS при попытке связаться с контроллером домена?

Нет, вторичный DNS-сервер используется только в качестве резервного, если первичный DNS не отвечает – Windows не будет разделять их использование на основе запрашиваемого домена. В лучшем случае, вы

Насколько я понимаю, контроллер домена (в данном случае Linux) и/или Windows 10 требуют, чтобы основным DNS был контроллер домена.

Нет, клиентская система просто требует, чтобы домен Active Directory (и все его поддомены) былиразрешимыйлюбым DNS-сервером, который вы используете, неважно, идет ли он напрямую или проходит через 10 DNS-серверов.

Итак, если у вас есть домен локальной сети, например, example.corpи AD настроен как его поддомен, вы можете добавить запись NS, указывающую на него — делегирование. (Это тот же механизм, который позволяет вам разрешать все миллионы доменов Интернета без необходимости напрямую настраивать каждый из их серверов имен.)

ad.example.corp.      NS     dc1.ad.example.corp.
dc1.ad.example.corp.  A      172.16.0.1
dc1.ad.example.corp.  AAAA   2001:db8:e27f::7

Если у локальной сети нет собственного домена или если это полностью отдельные ветви, то, скорее всего, нельзя использовать обычные DNS-делегирования, но ваш DNS-сервер локальной сети, скорее всего:

# dnsmasq
server=/ad.example.corp/172.16.0.1

# Unbound
stub-zone:
    name: "ad.example.corp"
    stub-addr: 172.16.0.1

Однако все эти механизмы требуют, чтобы DNS-сервер локальной сети мог связаться с контроллером домена AD, поэтому между ними должна быть какая-то форма маршрутизации или VPN.

Связанный контент