Re: Microsoft's nslookup Implementation Problems
The Cisco VPN Client does, indeed, change the Microsoft generated DNS search list. The Microsoft DNS resolver routines will use the appropriate Microsoft or Cisco generated search list to resolve names and IP addresses. The problem is that Microsoft's nslookup is isn't using this nor does it use the name server specified on the command line. The problem isn't so much that Microsoft's nslookup implementation returns the wrong answer. The problem is that Windows weanies believe that nslookup is returning the correct answer. Thanks for your help. On Jun 15, 2010, at 11:20 AM, Tim Maestas wrote: > 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 > 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 >> -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
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 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
Re: Microsoft's nslookup Implementation Problems
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
Re: Microsoft's nslookup Implementation Problems
In article , Merton Campbell Crockett wrote: > I identified the problem in my original message. The Windows nslookup > problem involves the failure to send DNS queries to the name server specified > on the command line. Is it sending out any queries at all? If not, my guess is that it's checking the Windows DNS cache first. Does it work as expected if you do ipconfig /flushdns before nslookup? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On Jun 14, 2010, at 7:03 AM, b19...@anl.gov wrote: > On 06/13/10 13:00, Merton Campbell Crockett wrote: >> Microsoft's nslookup is broken. What alternative applications that can >> be installed and used in a Windows XP environment that will continue to >> work in a Windows 7 environment after a decision is made to upgrade Windows? > > In this discussion, I have not seen any definition/details as to > what is "broken". I identified the problem in my original message. The Windows nslookup problem involves the failure to send DNS queries to the name server specified on the command line. nslookup alliance.gd-ais.com ns.azsd01.gd-ais.com When used in an interactive mode, the same failure occurs. nslookup > server ns.azsd01.gd-ais.com > alliance.gd-ais.com The response displayed by Windows nslookup in both cases indicate that the information was obtained from the specified name server. However, if you have tcpdump running on the name server, you will find that the name server was never queried. In each of the above cases, had the name server been queried, the user would have received two A records for the Internet accessible portal that allows employees at customer sites, customers, and vendors to access alliance.gd-ais.com. What was displayed was the internal address for alliance.gd-ais.com. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 13:00, Merton Campbell Crockett wrote: > Microsoft's nslookup is broken. What alternative applications that can > be installed and used in a Windows XP environment that will continue to > work in a Windows 7 environment after a decision is made to upgrade Windows? In this discussion, I have not seen any definition/details as to what is "broken". In the "standard" nslookup, I see some deficiencies: 1) The code checks to see that the DNS server being used is registered in DNS - both forward and reverse. If not, nslookup quits. 2) There are times when the user poses a question to nslookup, and what is produced is not an answer. For example, there could be in the DNS response packet, "ANSWER: 0" and an SOA record as authority. The "dig" utility shows the header fields, so we know that there is no answer. But the novice nslookup user sees the SOA and wonders why that is an answer to his/her question. But neither of these deficiencies is Microsoft's fault. These are deficiencies from the early days of nslookup, I believe. I have no idea if MS has modified the nslookup code. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 D~v ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Microsoft's nslookup Implementation Problems
Hah! Convincing PHBs that a "mature OS like Windows" is broken as compared to that "weird UNIX/Linux stuff" is like convincing the Amish that horse drawn plows aren't the best way to improve crop yields. You're fighting a religious battle in both cases. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Niall O'Reilly Sent: Monday, June 14, 2010 5:08 AM To: Merton Campbell Crockett Cc: BIND Users List Subject: Re: Microsoft's nslookup Implementation Problems On 13/06/10 23:55, Merton Campbell Crockett wrote: > Providing access to the web-based tools to IT personnel might not be that big of a challenge; however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. Perhaps the initial target audience for this tool should be the (hopefully) small number of decision-makers who can require a corporate upgrade and whom you need to convince of how bad the broken nslookup is? IHTH /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 13/06/10 23:55, Merton Campbell Crockett wrote: Providing access to the web-based tools to IT personnel might not be that big of a challenge; however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. Perhaps the initial target audience for this tool should be the (hopefully) small number of decision-makers who can require a corporate upgrade and whom you need to convince of how bad the broken nslookup is? IHTH /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 15:55, Merton Campbell Crockett wrote: Providing access to the web-based tools to IT personnel might not be that big of a challenge; Excellent! however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. I would assert that "the general user" has no idea what nslookup is, or even how to open a windows command line. I can't speak to what passes for "the general user" in your environment however. It produces the "wrong" answers. The result is unnecessary service requests that must be processed. In my mind, this is the problem that needs to be addressed. Then you're back to replacing and/or removing nslookup on each desktop (assuming of course that you've ruled out a preemptive user education program pointing users to the tool that you're going to create). Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On Jun 13, 2010, at 2:21 PM, Doug Barton wrote: >> The problem with the erroneous functioning of Microsoft's nslookup.exe >> is that it requires a corporate wide change. There are a number of >> reasonably intelligent users that assume nslookup.exe is providing them >> correct information. I would need to convince management that it needs >> to be replaced with the ISC version or convince them to deploy DiG to >> all systems. Deploying DiG might be the easier as it doesn't replace >> something distributed by Microsoft. At the same time, the tool that >> users are familiar with is broken. It needs to be replaced. This will be >> a "hard sale" to management. > > That's a different scale of problem than what you originally described. :) > Without knowing more about your internal political/support/etc. structure > it's hard to be sure what the "right" answer is. However if the scope is not > "replace/augment nslookup for a few support techs" but rather "find a way to > give a large number of, possibly non-technical users the right answers" then > I would suggest that perhaps setting up an internal web page that explains > the problem in the simplest possible terms, and provides a CGI with access to > a working version of nslookup and/or dig so that they can get the answers > they need might do the trick. It's interesting that you should mention web-based tools. I had developed several of these for a DoD customer in the latter half of the Nineties. As a proof of concept, they were implemented on my local network. They are still accessible after the last acquisition/merger of my company. It wouldn't take much work to modify the PHP code that I used to eliminate some features that are no longer available due to corporate security policies. Providing access to the web-based tools to IT personnel might not be that big of a challenge; however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. It produces the "wrong" answers. The result is unnecessary service requests that must be processed. In my mind, this is the problem that needs to be addressed. I'm still an Engineer although I was surreptitiously transferred from Engineering to Information Technology 5 years ago to resolve a "political" issue. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 14:08, Merton Campbell Crockett wrote: On Jun 13, 2010, at 1:08 PM, Doug Barton wrote: On 06/13/10 13:00, Merton Campbell Crockett wrote: Microsoft's nslookup is broken. What alternative applications that can be installed and used in a Windows XP environment that will continue to work in a Windows 7 environment after a decision is made to upgrade Windows? In the past I've installed nslookup and dig from the BIND package for windows to solve this problem. You wouldn't happen to know when Microsoft's implementation became hopelessly broken would you? Well given my anti-microsoft bias, my natural answer is "at conception" but that's not particularly helpful for you, sorry. :) Being, primarily, a Linux/Unix user; I tend not to use nslookup except when logged into a Windows system. It has to be several years since I last used nslookup until the last few days. http://dougbarton.us/DNS/bind-users-FAQ.html#nslookup-evil The problem with the erroneous functioning of Microsoft's nslookup.exe is that it requires a corporate wide change. There are a number of reasonably intelligent users that assume nslookup.exe is providing them correct information. I would need to convince management that it needs to be replaced with the ISC version or convince them to deploy DiG to all systems. Deploying DiG might be the easier as it doesn't replace something distributed by Microsoft. At the same time, the tool that users are familiar with is broken. It needs to be replaced. This will be a "hard sale" to management. That's a different scale of problem than what you originally described. :) Without knowing more about your internal political/support/etc. structure it's hard to be sure what the "right" answer is. However if the scope is not "replace/augment nslookup for a few support techs" but rather "find a way to give a large number of, possibly non-technical users the right answers" then I would suggest that perhaps setting up an internal web page that explains the problem in the simplest possible terms, and provides a CGI with access to a working version of nslookup and/or dig so that they can get the answers they need might do the trick. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On Jun 13, 2010, at 1:08 PM, Doug Barton wrote: > On 06/13/10 13:00, Merton Campbell Crockett wrote: >> Microsoft's nslookup is broken. What alternative applications that can >> be installed and used in a Windows XP environment that will continue to >> work in a Windows 7 environment after a decision is made to upgrade Windows? > > In the past I've installed nslookup and dig from the BIND package for windows > to solve this problem. You wouldn't happen to know when Microsoft's implementation became hopelessly broken would you? Being, primarily, a Linux/Unix user; I tend not to use nslookup except when logged into a Windows system. It has to be several years since I last used nslookup until the last few days. The problem with the erroneous functioning of Microsoft's nslookup.exe is that it requires a corporate wide change. There are a number of reasonably intelligent users that assume nslookup.exe is providing them correct information. I would need to convince management that it needs to be replaced with the ISC version or convince them to deploy DiG to all systems. Deploying DiG might be the easier as it doesn't replace something distributed by Microsoft. At the same time, the tool that users are familiar with is broken. It needs to be replaced. This will be a "hard sale" to management. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 13:00, Merton Campbell Crockett wrote: Microsoft's nslookup is broken. What alternative applications that can be installed and used in a Windows XP environment that will continue to work in a Windows 7 environment after a decision is made to upgrade Windows? In the past I've installed nslookup and dig from the BIND package for windows to solve this problem. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
