This chapter will lead you through the common application layer protocols and will make it easy for you to find any anomalies. You will understand and analyze the normal behavior of application layer protocols by looking at the most common protocols and understand their usual and unusual behaviors.
We will cover some of the most common application layer protocols that govern today's networks, whether small or big. Without spending too much time, let me take you on this wonderful journey of protocols.
Imagine a world of Internet where you have to type a random numerical value (IP address), instead of a name, to visit a website. Also, assume that each numerical figure is different. Considering this, how many IP addresses can you memorize? 5? 10? Perhaps, 50 at max? So, now, you are confined to visiting just 50 websites. This doesn't really sound feasible.
Suppose instead of just memorizing the IP addresses, you note down each of them, followed by the name that you want to give to the website to figure out which website is for what purpose. Now, you can create an Excel file for yourself, consisting of the IP addresses written next to the name of the website you gave. This way, probably, you can collect more than a thousand website addresses for later use.
For the sake of your unlimited web experience, DNS comes to your rescue, and it does exactly what you did in the preceding example. DNS creates a database of websites with their IP addresses, along with the name of the domain, A single row of record is often termed as resource records in a zone file. Each entry in the zone file is termed as a resource record. DNS uses TCP and UDP, both for different purposes, over the port 53
by default.
As a client, when you try to visit a website from your LAN environment, your request is being sent through an internal DNS server that looks up the resource records it contains. The request is termed as a DNS query. If your DNS server has already saved the IP address for the domain you are looking for, your client machine will get a reply from the internal DNS server that contains the IP address of the website you are trying to visit. Thus, you can form IP packets and start communicating. This reply is termed as a DNS response.
A DNS packet consists of a couple of unique fields that are briefly discussed here:
Opcode |
Description |
---|---|
0 |
Standard query |
1 |
Inverse query |
2 |
Server status request |
3 |
Unassigned |
4 |
Notify |
5 |
Update |
6-15 |
Unassigned |
Code |
Description |
---|---|
0 |
No error |
1 |
Format error |
2 |
Server failure |
3 |
Name error |
4 |
Not implemented |
5 |
Refused |
Type |
Description |
---|---|
A |
Host address |
NS |
Name server |
MX |
Mail exchange |
SOA |
Start of zone authority |
PTR |
Pointer record |
AAAA |
IPv6 address |
AXFR |
Full zone transfer |
IXFR |
Incremental zone transfer |
A client sends a query to the DNS server that possesses the name resolution information. Using this information, the client can start IP-based communication. Sometimes, the information the client is looking for is not available with the DNS server it requested. In this case, the DNS server itself transfers the query to any neighbor DNS it knows about, if recursion is desirable. The whole query and response thing is completed within two packets only. Refer to the following Figure 4.1 where I am trying to visit https://www.google.co.in. A request from my client located at 192.168.1.103
is sent to the default gateway at 192.168.1.1
. This gateway will forward my query to the DNS server it knows about:
If you notice, here, DNS is using UDP as an underlying protocol. If you want to know more about the DNS query being generated, just expand the flags section. This section will list various details such as whether recursion is available, whether recursion is desired, whether the query is truncated, what the response code is, what the Opcode for the query is, and so on. Please refer to the following screenshot.
The expanded Flags
section depicts that the type of DNS packet is a query, the packet data is not truncated, and recursion is desirable if available.
In response to this query, you will be seeing one more packet with the same transaction ID that denotes the association of a particular query. It is the response packet. Response for our query will usually consist of IPv4 address for the domain we are trying to look for. We'll be returned with a single IP, or maybe multiple IPs available to it. If the domain we are looking for is not available, then its probable CNAME's will be returned in as favor.
Refer to Figure 4.2 to understand this:
As I said, we could get multiple replies. If you notice the Answer RRs section, we have received 5 replies for the www.google.com domain. For verification that the response received belongs to the previous query only, just match the Transaction ID
. Expand any section in the answers category to view more details. Refer to the following image:
Name resolution problems can have a significant impact on the performance of a network. One of the most common DNS problems you can face is when looking for something that does not exist in the DNS server's database. Sometimes, you are trying to visit a website that exists, but your DNS server is not able to resolve the domain you gave. It could also be a timed-out situation where your client waited more than the expected time for a DNS response.
In the following Figure 4.3, I am trying to check the type A record for the http://google.com domain, which is actually an incorrect syntax. Hopefully, it won't be resolved:
As expected, we got a Not Found
error. I only tried once, but the client tried it twice to resolve the domain given. What got captured is depicted in Figure 4.4 here:
There can be multiple situations where you can get stuck. The best option is to first have a benchmark set for your own network, and then try comparing your problem with the benchmark you created. For example, check the name you are trying to resolve, launch a protocol analyzer, and dig into the name resolution queries and responses. Understand how long it is taking to complete the query, the response process, and so on. Every device on the network maintains a local DNS cache (host file), which is initially used to resolve any domain you request. If the local DNS cache does not have the entry for that domain, then the request will be forwarded to the local network's DNS server, which will perform the lookup. If found, their response will be sent. Otherwise, the request from the local DNS server will be forwarded to an external DNS server, which the local DNS server is configured to look for.
3.135.206.254