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.
- DNS—normal and unusual
- Lab Up—DNS
- FTP—normal and unusual
- Lab Up
- HTTP—normal and unusual
- Lab Up—HTTP
- SMTP—normal and unusual
- Lab Up—SMTP
- SIP—normal and unusual
- Lab Up—SIP
- VoIP—normal and unusual
- Lab Up—VoIP
- Decrypting encrypted traffic
- Practice questions
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:
- Transaction ID: This is a number that keeps the dots connected between a particular domain query and it's corresponding response.
- Query/response: Every DNS packet is marked as a query or a response, depending on the details it contains.
- Flag bits: Each query and response contains different flag bits set, which are as follows.
- Response: The message is a query or a response.
- Opcode: This determines the type of query contained. Opcode ranges between 0–15. Refer to the following table:
Opcode
Description
0
Standard query
1
Inverse query
2
Server status request
3
Unassigned
4
Notify
5
Update
6-15
Unassigned
- Truncated: This determines whether the packet is truncated if its size is large (greater than 512 bytes).
- Recursion desired: The query sent by your client is supposed to go on a recursive search procedure from one DNS server to another if the resource record you are looking for is not present.
- Recursion available: If this bit is set, then it means the recursion that your client requested is available, and if what you are looking for is not present on one server, then your query would be transferred to another DNS for lookup procedure.
- Reserved (z): .As defined by RFC 1035; Reserved for future use, must be set to zero for all queries and responses.
- Response code: The values in this field signifies the response.
- Response code: This field is used to signify whether errors and the type of error. Here are the possible code values that you can receive:
Code
Description
0
No error
1
Format error
2
Server failure
3
Name error
4
Not implemented
5
Refused
- Questions: Indicates the number of queries present in the packet.
- Answers: Indicates the number of answers in response to the query sent.
- Authority RRs: Indicates the number of authority resource records sent as response.
- Additional RRs: Indicates the number of additional resource records sent as response.
- Query section: The query sent to the DNS Server, it should be the same in the response received as well.
- Answer section: The answer that came as a response to our query. The response can be multiple too. The answer basically consists of the resource records that came in response to our query.
- Type: This field indicates the type of query sent. Refer to the following table for common query types.
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
- Additional info: This field includes additional info containing resource records. It is not required to answer the query.
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:
Figure 4.1: DNS query
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:
Figure 4.2: DNS response
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:
Figure 4.3: Type A record for http://google.com
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:
Figure 4.4: DNS Response-No Such Name
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.