為什麼 dig +trace 有時會針對 Windows Server DNS 失敗？

我的團隊有一個指向 Active Directory 提供的 DNS 的伺服器，以確保它能夠訪問該域管理的任何主機。不幸的是，我的團隊也需要dig +trace經常執行，我們偶爾會得到奇怪的結果。我是 DNS 管理員，但不是域管理員，但負責這些伺服器的團隊也不確定這裡發生了什麼。

問題似乎在作業系統升級之間轉移，但很難說這是作業系統版本的特徵還是升級過程中更改的其他設置。

• 當上游伺服器是 Windows Server 2003 時，第一步（來自第一個條目的dig +trace請求）偶爾會返回 0 字節響應。. IN NS``/etc/resolv.conf
• 當上游伺服器升級到 Windows Server 2012 時，零字節響應問題消失了，但取而代之的是我們偶爾會獲取 DNS 伺服器上配置的轉發器列表的問題。

第二個問題的例子：

$ dig +trace -x 1.2.3.4      

; <<>> DiG 9.8.2 <<>> +trace -x 1.2.3.4
;; global options: +cmd
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.
;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms

1.in-addr.arpa.         84981   IN      NS      ns1.apnic.net.
1.in-addr.arpa.         84981   IN      NS      tinnie.arin.net.
1.in-addr.arpa.         84981   IN      NS      sec1.authdns.ripe.net.
1.in-addr.arpa.         84981   IN      NS      ns2.lacnic.net.
1.in-addr.arpa.         84981   IN      NS      ns3.apnic.net.
1.in-addr.arpa.         84981   IN      NS      apnic1.dnsnode.net.
1.in-addr.arpa.         84981   IN      NS      ns4.apnic.net.
;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms

1.in-addr.arpa.         172800  IN      SOA     ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net.
4827 7200 1800 604800 172800
;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms

在大多數情況下，這不是問題，但dig +trace如果我們在 AD 具有內部視圖的域內進行跟踪，則會導致走錯路。

為什麼會dig +trace失去理智？為什麼我們似乎是唯一抱怨的人？

你被根提示控制了。這個解決起來很棘手，它取決於理解. IN NS在跟踪開始時發送的查詢沒有在數據包上設置RD（需要遞歸）標誌。

當 Microsoft 的 DNS 伺服器收到對根名稱伺服器的非遞歸請求時，它們可能會返回配置的根提示。只要您不將RD標誌添加到請求中，伺服器就會很高興地整天繼續返回具有固定 TTL 的相同響應。

$ dig @192.0.2.11 +norecurse . NS

; <<>> DiG 9.8.2 <<>> @192.0.2.11 +norecurse . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12586
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.

;; ADDITIONAL SECTION:
dns2.ad.example.com.    3600    IN      A       192.0.2.228
dns1.ad.example.com.    3600    IN      A       192.0.2.229

這是大多數故障排除工作將失敗的地方，因為一個簡單的假設是dig @whatever . NS會重現問題，這實際上完全掩蓋了它。當伺服器收到對設置了標誌的根名稱伺服器的請求時RD，它會伸出手來獲取真正的根名稱伺服器的副本，並且所有後續. NS 沒有標誌的請求RD都將神奇地開始按預期工作。這又讓人dig +trace高興了，每個人都可以回去撓頭，直到問題再次出現。

您的選擇是與您的域管理員協商不同的配置，或者解決該問題。只要有毒的根提示在大多數情況下都足夠好（並且您知道它們不適合的情況：衝突的觀點等），這並不是一個巨大的不便。

一些不更改根提示的解決方法是：

• 在預設解析器較少的機器上執行您的跟踪。
• 從名稱伺服器開始跟踪，該名稱伺服器返回 Internet 的根名稱伺服器以響應. NS. 您也可以將此名稱伺服器硬連線到${HOME}/.digrc，但這可能會使共享帳戶上的其他人感到困惑，或者在某些時候被您忘記。 dig @somethingelse +trace example.com
• 在執行跟踪之前自己播種根提示。

dig . NS

dig +trace example.com

引用自：https://serverfault.com/questions/605081