Name Resolution Problem

[Randy Adams]

I agree. Not DNS (BIND) server related.

I would also check the name resolution config on the remote workstations.

If they are resolving the name from in-addr-arpa when you do a ping test,
they may cache that entry... thus allowing you to get to the devices by name
after that.

The other thing you should check is your domain suffix search order in your
client configs. Make sure that the domain suffix for the servers you want to
be able to get to is listed there.

And finally.

Use NSlookup from one of the workstations and lookup the names of the
servers using the FQDN to make sure you are getting an appropriate (any?)
response from your DNS.\

Good luck.

Randy Adams - CCNA, MCSE
Network Manager
TELUS Communications Inc.
Technology & Operations
(403)503-3011

got snow???
http://www.skiamigos.com

-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Wednesday, August 29, 2001 12:50 PM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: Name Resolution Problem



If a ping makes the access work temporarily, then this is almost
certainly not a DNS problem. DNS isn't related to ping or anything at
that level of network (except as a consumer of network resources, like
everything else).

Since you say the access works "until a reboot of the access device",
then that strongly implicates the "access device" as the source of the
problem.


- Kevin

rkirby at modimes.org wrote:

> We are running an NT network and have recently experienced problem
> resolving two Intranet server pages from locations outside of the
> local net (WAN, VPN, etc.)  We have several other Intranet servers
> that are all accessable from both local and remote sites.  The local
> resident  users do not have not problems with the access to these two
> resouces in question.  We have primary and secondary WINS server.
>
> >From the remote sites (WAN, VPN) we cannot resolve the URL name using
> the IE browser.  If we ping either the IP address or the resouce name
> they both return successfully.  Once this has been done we can
> successfully access both resources via the browser until a reboot of
> the access device.
>
> Does anyone offer a suggestion to isolate where the problem is?