Vista will not resolve DNS

  • Thread starter Thread starter Kevin D. Goodknecht [MVP]
  • Start date Start date
K

Kevin D. Goodknecht [MVP]

I've been pulling my hair out over this one. I suspect it may have had
malware infection, ran combofix, TrendMicro Sysclean, reset IPv4, disabled
IPv6, reset the Winsock, uninstalled Expired Norton 360, installed Microsoft
Security Essentials, tried it with the Firewall on and off, checked the
registry for as many Winsock Redirectors and firewalls I could think of. I
don't know of anything I've missed, I'm hoping someone here can think of
something.

I can ping IP Addresses, but cannot ping any name, not even localhost. The
DNSCache is caching names but it won't answer for application that resolves
names, Including IE, Google Chrome, Firefox, tracert, nothing!

It can browse the Internet with all installed browsers, if it uses my proxy
server, since the proxy resolves names for the browser, but if it depends on
the DNS Resolver Service it won't work. It is Vista basic that belongs to a
customer and is not a member of a domain.

I've posted pings, ipconfig /all, and net start below.

C:\Users\Test>ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

C:\Users\Test>ping 192.168.201.1

Pinging 192.168.201.1 with 32 bytes of data:
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64

C:\Users\Test>ping localhost
Ping request could not find host localhost. Please check the name and try
again.


C:\Users\Test>ping www.yahoo.com
Ping request could not find host www.yahoo.com. Please check the name and
try ag
ain.

C:\Users\Test>tracert yahoo.com
Unable to resolve target system name yahoo.com.



Windows IP Configuration

