DNS-клиент против Nslookup — ручное тестирование DNS-клиента на наличие записей SRV

DNS-клиент против Nslookup — ручное тестирование DNS-клиента на наличие записей SRV

Существуют различные ссылки (например,DNS не может разрешить имя хоста; nslookup можетилиhttps://web.archive.org/web/20160525082756/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.htmlилиhttps://web.archive.org/web/20121113214415/http://cbfive.com/blog/post/PING-vs-NSLookup.aspx), в которых указано следующее или что-то подобное, но не даны предложения по использованию альтернатив:

Причина, по которой ping не может разрешить имя хоста, а nslookup может, заключается в том, что nslookup — это низкоуровневый инструмент, который обходит DNS-клиент Windows. Он использует любой DNS-сервер, который вы ему укажете (первый по умолчанию), и выполняет запрос на лету.

Мой вопрос в том, как я могувручнуюпротестировать DNS-клиент для проверки записи SRV? Есть ли способ увидеть информацию DNS, которую он пытается использовать? Я не могу установить Wireshark на каждом сервере в каждой среде, поэтому я ищу другой способ устранения неполадок. Я предполагаю, что ответ «нет», иначе зачем бы мы использовали nslookup (несовершенный, каким бы он ни был). Очевидно, я не могу использовать ping для записи SRV.

Отредактировано с обновленными результатами: Запросы UDP слишком длинные, поэтому ответ DNS с флагом усечения отправляется клиенту, поэтому необходимо сделать запрос TCP. Следующий пакет после запроса TCP DNS (от TargetDNS клиенту): "TCP-сегмент собранного PDU" (который выглядит так, как будто содержит информацию об ответе), а затем отличается в зависимости от сценария:

  • Запрос nslookup - при запросе nslookup фактически отправляется пакет ответа DNS с информацией
  • ApplicationX (который, как я полагаю, использует Windows DNS Client) - запрос клиента Windows DNS, нет пакета ответа DNS (т.е. как будто другой TCP-пакет был утерян)
    • В кэше DNS (ipconfig /displaydns) или в кэше клиентского DNS-сервера для записи SRV ничего нет (даже отрицательного).

Это доказывает, что неудивительно, что DNS-клиент и nslookup получают разные результаты, но что именно они делают по-разному (дисконтирование хостов, lmhosts, добавление суффиксов поиска DNS и т. д.)? Они используют одни и те же DNS-серверы (что подтверждает Wireshark). Как мне сузить круг возможных неисправностей?

решение1

Вы правильно понимаете, что nslookupDNS-клиент действует сам по себе, отдельно от того, что делает ОС от имени типичных приложений.

Командлет Powershell Resolve-DnsName, с другой стороны, использует базовый DNS-клиент Windows. Таким образом, это инструмент, который можно использовать для запуска обычного поведения ОС для поиска DNS (или других источников, несмотря на название!), отдельно от вашего приложения.

Например, что-то вроде этого в качестве примера поиска SRV:

Resolve-DnsName -Type SRV _sip._tcp.example.com

Примечание:
Поведение nslookupи ему подобных (обычно digявляется предпочтительным инструментом в этой категории) полезно для исследования поведения DNS, в частности потому, что локальная среда не влияет на результаты, но в то же время это делает эти инструменты непригодными для исследования поведения локальной среды ОС.

Связанный контент