У меня есть DHCP-сервер, настроенный на постоянное динамическое обновление записей DNS. DNS-сервер настроен на разрешение как безопасных, так и небезопасных обновлений (я знаю, что это небезопасно, но это только внутренняя сеть, без подключения к Интернету). Оба — Windows Server 2016.
Один домен, один лес.
Есть филиал, у которого другая подсеть (все еще тот же домен), с VPN между главным офисом и филиалом. Другой DC в филиале, который запускает DHCP (только для филиала) и DNS (для всего домена). Репликация между DC в главном офисе и филиалах работает нормально.
Ничего особенного не установлено относительно подсетей. Зоны прямого и обратного просмотра существуют для обеих подсетей в DNS.
Клиенты в главном офисе получают IP-адреса от контроллера домена в главном офисе, а DNS корректно обновляет их записи A и записи PTR.
Однако в филиале, хотя клиенты получают IP-адреса и создаются соответствующие записи A, для клиентов DHCP записи PTR не создаются. (Только для статических записей.)
Клиенты отправляют опцию 81 в пакете запроса DHCP с полным доменным именем, все флаги установлены на ноль.
Обратите внимание, что я разрешаю как безопасные, так и небезопасные обновления, поэтому это не должно быть вызвано отсутствием учетных данных. Я не настраивал учетные данные для обновлений DNS, но не вижу, как это может помочь, поскольку небезопасные обновления разрешены.
На клиентах установлен флажок «Зарегистрировать адреса этого подключения в DNS» (по умолчанию в Windows).
Я видел предложения настроить каждого клиента с опцией «Использовать DNS-суффикс этого подключения при регистрации DNS». Пока не пробовал, но не вижу, почему это должно как-то помочь. (Он отправляет FQDN, и это должен быть сервер, выполняющий регистрацию DNS.) И хотелось бы избежать необходимости настраивать всех клиентов вручную.
Кто-нибудь знает, связано ли это с тем, что в том же домене есть вторая подсеть?
И как мне правильно его настроить, чтобы DNS/DHCP понимали, что делать?
решение1
Решил проблему, обновив учетные данные на DHCP-сервере для филиала — на самом деле это не было связано с несколькими подсетями.
(Щелкните правой кнопкой мыши по IPv4 под именем домена на сервере DHCP, выберите «Дополнительно» и «Учетные данные», введите новую информацию о пользователе/пароле — это должна быть учетная запись непривилегированного пользователя, предназначенная только для этой цели, с неограниченным сроком действия пароля, и пользователь не сможет изменить пароль. Я говорю «непривилегированный» — но он должен быть членом группы DnsAdmin.)
На этом DHCP-сервере в филиале (и только на нем) учетные данные были установлены на реальную учетную запись пользователя, пароль которого был изменен несколько месяцев назад.
Поскольку небезопасные обновления были разрешены, неудачная аутентификация обычно не имела значения.
Но я думаю, что это имело значение, потому что мое доменное имя многоуровневое (internal.example.com), и AD создал зону прямого просмотра для "internal.example.com" и "example.com". И в зоне "example.com" динамические обновления были установлены на "Только безопасные", в то время как для "inernal.example.com" было установлено "Небезопасные и безопасные".
Таким образом, тот факт, что родительский домен не мог быть обновлен, каким-то образом привел к сбою обновления PTR.
(Обратите внимание, что добавление DHCP-серверов в группу DnsUpdateProxy в этом случае НЕ решило проблему.)