resolves remotely, but fails locally...

[Mathias Körber]

> I have a weird bind 8.2.2p7 problem...
>=20
> Locally:
> nslookup ns1.webgoku.com 63.165.246.4
> *** Can't find server name for address 63.165.246.4: Timed out
> *** Default servers are not available

One of the many bad bugs in nslookup, I think.
Before it actually tries looking up ns1.webgoku.com, it tries finding =
the
name for the server you listed in the second argument. And because it
has apready processed the arguments, it asks *that* nameserver. Now it
seems that 63.165.246.4 is itself not able to return you its=20
PTR record (4.246.165.63.in-addr.arpa), because it
	a) is not authoritative for the reverse domain
and	b) is non-recursive, so it can't do it yourself.
Thus a tieout occurs *before* nslookup even asked it for =
ns1.webgoku.com.

This *should* work if you use nslookup in intercative mode:
	$ nslookup
	> server 63.165.245.4
	> ns1.webgoku.com
as in this mode it will ask the *old* (default) server for the
reverse record for the new server...

Or use dig (better anyway).
=20

>=20
> it fails...
>=20
> Remotely:
> nslookup ns1.webgoku.com 63.165.246.4
> Server:  ns1.webgoku.com
> Address:  63.165.246.4
>=20
> Name:    ns1.webgoku.com
> Address:  63.165.246.4
>=20
> works just fine...
>=20
>=20
> Any pointers?
>=20
>=20
>=20