Actually, according to microsoft, the dns client in XP was *intended* to
check to see if a dns lookup had failed earlier before going to the
hosts file.
We did ping the internal domain controller, added the bogus FQDN, and
tried again. None of that worked, because prior to the VPN working, and
lookup of the domain controller had failed, and been cached. So,
because the failiure was checked before the hosts file, once the VPN was
up, the dns lookups didn't work.
Oh yes, the XP install was factory Dell.
--- Begin Message ---
|
Subject: |
Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup |
|
Date: |
Wed, 19 Apr 2006 15:22:32 -0700 |
Then you've hosed your XP install. XP does not resolve cached addresses
before the hosts file.
Ping your 1918 domain controller. Add a bogus entry for the FQDN of the
same machine. Ping it again. Hosts file overrides. I'm not sure what you
mean by "DNS failiures" though. Please post something we can all use to
test your rotten but unsurprising behavior.
Oh, and before getting very frustrated, even in your hosed install, just try
a "IPCONFIG /flushdns" next time.
t
On 4/17/06 5:33 AM, "john@johnsdomain.org" <john@johnsdomain.org> spoketh to
all:
The XP DNS client has other problems as well. It caches DNS failiures
(arguably out of spec with the RFC, BTW), screwing up VPNs if you're VPNed
into an internet network that has local domains which need to resolve to
RFC1918 addresses. The cached failed lookups get prefered to forced entries
in the hosts file, if that is tried as a way of forcing the dns lookups to
work. Very frustrating. So, this isn't much of a surprise. Rotten, yes,
surprising, no.
--- End Message ---
