Having been a victim of this issue I can attest to this reported behaviour. Your failure to reproduce the issue is due to using different testing methods. Although you are following his reported testing method, it is important to note that his "do a dns lookup" does not mean to "perform an nslookup." It is important to note his comment that "Also of interest is that nslookup didn't use the windows dns services to send dns requests, but used its own, and so behaved differently than expolorer or ping." Follow the below to reliable reproduce the issue. Go to IE and browse to non-existanthost.localdomain.com (running nslookup does not result in the response being cached) Run ipconfig /displaydns to verify that negative acknowledgement is cached locally on the client C:\>ipconfig /displaydns non-existanthost.localdomain.com ---------------------------------------- Name does not exist. Create DNS records so the entry now exists. You can even place the entry in the hosts file. Close browser (or command prompt) and attempt to browse again in IE again (or attempt to ping host) without running ipconfig /flushdns C:\>ping non-existanthost.localdomain.com Ping request could not find host non-existanthost.localdomain.com. Please check the name and try again. Run ipconfig /displaydns to verify that negative acknowledgement is still cached locally on the client. C:\>ipconfig /displaydns non-existanthost.localdomain.com ---------------------------------------- Name does not exist. Run ipconfig /flushdns and then run ipconfig /displaydns to verify the entry is gone C:\>ipconfig /flushdns Windows IP Configuration Successfully flushed the DNS Resolver Cache. Close browser (or command prompt) and attempt to browse again in IE again (or attempt to ping host) C:\>ping non-existanthost.localdomain.com Pinging non-existanthost.localdomain.com [255.255.255.255] with 32 bytes of data: -----Original Message----- From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx] Sent: Thursday, April 20, 2006 12:39 PM To: John Biederstedt; Bugtraq Subject: Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup I don't think your issue is with the XP client DNS resolver. If this consistently fails for you, it must be on the Checkpoint client side. I've tested this repeatedly in a myriad of different scenarios, and the resolution has worked exactly as it should in each case. With the exception of the Checkpoint product (I use ISA, not Checkpoint) I followed your steps precisely without once experiencing any issues (other than the failed DNS lookup, which was of course expected.) I really hope that the Bugtraq moderator decides to post this thread, as I think it very well exemplifies the need for this type of follow-up data to be published rather than just the first "Oh, X is broken as well because of Y" posts. I know this list is extremely difficult to moderate (I really do, Dave- just my 2 weeks moderating the MS-Focus list was very time intensive just from SPAM, even though I may seem a bit intolerant of things sometimes) but it is critical for people to get full, accurate bits of data. I'm not trying to be an ass here (I'm really not) but this specific issue has come from a post about an "XP DNS client resolver" problem that was "rotten, yes, surprising, no" to an "according to Microsoft" being "intended" behavior, to now us seeing that you've most likely got Checkpoint client problems that have nothing to do with the dnsapi.dll. We've got no references to anything "according to Microsoft" and now that we've got detailed information, everyone else on the list can test this for themselves and see that there isn't an issue. t On 4/20/06 8:14 AM, "John Biederstedt" <john@xxxxxxxxxxxxxxx> spoketh to all: > In brief: > need a checkpoint firewall 4.1 or higher. set up a preshared key. > install client on winXP machine -w- preshared key. > boot XP box not in target network, but from a remote network connected > to the Internet via TCP/IP. > Once connectivity to the Internet is established do a dns lookup of > something you know will resolve, like www.google.com. > lookup something within the target network that won't resolve - force > a failed dns lookup. > establish a VPN into the checkpoint firewall. > verify the VPN is working by pinging something in the target network > that is known to reply to pings, like a DC. > run a nslookup from previous step of FQDN inside target network. > enter known values for target FQDN into hosts file. > try lookup again. > > Failed for us consistantly. > > I'd be interested in knowing if other have had this problem. We ended > up pushing a script that ran at VPN setup time that flushed the DNS > cache. We also pushed a hosts file with the needed FQDNs, since both > were needed to net nslookups to work right. Also of interest is that > nslookup didn't use the windows dns services to send dns requests, but > used its own, and so behaved differently than expolorer or ping. It > did use the hosts file first, while the windows OS dns services needed > to have the dns flushed to get rid of the cached failures. We > observed this by watching traffic and seeing that a windows XP box > tried twice to resolve a dns query (two requests sent) when using > nslookup with a different timeout, while the same thing from explorer > tried four times with a different timeout. Ping resulted in the same > dns query traffic as expolorer. >
