DNS protocol message format

DNS query and response messages use a uniform format. These messages can be transported in UDP datagrams via port 53 or TCP datagrams via port 53. UDP datagrams have a fixed size of 512 bytes and must be truncated if the message is longer. This is identified by the Tc flag. DNS messages are composed as follows:

Detail of message header :
– Identifier: Integer representing a request, to be copied in the response, enabling the originating application to identify the return datagram. (16-bit)
– Flags : Qr : This field indicates whether the message is a request (0) or a response (1). (1 bit), Opcode: This field specifies the type of query (4 bits): 0: Standard query (Query), 1: Inverse query (IQuery), 2: Server status (Status), 3-15: Reserved for future use, Aa: This flag stands for “Authoritative Answer”. Indicates whether the name server responding to the request is authoritative on the domain (1 bit). Tc: This field indicates that this message has been truncated. This flag is set to 0 when TCP is used, but when UDP is used it can be set to 1 if the response exceeds 512 bytes (1bit). Rd: This flag allows you to request recursion by setting it to 1 (1 bit). Ra: This flag indicates that recursion is authorized (1 bit). Z: This one is reserved for future use. It must be set to 0 (1 bit). Rcode: This field indicates the type of response (4 bits): 0: No error, 1: Format error in request, 2: Problem on server, 3: Name does not exist, 4: Not implemented, 5: Refused, 6-15: Reserved.
– Number of questions: Specifies the number of entries in the “Question” section (16 bits)
– Number of RR answers: Specifies the number of entries in the “Answer” section (16 bits)
– Number of RR authorities: Specifies the number of entries in the “Authority” section (16 bits)
– Number of additionnal RR: Specifies the number of entries in the “Additionnal” section (16 bits).

The rest of the DNS message corresponds to “useful” information:
– Question Section: Indicates the type, class and domain on which the query was executed.
– Answer Section: Indicates the RRs corresponding to the request response (Section filled in only if flag aa is set to 1).
– Authority Section: Indicates the RRs corresponding to Authoriative servers (which have authority over the domain in question).
– Additionnal Section: Indicates the RR of additional information that can be provided by the DNS server (e.g. IP addresses of servers listed in the authority section).

The name server database (domain file and reverse resolution files) is made up of “Resource Records” (RRs). These recordings are divided into classes. The only registration class usually used is the Internet class (IN). The set of resource information associated with a particular name is made up of four separate resource records (RR). Here are the various fields of an RR, which you can also find in Rfc 1035 in chapter 3.2.1 :

Details of RR fields :
– Name: The name corresponds to the domain where the RR is located, but may be different depending on the type: A: Host name, CNAME: Host name, PTR: IP address,
– Type: This field specifies the type of data used in the RR. Here are the different types available (16 bits):

– Class: This field has a value identifying a protocol family or an instance of a protocol. Here are the possible protocol classes (16 bits) :

– TTL: This is the RR lifetime (in seconds), used by name solvers when they have a cache of RRs to find out how long the cache information is valid (32 bits).
– Length: This field indicates the length of the following data (16 bits).
– Data: Data identifies the resource. What you put in this field obviously depends on the type of resource you’re describing: A: For the IN class, a 32-bit IP address. For the CH class, a domain name followed by a 16-bit Chaotic octal address. CNAME: a domain name. MX: a 16-bit preference value (as low as possible) followed by the name of the host wishing to act as a mail exchanger for the owner’s domain.
. PTR: An IP address in the form of a name. NS: A host name. SOA: Several fields: Primary name server, Mail contact, Serial: zone version number, Refresh: interval in seconds between updates requested by the secondary server and the primary server, Retry: delay in seconds that the secondary or slave servers must wait before renewing the request, Expire: time after which the zone is considered invalid if the secondary or slave servers cannot reach the primary server, TTL minimum: used to specify, in seconds, the lifetime for which responses corresponding to requests for non-existent records are kept in cache.

After explaining the format of DNS frames, we’ll illustrate this document with a few examples.

We’ll take a look at the requests and responses of a dnslookup.fr domain resolution. From a client workstation, we will simulate the recursive queries performed by DNS servers:

(1) This is the first request made. It consists in asking the s root server which are the:

We can see from the first flag that this message is a request.

(2) This is the response to the request for TLD servers. This response returns the list of .fr TLD servers:

The first flag tells us that this message is a response. The authority flag tells us that the server is not authoritative. The response therefore contains Authority RRs. The Authority RRs correspond to the 7 TLD servers with authority over .fr. The Additional RRs correspond to the IPv4 and IPv6 (if any) addresses of the TLD servers. This avoids having to make another request to query them. The response can be formatted as :

(3) This is the request to retrieve authoritative nameservers on the dnslookup.fr domain from the :

We can see from the first flag that the message is a request.

(4) This is the answer to the previous query. It contains the list of authoritative name servers on the :

We can see from the first flag that this message is a reply. The authority flag is still not positioned. In fact, TLD servers are not authorities on the dnslookup.fr domain and therefore return the list of dnslookup.fr name servers in the Authoriative section. The answer can be formatted :

(5) This is the last request to retrieve the name server records for the dnslookup.fr domain:

We can see from the first flag that this message is a request.

(6) This is the response from the dnslookup.fr name server. This response contains all :

We can see from the first flag that this message is a reply. For the first time since the start of our queries, the authority flag has been set. Indeed, this time if no Authoriative RRs but 8 Answer RRs. The Answer section contains domain records. In the frame analysis, we can see the beginning of the SOA record, proving once again that the server is authoritative. The Additional section contains records of IPv4 and IPv6 addresses (if available) for various hosts. The answer can be formatted :

In the end, we needed no less than 3 queries to obtain the desired result. The queries are always the same, only the answers change. Our dnslookup. fr tool enables us to extract nameservers at root, TLD and domain levels. By analyzing the authority flag, we can check whether or not the server is an authority on the domain. This analysis is necessary because it’s possible that TLD servers are returning servers that are still not authoritative on the domain. In this case, it is necessary to repeat the request on these servers so that they return the authoritative servers on the domain.