Проблема с reverse DNS запросами на клиенте

[Loyder]

Может быть кто-то сталкивался или подскажет, куда можно еще посмотреть.
Имеется Windows Server 2012, в MS cluster. В настройках TCP/IP протокола на нем сконфигурированы 3 днс сервера (он выступает в качестве DNS клиента).
С помощью nslookup с каждого из этих серверов все замачетельно резолвится (и прямые, и reverse записи (ip-адрес в имя).
Если запустить команду "netstat -a" - она долго отрабатывает - некоторые адреса быстро, некоторые - долго, по нескольку секунд.
"netstat -an" - работает быстро (понятно почему, она не разрешает ip-адреса в имена). При этом в момент работы netstat -a на сетевом уровне видно, что запросы к серверу обрабатываются в течение миллисекунд - то есть сервер отвечает быстро.
Вручную с помощью nslookup эти же адреса разрешаются быстро (миллисекунды).

Так же на сетевом уровне с помощью Wireshark смотрел в это время запросы NetBIOS, WINS - ничего нет подозрительного.

На уровне конфигурации ip протокола - тоже все хорошо. Нет никаких некорректных маршрутов, все DNS сервера (их 3) - исправно отвечают, маршруты до них корректные. Так же сконфигурированы 2 WINS сервера, но к ним практически не видно запросов.

Проблема проявляется только с reverse dns запросами, прямые - работают нормально, на уровне приложений никаких проблем не видно.
К серверам DNS - доступа нет, но судя по сетевому трафику и по работе nslookup - обратная зона сконфигурирована и работает корректно.

В какую сторону можно еще посмотреть? У меня как-то идей не осталось уже...

И скорее любопытство, кроме netstat -a, как-то еще можно проверить работу reverse dns средствами операционной системы (nslookup не показывает проблему). Работу прямых запросов - можно проверить, например, с помощью ping.

[Palych]

Я бы попробовал посмотреть что творится в strace netstat -a...

[Loyder]

Я бы попробовал посмотреть что творится в strace netstat -a...

Не очень понятно написал. Проблема на стороне Windows Server 2012, который выступает в качестве DNS клиента.
Поэтому на нем нет strace (беглым поиском особо не нашел аналога).

[uncle_Pasha]

Смотря кто коннектится - если адреса не локальные, то reverse lookup может занимать достаточно долгое время.
Возможно сервер не использует recursive query и пытается лезти во вне сети, а доступ заблокирован - в результате запрос отваливается только по таймауту. Снимите трассу Wireshark по UDP+TCP dst port 53 - все станет понятно.

[Loyder]

Снимите трассу Wireshark по UDP+TCP dst port 53 - все станет понятно.

Адреса локальные, nslookup на эти адреса выполняется за миллисекунды. В Wireshark - видно, что ответ приходит в течение миллисекунд. С этой точки зрения претензий к DNS серверу никаких нет.
Похоже, что nslookup - посылает запросы непосредственно к DNS серверу, и не использует локальный dns клиент.
А netstat использует локальный dns клиент, который вносит задержку только при разрешении reverse запросов.
Если хосты добавить в hosts файл - становится нормально. Но повторюсь, с DNS сервером - проблем нет - запросы обрабатываются быстро, никаких задержек нет.
[i

2018-04-14_20-27-04.png

Запросы видны по 2 раза - это потому кластер, с 2 сетевыми интерфейсами, я собирал пакеты на всех интерфейсах.

[Loyder]

2018-04-14_23-06-51_hided.png

Нашел альтернативу "netstat -a". Команда "ping -a" выполняет reverse lookup средствами DNS клиента.
Запускал "ping -a 10.198.126.28" .В Wireshark видно, что запрос к днс серверу был отправлен в 2.138 секунды, ответ получен в 2.139 секунды (то есть ответ пришел в течение 1 миллисекунды (округленно)).

Но первый ICMP запрос был отправлен к серверу спустя 4.7 секунды - в 6.89. Что происходило в течение этих 4 секунд ?

Повторная командa "ping -a 10.198.126.28" - уже не отправляет запрос к DNS серверу (берет имя из кеша) и сразу же начинает посылать ICMP пакеты, без дополнительной задержки.

[uncle_Pasha]

А что было в ответе? Если пакет посмотреть?
Возможно, DNS не смог разрешить адрес через DNS и отправил запрос через что-то еще - WINS(?) и что там на очереди.

[Palych]

Но первый ICMP запрос был отправлен к серверу спустя 4.7 секунды - в 6.89. Что происходило в течение этих 4 секунд ?

Я извиняюсь, но я это и предлагал попробовать выяснить с помощью strace

[uncle_Pasha]

Я извиняюсь, но я это и предлагал попробовать выяснить с помощью strace

Жопа у них, на виндах, с strace...

[Palych]

Я извиняюсь, но я это и предлагал попробовать выяснить с помощью strace

Жопа у них, на виндах, с strace...

Если я правильно понимаю - проблема проявляется у клиента.
Можно поднять линукс (хоть инсталляционый диск в VM) и посмотреть как оно оттуда выглядит...

[uncle_Pasha]

Если я правильно понимаю - проблема проявляется у клиента.
Можно поднять линукс (хоть инсталляционый диск в VM) и посмотреть как оно оттуда выглядит...

Palych, то, что может случиться на винде, возможно никогда не произойдет на линуксе.
IMHO, проблема в том, что обратная зона не прописана в DNS ("no response found" in the trace), а потом выползают дополнительные виндовые прелести.

[Loyder]

А что было в ответе? Если пакет посмотреть?
Возможно, DNS не смог разрешить адрес через DNS и отправил запрос через что-то еще - WINS(?) и что там на очереди.

В пакете - нормальный ответ (это видно на скриншоте). Других запросов NetBios, WINS - нет ( с помощью wireshark ничего не видно).
Другие сервера Windows нормально работают с этими же серверами DNS. Похоже, проблема проявляется только на серверах, входящих в MS Cluster.
Если добавить соответствующую запись в hosts файл - то все становится хорошо, этой дополнительной задержки нет.
Если запись берется из локального DNS кеша (после нескольких попыток) - то тоже нет этой дополнительной задержки.
Насколько понимаю, DNS клиент должен работать следующим образом:
1. Смотрит hosts файл
2. Смотрит локальный dns кеш
3. Посылает запрос к dns серверу
4. Посылает запрос NetBios, WINS.

Получается, что после 1 или 2 шага если получен успешный ответ - то все хорошо, дополнительной задержки нет.
Если ответ получен после 3 шага - то на 4 шаг - не переходит, но при этом что-то внутри себя делает (или я криво смотрю NetBIOS, WINS запросы - но не похоже, я вижу периодически широковещательные обновления для WINS, а вот запросов - не видно)

Дополнительное наблюдение - TTL установлено для этой записи в 86400 секунд, но фактически из кеша она пропадает через несколько десятков секунд (10-20 примерно).

Вот здесь описывается похожая проблема:
https://stackoverflow.com/questions/281 ... able-ip-ad
Но был применен workaround - поднят свой dns клиент...
Больше ничего похожего не находится...

[Loyder]

Жопа у них, на виндах, с strace...

Если я правильно понимаю - проблема проявляется у клиента.
Можно поднять линукс (хоть инсталляционый диск в VM) и посмотреть как оно оттуда выглядит...

На других серверах Windows - тоже прописаны эти же DNS сервера, и на них такой проблемы нет.
То есть проблема не c DNS сервером, а с DNS клиентом локальным.

strace на Windows - нет. На Linux смотреть - по идее, не поможет, так как проблема с локальным DNS клиентом.
Пробовал запускать ProcessMonitor, он записал лог на 300 Мбайт за примерно минуту. Запросы к DNS серверу - вижу в нем, PING (ICMP) запросы - не вижу... В общем - много всего лишнего с одной стороны, и не все ловится - с другой.

[Palych]

strace на Windows - нет. На Linux смотреть - по идее, не поможет, так как проблема с локальным DNS клиентом.

Как знать... возможно получится воспроизвести настройки клиента, которые вызывают такую же пробоему.

[uncle_Pasha]

Дополнительное наблюдение - TTL установлено для этой записи в 86400 секунд, но фактически из кеша она пропадает через несколько десятков секунд (10-20 примерно).

TTL определяет время кэширования для DNS, когда можно выдавать non-authoritative answer.
Виндовый резолвер ее не использует. Там обычно порядка 30 минут кэшируются положительные ответы, и несколько секунд отрицательные, что опять наводит на мысль, о failed reverse lookup.