关于BIND8与BIND9的一个问题

问题之提出：
[quote:3a81d2f142="netocool "]
[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邮件系统发邮件到对方的服务器就很正常 


请帮忙分析
[/quote:3a81d2f142]


-----------------
问题之解答：

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

查看 nukabe 在 .cn 下的 NS 記錄
[code:1:3a81d2f142]
[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
[/code:1:3a81d2f142]

發現授權給 上述兩部 DNS Server, 但 Domain 不同於 nukabe.cn
BIND 8 在這裏會看到 202.106.124.195 這個 IP , BIND 9 跟本不甩這
個 IP  (這是很大的差別哦...BIND 8 相信 Additional, BIND 完全不用 
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 看到
[code:1:3a81d2f142]
ns.xinnetdns.com.       123026  IN      A       210.51.170.66
[/code:1:3a81d2f142]
[b:3a81d2f142]所以 bind 8 就會對 202.106.124.195/210.51.170.66 查 cukabe.cn 的 MX 記錄[/b:3a81d2f142]
所以都可以查得到 MX 記錄 



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

所以我們再查 .cn 下的 xinnet.cn 的 NS 記錄
[code:1:3a81d2f142]
[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

[/code:1:3a81d2f142]
查出來有 6 筆,這六筆就是 xinnet.cn 的權威資料所在

所以我們選第一部來看其自身domain (xinnet.cn) 的 NS 記錄
[code:1:3a81d2f142]
[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.
[/code:1:3a81d2f142]
發現了什麼 !? .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 的代管業者才是錯誤的源頭

你若有 DNS 的問題,建議來 DNS 版問,在 Linux 版會被淹沒 ...
弄清楚為什麼比在那猜測來的有意義多了

peng 回复于：2004-09-13 16:10:06

呵呵，这个问题俺在bind9一出来就遇见过。 说白了，都是不规范惹得祸。。

netocool 回复于：2004-09-14 10:26:57

这个问题困扰我很久了 兄弟你有什么办法呢? 我电话跟他们的800聊了,他们的回复是: figlec.com 得mx记录您指向了mail.figlec.com,然后在A记录中mail.figlec.com又指向您的服务器，这样得记录就会造成邮件得收发时出现问题，因为一般得邮局服务器在邮件收发时都会检测mx域和helo域，如果这两个域出现误差就会造成邮局得无法解析，所以，请您在mydns中修改mx指到您的邮局服务器得ip。 我已经按照他们的说法改了,但是还是不能解决问题..... 很忧郁....

peng 回复于：2004-09-14 11:23:11

[quote:0a98ef54fc="netocool"]这个问题困扰我很久了 兄弟你有什么办法呢? 我电话跟他们的800聊了,他们的回复是: figlec.com 得mx记录您指向了mail.figlec.com,然后在A记录中mail.figlec.com又指向您的服务器，这样得记录就会造成邮件得收?.........[/quote:0a98ef54fc] 可笑啊，他们到底动不动啊。mx记录指向主机，主机添加a记录，这个是国际标准写法。mx直接些ip，100％的是不规范的写法。很多国外的dns服务器都会提示语法错误的。 正确就是： @  IN MX 10 mail mail IN A  22.22.22.22 如果写成这样，才有版本兼容问题呢。 @ IN MX 10 22.22.22.22 还有，其他接收服务器的检查mx记录是smtp协议传输要找的邮件记录，helo是做反相解析，检查域名对应的ip是否和正解一直（防止垃圾邮件的一个规则）。只要做了mx是mail主机，mail主机是对应ip是你的邮件主机就ok的。。 不行你就让他看看这个帖子，再不行就开骂吧。。

netocool 回复于：2004-09-14 14:02:00

谢谢'零二年的夏天'老大的关注,将我的问题提出来 为此我想重新一下我的问题 现在出现最大的问题是我不能使用nukabe.cn(新网解析的域名,本公司的QMAIL系统),synergie.com.cn(新网解析的域名,本公司的QMAIL系统)发邮件到figlec.com(新网解析的域名,自身公司的QMAIL系统),都出现问题,查看mail log可以见到的提示是: 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/ figlec.com这边的QMAIL logs没有出现有连接的提示,但是在figlec.com这边的Firewall日志可以看到: Sep 13 04:46:02.442 FIGLEC smtp[6704]: 343 smtpd Warning: Host [202.103.166.34] tried to send mail from '<admin@nukabe.cn>' - 450 4.4.1 Sender domain not found in DNS Sep 13 04:46:02.442 FIGLEC dnsd[531]: 120 dnsd Info: Failed to handle request from 127.0.0.1 for MailServer for nukabe.cn. - no progress possible (202.106.124.195/No response, 210.51.170.66/No response) Sep 13 04:46:02.489 FIGLEC smtp[6704]: 121 Statistics: duration=91.90 id=3x9Zc sent=51 rcvd=130 srcif=eth1 src=202.103.166.34/33373 cldst=202.103.202.76/25 svsrc=192.168.1.1/42974 dstif=eth2 dst=192.168.1.10/25 proto=smtp rule=7 (Host [202.103.166.34] tried to send mail from '<admin@nukabe.cn>' - 450 4.4.1 Sender domain not found in DNS) 但是使用21cn.com,163.com....就可以正常发邮件到figlec.com 另外从国外发过来的邮件(edf.fr)到figlec.com大部分都不正常 今天下午我做了一下测试: [root@mail2 root]# dig mx figlec.com   ; <<>> DiG 9.2.2 <<>> mx figlec.com ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35480 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0   ;; QUESTION SECTION: ;figlec.com.                    IN      MX   ;; Query time: 140 msec ;; SERVER: 202.96.128.68#53(202.96.128.68) ;; WHEN: Tue Sep 14 13:49:55 2004 ;; MSG SIZE  rcvd: 28   [root@mail2 root]# dig mx 21cn.com   ; <<>> DiG 9.2.2 <<>> mx 21cn.com ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53505 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4   ;; QUESTION SECTION: ;21cn.com.                      IN      MX   ;; ANSWER SECTION: 21cn.com.               4758    IN      MX      10 mta.21cn.com. 21cn.com.               4758    IN      MX      10 mta2.21cn.com.   ;; AUTHORITY SECTION: 21cn.com.               80353   IN      NS      dns.21cn.net. 21cn.com.               80353   IN      NS      dns.21cn.com.   ;; ADDITIONAL SECTION: mta.21cn.com.           1167    IN      A       61.140.60.20 mta2.21cn.com.          4758    IN      A       61.140.60.70 dns.21cn.com.           1886    IN      A       202.104.32.253 dns.21cn.net.           166751  IN      A       202.104.32.251   ;; Query time: 73 msec ;; SERVER: 202.96.128.143#53(202.96.128.143) ;; WHEN: Tue Sep 14 13:50:02 2004 ;; MSG SIZE  rcvd: 175   [root@mail2 root]#  看来新网DNS的解析真的不是很稳定

abel 回复于：2004-09-14 14:37:25

像peng 兄說的那樣是很正確的~ 如果 "新網" (我不知道這是家什麼公司...) 不肯改... 你何不妨找 BIND 8 的 DNS Server 來做為 Client 指定, 也請對方也找 BIND 8 的. 不然就換一家代管業者.. 基本上,大概可以說,給"新網"代管的 Domain 都會有這個問題存在, 原因就是上面提到的, NS 記錄上下不一致, nukabe.cn 或許是對的 但 nukabe.cn 的那幾部的 NS 有問題呀 ..連帶的 nukabe.cn 出錯

peng 回复于：2004-09-14 15:20:12

[quote:5faa15ed71="abel"]像peng 兄說的那樣是很正確的~ 如果 "新網" (我不知道這是家什麼公司...) 不肯改... 你何不妨找 BIND 8 的 DNS Server 來做為 Client 指定, 也請對方也找 BIND 8 的. 不然就換一家代管業者.. 基本上,大概可?.........[/quote:5faa15ed71] 新网也算国内比较大的域名代理机构了。。 和万网（www.net.cn）都差不多啊。。 真有点意思，难道他们以前就没有遇见这种情况？。。 这个问题出现快2年了吧。。

q1208c 回复于：2004-09-14 15:21:30

[quote:275e3e3984="netocool"]l2 root]#  看来新网DNS的解析真的不是很稳定[/quote:275e3e3984] 我刚刚试了一下，可以找到MX的。当然是在我这。 但如查用你那个DNS SERVER就找不到了。 你可以试试的。  [code:1:275e3e3984][root@rhel etc]# dig @dns.guandzhou.gd.cn mx figlec.com dig: Couldn't find server 'dns.guandzhou.gd.cn': Name or service not known [root@rhel etc]# dig @dns.guangzhou.gd.cn mx figlec.com   ; <<>> DiG 9.2.2 <<>> @dns.guangzhou.gd.cn mx figlec.com ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0   ;; QUESTION SECTION: ;figlec.com.                    IN      MX   ;; Query time: 374 msec ;; SERVER: 202.96.128.68#53(dns.guangzhou.gd.cn) ;; WHEN: Tue Sep 14 15:16:46 2004 ;; MSG SIZE  rcvd: 28   [root@rhel etc]# [/code:1:275e3e3984] 用我自己的DNS SERVER就没问题。建议你指向别的DNS SERVER试试看。

netocool 回复于：2004-09-16 09:33:36

问题解决了,abel讲得正确,完全是DNS 代管業者的错 解决方法,联系新网,要求他们讲我们的域名解析服务器(NS记录)修改为: ;; AUTHORITY SECTION: figlec.com.             34783   IN      NS      ns2.xinnet.cn. figlec.com.             34783   IN      NS      ns2.xinnetdns.com.

xpnew 回复于：2004-09-19 23:56:46

看来你们都是职业的杀手了，我这个业余的问点问题（主要是书上没讲到这里） 下面这行，其中34783是83是什么意思？是不是TTL呀？ figlec.com. 34783 IN NS ns2.xinnet.cn.

wingger 回复于：2004-11-05 09:55:14

霍霍，上了生动的一课

网事随风 回复于：2004-11-30 16:36:37

可是我不明白,为什么改成: figlec.com. 34783 IN NS ns2.xinnet.cn.  figlec.com. 34783 IN NS ns2.xinnetdns.com. 就会没问题呢? NS不一致的问题不是还是存在么?

原文转自：http://www.ltesting.net