DNS message format for network learning

[[398925]]

This article is reprinted from the WeChat public account "Xiaocai Learns Programming", written by fasionchan. Please contact Xiaocai Learns Programming public account to reprint this article.

As we have learned before, we know that to query a domain name, we need to communicate with the DNS server. So, what is the DNS communication process like?

DNS is a typical Client-Server application. The client initiates a domain name query request, and the server responds to the request:

DNS generally uses UDP as the transport layer protocol (TCP is also acceptable), and the port number is 53. Both the request message and the response message are used as data and are transmitted in UDP datagrams:

Obviously, both the DNS request message and the response message need to meet certain formats in order to be understood by both parties. This is the area of ​​responsibility of the DNS protocol, which is located above the transport layer and belongs to the application layer protocol.

Message Format

DNS messages are divided into two types: request and response. The structure is similar and can be roughly divided into five parts:

• The header describes the message type and the following 4 sections;
• Question section ( question ), which stores query questions;
• The answer section (answer) stores the answer to the question, that is, the query result;
• Authorization information section (authority), which stores authorization information;
• Additional information section (additional), saves additional information;

There are also many documents that refer to DNS requests as DNS queries, which have the same meaning.

The header is fixed, with a total of 12 bytes; the other sections are not fixed, and the number of records can be more or less, and the number is stored in the header. The header is divided into 6 fields:

• Identifier, a 16-bit ID, is returned in the response as is, to match requests and responses;
• Flags: some flag bits, 16 bits in total;
• Question count, a 16-bit integer indicating the number of records in the question section;
• Answer count, a 16-bit integer indicating the number of records in the answer section;
• Authority record count, a 16-bit integer indicating the number of records in the authority information section;
• Additional record count: a 16-bit integer indicating the number of records in the additional information section.

Finally, let's explain the various flag bits in the flag field:

• The QR bit marks whether the message is a query request or a query response;
  • 0 indicates a query request;
  • 1 indicates query response;
• The operation code (opcode) occupies 4 bits and indicates the type of operation:
  • 0 represents a standard query;
  • 1 represents reverse query;
  • 2 represents server status request;
• The AA bit indicates authoritative answer, which means that the current query result is given by the authoritative server of the domain name;
• The TC bit means truncated. When using UDP, if the response exceeds 512 bytes, only the first 512 bytes are returned;
• The RD bit indicates recursion desired, which is set in the request and returned in the reply;
  • When this bit is 1, the server must process the request: if the server does not have an authoritative answer, it must request other DNS servers on behalf of the client, which is also called a recursive query;
  • When this bit is 0, if the server does not have an authorized answer, it returns a list of servers that can handle the query to the client, and the client performs the iterative query itself;
• The RA bit indicates recursion available. If the server supports recursive queries, it will set this bit in the response to inform the client.
• Reserved bits, these 3 bits are currently unused and are reserved for future expansion;
• The response code is 4 digits long and indicates the result of the request. Common values ​​include:
  • 0 means no error;
  • 3 indicates a name error, which is returned by the authoritative server and means that the domain name to be queried does not exist;

Problem Record

When the client queries a domain name, it needs to send a request message to the server; the domain name to be queried is recorded as a question and saved in the question section.

The question section supports saving multiple question records, and the number of records is saved in the question record number field in the DNS header. This means that a single DNS protocol request can query multiple domain names at the same time, although usually only one is queried.

A question record consists of 3 fields:

• The domain name to be queried ( Name ). The length of this field is not fixed and is determined by the specific domain name.
• Query type (Type). In addition to the IP address, the domain name can also be associated with other information. Common types include (described in detail in the next section):
  • 1 indicates A record, i.e. IP address;
  • 28 indicates AAAA record, i.e. IPv6 address;
  • etc
• Class is usually 1, indicating a TCP/IP Internet address;

Finally, let's look back at the domain name field. Its length is not fixed. The domain name is split into several parts by . and then saved in sequence. Each part begins with a leading count byte, recording the number of characters in the current part.

Take the domain name fasionchan.com. as an example. It is divided into three parts: fasionchan, com, and an empty string. Please note that the empty string represents the root domain. Therefore, the domain name fields to be queried are:

• A leading byte stores the integer 10, and then 10 bytes store the fasionchan part (secondary field);
• A leading byte stores the integer 3, and then 3 bytes store the com part (first-level domain);
• A leading byte holds the integer 0, and then 0 bytes hold the part (root domain);

It can be seen that the length of each domain name can theoretically support up to 255 characters.

