Почему Windows перестает резолвить внутренние DNS?
Проблема:
Рабочие места(не в домене) на Windows 7 pro периодически перестают резолвить имена внутрисетевых серверов.
При этом перезапуск сети, а так же вполение команды "ipconfig /renew" или "ipconfig /flushdns" - нормализует работу.
При чем два Win 7 pro x64 в одной подсети. С одинаковым набором обновлений. У одного есть поблемы с разрешением внутренних имен, а у другого - нет.
При этом оба одинаково без проблем разрешают внешние имена (в частности one.one.one.one)
Как все устроено:
Есть несколько офисов, объединенные в сеть без домена.
Обращение к серверам - по IP
В качестве начального этапа на пути к домену выбрано создание контроллера и использование его DNS в одноранговой сети (правильные DNS клиентам выдаются роутером).
В дополнение к DNS от контроллера домена (Windows 2012 R2), существует резервный DNS - BIND, который корректно синхронизирует зоны с первичного DNS (DC).
Клиенты - преимущественно Windows 7 (по причине имеющихся лицензий).
В какую сторону копать? Как можно причину такого странного поведения?
Или может кто уже сталкивался с таким?
В ответе должен быть указан IP сервера который ответил на DNS запрос
nslookup fileserver
nslookup fileserver.corp.local
Потом попробуй сам указать в запросе DNS сервер, я привел пример с 1.1.1.1, ты должен подставить свой локальный сервер
nslookup fileserver 1.1.1.1
nslookup fileserver.corp.local 1.1.1.1
Так же хорошей практикой будет отдавать по DHCP суффик DNS зоны. В твоем пример это corp.local.
Когда будет запускать ping fileserver, ПК сам должен дописать суффикс corp.local.
В настройках ПК не должно быть других DNS кроме внутреннего. Все запросы должны должны проходить через внутренний DNS.
Valentin Barbolin,
Через nslookup я производил принципиальную проверку работы DNS-серверов, но не диагностику в момент обнаружения проблемы.
Попробую так проверить при возникновении проблемы...
Зона corp.local - раздается роутером.
Да, некоторые роутеры (например mikrotik) позволяют перенаправлять трафик для определенной зоны на указанный DNS. Это так же можно реализовать с помощью firewall и перехватывать-перенаправлять все запросы на 53 порт для определенной зоны, но лучше использовать встроенный функционал роутера, на самих же клиентах указывать в качестве DNS только IP роутера, что бы все запросы шли через него.
Так же не стоит забывать, что некоторые браузеры могут использовать DOH и игнорировать локальные DNS настройки.
Для микротика
ip dns static> add regexp=".*\\.corp\\.local\$" forward-to=10.0.0.1
ip dns static> add regexp=".*\\.local\$" forward-to=10.0.0.1
Valentin Barbolin,
да, роутер - Микротик, но перенаправления трафика по ДНС не реализовано.
DHCP сервер микротика выдает клиенту IP, Gateway, DNS servers, Domain
Браузеры тут не при чем, проблема бывает исключительно при обращении к файловым серверам или RDP.
Valentin Barbolin,
касательно того проблемного компа: убрал внешние dns и все стало резольвиться корректно. Я перевел всю сеть только на внутренние DNS и считал вопрос решенным.
Но тут отвалился из сети контроллер (по физическим причинам) и всплыла проблема, что клиенты не резольвят с вторичных внутренних DNS !
Для чистоты эксперимента подопытного клиента ввел в АД, сеть изменилась на доменную.
кладу 1.41
# nslookup fs.corm.local
DNS request timed out.
timeout was 2 seconds.
╤хЁтхЁ: UnKnown
Address: 192.168.1.41
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Превышено время ожидания запроса UnKnown
- клиенту все равно на резервный ДНС.
Допускаю что резервный (на линуксе) - где-то не так себя ведет.
Меняю в настройках сети клиента порядок ДНС: первый - резерв, второй - АД
Включены оба ДНС:
# nslookup fs.corp.local - резолвит с 192.168.1.42
кладу 1.42
# nslookup fs.corm.local
DNS request timed out.
timeout was 2 seconds.
╤хЁтхЁ: UnKnown
Address: 192.168.1.42
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Превышено время ожидания запроса UnKnown
Таким обрезом получаю, что оба ДНС сервера работают корректно, а мозги делает клиент, которому пофиг на вторичные ДНС-сервера!
В чем может быть причина такого?
Сергей, После "кладу 1.41" надо выполнить команду nslookup fs.corp.local 192.168.1.42. Надо убедиться, что у тебя синхронизированы зоны, а не просто форвард запросов с 1.42 на 1.41
винда с ДНС работает так, что отправляет запрос на любой на свое усмотрение, а не по порядку в списке
Это не совсем так, в group policy можно определить как windows будет работать с DNS. Можно поочереди перебирать DNS, можно одновременно на все DNS отправлять запрос и использовать первый пришедший ответ.
Максим Слепенков, В windows 10 они сделали интересную оптимизацию для ускорения интернета. Если включить эту политику, то оптимизация будет выключена и windows будет поочереди опрашивать DNS в порядке который указан на сетевом интерфейсе.
Так же в рамках NRPT можно гибко определить DNS для опеределенной зоны
при указании конкретного dns резолв происходит нормально.
Т.е. если первичный - 1.41 - кладу его
# nslookup fs.corp.local - говорит что не может и ссылается на 1.41
тут же делаю nslookup fs.corp.local 192.168.1.42 - все ок.
И наоборот: когда первым указан резерв, кладу резерв - остается MS DNS - сам держатель зон. Он не отвечает при
nslookup fs.corp.local
но если тут же nslookup fs.corp.local 192.168.1.41 - все ок.
в HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\ - раздел "DNSClient" отсутствует
поведение при резолве такое же как 7ки:
- резолв с указанием каждого dns-сервера - работает
- при отключении первого из указанных в настройках dns-а - резолв не происходит, даже если 2й - сам контроллер домена.
PS. Win 10 Pro, ver 2004 сборка 19041.330 (из какого-то старого образа развернута) - есть ли смысл поднимать самую последнюю версию для диагностики или будет то же самое?
Если это может пролить свет - могу хоть 11ю или любую другую сделать.
WINS - это не DNS.
Если собрались делать домен, то на WINS не обращайте внимания. WINS считается вредным артефактом.
Компы не пингуюся по имени, потому что используют WINS.
В домене будут использовать DNS.
