有各種參考資料（例如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://cb Five.com/blog/post/PING-vs-NSLookup.aspx）陳述以下內容或類似內容，但不提供替代方案的建議：
ping 無法解析主機名稱但 nslookup 可以的原因是因為 nslookup 是繞過 Windows DNS 用戶端的低階工具。它使用您告訴它的任何 DNS 伺服器（預設是第一個），並即時執行查詢。
我的問題是，我怎麼樣才能手動測試 DNS 用戶端以檢查 SRV 記錄？有沒有辦法查看它嘗試使用的 DNS 資訊？我無法在每個環境中的每個伺服器上都安裝 Wireshark，因此我正在尋找另一種方法來排除故障。我認為答案是“否”，否則我們為什麼要使用 nslookup（因為它是有缺陷的）。顯然我不能使用 ping 來取得 SRV 記錄。
編輯更新結果：UDP 查詢太長，因此帶有截斷標誌的 DNS 回應被傳送到客戶端，因此需要進行 TCP 查詢。 TCP DNS 查詢後的下一個封包是（從 TargetDNS 到客戶端）：「重組 PDU 的 TCP 段」（看起來包含回應資訊），然後根據場景的不同而有所不同：
- Nslookup 查詢 - 透過 nslookup 查詢，實際上有一個包含資訊的 DNS 回應封包
- ApplicationX（我相信使用Windows DNS客戶端） - Windows DNS客戶端查詢，沒有DNS回應資料包（即像其他TCP資料包一樣已經遺失）
- DNS 快取 (ipconfig /displaydns) 或用戶端 DNS 伺服器快取中沒有任何內容用於 SRV 記錄（甚至沒有負數）。
毫不奇怪，它證明 DNS 用戶端和 nslookup 得到不同的結果，但它們到底做了什麼不同的事情（折扣主機、lmhosts、附加 DNS 搜尋後綴等）？他們使用相同的 DNS 伺服器（Wireshark 證明）。如何縮小故障範圍？
答案1
您的理解是正確的，它nslookup本身充當 DNS 用戶端，與作業系統代表典型應用程式執行的任何操作分開。
Resolve-DnsName另一方面，Powershell cmdlet使用底層 Windows DNS 用戶端。因此，這是一個可用於觸發 DNS 查找（或其他來源，儘管名稱！）的正常作業系統行為的工具，與您的應用程式分開。
例如，作為SRV查找的範例：
Resolve-DnsName -Type SRV _sip._tcp.example.com
附註：等
行為（一般是該類別中選擇的工具）對於調查 DNS 行為很有用，具體是因為本地環境不會影響結果，但同時也使得這些工具不適合調查行為本地作業系統環境。nslookupdig