In general, for the most authoritative and comprehensive definition of DNS see the RFC document, here . However, this article is not a comprehensive DNS documentation. It starts from a usage example, uses wireshark to analyze and present a specific DNS request, and introduces the meaning of some of the most common fields in DNS.
The emergence of domain names is to facilitate people to remember the addresses of public services in the network, so domain names are generally represented by strings with specific meanings, such as csdn.net. However, the identification of the host in the network space is the IP address, and the IP address is divided into IPv4 and IPv6, such as 192.168.0.1. The use of numbers to represent addresses is friendly to machines and facilitates operations such as storage and addressing. What humans remember is the domain name, what the machine remembers is the IP address. In order to complete the interaction between man and machine, DNS appeared. The full name of DNS is called domain name system, and the essence of DNS is the mapping table from domain name to IP. Of course, it is easy to build this table, but how to make good use of this table in cyberspace requires the cooperation of software and hardware. The software here refers to what we usually call the DNS protocol, and the hardware here is the various DNS servers that exist in the network space.
DNS example
DNS requests are very simple in terms of business logic, as shown in Figure 1 below:
Figure 1
- The source address 192.168.0.103 initiates a DNS request to the destination address 192.168.0.1.
- 192.168.0.1 responded to the IP address corresponding to the p3p.sogou.com domain name.
Among them, 192.168.0.103 is the client requesting resolution, 192.168.0.1 is the local DNS server address, and there are multiple IP addresses corresponding to the p3p.sogou.com domain name, including multiple IP addresses such as 49.7.176.34 and 49.7.176.60. The above is a description of the entire DNS business logic, and the analysis of the request and response fields is as follows.
Whether it is a DNS request message or a response message, the overall structure of the DNS message in RFC1035 is shown in Figure 2:
Figure 2
The header part is available for every DNS message. According to the difference of the header, the content structure of the DNS request and response is different.
DNS header
The Header structure is as shown in Figure 3:
Figure 3
An example of the request header corresponding to Figure 1 is shown in Figure 4:
Figure 4
An example of the response header corresponding to Figure 2 is shown in Figure 5:
Figure 5
Whether transaction ID
is for TCP or UDP, one stream can carry multiple requests and responses. Therefore, in order to distinguish the request and the corresponding pair appearing on a stream, the two parties in the communication use the transaction ID to distinguish at the application layer, which is called a transaction interaction. It can be seen that Figure 4 and Figure 5 use the same transaction ID to represent this bunch of requests and responses.
QR
- The meaning of each subsequent bit in the QR field is different according to the difference of the first bit. If the first flag is 0, it means this is a DNS request, as shown in Figure 4. If the first flag is 1, it means this is a DNS response as shown in Figure 5.
The OPCODE
field uses a total of 4 bits to represent. 0 means a standard DNS request. 1 means reverse DNS request, usually DNS requests IP through domain name, and reverse DNS means requesting domain name through IP. However, when using nslookup to make a reverse DNS request, the value of this field is still 0, and the type field of the request is actually used to indicate reverse DNS, as shown in Figure 6. An OPCODE of 2 indicates the status of the request server. OPCODE3-15 are reserved for use.
Figure 6
AA
AA is Authoritative Answer, which means an authoritative response. When the responding server is not the DNS server set during domain name registration, the value in the DNS response is 0, as shown in Figure 5. When the responding server is the DNS server specified during domain name registration, the value is 1. This field is used to remind that there may be problems in the response of the non-registered designated DNS resolution server.
Due to the limitation of the IP bearer layer in TC
, when the upper layer message is too large, fragmentation transmission will occur. The DNS application layer uses this flag to indicate whether the DNS message is truncated. 0 means it is a complete DNS message, 1 means truncation occurs, as shown in Figure 4/5.
RD
Recursion desired, the query method of DNS includes recursive query and iterative query. The flag bit is 1 to request the DNS server to use recursive query, and 0 to indicate that the client uses iterative query. Recursive query is more common, as shown in Figure 4/5 shown. The two query methods will be introduced separately.
RA
This field is meaningful in the DNS response. When it is 1, it means that the server supports recursive query, as shown in Figure 5 above.
Z
is reserved for future planning, as shown in Figure 4/5.
AD
has 3 Z reserved bits in Figure 3, but in Figure 4/5, Z only occupies 1 bit. This is because RFC1035 was written in 1987, which is very old and has undergone many revisions during the period, as shown in Figure 7 below:
Figure 7
The reserved field has been revised in RFC2535, as shown in Figure 8 below: Figure
8
therefore means that AD indicates whether the response data has been authenticated by the DNS server, and this flag has actual meaning in the response, as shown in Figure 5.
CD
indicates whether the data that has not been authenticated by the server is acceptable, 0 indicates unacceptable, 1 indicates acceptable, as shown in Figure 4/5.
RCODE
Response code, a 4-digit response code, used to indicate possible errors in the server. 0 means there is no error, 1 means that the DNS request format is wrong/the server cannot parse the request, and 2 means that the server itself cannot parse the request. Other values appear less frequently, and you can refer to the RFC1035 document after they appear.
The 2 bytes of QDCOUNT
indicate the number of domain names to be queried subsequently. The value in Figure 4 is 1, and there is only one record in the corresponding request. The 2 bytes of ANCOUNT indicate the number of entries in the DNS server response, as shown in Figure 5, there are 5 response records, because a domain name may correspond to multiple IP addresses, so there are 5 response records
. The 2 bytes of NSCOUNT indicate the number of records authenticated by the server, as shown in Figure 4/5, and the structure of the authentication record in Figure 2. ARCOUNT 2 bytes indicate whether there are additional information records, as shown in Figure 4/5, and the structure of the additional information in Figure 2.
DNS request field
The content of the request message defined by RFC 1035 is as shown in Figure 9: Figure
9
QNAME
This field indicates the content of the requested domain name. Since the domain name string is variable in length, this part of the content uses a special encoding method, length + character content, and is encoded in ASCII code 0 as the end.
QTYPE
This field uses two bytes to indicate the type of the request record, as shown in Figure 4, the number 1 represents the A record, that is, the resolution from the domain name to the IP address. In addition, DNS also supports many other resolution request types, as shown in Figure 10 below. Among them, CNAME represents an alias record; NS represents the IP address record for querying the DNS server; PTR represents a reverse query record, that is, the mapping record from IP to DNS; MX represents the mapping record from the domain name to the mail server address, such as searching according to the mailbox suffix The corresponding mail server address belongs to this scenario.
In the early network, QCLASS
considered other networks outside the Internet, as shown in Figure 11. But this field is basically 1 in DNS requests now, because other kinds of networks basically disappear.
Figure 10
Figure 11
DNS response field
The content of the request message defined by RFC 1035 is shown in Figure 12:
Figure 12
Among them, the meanings of NAME, TYPE, and CLASS are the same as those in the request, and the meanings of other fields are as follows:
TTL
4 bytes indicate the number of seconds that the DNS record suggestion is cached.
The two bytes of RDLENGTH
indicate the data length of the RDDATA part, and
the RDDATA
variable-length data indicates the content of analysis, which corresponds to the analyzed IP address in Figure 5.
Through the above RFC documents and actual DNS data packets, each field of DNS is introduced, and the two query methods of DNS will be introduced later.
This article is an original article by the youth in the village of CSDN, and may not be reproduced without permission. The blogger links here .