Host Name . . . . . . . . . . . . : dana-PC
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : office.wftx.us

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : office.wftx.us
Description . . . . . . . . . . . : NVIDIA nForce 10/100/1000 Mbps
Ethernet #3
Physical Address. . . . . . . . . : 00-1D-72-B0-B7-87
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.201.152(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, February 23, 2010 1:51:27 PM
Lease Expires . . . . . . . . . . : Wednesday, February 24, 2010 2:27:51
PM
Default Gateway . . . . . . . . . : 192.168.201.1
DHCP Server . . . . . . . . . . . : 192.168.201.5
DNS Servers . . . . . . . . . . . : 192.168.201.5
192.168.201.15
192.168.201.13
192.168.201.25
Primary WINS Server . . . . . . . : 192.168.201.5
Secondary WINS Server . . . . . . : 192.168.201.13
192.168.201.15
NetBIOS over Tcpip. . . . . . . . : Enabled

C:\Users\Test>net start
These Windows services are started:

Agere Modem Call Progress Audio
Application Experience
Application Information
Background Intelligent Transfer Service
Base Filtering Engine
COM+ Event System
Cryptographic Services
DCOM Server Process Launcher
Desktop Window Manager Session Manager
DHCP Client
Diagnostic Policy Service
Diagnostic Service Host
Diagnostic System Host
Distributed Link Tracking Client
DNS Client
Group Policy Client
Human Interface Device Access
IKE and AuthIP IPsec Keying Modules
IP Helper
IPsec Policy Agent
KtmRm for Distributed Transaction Coordinator
Microsoft Antimalware Service
Multimedia Class Scheduler
Network Connections
Network List Service
Network Location Awareness
Network Store Interface Service
NVIDIA Display Driver Service
Plug and Play
Portable Device Enumerator Service
Program Compatibility Assistant Service
ReadyBoost
Remote Access Connection Manager
Remote Procedure Call (RPC)
Remote Registry
Secondary Logon
Secure Socket Tunneling Protocol Service
Security Accounts Manager
Security Center
Server
Shell Hardware Detection
Software Licensing
SSDP Discovery
Superfetch
System Event Notification Service
Tablet PC Input Service
TCP/IP NetBIOS Helper
Telephony
Terminal Services
Themes
UPnP Device Host
User Profile Service
VNC Server Version 4
WebClient
Windows Audio
Windows Audio Endpoint Builder
Windows Driver Foundation - User-mode Driver Framework
Windows Error Reporting Service
Windows Event Log
Windows Firewall
Windows Image Acquisition (WIA)
Windows Management Instrumentation
Windows Modules Installer
Windows Search
Windows Time
Windows Update
WinHTTP Web Proxy Auto-Discovery Service
Workstation

The command completed successfully.

--
--
Best regards,
Kevin D. Goodknecht Sr.
Hope This Helps

===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
http://message.wftx.us/
 
Kevin D. Goodknecht said:
I've been pulling my hair out over this one. I suspect it may have had
malware infection, ran combofix, TrendMicro Sysclean, reset IPv4, disabled
IPv6, reset the Winsock, uninstalled Expired Norton 360, installed
Microsoft Security Essentials, tried it with the Firewall on and off,
checked the registry for as many Winsock Redirectors and firewalls I could
think of. I don't know of anything I've missed, I'm hoping someone here
can think of something.

I can ping IP Addresses, but cannot ping any name, not even localhost. The
DNSCache is caching names but it won't answer for application that
resolves names, Including IE, Google Chrome, Firefox, tracert, nothing!

It can browse the Internet with all installed browsers, if it uses my
proxy server, since the proxy resolves names for the browser, but if it
depends on the DNS Resolver Service it won't work. It is Vista basic that
belongs to a customer and is not a member of a domain.

I've posted pings, ipconfig /all, and net start below.

C:\Users\Test>ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

C:\Users\Test>ping 192.168.201.1

Pinging 192.168.201.1 with 32 bytes of data:
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64
Reply from 192.168.201.1: bytes=32 time=1ms TTL=64

C:\Users\Test>ping localhost
Ping request could not find host localhost. Please check the name and try
again.


C:\Users\Test>ping www.yahoo.com
Ping request could not find host www.yahoo.com. Please check the name and
try ag
ain.

C:\Users\Test>tracert yahoo.com
Unable to resolve target system name yahoo.com.



Windows IP Configuration

Host Name . . . . . . . . . . . . : dana-PC
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : office.wftx.us

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : office.wftx.us
Description . . . . . . . . . . . : NVIDIA nForce 10/100/1000 Mbps
Ethernet #3
Physical Address. . . . . . . . . : 00-1D-72-B0-B7-87
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.201.152(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, February 23, 2010 1:51:27
PM
Lease Expires . . . . . . . . . . : Wednesday, February 24, 2010 2:27:51
PM
Default Gateway . . . . . . . . . : 192.168.201.1
DHCP Server . . . . . . . . . . . : 192.168.201.5
DNS Servers . . . . . . . . . . . : 192.168.201.5
192.168.201.15
192.168.201.13
192.168.201.25
Primary WINS Server . . . . . . . : 192.168.201.5
Secondary WINS Server . . . . . . : 192.168.201.13
192.168.201.15
NetBIOS over Tcpip. . . . . . . . : Enabled

C:\Users\Test>net start
These Windows services are started:

Agere Modem Call Progress Audio
Application Experience
Application Information
Background Intelligent Transfer Service
Base Filtering Engine
COM+ Event System
Cryptographic Services
DCOM Server Process Launcher
Desktop Window Manager Session Manager
DHCP Client
Diagnostic Policy Service
Diagnostic Service Host
Diagnostic System Host
Distributed Link Tracking Client
DNS Client
Group Policy Client
Human Interface Device Access
IKE and AuthIP IPsec Keying Modules
IP Helper
IPsec Policy Agent
KtmRm for Distributed Transaction Coordinator
Microsoft Antimalware Service
Multimedia Class Scheduler
Network Connections
Network List Service
Network Location Awareness
Network Store Interface Service
NVIDIA Display Driver Service
Plug and Play
Portable Device Enumerator Service
Program Compatibility Assistant Service
ReadyBoost
Remote Access Connection Manager
Remote Procedure Call (RPC)
Remote Registry
Secondary Logon
Secure Socket Tunneling Protocol Service
Security Accounts Manager
Security Center
Server
Shell Hardware Detection
Software Licensing
SSDP Discovery
Superfetch
System Event Notification Service
Tablet PC Input Service
TCP/IP NetBIOS Helper
Telephony
Terminal Services
Themes
UPnP Device Host
User Profile Service
VNC Server Version 4
WebClient
Windows Audio
Windows Audio Endpoint Builder
Windows Driver Foundation - User-mode Driver Framework
Windows Error Reporting Service
Windows Event Log
Windows Firewall
Windows Image Acquisition (WIA)
Windows Management Instrumentation
Windows Modules Installer
Windows Search
Windows Time
Windows Update
WinHTTP Web Proxy Auto-Discovery Service
Workstation

The command completed successfully.

--
--
Best regards,
Kevin D. Goodknecht Sr.
Hope This Helps

===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
http://message.wftx.us/


Kevin,

How are you? It's been awhile since we've spoken.

Curious, what is in the system32\drivers\etc\hosts file? If it can't find
localhost, as you know, that's where it is supposed to be. ALso check the
reg to make sure that a virus didn't change the hosts file location.

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath.

Other than that, maybe there was a 3rd party network malware tool installed
hijacking network services. Maybe a packet sniffer to see what that
workstation is doing, if it is trying to contact some external entity?

Just conjecture... Sometimes these can be difficult to track down where a
reinstall takes less time if it was previously infected by malware! :-) I
have a machine sitting in my basement with similar issues that belongs to my
daughter's boyfriend. And I can't reinstall it because he doesn't have the
original XP Home OEM
CD. It just blue screens, even in Safe Mode with Networking, however it
doesn't in Safe Mode. I am thinking of uninstalling and reinstalling TCP on
it, but haven't explored that yet in Safe Mode because I've been super busy
the past few weeks.... What a mess! LOL!

--
Ace

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

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please
contact Microsoft PSS directly. Please check http://support.microsoft.com
for regional support phone numbers.
 
The DNSCache is caching names but it won't answer for application that resolves names, Including IE, Google Chrome, Firefox, tracert, nothing!



How do you know that it's caching names if you haven't managed to make it successfully look up anything?&nbsp; In any case, you've missed a test:



&nbsp; DNS Servers . . . . . . . . . . . : 192.168.201.5
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.201.15
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.201.13
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.201.25



Query all of these with netdig or something similar.&nbsp; If that works, then you can eliminate firewalls and network connectivity as causes for the problem, and concentrate upon the DNS Client itself.



If you find yourself at that point, stop the DNS Client service, and see what happens to applications that perform DNS lookups once they have to do them directly, rather than via the client service.
 
Frankster said:
Well, in addition to the DNS troubleshooting ideas presented already, I
would advise to download and run the Malwarebytes Anti-Malware product
(free). I don't normally recommend any particular AV products, even
though I have my favorite... however, this Malwarebytes product is just so
damned good! It'll only take about 15 minutes to download and run.

http://www.malwarebytes.org.

Sorry if this seems too rudimentary, but no kidding, this is one heck of a
product (but, you might already know that - LOL). Oh well...

-Frank


I like that product, too. However I finally found a piece of malware it was
not able to clean up, and that was with my daughter's boyfriend's machine,
and one customer machine. The customer machine had a fake AV that it
couldn't find. However the other machine, is simply blue screening at boot,
and since it won't boot in Safe Mode with Networking, I can't update
malwarebytes when I run. It is proving a challenge to me right now. It only
runs in Safe Mode. I opted to disable all non-Microsoft services using
msconfig, and it still won't even come up in Safe with Networking.

I don't mean to hijack this thread, just pointing out as much as I like
malwarebytes too, it apparently didn't have the sigs for the latest thing
out there. The AV writers could have slightly changed the header in their
file to circumvent it.

Ace
 
in message
The DNSCache is caching names but it won't answer for application that
resolves names, Including IE, Google Chrome, Firefox, tracert, nothing!
How do you know that it's caching names if you haven't managed to make it
successfully look up anything? In any case, you've missed a test:
DNS Servers . . . . . . . . . . . : 192.168.201.5
192.168.201.15
192.168.201.13
192.168.201.25
Query all of these with netdig or something similar. If that works, then
you can eliminate firewalls and network connectivity as causes for the
problem, and concentrate upon the DNS Client itself.
If you find yourself at that point, stop the DNS Client service, and see
what happens to applications that perform DNS lookups once they have to do
them directly, rather than via the client service.


Hello Jonathan, it's been a long time, you are correct, I did err in leaving
out that that information, I tried to think of everything, but this should
rest your mind that I thought of it and did the tests.

Here is a flushdns, displaydns, a couple of pings and another displaydns. As
you can see the resolver seems to be working but ping doesn't get the answer
back.


************************************************
C:\Windows\system32>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\Windows\system32>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost


localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


localhost
----------------------------------------
No records of type AAAA



C:\Windows\system32>ping localhost
Ping request could not find host localhost. Please check the name and try
again.


C:\Windows\system32>ping sonicwall.wftx.us
Ping request could not find host sonicwall.wftx.us. Please check the name
and tr
y again.

C:\Windows\system32>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost


sonicwall.wftx.us
----------------------------------------
Record Name . . . . . : sonicwall.wftx.us
Record Type . . . . . : 1
Time To Live . . . . : 3581
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.201.1


localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


localhost
----------------------------------------
No records of type AAAA



C:\Windows\system32>ping sonicwall.wftx.us
Ping request could not find host sonicwall.wftx.us. Please check the name
and tr
y again.

C:\Windows\system32>


**********************************************************

Here's the Netdig response, I included both UDP and TCP Queries, all servers
answer the same.

opcode: Query, status: NoError, id: 42
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

QUESTION SECTION:
sonicwall.wftx.us. IN A

ANSWER SECTION:
sonicwall.wftx.us. 3600 IN A 192.168.201.1

Query time: 0 ms
Server : 192.168.201.5:53 udp (192.168.201.5)
When : 2/24/2010 3:11:17 PM
Size rcvd : 51

opcode: Query, status: NoError, id: 42
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

QUESTION SECTION:
sonicwall.wftx.us. IN A

ANSWER SECTION:
sonicwall.wftx.us. 3600 IN A 192.168.201.1

Query time: 0 ms
Server : 192.168.201.5:53 tcp (192.168.201.5)
When : 2/24/2010 3:11:23 PM
Size rcvd : 51




--
--
Best regards,
Kevin D. Goodknecht Sr.
Hope This Helps

===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.goodyscomputer.com/
http://support.wftx.us/
 
Frankster said:
I have ran into a similar case. When I do, I download a new copy (it
always has a very pretty current sig file embedded) and that seems to do
the trick. Sometimes I can run it from a location directly on my flash
drive, if necessary. On especially difficult cases where the Virus
disables Malwarebytes' Anti-Malware product, I run it on another machine
on the network against the victim machine, after mapping to the drive (use
"full scan"). Sometimes it is necessary to remove the drive and mount it
on a known good machine via USB adapter and run Anti-Malware on the good
machine (full scan again to hit the newly mounted victim drive).

One thing I have also found is that often I can get the victim drive
repaired enough this way (remotely mounted) so that at least the original
machine will boot and run Anti-malware natively. It is important to run
Anti-malware natively, using the normally used login, to get everything
cleaned up. I almost always find even more hits when running natively
even after a remote session "cleans" it. Just FYI... I'm sure you know
most of this - :)

