Hello, I cant figure this DNS issue out. I am wondering if this could be a Windows 7 issue though. I have quite a few users to where they cant get to my old domain which is a secondary zone in DNS. Sometimes they can ping some of the servers on that domain but certain servers that cant ping at all. When I do a nslookup it is showing the right dns server, I can even resolve the FQDN from within nslookup but when I try to ping the server using FQDN it times out. This is very weird. It seems that when they reboot it fixes itself but my users are starting to get annoyed by this. Does anyone have any thoughts on this?

if nslookup shows the right data, this is not a dns issue but rather a communication issue. You could try to use tracert to check if the routes used/tried are the same. Also check IPsec functionality and policies. As a test, you could consider turing of the firewall to determine whether it might cause the issue (only authenticated traffic or from a specific subnet allowed or alike). Does the issue occurs when pinging to any host? or only (specific) hosts of the old domain? MCP/MCSA/MCTS/MCITP

if nslookup shows the right data, this is not a dns issue but rather a communication issue. You could try to use tracert to check if the routes used/tried are the same. Also check IPsec functionality and policies. As a test, you could consider turing of the firewall to determine whether it might cause the issue (only authenticated traffic or from a specific subnet allowed or alike). Does the issue occurs when pinging to any host? or only (specific) hosts of the old domain? MCP/MCSA/MCTS/MCITP

if nslookup shows the right data, this is not a dns issue but rather a communication issue. You could try to use tracert to check if the routes used/tried are the same. Also check IPsec functionality and policies. As a test, you could consider turing of the firewall to determine whether it might cause the issue (only authenticated traffic or from a specific subnet allowed or alike). Does the issue occurs when pinging to any host? or only (specific) hosts of the old domain? MCP/MCSA/MCTS/MCITP

We have FW turned off. The servers are different sometimes and so are the users. I can ping by IP fine when the user has the issue but pinging FQDN fails. so since nslookup resolves the FQDN fine but pinging the FQDN fails but pinging the servers IP address works..... it is not a DNS issue then? The next time I see this, I will do a tracert. Thanks

We have FW turned off. The servers are different sometimes and so are the users. I can ping by IP fine when the user has the issue but pinging FQDN fails. so since nslookup resolves the FQDN fine but pinging the FQDN fails but pinging the servers IP address works..... it is not a DNS issue then? The next time I see this, I will do a tracert. Thanks

We have FW turned off. The servers are different sometimes and so are the users. I can ping by IP fine when the user has the issue but pinging FQDN fails. so since nslookup resolves the FQDN fine but pinging the FQDN fails but pinging the servers IP address works..... it is not a DNS issue then? The next time I see this, I will do a tracert. Thanks

Yes, just to validate, when the issue occurs, if you open a command prompt from the problematic computer and use the NSLOOKUP tool, you are directly querying the DNS server. If you receive the expected response, that means that DNS is resolving correctly. If you are unable to ping the target system, it is more likely that you are having a network communication issue. Using the tracert command can help you determine how far the packet can get before its dropped. Visit anITKB.com, an IT Knowledge Base.

Yes, just to validate, when the issue occurs, if you open a command prompt from the problematic computer and use the NSLOOKUP tool, you are directly querying the DNS server. If you receive the expected response, that means that DNS is resolving correctly. If you are unable to ping the target system, it is more likely that you are having a network communication issue. Using the tracert command can help you determine how far the packet can get before its dropped. Visit anITKB.com, an IT Knowledge Base.

Yes, just to validate, when the issue occurs, if you open a command prompt from the problematic computer and use the NSLOOKUP tool, you are directly querying the DNS server. If you receive the expected response, that means that DNS is resolving correctly. If you are unable to ping the target system, it is more likely that you are having a network communication issue. Using the tracert command can help you determine how far the packet can get before its dropped. Visit anITKB.com, an IT Knowledge Base.

Did you try to use the host file under the \etc folder? If it will make a change it’s a DNS issue. If not it’s the Comm. You can also use a logon script to copy the new host file to all your users. Nir This posting is provided “AS IS” with no warranties and confers no rights.

Did you try to use the host file under the \etc folder? If it will make a change it’s a DNS issue. If not it’s the Comm. You can also use a logon script to copy the new host file to all your users. Nir This posting is provided “AS IS” with no warranties and confers no rights.

