Проблема с 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.

[Loyder]

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

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

То, что эти же самые DNS сервера на другом Windows компьютере работают нормально, может быть доказательством, что с DNS серверами все хорошо и проблема не в них ?
Это система заказчика, и поставить дополнительно Linux поиграться - скорее не вариант. Если есть понимание, что нужно настроить и куда смотреть на Linux - наверное, можно пробовать обсуждать. У меня такого понимания нет

[Palych]

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

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

То, что эти же самые DNS сервера на другом Windows компьютере работают нормально, может быть доказательством, что с DNS серверами все хорошо и проблема не в них ?
Это система заказчика, и поставить дополнительно Linux поиграться - скорее не вариант. Если есть понимание, что нужно настроить и куда смотреть на Linux - наверное, можно пробовать обсуждать. У меня такого понимания нет

На Линуксе я бы поигрался с resolv.conf (вполне возможно в windows можно сделать то же самое): оставить только один сервер, убрать hosts, переключать между серверами...

[Loyder]

Там обычно порядка 30 минут кэшируются положительные ответы, и несколько секунд отрицательные, что опять наводит на мысль, о failed reverse lookup.

Вот ответ в Wireshark:

dns_reverse_lookup_response.png

Вот результат nslookup:

Code: Select all

C:\Users\admin\Documents>nslookup -debug 10.198.126.28
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        199.199.199.10.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  199.199.199.10.in-addr.arpa
        name = lbaxxxxx.xxx.xx
        ttl = 86400 (1 day)

------------
Server:  lbaxxxxx.xxx.xx
Address:  10.199.199.199

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        28.126.198.10.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  28.126.198.10.in-addr.arpa
        name = SVMXXXX.xxx.xx
        ttl = 86400 (1 day)

------------
Name:    SVMXXXX.xxx.xx
Address:  10.198.126.28

Вот не видно здесь failed reverse lookup.

Несколько смущает, что нет authority records. Но может ли это быть проблемой? Другой ведь windows работает точно с такой же записью, и там проблемы нет.
Опять же - если failed reverse lookup - должны же следующие механизмы быть задействованы (NetBIOS, WINS) - но запросов к ним нет...
И в конце-концов - адрес ведь в имя разрешается (что в случае failed reverse lookup не должно быть, по идее)
(Надеюсь, я не совсем запутал )

[Loyder]

На Линуксе я бы поигрался с resolv.conf (вполне возможно в windows можно сделать то же самое): оставить только один сервер, убрать hosts, переключать между серверами...

Ясно, спасибо

[Palych]

Ещё посмотреть подробнее как DNS работает:
Может при каких-то обстоятельствах клиент ждет уточнений?.. например при non authority response ожидает более достоверных данных...

[uncle_Pasha]

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

Если "другой виндоз" (тоже кластер, к стати?) в той же сети работает нормально, то надо искать проблему в настройках резолвера сервера, IMHO.

[uncle_Pasha]

например при non authority response ожидает более достоверных данных...

Кто ж ему пришлет, если он сам не попросит...

[Palych]

А сколько интерфейсов на той машине?

[Loyder]

Если "другой виндоз" (тоже кластер, к стати?) в той же сети работает нормально, то надо искать проблему в настройках резолвера сервера, IMHO.

Нет, другой windows, где работает нормально - не кластер.
Проблема воспроизводится на нескольких кластерных серверах.

[Loyder]

А сколько интерфейсов на той машине?

Всего 8 интерфейсов, enabled - 4, на каждом сконфигурирован ipv4 адрес, на одном интерфейсе - несколько ipv4 адресов.
Default Gateway - только один.

Code: Select all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : SVXXXXX
   Primary Dns Suffix  . . . . . . . : XXX.XX
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : XXX.XX
   System Quarantine State . . . . . : Not Restricted


Ethernet adapter LACP1Public:

   Connection-specific DNS Suffix  . : xxx.xx
   Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver
   Physical Address. . . . . . . . . : AC-16-2D-74-C5-34
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.199.50.44(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Donnerstag, 1. M„rz 2018 15:00:00
   Lease Expires . . . . . . . . . . : Donnerstag, 23. Mai 2154 16:07:56
   IPv4 Address. . . . . . . . . . . : 10.199.50.40(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 10.199.50.41(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 10.199.50.42(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.199.50.1
   DHCP Server . . . . . . . . . . . : 10.193.131.13
   DNS Servers . . . . . . . . . . . : 10.199.199.199
                                       10.193.131.13
                                       10.194.131.13
   Primary WINS Server . . . . . . . : 10.193.131.13
   Secondary WINS Server . . . . . . : 10.194.131.13
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter LACP2SAP:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver #2
   Physical Address. . . . . . . . . : 84-34-97-F9-C1-20
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.199.51.18(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Heartbeat:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : HP Ethernet 1Gb 4-port 331FLR Adapter #2
   Physical Address. . . . . . . . . : AC-16-2D-74-C5-37
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.199.32.40(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 
   NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter Local Area Connection* 11:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter
   Physical Address. . . . . . . . . : 02-87-A2-05-43-8E
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 169.254.1.154(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 
   NetBIOS over Tcpip. . . . . . . . : Enabled