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.

"Jonathan de Boyne Pollard" wrote
in message
ard.localhost...
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