Domain-Name-System

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

  • June 17, 2014

我的團隊有一個指向 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