Also, apologies if this appears to be a thread hijack.. but... it really
does sound like the OPs issue just might be a virus.

-Frank


I'm kind of thinking that with Kevin's, too. As for that machine I have, I
really don't have the time to work on it right now. I told him you can leave
it sit here until I come up with a game plan (this is after all the other
attempts I tried and him not having the OEM CD), he said he may be willing
to take it to Geek squad. I laughed and said, expect to lose data! But go
ahead if you feel that strongly. It is at the bottom of my list at the
moment, but I appreciate the suggestions! :-) I may just yank the drive and
put it in another machine. I just happen to have one right now from another
customer that I may just do that and get it to a point I can boot it. I can
say this, that I know the networking functions were compromised based on the
fact I found some oddball stuff in the hosts file. I changed it back to
default, made it Read only, checked the reg to make sure it's pointing to
the default location. So that part is eliminated. However, if some rogue DLL
is in there (yet to run Process Explorer and dont even know if that works in
SM), that can put a damper on things. <sigh>

Ace
 
Ace Fekay said:
Kevin,

How are you? It's been awhile since we've spoken.

The Readers Digest version is that, all things considered, I'm fine. If you
remember the story of how my truck driving career ended, I did my best to
stay away from it, turning in my CDL gave me lots of motivation and made
sure there was no turning back. At my age finding a job after 6.5 million
miles of driving which was preceded by a short 8 yr stint as a Roadie turned
Country and Western night club disc jockey, I was too old to go back to
turning records, or whatever they call it now that there aren't any records
to turn. So, 2 yrs ago I started my own company, Goody's Computer Support,
and while I haven't exactly gotten rich, I've seen a fairly steady increase
in business, even through this politics generated recession.



