Client DNS issue?

  • Thread starter Thread starter ping
  • Start date Start date
P

ping

Hi,

All clients are under the SBS 2003 domain named abc.local. All client
DNS entry are pointed to the DC. DC is configured to forward DNS to ISP
for unresolved DNS.

One of the Win XP client have problem communicating to another XP
client. No network path found. When i try to use ip to connect to file
share, no problem though. Nslookup can resolve the DNS entry too. A
restart solve the problem on the XP client. It happen occasionally.
Checked and verified it's not a firewall issue. Any service that I
should pay attention on? I have tried restarting DNS CLient service but
it doesn't help.
 
I would try changing the DCs forwarders to point to your router. Also, if
you are getting intermittent failures like this within your internal
network, this is the classic sign of mixing outside and inside DNS IPs in
the TCP/IP properties, somewhere! Maybe on your DCs? Maybe in your router?
Maybe in the client? Somewhere.

-Frank
 
Hi,

I will try to change the forwarder to the Router DNS Proxy. But strange
thing is that client is able to resolve to the correct ip when i check
with nslookup. No firewall blocking. But it just won't connect. There
are some mis-configuration of IP addressing, which I think may be the
cause too. Currently PIX firewall sits between Router and internal
network. The external interface of PIX is assigned 192.168.1.0/24, and
the internal interface DHCP is retrieved from pix(172.16.0.0/16).

Any idea?
 
In
ping said:
Hi,

I will try to change the forwarder to the Router DNS Proxy. But
strange thing is that client is able to resolve to the correct ip
when i check with nslookup. No firewall blocking. But it just won't
connect. There are some mis-configuration of IP addressing, which I
think may be the cause too. Currently PIX firewall sits between
Router and internal network. The external interface of PIX is
assigned 192.168.1.0/24, and the internal interface DHCP is retrieved
from pix(172.16.0.0/16).

Any idea?
Click to expand...

Honestly, with all respect to Frankster, I can't see how changing the
forwarder to the router will resolve internal client names. I wo uld leave
forwarding to the ISP to eliminate the extra query hop using the router will
cause in the resolution process, that is as long as you are allowing query
trafic thru to the DNS server.

As for internal resolution, you are saying your internal clients are
receiving a DHCP address from the PIX box? When the one client pings the
other client by name, what name gets resolved?

Why not use Windows DHCP? It works hand in hand with Microsoft DNS Dynamic
Updates (Option 080), along with using Secure Only Updates, along with the
numerous other Options available that PIX doesn't support.

If you can *please* post an ipconfig /all of your DC, one from the client
that is working, as well as one from the client that is not working. This
will help us get a better idea of your configuration on your clients and
what it's getting from the PIX DHCP, and to see if the DC matches, the
Primary DNS Suffix, Connection Spefici Suffix, and other information in the
ipconfig /all results.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

If you are having difficulty in reading or finding responses to your post,
instead of the website you are using, I would suggest to use OEx (Outlook
Express or any other newsreader of your choosing), and configure a newsgroup
account, pointing to news.microsoft.com. This is a direct link into the
Microsoft Public Newsgroups, and it is FREE and DOES NOT require a Usenet
account with your ISP. With OEx , you can easily find your post and watch &
track threads, sort by date, poster's name, watched threads or subject.

Not sure how? It's easy and you'll enjoy it
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.
=================================
 
Honestly, with all respect to Frankster, I can't see how changing the
forwarder to the router will resolve internal client names.
Click to expand...

Ah... no prob Ace. I certainly bow to your knowledge. Really. You are a
tremendous asset to this community. Actually, I didn't expect this change
to directly correct any problem. But I thought possibly it might indirectly
correct it and we could go from there, just by changing the series of events
in the chain.

Anyhow, just wanted you to know that I have learned a lot from your posts.
Thank you.

-Frank
 
In
Frankster said:
Ah... no prob Ace. I certainly bow to your knowledge. Really. You are
a tremendous asset to this community. Actually, I didn't expect this
change to directly correct any problem. But I thought possibly it
might indirectly correct it and we could go from there, just by
changing the series of events in the chain.

Anyhow, just wanted you to know that I have learned a lot from your
posts. Thank you.

-Frank
Click to expand...

Thanks, Frank. I don't know everything, and I'm still learning, for learning
is an non-stop thing. I've dealt with AD since the beta days in late 1998,
but I'm still learning little things off the other guys that I either have
forgotten about or didn't realize, especially in the AD groups, like Dean,
Joe, Cliff, Jerold, Paul, Brian, Laura Robinson (which I haven't seen out
here lately), and many many others, and of course I apologize to the ones I
forgot to mention.

What I tell alot of folks, especially my students and clients, if you want
to learn about anything computer-wise, I suggest to read the newsgroup
postings and the responses from everyone in here. There's alot of info here
going thru on a daily basis.

:-)

Cheers!
Ace
 
It may not be a name resolution issue at all. Rebooting the machine
should not effect what name you resolve, unless it updated its A
record somewhere, but if NSLookup is working then I doubt thats the
case. Are you sure its even using DNS? It may of looked for the
Netbios name when connecting to the share, or perhaps the security got
screwed up and was resolved on the reboot.

What are the IP addressing problems you spoke of? The PIX should not
be getting in the way of communications of 2 clients on the same
subnet, unless the PIX has proxy ARP enabled.

Client resolves name to IP, client ARPs IP, Server responds with its
IP (server as in the client your connecting to), client makes the
connection.

A netmon trace would be ideal for troubleshooting this issue if it
comes up again.

The clients will register thier DNS records without the DHCP flag set
to tell them to do so. As long as the DHCP Client service is running,
the client will attempt to contact the SOA for the domain and update
its record every 24 hours, on each reboot, and when issued an ipconfig
/registerdns. Getting your DHCP from the PIX should not matter.

Next time it happens, ping by single lable name. does it resolve to
the same IP? Run arp -a. Does the MAC address of the IP your
connecting to match what is on the ipconfig /all of the "server"
machine? Are you getting SMB singing data from GPO? Some things to
look at anyways if it happens again.
 
Rebooting the machine should not effect what name
you resolve
Click to expand...

Actually, this scenario is one of the classic signs of a misconfigured
TCP/IP stack using both internal and external DNS servers. Rebooting starts
the service over and may start with the *working* DNS IP, until it becomes
unreachable for some reason, and then it may shift to the *non-working* one
again. Reboot, everything starts over.

-Frank
 
Back
Top