為什麼 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