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是一种绕过Windows客户端的低级工具。它使用您告诉它的任何DNS服务器(默认情况下是第一个)，并动态执行查询。
我的问题是，我如何能够<#>手动测试DNS客户端来检查SRV记录？有没有办法查看它试图使用的DNS信息？我不能将Wireshark放在每个环境中的每个服务器上，所以我正在寻找另一种方法来排除故障。我猜想答案是“否”，否则我们为什么要使用nslookup (尽管它有缺陷)。显然我不能用ping来记录SRV。
根据更新的结果编辑: UDP查询太长，因此带有截断标志的DNS响应被发送到客户端，因此需要进行TCP查询。TCP查询后的下一个数据包是(从TargetDNS到客户端)：“重新组装的PDU的TCP段”(看起来包含响应信息)，然后根据场景不同：
- Nslookup查询-使用nslookup查询，实际上有一个包含以下信息的DNS响应包
- ApplicationX (我认为它使用Windows客户端)- Windows客户端查询，没有DNS响应包(即，与其他TCP数据包丢失一样) 。
- 在DNS缓存(ipconfig /displaydns)或客户端DNS服务器缓存中没有SRV记录(甚至不是否定的)。
毫不奇怪，DNS客户端和nslookup得到了不同的结果，但它们到底在做什么(打折主机、lmhost、附加DNS搜索后缀等等)？他们正在使用相同的DNS服务器(如Wireshark所证明)。我怎么才能缩小错在哪里呢？
回答 1
Server Fault用户
发布于 2022-04-14 15:29:30
您的理解是正确的，nslookup本身充当DNS客户端，与操作系统代表典型应用程序所做的操作不同。
另一方面，Powershell cmdlet Resolve-DnsName使用底层Windows客户端。因此，这是一个工具，可以用来触发DNS查找(或其他源，不管名称！)的正常OS行为，而不是您的应用程序。
例如，作为SRV查找的一个例子：
Resolve-DnsName -Type SRV _sip._tcp.example.comSidenote：nslookup等的行为(通常是此类别中选择的工具)对于调查DNS行为非常有用，特别是因为本地环境不影响结果，但同时也使这些工具不适合研究本地OS环境的行为。
https://serverfault.com/questions/1098612
复制相似问题
腾讯云开发者
