In my previous post on HTTP I used a tool called nslookup. It helps debug issues with DNS servers. Today I am going to inspect a few DNS requests in Wireshark.
Before we hit start, lets cover a few basics. DNS lives in layer 7 and operates on IP and UDP (http://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)). DNS is heavily cached so not all name lookups will end up in Wireshark. Hostnames are an example of private names. Today we are going to focus on public names that are served by the public internet.
In order to make for a good test, I am going to clear my DNS cache. At the command prompt type “ipconfig /flushdns”. If using chrome click the clear host cache button ( chrome://net-internals/#dns ). Next type ipconfig /all and take note of the primary dns server name.
Now we can start the capture. Apply the “dns” filter and visit this site http://www.laketrust.com. Notice the address bar change. Not only did we get redirected to https, we also got redirected to .org instead of .com. This is a slightly more interesting site than normal and it’s why I chose it. Lets take a look at that in Wireshark.
DNS queries are quick, small and efficient. The first response is 107 Bytes and has two answers. The first answer is just a CNAME or pointer to the real HOST A record “laketrust.com”. The CNAME won’t ever have an IP but does have a Time to live of 1 hour which is much greater than the HOST A record. TTL instructs the client how long to cache the record before having to query for it again. Also, there doesn’t have to be an answer for no “www” there just usually is.
There isn’t anything in that first DNS query that directs us to .org. Based on the packet numbers, there were 7 things that happened that we have filtered out. Clear the filter to take a look at the missing packets. When you find that DNS response you will see what happens next.
The DNS query gave us an IP. Now we can do stuff :] In this next segment of the capture you see a TCP 3-way handshake. Once that is complete my browser makes a HTTP GET request. The HTTP 301 response redirects us and not DNS. Then we start this whole process again with another DNS query.
DNS is for convenience. Ain’t nobody got time to memorize all the IPs of websites they want to visit. In the example, we had to wait for 2 painful round trips just for dns in order to actually get the “doing stuff” point. Fortunately, this is only required for the first lookup and the rest is sent to the DNS resolver cache until the TTL expires. Had the first CNAME actually pointed to the host we need we could have saved some time.
Also in the example, you’ll notice that I haven’t changed any of my settings in my router or PC in regards to DNS. They are set to automatic, which means I went all the way to my ISP to figure out what DNS server to use and naturally they suggest themselves. Instead of Comcast, Google has another option and they claim it can be faster. Lets investigate by changing your DNS in your router, or just for your PC. Verify the settings took with ipconfig /all. With this configuration I’ll only have to use Comcast if both Google servers are down. The order is important because the first one you enter is your primary.
DNS Servers . . . . . . . . . . . : 22.214.171.124 126.96.36.199 188.8.131.52
If we test the same scenario, you can see in the capture that the Source of my dns responses are now Google. And, in at least very casual testing, the Google servers are faster this time.
Because of physics, the location of this server you are contacting is very important. How far is a millisecond? Well that is a curious question which could be answered by the speed of light which is 186 miles. Multiply that by the pieces of equipment in between you and that server and you will have a vague estimate of how long your DNS queries will take in a no contention, best case scenario.
Before you settle on a different DNS server make sure to test everything. Especially services with a content delivery network that Google might not be privy to (https://developers.google.com/speed/public-dns/faq#cdn)
The OSI model doesn’t do DNS justice. So many things depend on it’s operation that it is best to envision it lower in your stack. Understanding and tuning at the lower levels can cause exponential benefits in user experience.