Проблемы конфигурации DNS. Клиенты в сети, не могущей разрешить название сервера DNS
Как я заявил в своем предыдущем ответе на Ваш вопрос, атаки "человек посередине" (если успешный) могут владеть всеми данными, переданными назад и вперед для зашифрованного канала.
Сертификаты, оба самоподписанные и выпущенные от доверяемого корня, могут фальсифицироваться, не убаюкивайтесь в ложное чувство защищенности при издании того пользователям от доверяемого корня. Единственная проблема, которую я должен преодолеть с одним выпущенным доверяемым корнем, заставляет Вашего пользователя принимать моего, когда я arp-отравил их компьютер. Если бы Вы думаете о большинстве конечных пользователей, насколько легкий это было бы?
Можно ли видеть проблемы теперь?
После того как конечный пользователь принимает МОЙ сертификат, я владею соединением от той точки вперед, и все данные проходят через мою машину.
У вас должна быть запись PTR в определении вашей обратной зоны (rev.1.168.192.in-addr.arpa), что-то вроде
2 PTR dns.domain.com
Также для выполнения прямого просмотра вам необходимо настроить запись NS для определения зоны пересылки (domain.com.db)
dns NS 192.168.1.2
Записи в файлах зон считаются относительными без точки в конце, поэтому это ...
2 IN PTR dns-serv1
2 IN PTR mydomain.com
... на самом деле означает ...
2 IN PTR dns-serv1.1.168.192.in-addr.arpa.
2 IN PTR mydomain.com.1.168.192.in-addr.arpa.
... что не делает
Вы, вероятно, захотите:
2 IN PTR dns-serv1.mydomain.com.
Я немного удивлен, что Windows все равно не показывает вам содержимое записи PTR . Как выглядит блок зоны для обратной зоны в named.conf.local ?