似乎無法解析域，但可以探勘它
我的主名稱伺服器中有一個有趣的錯誤。我正在使用綁定 9.3.4 執行 Fedora Linux。伺服器計劃更換，因為它很舊，但我必須同時讓它工作。問題是我的名稱伺服器無法解析 digbypines.ca。digbypines.ca 的權威名稱伺服器是 204.15.193.162 和 204.15.193.163。我的名稱伺服器位於 24.222.7.12。
防火牆錯誤（其中傳出的 DNS 連接被 SNAT 到埠 53）導致無法聯繫 digbypines.ca 的名稱伺服器。因此，如果我要在 24.222.7.12 連接到我的名稱伺服器並執行
dig @204.15.193.162 digbypines.ca我會得到
;; connection timed out; no servers could be reached如果我嘗試在埠 53 上遠端登錄到 204.15.193.162，我也會超時。既然如此，我刪除了 SNAT 防火牆規則，現在上面的命令按預期工作了。但這是有趣的部分。
出於某種原因，我無法說服 bind 與 digbypine 的名稱伺服器對話！即使修復了 SNATting，它也不起作用。
執行 ‘dig +trace digbypines.ca’ 表明我將獲得 NS 記錄，但它拒絕解決它們：
探勘 + 跟踪 digbypines.ca
; <<>> DiG 9.3.4-P1 <<>> +trace digbypines.ca ;; 全域選項： printcmd 。516709 IN NS
i.root-servers.net。. 516709 在 NS
j.root-servers.net。. 516709 在 NS
k.root-servers.net。. 516709 IN NS
l.root-servers.net。. 516709 IN NS
m.root-servers.net。. 516709 IN NS
a.root-servers.net。. 516709 在 NS
b.root-servers.net。. 516709 IN NS
c.root-servers.net。. 516709 IN NS
d.root-servers.net。. NS 516709
e.root-servers.net。. 516709 IN NS
f.root-servers.net。. 516709 在 NS
g.root-servers.net。. 516709 IN NS
h.root-servers.net。;; 在 1 毫秒內從 192.168.0.12#53(192.168.0.12) 接收到 408 個字節
約 172800 IN NS l.ca-servers.ca。約
172800 在 NS sns-pb.isc.org 中。約 172800 IN NS m.ca-servers.ca。約 172800 IN
NS c.ca-servers.ca。約 172800 IN NS
a.ca-servers.ca。約 172800 IN NS
j.ca-servers.ca。約 172800 IN NS
f.ca-servers.ca。約 172800 IN NS
k.ca-servers.ca。約 172800 IN NS
z.ca-servers.ca。約 172800 IN NS
e.ca-servers.ca。;; 在 120 毫秒內從 192.36.148.17#53(i.root-servers.net) 收到 430 個字節
digbypines.ca。86400 IN NS ns2.extremehosting.ca。digbypines.ca。86400 在 NS ns1.extremehosting.ca 中。;; 在 31 毫秒內從 156.154.101.4#53(l.ca-servers.ca) 收到 114 個字節
探勘：無法獲取“ns2.extremehosting.ca”的地址：失敗
我有點卡住了。我打電話給他們的支持小組，他們向我保證我的 IP 沒有被阻止。我真的不確定如何在命令行上探勘他們的名稱伺服器，但無法通過綁定進行相同的操作。
我還嘗試重新啟動綁定、網路和執行“rndc flush”。沒愛。
我可以在家解決 digbypines.ca 以及 ns2.extremehosting.ca 和 ns1.extremehosting.ca，所以我不確定發生了什麼。
我也可以
dig @204.15.193.163 ns2.extremehosting.ca從我的名稱伺服器的命令行成功執行。
嗯，我解決了。原來在我之前的系統管理員已經將所有傳出查詢強製到埠 53。extremehosting.ca 的名稱伺服器似乎阻止了埠 53 上的傳入連接，這些連接源自埠 53，因此我無法與它們通信。
通過從 named.conf 中刪除這些行：
query-source port 53; query-source-v6 port 53;並確認防火牆不會導致任何進一步的問題，名稱解析再次起作用。
此外，我發現這篇有助於確定您的名稱解析器的源埠行為的文章非常有幫助。解決這個 DNS 問題的副作用是我還插入了一個潛在的名稱記憶體中毒漏洞。
感謝所有發表評論的人。