--
--
Best regards,
Kevin D. Goodknecht Sr.
Hope This Helps

===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.goodyscomputer.com/
http://support.wftx.us/
===================================
 
Kevin D. Goodknecht said:
"Jonathan de Boyne Pollard" <[email protected]>
wrote in message
The DNSCache is caching names but it won't answer for application that
resolves names, Including IE, Google Chrome, Firefox, tracert, nothing!
How do you know that it's caching names if you haven't managed to make it
successfully look up anything? In any case, you've missed a test:
DNS Servers . . . . . . . . . . . : 192.168.201.5
192.168.201.15
192.168.201.13
192.168.201.25
Query all of these with netdig or something similar. If that works, then
you can eliminate firewalls and network connectivity as causes for the
problem, and concentrate upon the DNS Client itself.
If you find yourself at that point, stop the DNS Client service, and see
what happens to applications that perform DNS lookups once they have to do
them directly, rather than via the client service.


Hello Jonathan, it's been a long time, you are correct, I did err in
leaving out that that information, I tried to think of everything, but
this should rest your mind that I thought of it and did the tests.

Here is a flushdns, displaydns, a couple of pings and another displaydns.
As you can see the resolver seems to be working but ping doesn't get the
answer back.


************************************************
C:\Windows\system32>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\Windows\system32>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost


localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


localhost
----------------------------------------
No records of type AAAA



C:\Windows\system32>ping localhost
Ping request could not find host localhost. Please check the name and try
again.


C:\Windows\system32>ping sonicwall.wftx.us
Ping request could not find host sonicwall.wftx.us. Please check the name
and tr
y again.

C:\Windows\system32>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost


sonicwall.wftx.us
----------------------------------------
Record Name . . . . . : sonicwall.wftx.us
Record Type . . . . . : 1
Time To Live . . . . : 3581
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.201.1


localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1


localhost
----------------------------------------
No records of type AAAA



C:\Windows\system32>ping sonicwall.wftx.us
Ping request could not find host sonicwall.wftx.us. Please check the name
and tr
y again.

C:\Windows\system32>


**********************************************************

Here's the Netdig response, I included both UDP and TCP Queries, all
servers answer the same.

opcode: Query, status: NoError, id: 42
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

QUESTION SECTION:
sonicwall.wftx.us. IN A

ANSWER SECTION:
sonicwall.wftx.us. 3600 IN A 192.168.201.1

Query time: 0 ms
Server : 192.168.201.5:53 udp (192.168.201.5)
When : 2/24/2010 3:11:17 PM
Size rcvd : 51

opcode: Query, status: NoError, id: 42
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

