Why do I get different DNS response from OpenDNS?

[Cooky]

Trying out OpenDNS as URL-filter.
Noticed when I do nslookup on any site, the result is always 67.215.65.132, which belongs to OpenDNS.
//
C:>nslookup forums.anandtech.com
Server: resolver1.opendns.com
Address: 208.67.222.222

Non-authoritative answer:
Name: forums.anandtech.com
Address: 67.215.65.132
//

So my impression was that ALL traffic was going through OpenDNS like a proxy.
However, that's not the case.
When I perform any non-nslookup task, such as ping, traceroute, or loading a site in browser, traffic would go to the correct final destination. (confirmed in Wireshark)

//
C:>ping forums.anandtech.com

Pinging forums.anandtech.com [199.19.80.12] with 32 bytes of data:
Reply from 199.19.80.12: bytes=32 time=48ms TTL=53
Reply from 199.19.80.12: bytes=32 time=53ms TTL=53
//

It seems the behavior is:
if (nslookup), then 67.215.65.132
if else, then True_IP

How does OpenDNS know what answer/IP to reply to me?
All it gets should be a simple DNS query via UDP 53, and the answer should be consistent.

 

[Mushkins]

ping/tracert both do not show the dns server as part of the hops because the traffic doesnt go *through* the dns server like it would a proxy. Your router asks the DNS server "what is the IP address of www.google.com?" and it responds 123.123.123.123 or whatever. Then your router directly connects to that IP.

nslookup shows you the DNS results because it's specifically a DNS lookup tool

99% your DHCP server (your router, in this case) has OpenDNS configured as its primary DNS server, I believe DDWRT and Tomato firmwares both automatically set it OpenDNS.

 

[Cooky]

Thank you mushkins, for the reply.

Before ping/tracert can send ICMP packets on the wire, the host needs to resolve the name into IP first.
So it would go through a name resolution process just like nslookup...no?

My laptop is directly using OpenDNS as its DNS servers, and not the router.
My router just route & NAT packets.

 

[Mushkins]

Thank you mushkins, for the reply.

Before ping/tracert can send ICMP packets on the wire, the host needs to resolve the name into IP first.
So it would go through a name resolution process just like nslookup...no?

My laptop is directly using OpenDNS as its DNS servers, and not the router.
My router just route & NAT packets.

That's correct. Think of it as two separate transactions

When you type "ping google.com" the following happens:
1) Your PC asks the DNS server (OpenDNS) "what is the IP of google.com?"
2) The OpenDNS server, assuming it knows, returns to your PC "The IP of google.com is xxx.xxx.xxx.xxx"
3) Your PC then pings xxx.xxx.xxx.xxx directly, NOT "www.google.com"

Tracert and Ping do not display the DNS query as a "hop" because it's not a hop in the connection between your PC and the destination IP, it's a separate transaction. They simply display the results of the resolution information in the header where it says "pinging google.com (xxx.xxx.xxx.xxx)".

What you're describing would be the behavior of a proxy, where you ask the DNS server "what is the IP" and then the DNS server acts as a middle man, pings google for you, google returns the results to the DNS server, which then returns them to you. If DNS servers were gigantic internet proxies, the internet would be very, very slow

 

[SecurityTheatre]

That's correct. Think of it as two separate transactions

When you type "ping google.com" the following happens:
1) Your PC asks the DNS server (OpenDNS) "what is the IP of google.com?"
2) The OpenDNS server, assuming it knows, returns to your PC "The IP of google.com is xxx.xxx.xxx.xxx"
3) Your PC then pings xxx.xxx.xxx.xxx directly, NOT "www.google.com"

Tracert and Ping do not display the DNS query as a "hop" because it's not a hop in the connection between your PC and the destination IP, it's a separate transaction. They simply display the results of the resolution information in the header where it says "pinging google.com (xxx.xxx.xxx.xxx)".

What you're describing would be the behavior of a proxy, where you ask the DNS server "what is the IP" and then the DNS server acts as a middle man, pings google for you, google returns the results to the DNS server, which then returns them to you. If DNS servers were gigantic internet proxies, the internet would be very, very slow

This doesn't answer his question at all. He clearly already understands how DNS works. Go look at his two examples and explain why there are two different IPs.

Problem is, I don't know the answer, either- That's very strange behavior.

I'd put a Wireshark on it and see what happens and where the requests are directed. Perhaps the nslookup traffic is using TCP. I know it does use TCP when you enter the nslookup command prompt, but I thought it was UDP when using the command line.

 

[Cooky]

I had Wireshark running when I performed ping, tracert, and loading in browser.
All of them showed a name resolution response from OpenDNS DNS servers, which was the correct, actual IP.
However, my Symantec client seems to interfere w/ Wireshark's ability to see locally generated packets, so I only see return traffic sometimes.
I'm not seeing the initial name resolution requests, which could be the key to this behavior.

I'll probably need to SPAN traffic to my LAN port, while using wireless to initiate requests, which will take some time to set up.

In the mean time, can other OpenDNS users confirm if you're seeing the same behavior?

thanks!