DNS Protocol Analysis

DNS Messages

We know that the core function of name resolution is carried out by two different messages.

• Query: Sent by the client
• Response: Sent by the server

Each exchange of these messages is referred to as a transaction, and it is assigned a transaction ID by DNS.

• Thanks to the Transaction ID, if a client sends three different name requests to three different servers, we can easily find out which query initiated which response.
• This is an extremely useful feature that can be used when troubleshooting DNS issues or when conducting a forensic network analysis.

As a layer seven application, DNS must rely on a transport protocol layer four to transfer DNS messages from client to server and vice versa.
Most network protocols residing at the application layer usually rely on either TCP or UDP.
But DNS is interestingly one of the few protocols they use both depending on the operation taking place.

• For name resolution, where speed is of the essence, UDP is used as a transport protocol to carry both requests and responses, since UDP does not offer a reliable method of delivering messages. It is up to the client to keep track of the request sent so that if a response is not received at a specific time interval, the corresponding request can be retransmitted. In the interest of preventing excessive DNS traffic on the network, retransmissions are usually sent at an interval ranging from 2 to 5 seconds.
• TCP, on the other hand, is used when data must be delivered reliably, as is the case in scenarios such as zone transfers or when a DNS response requires more than 512 bytes of space.

In terms of size, all UDP DNS messages are limited to a payload of 512 bytes, though if a response message is larger than that, the message is then truncated and a special pin in the header is sent to indicate this outcome.
In such an event, the client would then be expected to retry the query over TCP instead, which doesn't have the same size limitation as UDP.
Transactions taking place over TCP remain a very small fraction of overall DNS traffic, regardless of which transport protocol is used.
The standard port of the server listens on by default is 53, while the port used by the client will always be an ephemeral one.

Other types of DNS messages outside the area of name resolution are:

• Notify: Allows master server to inform slave servers when the zone has changed code over UDP
• Update: Used to add or delete resource records or resource record sets from a specified zone, and it can be carried over either UDP or TCP depending on the size of the request.

DNS Response Codes (RCODES)

In an ideal world, we would like to see every single query that we make to result in a successful translation. Sometimes, however, we're not lucky, and DNS requests can fail to resolve for several reasons.
Whenever that happens, we want to get a first hint behind the failure encountered so that we can troubleshoot the problem effectively, identify the root cause of the issue and eventually fix it.
That's where rcodes come in.
Rcodes indicate whether a narrow condition exists in the response, and each code corresponds to a numeric value.

Most common RCODES that can be found in response messages:

• 0 NoError – No Error
• 1 FormErr – Format Error - which means that the name server was unable to interpret the query.
• 2 ServFail – Server Failure - means that the name server was unable to process this query due to a problem with the name server.
• 3 NXDomain – Non-Existent Domain - which signifies other domain name reference in the query does not exist.
• 4 NotImp – Not Implemented – which means is that the name server does not support the request, that kind of query.
• 5 Refused – Query Refused - which means that the query was refused since the nameserver refused to perform the specified operation for policy reasons.

The full list of RCODES can be found on the flip charts.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

DNS Header

The DNS header consists of a series of field, and we are going to inspect each one in turn.

• The first field in the DNS header is the transaction ID field that we talked about earlier on, in the section once again. Its purpose is to associate DNS queries with their corresponding responses.
• Then we have several flags, starting with a:
• QR bit, which indicates whether the header is for a query represented by a zero or a response represented by one.
• OPCODE - Specify. the query type, each DNS OPCODE is assigned a name.
• AA stands for authoritative answer, and it is valid in responses. Its specifies that the responding nameserver is an authority for the domain name being requested.
• TC stands for truncation, which is said when a message is truncated due to its length being greater. than the maximum size, which is 512 bytes.
• RD stands for Recursion Desired, which is a bait that is said in the query upon the client sending a recursive request to the DNS resolver.
• RA stands for Recursion Available, which denotes whether the name server that is responding. Indeed, supports recursive queries.
• Z reserved for future use, and it must be zero in all queries and responses.
• AD stands for authentic data, while CD stands for checking disabled, both flags are relevant to the DNS mechanism.
• Response codes abbreviated as RCODES. And like we've discussed earlier; they indicate whether an error condition exists in the response.
• Then we have an unsigned integer field:
•  query count that represents the number of questions.
• Then we have the answer count field that represents the number of answers
• NSCount or upcount, which represents the number of authoritative resources records
• ARCOUNT which represents the number of additional records.