Предисловие: я не администратор Windows. Я администратор Linux.
У меня есть сервер Windows 2016 с AD DNS, который обрабатывает внутренний DNS прямой и обратный поиск.
Где-то каким-то образом какой-то процесс автоматически добавляет записи обратного просмотра PTR для CNAME. Это нарушает нашу аутентификацию Kerberos для SSH между серверами, поскольку канонический поиск хоста с CNAME будет возвращать слишком много FQDN и блокировки Kerberos.
Проблема Kerberos SSH была решена, когда я удалил обратный поиск CNAME.
Тогда, на следующий день, готово! все записи PTR -> CNAME вернулись в AD DNS
Пример сверху (я изменил имена на общие, но общая настройка такая же):
Пара блоков сетевых операций, которые запускают SMTP и прокси-сервер Squid, имеют записи A
netops01.example.com -> 10.1.2.3
netops02.example.com -> 10.4.5.6
И в этом же ящике есть CNAME
netops
proxy
mailserver
По какой-то причине в AD DNS есть такие записи обратного просмотра:
3.2.1.10.in-addr.arpa. 3600 IN PTR netops.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR proxy.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR mailserver.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR netops01.example.com
Последняя запись - это запись A для этого хоста. Все остальные - это CNAME для этой записи A + еще одна запись A для второго хоста.
Ни я, ни другой администратор, занимающийся операциями, не создавали их. Мы также не устанавливали никаких запланированных задач для воссоздания обратного просмотра. Я также не могу представить себе вескую причину для использования точки обратного просмотра для CNAME или нескольких результатов. (Может быть, на это есть веская причина? Впрочем, я никогда раньше этого не делал)
Итак, я удалил все обратные поиски, кроме записи A. Kerberos SSH работает!
На следующий день все записи вернулись.
Я даже не уверен, как в Windows устранять неполадки (поэтому мое предисловие вверху)
Отвечая самому себе
Я нашел то, что мне не хватало. Две вещи:
На самом деле это не были CNAME. Это были записи A с несколькими хостами, перечисленными с целью балансировки нагрузки.
Поскольку это были A-записи, у них был флажок в строке «автоматически создавать связанную запись PTR».
Я снял отметку с этих записей. На самом деле это не помогло решить описанную здесь проблему: записи PTR все еще перестраиваются каждое утро.
тем не мение, в любом случае, это не то решение, которое я искал. Основная проблема заключалась в том, что Kerberos не работал. Что ж, это было легко решить, добавив параметр "rdns" в /etc/krb5.conf
[libdefaults]
rdns = ложь
По умолчанию Windows всегда пытается зарегистрировать как прямой, так и обратный поиск, используя динамический DNS.
Вы можете отключить эту функцию либо на клиентах, которые регистрируются сами, либо на DNS-сервере, либо на обоих. Самый быстрый способ решить вашу непосредственную проблему - отключить поддержку динамического DNS для соответствующих зон обратного просмотра. В долгосрочной перспективе, в зависимости от ваших обстоятельств, вы можете захотеть отключить его также и в передних зонах.
Я нашел снимок экрана с соответствующими настройками DNS-сервера. Вот. Вы хотите выбрать «Нет».
Подробнее об отключении динамического обновления на клиентах Вот и Вот. Это не обязательно, но в противном случае клиенты будут генерировать периодические сообщения журнала событий, потому что запросы динамического DNS отклоняются сервером.
NB: вам не следует отключать динамические обновления на контроллерах домена Active Directory или для зон Active Directory, таких как _msdcs
которые используются контроллерами домена для хранения информации об инфраструктуре домена. Это нарушит работу Active Directory.