richard wrote:
>
> Dear all,
> Thanks for your hint. But I have checked the following and the problem
> still exists.
> After the ./amdump, I still get the error:
> FAILURE AND STRANGE DUMP SUMMARY:
> 202.85.165 /home lev 0 FAILED [202.85.165.88: [addr 202.85.164.38:
> hostname
> lookup failed]
[...]
> My /etc/named.boot file:
> directory /var/named
> cache . named.ca
> primary 0.0.127.in-addr.arpa named.local
> primary 202.85.164.38.in-addr.arpa rev.38.164.85.202
There is no zone 202.85.164.38.in-addr.arpa.
First of all, in-addr.arpa. counts backwards, so the PTR-Record for
202.85.165.88 is in Zone 165.85.202.in-addr.arpa.
If you run an authoritative Zone for 165.85.202.in-addr.arpa and you
don't own the complete zone, you will have troubles nslookuping the
other hosts in that zone. You might want to setup "classless
in-addr-arpa delegation" (RFC 2317).
If this reverse zone ist hosted by your provider, ask him to add the
correct hostname for 202.85.164.38.
If this zone is hosted by you, make sure your parent zone's
(85.202.in-addr.arpa) NS records point to your nameservers.
$ dig 165.85.202.in-addr.arpa. ns
; <<>> DiG 8.2 <<>> 165.85.202.in-addr.arpa. ns
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; 165.85.202.in-addr.arpa, type = NS, class = IN
;; ANSWER SECTION:
165.85.202.in-addr.arpa. 4D IN NS hk1dns01.iadvantage.net.hk.
165.85.202.in-addr.arpa. 4D IN NS hk1dns02.iadvantage.net.hk.
;; Total query time: 673 msec
;; FROM: apollo to SERVER: default -- 192.168.1.6
;; WHEN: Mon Dec 11 12:08:34 2000
;; MSG SIZE sent: 41 rcvd: 104