Did you try to use the host file under the \etc folder? If it will make a change it’s a DNS issue. If not it’s the Comm. You can also use a logon script to copy the new host file to all your users. Nir This posting is provided “AS IS” with no warranties and confers no rights.

We dont use Host files but I am tempting to do it. Thanks for all the help

We dont use Host files but I am tempting to do it. Thanks for all the help

We dont use Host files but I am tempting to do it. Thanks for all the help

Hi Jerry, Thanks for posting here. Have you also set DNS suffix for this problematic host ? Please end with a dot when input FQDN and try pinging again and see how is going . Thanks. Tiger Li Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Check this out. So I got in this morning and 2 people couldnt get to my secondary zone. Once again the nslookup was fine but pinging the fqdn didnt work. Pinging the ip worked fine. I went into the nic card and unchecked IP6 on both computers and now they work fine immediately after I did this.

So, PING as opposed to NSLOOKUP will not perform the name resolution process the same. As described above, when you use NSLOOKUP, you are connecting directly to a DNS server and querying that server. When you use PING, if you supply the command a host name such as PING server1.domain.com, you are using client side name resolution processes which includes querying DNS, but it also uses a variety of other processes to resolve the name. Here is a summary which can help you understand the process... Microsoft Windows TCP/IP NetBIOS and Host Name Resolution http://www.anitkb.com/2010/08/microsoft-windows-tcpip-netbios-and.html Unbinding IPv6 seems like it resolved the issue. You may want to test that a few more times before you are sure that IPv6 was the culprit in this scenario. Visit anITKB.com, an IT Knowledge Base.

So, PING as opposed to NSLOOKUP will not perform the name resolution process the same. As described above, when you use NSLOOKUP, you are connecting directly to a DNS server and querying that server. When you use PING, if you supply the command a host name such as PING server1.domain.com, you are using client side name resolution processes which includes querying DNS, but it also uses a variety of other processes to resolve the name. Here is a summary which can help you understand the process... Microsoft Windows TCP/IP NetBIOS and Host Name Resolution http://www.anitkb.com/2010/08/microsoft-windows-tcpip-netbios-and.html Unbinding IPv6 seems like it resolved the issue. You may want to test that a few more times before you are sure that IPv6 was the culprit in this scenario. Visit anITKB.com, an IT Knowledge Base.

So, PING as opposed to NSLOOKUP will not perform the name resolution process the same. As described above, when you use NSLOOKUP, you are connecting directly to a DNS server and querying that server. When you use PING, if you supply the command a host name such as PING server1.domain.com, you are using client side name resolution processes which includes querying DNS, but it also uses a variety of other processes to resolve the name. Here is a summary which can help you understand the process... Microsoft Windows TCP/IP NetBIOS and Host Name Resolution http://www.anitkb.com/2010/08/microsoft-windows-tcpip-netbios-and.html Unbinding IPv6 seems like it resolved the issue. You may want to test that a few more times before you are sure that IPv6 was the culprit in this scenario. Visit anITKB.com, an IT Knowledge Base.

Hi Jerry, Thanks for update. Actually we’d not recommend to disable IPv6 , it may will properly cause some issues in future. But if this did work for you , we’d suggest to do that with following the workaround in KB 929852. Arguments against disabling IPv6 http://blogs.technet.com/b/netro/archive/2010/11/24/arguments-against-disabling-ipv6.aspx Meanwhile, you can also test by resetting TCP/IP protocol for these problematic hosts and see how is going http://support.microsoft.com/kb/299357 Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Jerry, Thanks for update. Actually we’d not recommend to disable IPv6 , it may will properly cause some issues in future. But if this did work for you , we’d suggest to do that with following the workaround in KB 929852. Arguments against disabling IPv6 http://blogs.technet.com/b/netro/archive/2010/11/24/arguments-against-disabling-ipv6.aspx Meanwhile, you can also test by resetting TCP/IP protocol for these problematic hosts and see how is going http://support.microsoft.com/kb/299357 Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Jerry, Thanks for update. Actually we’d not recommend to disable IPv6 , it may will properly cause some issues in future. But if this did work for you , we’d suggest to do that with following the workaround in KB 929852. Arguments against disabling IPv6 http://blogs.technet.com/b/netro/archive/2010/11/24/arguments-against-disabling-ipv6.aspx Meanwhile, you can also test by resetting TCP/IP protocol for these problematic hosts and see how is going http://support.microsoft.com/kb/299357 Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.