DNS Query Types and Application Troubleshooting: An Introduction
This is the first in a series of articles (see article 2 and article 3) covering some important aspects to know about the DNS protocol, including the DNS query and DNS response, when troubleshooting application performance issues.
First of all, let’s have a look at the DNS protocol itself. DNS stands for Domain Name System and comes from the fact that humans prefer names to numbers (but computers don’t). It is for example much more easier to remember www.google.com (called a FQDN – Fully Qualified Domain Name) than 22.214.171.124 !
DNS provides not only clarity to users, it also provides a much greater level of flexibility. If the network administrator decides to change the DNS server’s IP address for any reason, the applications that rely on it do not have to be modified. Instead, only the network configuration of the clients’ workstations needs to be modified to make it valid for all applications that are used.
DNS is a query/response protocol. The client queries an information (for example the IP address corresponding to www.google.com) in a single UDP request. This request is followed by a single UDP reply from the DNS server. DNS uses UDP port 53 to connect to the server.
TCP can also be used for response data size exceeding 512 bytes or for specific tasks such as zone transfers.
When is DNS Being Used?
DNS can be used to:
- Convert hostnames to IP addresses
- Convert IP addresses to hostnames (this is called inverse or pointer query)
- Transfer information between DNS servers
- Look up other names elements such as MX records (mail exchange)
DNS Query and Reply Structure
A DNS query and a DNS reply share the same basic structure. Let’s have a look at one DNS query and corresponding response in Wireshark. The DNS query looks like this:
The corresponding DNS response looks like this:
The structure of both the DNS query and the DNS response is identical and is composed of:
- A transaction ID that links a query with its related response
- A flag section (only the first two parameters are discussed here, the others will be discussed in another article about DNS)
- The first bit identifies the query (value = 0) or the response (value = 1)
- The Opcode (4 bits) identifies the type of query (generally 0000 to indicate a standard DNS query)
- 4 parameters follow the flags section:
- Questions: the value provides the number of requests that are sent in the DNS query segment
- Answer RRs/Authority RRs/Additional RRs: RR stands for Resources Records. These parameters will be discussed in another article about DNS.
- The query itself, identified by its type. There are lots of types of DNS queries. Here are the main ones:
- Type “A” for IPv4 addresses
- Type “AAAA” for IPv6 addresses
- Type “CNAME” (Canonical Names) – specifies a domain name that has to be queried in order to resolve the original DNS query
- Type “PTR” (Pointer) that specified a reverse query (requesting the FQDN – Fully Qualified Domain Name – corresponding to the IP address you provided)
- Type “NS” (Name Server) to get information about the authoritative name server
- Type “SOA” (Start Of zone Authority): used when transferring zones
- Type “MX” (Mail eXchange) to request information about the mail exchange server for a specific DNS domain name
- The response (only in the response packet of course)
When analyzing DNS performance, the first step is to identify all DNS query types that exist in your infrastructure.
With Skylight™, this is child’s play.
More importantly, Skylight provides the corresponding error codes that the DNS queries have produced. This will be discussed in another article about DNS.
Lots of business applications rely on DNS protocol today.
An abnormal DNS behavior can have dramatic effects on overall application performance. This is why it is so important to keep an eye on it. Skylight analyses DNS traffic at the layer 7, meaning it can clearly identify the DNS query types and related performance metrics (see other articles for more information).
If you would like to hear more about DNS performance drivers, I would recommend you to take a look at this article on the top 4 indicators of DNS performance leak.