An analysis of BIND8 and BIND9 problems

Article title: resolve a problem about BIND8 and BIND9. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Question:
Netocool writes:
　　
[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] #
　　
This is often the case on my server. when I use dig mx domain.com, I often cannot find the domain name record, and sometimes it is normal.
What causes this problem? Is it because of the DNS server provided by my local ISP or the DNS server on domain.com?
　　
Also, when I use my company's linux + qmail mail server to send an email to the other party's linux + qmail mail server, I observe my local log and the following prompt appears, the recipient has not received the email:
Sep 9 15:09:28 mail qmail: 1094713768.604001 delivery 132: deferral: Rule./Remote_host_said: _ rule _4.4.20.sender_domain_not_found_in_dns/
　　
I don't know why this is the case. Is it a DNS problem?
However, it is normal that I use 21cn.com instead of linx + qmai of my company to send emails to the recipient's server.
　　
Please help analyze
　　
-----------------
Answer:
　　
Too many dns settings are incorrect...
The nukabe.cn settings are correct.
However, his managed service team pushed the question.
The reason why you cannot use ISP is that ISP Run BIND 9.X,
It is running BIND 8.X in all parts like 21cn.com ..
Because BIND 9 has strict DNS settings (authorization relationship, NS RRs)
　　
View NS records of nukabe under. cn
Code:
　　
[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
　　
The authorization is found to be granted to the above two DNS servers, but the Domain is different from nukabe.cn BIND 8. here we will see the IP address 202.106.124.195, BIND 9 does not discard this IP address (this is a big difference... BIND 8 believes that Additional, BIND Does Not Need Addtional Section at all, because of security and the correctness of the resolution) BIND 8, select either one, if you choose ns.xinnet.cn. check MX records directly to 202.106.124.195. if ns.xinnetdns.com is selected. because no Addtional information is available. com query ........ to dig @ a.gtld-servers.net xinnetdns.com. ns can be seen in addtional
Code:
　　
Ns.xinnetdns.com. 123026 in a 210.51.170.66
　　
Therefore, bind 8 will query the MX record of cukabe.cn for 202.106.124.195/210.51.170.66.
Therefore, you can obtain the MX record.
　　
Therefore, we can see from BIND 9 that he will not use the IP address brought out by addtional section.
AUTHORITY Answer (AA)
　　
So we can check the NS record of xinnet.cn under. cn
Code:
　　
[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
　　
Six pieces of data are found, which are the authoritative data of xinnet.cn.
So we chose the first part to view the NS record of its own domain (xinnet.cn ).
Code:
　　
[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.