I have Windows 7 professional x64 pc. I have another host running Linux, trixter.intranet.org, which serves several web sites, each with a different host alias: hg.intranet.org, svn.intranet.org, bugzilla.intranet.org, etc. Occasionally, the Windows pc will be unable to find any of the aliased hosts, even when it can find the canonical name. The aliases will be un-resolvable for a period of several minutes, and then, with no intervention, they can be found again. Trixter is also my nameserver, (bind 9.6.2-p2), the host aliases are defined with CNAME entries. Trixter can always resolve the aliases to itself. Even stranger, when I use Cygwin from the problematic Windows 7 PC, it CAN resolve the hosts. I can ping hg.intranet.org from a Cygwin shell, but not from a “cmd.exe” window. Administrator privileges make no difference. What could be the problem, and it there a way to fix this?

Hello, This problem could be caused by several different things and without further troubleshooting a very difficult question to answer. My suggestion would be to use a network sniffing tool such as Wireshark or Microsoft Network Monitor to take a network trace while trying to reproduce the problem. You could run the network trace while trying to use the Cygwin shell, then stop the trace. You could also run the network trace while trying to resolve names from the cmd line, save that as well. Remember that each time you attempt this, you should run the "ipconfig /flushdns" cmd to ensure that the local DNS Cache is clear and that the client will be forced to send out a DNS Query. You could apply a DNS filter to the traces to see exactly how the name resolution process is working from this client and that might provide you with the answer or a clue as to what the problem is. Another suggestion is to use the built in command nslookup and point to the client's preferred DNS server and try to resolve the names that way. If data analysis is required, it will be necessary for you to open a paid support incident with Microsoft. This can be facilitated through your premier contract if you have one or through the following link: http://support.microsoft.com/

I know what you are writing, and you might have a good reason for posting them. You are saying, "I don't know" and "it is hard to tell." Neither is a good "answer" for someone who is suffering from this issue. You, a would-be helpful reader, do not have enough info. I, the sufferer, don't have access to the Microsoft issue database. I have used netshark (wireshark?) in the past, and am comfortable in saying that netshark is a seriously HARDCORE tool. If the solution lies in sniffing packets, it is a BUG in the Win 7 IP stack.

Interestingly I've started seeing the same problem here at my office intranet since using a CNAME for a new resource. Locally hosted DNS via Windows Server 2008 R2 (replicated across 2 servers, both referenced as DNS sources in DHCP) Windows 7 clients randomly fail to resolve the resource. FlushDNS corrects the problem. I cannot find any common variables, but have not run wireshark. Observations: 1) When the issue is happening, I can run NSLookup on an affected machine and it does properly resolve the resource name 2) I can successfully ping the resource by its name 3) The resource is being accessed by a WSDL generated class in a Windows Form application. The Web Service URL (CNAME ) is supplied at runtime. It is often initially resolved, and over the course of the day of using the application resolution failures may or may not occur (usually it works fine.) Re WireShark The issue has yet to appear on my dev box where WireShark is installed. I do not feel comfortable deploying wireshark to all of my users (for an untold number of reasons, including security) If I need to install wireshark at the time of the issue, there is no guarantee that the problem will still be occurring once the installation is complete. Should the issue occur and I do have wireshark handy, what do you recommend I filter for? I generally look at web traffic of TCP streams over port 80, what would be the appropriate traffic type/port? Next Step Though I do not understand why it would be an issue (or is even related) I will move away from using a CNAME to an A record and see if the problem continues. I'll post back here if I have any updates to report Thanks for any help our fellow forum goers, MVP's can give. - Jordan

The issue has occurred for another user, changing from a cname to an A record did not seem to resolve the issue. Any help would be greatly appreciated.

I think I may have just struck gold and was able to grab a packet dump. I'm going to start a new thread as Charlweed does not appear to be checking this one (he originally posted the issue a few months ago) and I am unable to confirm that this is the same problem.