[轉錄]關於BIND8與BIND9的一個問題

關於BIND8與BIND9的一個問題
出處：http://bbs.chinaunix.net/forum/viewtopic.php?t=406740

作者：abel
問題之提出：

[root@mail root]# dig mx nukabe.cn

; <<>> DiG 9.3.0rc2 <<>> mx nukabe.cn
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15736
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nukabe.cn. IN MX

;; Query time: 24 msec
;; SERVER: 202.96.128.143#53(202.96.128.143)
;; WHEN: Thu Sep 9 15:18:18 2004
;; MSG SIZE rcvd: 27

[root@mail root]# dig mx nukabe.cn

; <<>> DiG 9.3.0rc2 <<>> mx nukabe.cn
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4049
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nukabe.cn. IN MX

;; ANSWER SECTION:
nukabe.cn. 3600 IN MX 10 202.103.156.24.

;; AUTHORITY SECTION:
nukabe.cn. 86400 IN NS ns.xinnetdns.com.
nukabe.cn. 86400 IN NS ns.xinnet.cn.

;; ADDITIONAL SECTION:
ns.xinnet.cn. 2870 IN A 202.106.124.195
ns.xinnetdns.com. 161267 IN A 210.51.170.66

;; Query time: 99 msec
;; SERVER: 202.96.128.143#53(202.96.128.143)
;; WHEN: Thu Sep 9 15:18:20 2004
;; MSG SIZE rcvd: 143

[root@mail root]#

在我的伺服器上,經常遇到這種情況,使用dig mx domain.com的時候,經常找不到功能變數名稱的記錄,有時侯又正常
出現這種情況會是什麼問題引起的呢?是我本地ISP提供的DNS伺服器的問題,還是在domain.com功能變數名稱解析伺服器的問題呢?

還有,我使用我公司linux+qmail的郵件伺服器發郵件到對方的linux+qmail郵件伺服器的時候,我觀察我本地的log日誌,出現如下的提示,對方沒有收到郵件:
Sep 9 15:09:28 mail qmail: 1094713768.604001 delivery 132: deferral:
Connected_to_202.103.xxx.xxx_but_sender_was_rejected
./Remote_host_said:_450_4.4.1_Sender_domain_not_found_in_DNS/



非常不明白為什麼會出現這樣的情況,是DNS的問題嗎?
但是我使用21cn.com的郵件而不使用我公司的linx+qmai郵件系統發郵件到對方的伺服器就很正常


請幫忙分析

-----------------
問題之解答：

dns 的設定有太多錯誤...
nukabe.cn 設的沒有錯
但他的代管業者一推問題
你用 ISP 的解不出來原因在於 ISP Run BIND 9.X,
其在像 21cn.com .. 都跑 BIND 8.X
因為 BIND 9 對 DNS 的設定 (授權關係,NS RRs) 檢查較嚴格

查看 nukabe 在 .cn 下的 NS 記錄

[root@ns11 resolv]# dig @dns3.cnnic.net.cn ns nukabe.cn
;nukabe.cn. IN NS
;; AUTHORITY SECTION:
nukabe.cn. 86400 IN NS ns.xinnet.cn.
nukabe.cn. 86400 IN NS ns.xinnetdns.com.

;; ADDITIONAL SECTION:
ns.xinnet.cn. 86400 IN A 202.106.124.195


發現授權給 上述兩部 DNS Server, 但 Domain 不同於 nukabe.cn
BIND 8 在這裏會看到 202.106.124.195 這個 IP , BIND 9 跟本不甩這
個 IP (這是很大的差別哦...BIND 8 相信 Additional, BIND 9 完全不用
Addtional Section,因為安全上及解析的正確性的考量)
BIND 8,二選一找一部,若選到 ns.xinnet.cn. 就直接往 202.106.124.195
查 MX 記錄了,若選到 ns.xinnetdns.com. 則因為沒有 Addtional 資料可
資,所以往 .com 的查 ........
以 dig @a.gtld-servers.net xinnetdns.com. ns 可以在 addtional 看到

ns.xinnetdns.com. 123026 IN A 210.51.170.66

所以 bind 8 就會對 202.106.124.195/210.51.170.66 查 cukabe.cn 的 MX 記錄
所以都可以查得到 MX 記錄



所以,我們以 BIND 9 來看,他不會用 addtional section 所帶出來的 IP,他以
AUTHORITY Answer (簡稱 AA) 為依據

所以我們再查 .cn 下的 xinnet.cn 的 NS 記錄

[root@ns11 resolv]# dig @dns3.cnnic.net.cn xinnet.cn. ns
;ns.xinnet.cn. IN NS

;; AUTHORITY SECTION:
xinnet.cn. 86400 IN NS ns2.xinnet.cn.
xinnet.cn. 86400 IN NS ns2.xinnetdns.com.
xinnet.cn. 86400 IN NS dns2.xinnet.com.
xinnet.cn. 86400 IN NS ns.xinnet.cn.
xinnet.cn. 86400 IN NS ns.xinnetdns.com.
xinnet.cn. 86400 IN NS dns.xinnet.com.

;; ADDITIONAL SECTION:
ns.xinnet.cn. 86400 IN A 202.106.124.195
ns2.xinnet.cn. 86400 IN A 210.51.170.67

查出來有 6 筆,這六筆就是 xinnet.cn 的權威資料所在

所以我們選第一部來看其自身domain (xinnet.cn) 的 NS 記錄

[root@ns11 resolv]# dig @ns2.xinnet.cn. xinnet.cn. ns
;xinnet.cn. IN NS

;; ANSWER SECTION:
xinnet.cn. 1800 IN NS ns2.chinadns.com.
xinnet.cn. 1800 IN NS ns.chinadns.com.
xinnet.cn. 1800 IN NS dns.xinnet.com.
xinnet.cn. 1800 IN NS dns2.xinnet.com.

發現了什麼 !? .cn 說 xinnet.cn 是由上述六部管理的
ns2.xinnet.cn 又說 xinnet.cn 是由這四部管理的
請問, DNS 要相信誰呢 !? (其他我就不列了)

我只能說,這家代管業者(應該是有做DNS代管業務吧) dns 技術能力太差,所以會出現許多你
預期外的東西,因為他們連 BIND 8/9 的差異都分不清,且對 DNS 授權的概念也不清,
他們犯的錯誤造成 BIND 9 (就是你 ISP 提供的 DNS Server) 對 nukabe.cn
所有的資料 (不只 MX) 會有時解的出來,有時解不出來

你的 ISP 沒有錯,就算有錯也只是用了對解析過程較嚴格的 BIND 9
nukabe.cn 的代管業者才是錯誤的源頭