DNS Problems
March 1, 2006 5:30 PM Subscribe
DNS Problems:Can ping outside address but can't resolve DNS
I have a small 5 computer LAN. All computers have no problems except for one Windows XP machine. I have verified that all settings are correct. I can do a tracert to an outside address though it take about 19 hops, but can resolve any domain names. Any ideas on what to check next?
I have a small 5 computer LAN. All computers have no problems except for one Windows XP machine. I have verified that all settings are correct. I can do a tracert to an outside address though it take about 19 hops, but can resolve any domain names. Any ideas on what to check next?
Response by poster: Yes, I can ping my router which is my primary DNS machine
posted by tirebouchon at 5:47 PM on March 1, 2006
posted by tirebouchon at 5:47 PM on March 1, 2006
What CrayDrygu said. And..
Your ISP is required to maintain at least a primary and secondary DNS server. Your router should have these addresses loaded as its primary and secondary DNS sources, but it is not a bad idea to have additional DNS servers you can reach loaded as backups, in case, for some reason, your router can't do DNS queries on your ISP's machines. So, you could put 4.2.2.1 as your third DNS entry (or whatever other DNS machine you can connect with on as few hops as possible, outside your ISP's domain).
If your router is not caching DNS, you could also load these tertiary DNS sources in your Windows machine, or if you are getting your private IP address assignments on your LAN via DHCP from your router, make sure that your router is configured to pass them out in it DHCP negotiation, so your Windows machines have them.
posted by paulsc at 6:09 PM on March 1, 2006
Your ISP is required to maintain at least a primary and secondary DNS server. Your router should have these addresses loaded as its primary and secondary DNS sources, but it is not a bad idea to have additional DNS servers you can reach loaded as backups, in case, for some reason, your router can't do DNS queries on your ISP's machines. So, you could put 4.2.2.1 as your third DNS entry (or whatever other DNS machine you can connect with on as few hops as possible, outside your ISP's domain).
If your router is not caching DNS, you could also load these tertiary DNS sources in your Windows machine, or if you are getting your private IP address assignments on your LAN via DHCP from your router, make sure that your router is configured to pass them out in it DHCP negotiation, so your Windows machines have them.
posted by paulsc at 6:09 PM on March 1, 2006
Windows firewall blocking DNS (port 53)? (unlikely, though)
Something like ZoneAlarm blocking outgoing port 53?
Is another computer running Linux or OS X? You could run tcpdump -n port 53 there, and then run nslookup on the XP machine, and watch the tcpdump to see what's going on.
Or, as mentioned above, mix in an external DNS server.
posted by kurumi at 6:11 PM on March 1, 2006
Something like ZoneAlarm blocking outgoing port 53?
Is another computer running Linux or OS X? You could run tcpdump -n port 53 there, and then run nslookup on the XP machine, and watch the tcpdump to see what's going on.
Or, as mentioned above, mix in an external DNS server.
posted by kurumi at 6:11 PM on March 1, 2006
Response by poster: I can ping the primary and seconday DNS machines and I have also tried using 4.2.2.1 to no avail. The router is using DHCP and when I do an IPCONFIG everything looks great. It's like something is hijacking my dns settings behind the scenes. Any way I would be able to see if that is happening?
posted by tirebouchon at 6:52 PM on March 1, 2006
posted by tirebouchon at 6:52 PM on March 1, 2006
You might find a packet sniffer handy in a situation like this, to see what's happening "behind the scenes"...try Ethereal, it's free/opensource. You can easily capture your network traffic frames and sort/filter them to view what's happening on DNS resolution.
posted by edverb at 7:28 PM on March 1, 2006
posted by edverb at 7:28 PM on March 1, 2006
If it's a LAN of 5 machines, and only one is having a problem, then it's a problem with that machine. (OK, maybe the router itself...)
I saw a few cases recently of Norton's Internet Security suite suddenly deciding to block DNS lookups. In all cases, Norton's was installed but had never been configured! Since it wasn't configured, there was no way of turning it off (not that there ever really is with Norton's anyway...). Completely uninstalling it was the only answer.
If you do an "nslookup metafilter.com" from a command prompt on the offending machine, that'll at least tell you what DNS server it's really trying to use, and whether it's responding or not. Check the result against one of the other machines on the LAN.
posted by Pinback at 8:00 PM on March 1, 2006
I saw a few cases recently of Norton's Internet Security suite suddenly deciding to block DNS lookups. In all cases, Norton's was installed but had never been configured! Since it wasn't configured, there was no way of turning it off (not that there ever really is with Norton's anyway...). Completely uninstalling it was the only answer.
If you do an "nslookup metafilter.com" from a command prompt on the offending machine, that'll at least tell you what DNS server it's really trying to use, and whether it's responding or not. Check the result against one of the other machines on the LAN.
posted by Pinback at 8:00 PM on March 1, 2006
Uninstall any Norton firewall software. I recently had a very similar problem, called tech support, they told me it was my firewall. Adamant, I cried "but my firewall isnt even running!". Uninstalled it, problem was fixed. Strange, but true.
posted by sophist at 12:53 AM on March 2, 2006
posted by sophist at 12:53 AM on March 2, 2006
Reinstall your TCP/IP stack on the Windows XP machine using the netsh command - "netsh int ip reset resetlog.txt".
It's a simple command line tool in Windows XP, fixes many strange things.
posted by disclaimer at 4:51 AM on March 2, 2006
It's a simple command line tool in Windows XP, fixes many strange things.
posted by disclaimer at 4:51 AM on March 2, 2006
Response by poster: I tried reinstalling the TCP/IP stack and that didn't work. After installing Ethereal 99% UDP traffic all of it says
"name query NB Microsoft.com" with the destination as 192.168.1.255
posted by tirebouchon at 8:18 AM on March 2, 2006
"name query NB Microsoft.com" with the destination as 192.168.1.255
posted by tirebouchon at 8:18 AM on March 2, 2006
After installing Ethereal 99% UDP traffic all of it says "name query NB Microsoft.com" with the destination as 192.168.1.255
I'm not sure what bearing this has on your original problem. What you're looking for is an answer to where the DNS queries are failing. Try running the capture while you use a browser to visit, or a CMD prompt to ping various domain names you're unable to resolve (and mix in a few you've never visited), and take notice of how DNS queries are handled in the capture, their destination and where the breakdown in resolution is occurring.
As for the UDP packets you're seeing (which may or may not be related) I'm not entirely certain what that means, tirebouchon. I think it means that your machine is trying to connect to a network share (NB is "NetBIOS") called "microsoft.com", sending the name query using UDP to your LAN's broadcast address (192.168.1.255) effectively querying every machine for the share. I don't know if you have a shared folder (perhaps unreachable?) on your LAN with that name, or if you once did and now don't. On the packets you captured, is the UDP source port 137? Does any machine on the LAN respond to this query?
I'm (obviously) not familiar with every possibility, but I typically see network share resolution listed under protocol NBNS in captures, not under UDP. So I'd like to know which application or service is sending these queries, especially if there are a lot of them and they are unresolved.
So, not being sure which application or service is seeking to resolve "microsoft.com" as a NetBIOS name on the LAN, I might try using a tool such as TCPView to correlate the source UDP port to the application or service which is attempting to make this connection, and once I know what is flooding my network with these requests, take it from there.
It may not have any bearing on the DNS thing though. It may also point you towards some systemic problem. Just trying to get a picture of what's going on.
posted by edverb at 9:27 AM on March 2, 2006
I'm not sure what bearing this has on your original problem. What you're looking for is an answer to where the DNS queries are failing. Try running the capture while you use a browser to visit, or a CMD prompt to ping various domain names you're unable to resolve (and mix in a few you've never visited), and take notice of how DNS queries are handled in the capture, their destination and where the breakdown in resolution is occurring.
As for the UDP packets you're seeing (which may or may not be related) I'm not entirely certain what that means, tirebouchon. I think it means that your machine is trying to connect to a network share (NB is "NetBIOS") called "microsoft.com", sending the name query using UDP to your LAN's broadcast address (192.168.1.255) effectively querying every machine for the share. I don't know if you have a shared folder (perhaps unreachable?) on your LAN with that name, or if you once did and now don't. On the packets you captured, is the UDP source port 137? Does any machine on the LAN respond to this query?
I'm (obviously) not familiar with every possibility, but I typically see network share resolution listed under protocol NBNS in captures, not under UDP. So I'd like to know which application or service is sending these queries, especially if there are a lot of them and they are unresolved.
So, not being sure which application or service is seeking to resolve "microsoft.com" as a NetBIOS name on the LAN, I might try using a tool such as TCPView to correlate the source UDP port to the application or service which is attempting to make this connection, and once I know what is flooding my network with these requests, take it from there.
It may not have any bearing on the DNS thing though. It may also point you towards some systemic problem. Just trying to get a picture of what's going on.
posted by edverb at 9:27 AM on March 2, 2006
This thread is closed to new comments.
posted by paulsc at 5:34 PM on March 1, 2006