One thing I also learned recently is that the Cisco IPSEC VPN client dialer hijacks all UDP DNS packets and sends them to the DNS server handed out by the VPN concentrators. So "dig @x.x.x.x" and "nslookup foo.bar x.x.x.x" queries don't actually go to x.x.x.x. Don't know if that's in play here but thought it worth mentioning.
-Tim On Tue, Jun 15, 2010 at 11:06 AM, Steve Shockley <steve.shock...@shockley.net> wrote: > On 6/13/2010 4:00 PM, Merton Campbell Crockett wrote: >> >> Inspecting the query log on the name server indicates that BIND never >> services a request from the system running Microsoft's nslookup tool. In >> addition, using tcpdump in controlled tests, I find that Microsoft's >> nslookup implementation never sends any requests to any name server that >> is designated in a "server" command unless it is one of the default name >> servers that the system would normally use. > > WinXP and newer sometimes cache results in unexpected ways, including > caching failed lookups. Perhaps flushing the DNS cache will help. > > With that said, I could not duplicate the problem on Win7's nslookup: > >> foo.shockley.net > Server: server2003.internal.corporate > Address: 192.168.x.x > > *** server2003.internal.corporate can't find foo.shockley.net: Non-existent > domain > >> server 208.67.222.222 > Default Server: resolver1.opendns.com > Address: 208.67.222.222 > >> foo.shockley.net. > Server: resolver1.opendns.com > Address: 208.67.222.222 > > Non-authoritative answer: > Name: foo.shockley.net > Address: 67.215.65.132 > > (foo.shockley.net does not exist, that result is an opendns ad page.) > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
