In the previous recipe, we saw how to identify a normal operation of DNS. In this recipe, we will learn how to discover problematic behavior of DNS, and how to figure out its source.
A DNS problem can result in bad performance while browsing the Internet, slow network while working inside the organization network, or any other performance issues. We will see how to isolate these problems and how to find out whether it is a DNS issue or not.
There are two major types of problems in DNS:
In both cases, connect your Wireshark to the network in the following order when you suspect an Internet connectivity problem:
How will you know that this is the problem?
Assuming your connectivity to the network is working properly, ping the website you are trying to browse (for example, issue the command: ping www.packtpub.com
) and see if you get any response.
0x971e
(the same code in query and response indicates that this is the response to the query)346 ms
delay between the DNS query and response, which means that the response came from an overseas server (for example, browsing from Europe when the DNS server is in Taiwan)a.dns.tw
(that is, DNS server is in Taiwan), which means that the DNS system works properly and your PC queried one of the authoritative DNS servers for .tw
When you right-click on one of the packets in the preceding screenshot and choose Follow UDP Stream, you will see that the DNS resolver on your PC sends several queries (with increasing time intervals between them), and then stops. This is shown in the next screenshot:
How will you know that this is the problem?
You will get a graph of the DNS response times throughout the capture time.
In this graph, you will see that most of the response times fall below 100mSec, which is quite reasonable. We have two peaks that indicate a probable problem, one at the beginning of the capture with 300 ms, and one at the end of the capture with 450 ms.
There are six basic types of DNS response codes defined in RFC 1035
. Additional error codes (up to 21) were defined in later standards (RFC 2136
, RFC 2671
, RFC 2845
, and RFC 2930
). Error codes can be found at http://tools.ietf.org/html/rfc2929#section-2.3.
The most common codes are shown in the following table:
Error code |
Name |
What is it (RFC 1035) |
Why it happens |
What to do |
---|---|---|---|---|
|
No error condition |
No error, everything works fine. |
This signifies that everything is working. |
Be happy. |
|
Format error |
The DNS server couldn't interpret the query. |
This error code is usually shown when the DNS server does not support DNS extensions, for example, |
In most cases, there is nothing to do. The DNS request will be sent again without the extension. If the problem still exists, change the DNS server. |
|
Server failure |
The DNS server was not able to process the query due to a problem with the name server. |
This error code signifies that there is a problem in the DNS server. |
Configure another DNS server and check again. |
|
Name error |
This is meaningful only for responses that are coming from authoritative name servers. |
This error code signifies that the domain name requested in the query does not exist. |
Check the domain name. |
|
Not Implemented |
The DNS server does not support the requested type of query. | ||
|
Refused |
The DNS server refuses to perform the specified operation due to policy reasons. |
A name server may not wish to provide the information to the particular requester. A name server may not wish to perform a particular operation. |
This occurs due to connectivity problems, if the forward DNS is not configured, or if there is a problem in one of the DNS servers on the way. |
What DNS server should I configure? I have been asked this question many times. My answer to this is simple—a server that is physically close to you (that is, not an overseas server), and one that you know is efficient. An efficient server, that is, overseas will give slow responses due to the communication lines, and a nearby non-efficient server will also give you slow response times.
In the preceding graph, we see a measurement taken with the Google Namebench open software (freeware). It shows the following details:
10.0.0.138
)To summarize this, it is OK to have response times of around 100 ms; and in most of the cases, 150-200 ms will also be good enough. Don't worry if there are momentary peaks—it can be that your resolver is querying authoritative servers on the other side of the globe.
When you open a web page that holds a lot of content, your browser can send even tens of DNS queries. In the following screenshot, you see what happens when I open the browser to www.cisco.com.
It starts with a DNS query to the A
record of www.cisco.com (marked as 1 in the preceding screenshot), then a query to ap.ff.avast.com
(marked as 2 in the preceding screenshot), which is the web shield server of Avast antivirus, to www.static-cisco.com
(marked as 3 in the preceding screenshot), ciscosystems.tt.omtrdc.net
(marked as 4 in the preceding screenshot), news (marked as 5 in the preceding screenshot), products (marked as 6 in the preceding screenshot), and newsroom (marked as 7 in the preceding screenshot) sites.
When we look at the response time graph (shown in the next screenshot), we see that the DNS response times are up to 600 ms. This explains why it took a few seconds to open the entire web page of Cisco.
3.128.205.21