The zone appears to be configured incorrectly. That is why your results and Scott's are so odd. I'll explain below, but in summary, the name servers to which the zone is delegated have what appears to be rubbish records. Specifically these:
gdpu.cn. 3600 IN NS gdpu.cn. gdpu.cn. 3600 IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn. 3600 IN A 219.136.229.43 dns4.dmz.local. 3600 IN A 10.55.11.11 I'll explain in a little more detail... First check the delegation: (I've reduced the output for the sake of readability) arapahoe:~ kfeher$ dig ns cn +short a.dns.cn. ns.cernet.net. b.dns.cn. d.dns.cn. c.dns.cn. e.dns.cn. Then query one of those servers for the domains NS record: arapahoe:~ kfeher$ dig ns gdpu.cn @D.DNS.cn ;; AUTHORITY SECTION: gdpu.cn. 21600 IN NS dns1.gdpu.cn. gdpu.cn. 21600 IN NS dns2.gdpu.cn. ;; ADDITIONAL SECTION: dns1.gdpu.cn. 21600 IN A 219.136.229.41 dns2.gdpu.cn. 21600 IN A 219.136.229.42 This is correct so far. Lets see if the 2 name servers agree... arapahoe:~ kfeher$ dig ns gdpu.cn @dns2.gdpu.cn ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn. 3600 IN NS gdpu.cn. gdpu.cn. 3600 IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn. 3600 IN A 219.136.229.43 dns4.dmz.local. 3600 IN A 10.55.11.11 A 10.x.x.x address is an rfc1918 address and is either internal zone information leaking to the outside world, or just plan wrong. In any case you will not be able to query it. The other address does not respond to DNS queries. I suspect this is in fact a webserver accidentally listed as a nameserver. Note that the reason your queries fail is because name servers are supposed to assume that the apex of the zone contains the most correct data. Therefore if the 2 name servers to which this zone is delegated respond with rubbish, your resolver will cache that rubbish. If you know the owner of that domain their name server should have these 2 records most likely: gdpu.cn. 21600 IN NS dns1.gdpu.cn. gdpu.cn. 21600 IN NS dns2.gdpu.cn. On 11/5/09 12:57 PM, "Tech W." <tech...@yahoo.com.cn> wrote: > > Hi, > > Firstly the DNS serveres for that domain is not mastered by me. > I got the NS dig info as below. > You can see, if I specify another public DNS (211.66.80.161), the results can > be fetched. If I don't specify a DNS (use the default one 202.96.128.143 of my > ISP), dig gets nothing. > So I'm really confused on their configure. > Please help again, thanks~ > > > # dig gdpu.cn ns @211.66.80.161 > > ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns @211.66.80.161 > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57139 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;gdpu.cn. IN NS > > ;; ANSWER SECTION: > gdpu.cn. 21347 IN NS dns2.gdpu.cn. > gdpu.cn. 21347 IN NS dns1.gdpu.cn. > > ;; ADDITIONAL SECTION: > dns2.gdpu.cn. 21347 IN A 219.136.229.42 > dns1.gdpu.cn. 21347 IN A 219.136.229.41 > > ;; Query time: 3 msec > ;; SERVER: 211.66.80.161#53(211.66.80.161) > ;; WHEN: Mon May 11 18:51:19 2009 > ;; MSG SIZE rcvd: 95 > > > # dig gdpu.cn ns > > ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15877 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;gdpu.cn. IN NS > > ;; Query time: 1 msec > ;; SERVER: 202.96.128.143#53(202.96.128.143) > ;; WHEN: Mon May 11 18:51:24 2009 > ;; MSG SIZE rcvd: 25 > > --- On Mon, 11/5/09, Scott Haneda <talkli...@newgeo.com> wrote: > >> >> I do not think you can have a .local NS. Both of >> those NS's have to be reachable by the outside world, and >> .local is not. It may be on your local lan, but outside >> that, it will not be. > > > > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