The query type will not be expanded here, and will be introduced in detail in the next section.

Resource Record

After the server processes the query request, it needs to send a response message to the client; the domain name query result is stored as a resource record in the answer and the following two sections.

The answer section, authorization information section, and additional information section are all composed of one or more resource records. The number of records is stored in the corresponding field in the header and will not be repeated here.

The structure of a resource record is very similar to that of a question record. It has a total of 6 fields, the first 3 of which are exactly the same as those of a question record:

• The queried domain name ( Name ), which is the same as the problem record;
• Query type ( Type ), same as the problem record;
• Class, same as the problem record;
• Validity period (TTL). Domain name records are generally not frequently changed, so the results can be cached within the validity period to reduce the request frequency;
• Resource Data Length, i.e. the length of the query result;
• Data (Resource Data), i.e., query results;

If the query type is an A record, the query result is an IP address, which is stored in the data field of the resource record; and the data length field value is 4, because the length of the IP address is 32 bits, equivalent to 4 bytes.

Message Example

We take the domain name test.fasionchan.com as an example to explain the DNS query request message and response message.

Execute the dig command to query the domain name:

 dig test.fasionchan.com

We captured a communication process of querying test.fasionchan.com and saved the result on Github for reference. You can download the captured result to your local computer, open it with WireShark, and analyze it in combination with the explanation.

Request message

The request message of the packet capture result only has the header, question section and additional section. The diagram assumes that there is no additional section.

First look at the header. The number of question records is 1, and the numbers of other records are 0. This means that the request message only has a question section, and there is only one question record in the question section, and only one domain name is queried. The flags in the header are as follows:

• QR=0, indicating that the message is a request message;
• The operation code is 0, indicating that this DNS request is a standard request;
• TC=0, indicating that the request message is not truncated;
• RD=1, indicating that the client wants the server to perform recursive queries;

We are already familiar with the problem record, so we will not repeat it:

• Type=1, indicating that the client wishes to query the A record, that is, the IP address associated with the domain name;
• Class=1, representing TCP/IP Internet;

Reply message

The packet capture result reply message only has the header, question section and answer section. The question record in the question section is the same as the request message, so it is not expanded in the figure.

First look at the header. The number of question records is 1, the number of answer records is also 1, and the numbers of other records are 0. This means that the reply message only has the question section and the answer section, and each of them has only one record. The flag bits in the header are as follows:

• QR=1, indicating that the message is a response message;
• The operation code is 0, indicating that this DNS request is a standard request;
• AA=0, indicating that the result is not returned by the authoritative server of the domain name, because the query object is the local DNS cache server (if the query is initiated to the authoritative server, the response message it returns is AA=1);
• TC=0, indicating that the response message is not truncated;
• RD=1, consistent with the request message, omitted;
• RA=1, indicating that the server supports recursive queries;
• The response code is 0, indicating that the query is successful and there is no error;

The resource record in the answer section is the query result. The first three fields are the same as the question record and will not be repeated here.

The TTL field is an integer indicating the validity period in seconds. The validity period of the query result in the example is 752 seconds, or 12 minutes and 32 seconds. In other words, the query result is valid for 12 minutes and 32 seconds from now on, and there is no need to request it again.

The query result is an IP address with a length of 4 bytes, which is stored in the resource data field.

Domain name compression

We noticed that in the reply message, the question record in the request message is returned as is. Since both the question record and the resource record store the domain name, this means that the domain name will be stored repeatedly, and the message size is limited!

In order to save message space, it is necessary to solve the problem of repeated storage of domain names, which is also called information compression. The specific method is as follows:

When a domain name appears in a message for the second time, it is stored in two bytes. The highest two bits of the first byte are both 1, and the remaining part is combined with the second byte to indicate the offset of the domain name in the message when it first appears. Through this offset, the corresponding domain name can be found.

As a result, the domain name that originally required 21 bytes to store can now be stored in just two bytes, greatly reducing the amount of data!

In fact, the domain name compression mechanism can also be performed on a certain part of the domain name. For example, suppose a request message queries two domain names at the same time:

• fasionchan.com
• test.fasionchan.com

The request message contains two question records, corresponding to the domain names fasionchan.com and test.fasionchan.com. Both domain names have a public suffix fasionchan.com and do not need to be saved repeatedly.

As shown in the figure above, the second domain name only needs to save the test part, and then add two special compression bytes to point to fasionchan.com in the first question record. If the order of the two question records is reversed, the result is similar, so you can think about it yourself.