QUESTION SECTION:
sonicwall.wftx.us. IN A

ANSWER SECTION:
sonicwall.wftx.us. 3600 IN A 192.168.201.1

Query time: 0 ms
Server : 192.168.201.5:53 tcp (192.168.201.5)
When : 2/24/2010 3:11:23 PM
Size rcvd : 51


So the hosts file appears fine, and based on your testing, DNS resolution
appears fine. Curious, if you create an entry in the hosts file for
sonicwall.wftx.us, does it resolve and ping?

Ace
 
Query all of these with netdig or something similar.&nbsp; If that works, then you can eliminate firewalls and network connectivity as causes for the problem, and concentrate upon the DNS Client itself.



If you find yourself at that point, stop the DNS Client service, and see what happens to applications that perform DNS lookups once they have to do them directly, rather than via the client service.



Hello Jonathan, it's been a long time, you are correct, I did err in leaving out that that information, I tried to think of everything, but this should rest your mind that I thought of it and did the tests.



Here is a flushdns, displaydns, a couple of pings and another displaydns. As you can see the resolver seems to be working but ping doesn't get the answer back.



Your netdig results eliminate firewalls and anything network related as the source of the problem.&nbsp; Your ipconfig /displaydns furthermore shows that the DNS Client service has correctly performed the lookups it was asked to.&nbsp; The problem is thus somewhere between the application processes and the DNS Client service.&nbsp;



The applications communicate with the DNS Client service using (L)RPC.&nbsp; (So, too, does ipconfig, which makes the results very interesting, considering that ipconfig seems to have no problem communicating with the service yet ordinary DNS lookups from applications apparently do.)&nbsp; As I suggested above, turn the DNS Client service off, and do those application lookups again.&nbsp; That should succeed, demonstrating that you have an unusual problem with LRPC for lookups to and from the DNS Client.



One potential problem area there could be the search path logic.&nbsp; So try some tests that use fully-qualified domain names, in order to bypass that mechanism.
 
in message
Query all of these with netdig or something similar. If that works,
then you can eliminate firewalls and network connectivity as causes for
the problem, and concentrate upon the DNS Client itself.

If you find yourself at that point, stop the DNS Client service, and
see what happens to applications that perform DNS lookups once they have
to do them directly, rather than via the client service.

Hello Jonathan, it's been a long time, you are correct, I did err in
leaving out that that information, I tried to think of everything, but
this should rest your mind that I thought of it and did the tests.

Here is a flushdns, displaydns, a couple of pings and another displaydns.
As you can see the resolver seems to be working but ping doesn't get the
answer back.

Your netdig results eliminate firewalls and anything network related as
the source of the problem. Your ipconfig /displaydns furthermore shows
that the DNS Client service has correctly performed the lookups it was
asked to. The problem is thus somewhere between the application processes
and the DNS Client service.

The applications communicate with the DNS Client service using (L)RPC.
(So, too, does ipconfig, which makes the results very interesting,
considering that ipconfig seems to have no problem communicating with the
service yet ordinary DNS lookups from applications apparently do.) As I
suggested above, turn the DNS Client service off, and do those application
lookups again. That should succeed, demonstrating that you have an
unusual problem with LRPC for lookups to and from the DNS Client.

One potential problem area there could be the search path logic. So try
some tests that use fully-qualified domain names, in order to bypass that
mechanism.



I believe the same. I'm thinking the machine was infected causing issues
with network services, whether being the DNS Client service, or some other
component. I'm also leaning towards suggesting a TCP/IP reset. Also, if I
recall, Kevin may have an ISA server, possibly? If so, is there a firewall
(or similar) client installed? It could also be a winsock corruption. I
think to possibly look at least to eliminate that possibility first. The
following links may help.

How to determine and to recover from Winsock2 corruption in ...To repair
Winsock if you do not have Windows XP SP2 installed, delete the corrupted
registry keys, and then reinstall the TCP/IP protocol. ...
http://support.microsoft.com/kb/811259

How to reset Internet Protocol (TCP/IP)When you run the reset command, it
rewrites two registry keys that are used by TCP/IP. This has the same result
as removing and reinstalling the protocol. ...
http://support.microsoft.com/kb/299357

Ace
 
Your netdig results eliminate firewalls and anything network related as the source of the problem. Your ipconfig /displaydns furthermore shows that the DNS Client service has correctly performed the lookups it was asked to. The problem is thus somewhere between the application processes and the DNS Client service.



The applications communicate with the DNS Client service using (L)RPC.&nbsp; (So, too, does ipconfig, which makes the results very interesting,&nbsp; considering that ipconfig seems to have no problem communicating with the service yet ordinary DNS lookups from applications apparently do.) As I suggested above, turn the DNS Client service off, and do those application lookups again. That should succeed, demonstrating that you have an unusual problem with LRPC for lookups to and from the DNS Client.



[...]



I believe the same. I'm thinking the machine was infected causing issues with network services, whether being the DNS Client service, or some other component. [...]



The RPC endpoint mapper is a likely candidate, affecting specific operations on the 45776b01-5956-4485-9f80-f428f7d60129 interface.&nbsp; A more likely candidate is the DNS library code that invokes LRPC.&nbsp; But this could as easily be some internal data corruption, and not code corruption at all.



I'm also leaning towards suggesting a TCP/IP reset. Also, if I recall, Kevin may have an ISA server, possibly? If so, is there a firewall (or similar) client installed? It could also be a winsock corruption. I think to possibly look at least to eliminate that possibility first.



M. Goodknecht did say that xe had already reset WinSock.&nbsp; But re-installing the actual DLLs is important in order to recover from malware infection that has corrupted them, which of course the MSKB 299357 procedure (by its own admission) doesn't achieve.&nbsp; One better procedure for this is running the System File Checker, outlined in MSKB 310747.
 
in message
Your netdig results eliminate firewalls and anything network related as
the source of the problem. Your ipconfig /displaydns furthermore shows
that the DNS Client service has correctly performed the lookups it was
asked to. The problem is thus somewhere between the application processes
and the DNS Client service.

The applications communicate with the DNS Client service using (L)RPC.
(So, too, does ipconfig, which makes the results very interesting,
considering that ipconfig seems to have no problem communicating with the
service yet ordinary DNS lookups from applications apparently do.) As I
suggested above, turn the DNS Client service off, and do those application
lookups again. That should succeed, demonstrating that you have an unusual
problem with LRPC for lookups to and from the DNS Client.

[...]

I believe the same. I'm thinking the machine was infected causing issues
with network services, whether being the DNS Client service, or some other
component. [...]

The RPC endpoint mapper is a likely candidate, affecting specific
operations on the 45776b01-5956-4485-9f80-f428f7d60129 interface. A more
likely candidate is the DNS library code that invokes LRPC. But this
could as easily be some internal data corruption, and not code corruption
at all.

I'm also leaning towards suggesting a TCP/IP reset. Also, if I recall,
Kevin may have an ISA server, possibly? If so, is there a firewall (or
similar) client installed? It could also be a winsock corruption. I think
to possibly look at least to eliminate that possibility first.

M. Goodknecht did say that xe had already reset WinSock. But
re-installing the actual DLLs is important in order to recover from
malware infection that has corrupted them, which of course the MSKB 299357
procedure (by its own admission) doesn't achieve. One better procedure
for this is running the System File Checker, outlined in MSKB 310747.



Good point, 299357 is just a registry reset, based on the script. Possibly
the SFC may do the trick. Or possibly after running the reset (if Kevin
already had performed the proc), rename the winsock.dll, and copy a working
winsock.dll file from another machine?

Ace
 
Back
Top