一次 DNS 查询会产生多少流量
参考资料：
以客户端的角度，根据相关协议的 RFC 文档内容来计算 IPv4 网络中一次 DNS 查询会产生多少网络流量。
根据 RFC 1122 TCP/IP 模型可以知道，要计算一次 DNS 查询所产生的流量，首先需要知道 DNS 协议在应用层产生的数据大小，然后根据传输层 TCP 或 UDP 协议计算出数据封包后的大小，最后根据网络层 IP 协议计算出实际产生的流量。
应用层 - DNS
参考资料：
根据 RFC 1035 中的定义，域名以 Label 组成，以长度为零的 Label 结束，只能包含 ASCII 字符中的字母（A-Za-z）、数字（0-9）以及 -（注1、注2）。每个 Label 的长度最大为 63 Byte，域名的总的最大长度为 253 Byte（注3）。所有的域名都有一个根域，完整的域名应该为 example.com.，DNS 应用在查询时会自动补全最后的 . 。
RFC 中对域名定义为大小写不敏感，example.com 与 EXAMPLE.COM 会获得相同的查询记录，但浏览器 URL 中除了 scheme 与 host，其他部分是大小写敏感的。如果后端没有进行处理， http://example.com/a 与 http://example.com/A 是指向不同的资源。
-
注1：RFC 1035 规定 Label 必须以字母开头，但是 RFC1123 - 6.1.3.5 中去掉了这个限制。
-
注2：在浏览器中可以输入非 ASCII 字符作为域名，实际是使用基于 Punycode 码的 IDNA 系统，将 Unicode 字符串映射为有效的 DNS 字符集。
-
注3：RFC 1035 规定域名最大长度为 255 Byte，但根据 RFC 中的编码规则，
.并不会参与编码，除了 Label 字符串需要编码外还需要将 Label 的长度进行编码，加上最后的长度为 0 的 Label，因此实际可用长度为 253 Byte。
Message
DNS 协议通信的消息格式只有一种，分为 5 个部分，Header 是一定存在的，其他部分在一些情况下为空。
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
Header
Header 是必须存在的，大小固定为 12 Byte。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 字段 | 长度 | 说明 |
|---|---|---|
| ID | 2 Byte | A 16 bit identifier assigned by the program that generates any kind of query. |
| QR | 1 Bit | A one bit field that specifies whether this message is a query (0), or a response (1). |
| OPCODE | 4 Bit | A four bit field that specifies kind of query in this message. |
| AA | 1 Bit | Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. |
| TC | 1 Bit | TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. |
| RD | 1 Bit | Recursion Desired - this bit may be set in a query and is copied into the response. |
| RA | 1 Bit | Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. |
| Z | 3 Bit | Reserved for future use. |
| RCODE | 4 Bit | Response code - this 4 bit field is set as part of responses. |
| QDCOUNT | 2 Byte | an unsigned 16 bit integer specifying the number of entries in the question section. |
| ANCOUNT | 2 Byte | an unsigned 16 bit integer specifying the number of resource records in the answer section. |
| NSCOUNT | 2 Byte | an unsigned 16 bit integer specifying the number of name server resource records in the authority records section. |
| ARCOUNT | 2 Byte | an unsigned 16 bit integer specifying the number of resource records in the additional records section. |
Question
查询时 Question 是必须存在的，其中 QTYPE 和 QCLASS 为固定长度，QNAME 是可变长度，由所查询的域名长度决定。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 字段 | 长度 | 说明 |
|---|---|---|
| QNAME | variable | a domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. |
| QTYPE | 2 Byte | a two octet code which specifies the type of the query. |
| QCLASS | 2 Byte | a two octet code that specifies the class of the query. |
QNAME 为可变长度，域名会被编码为 {label-length}{label-string}...{label-length}{label-string}0，所以实际占用的数据会多 2 Byte。
Resource Record
Answer Authority Additional 的结构是相同的，NAME 与 RDATA 是可变的。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 字段 | 长度 | 说明 |
|---|---|---|
| NAME | variable | a domain name to which this resource record pertains. |
| TYPE | 2 Byte | two octets containing one of the RR TYPE codes. |
| CLASS | 2 Byte | two octets containing one of the RR CLASS codes. |
| TTL | 4 Byte | a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. |
| RDLENGTH | 2 Byte | an unsigned 16 bit integer that specifies the length in octets of the RDATA field. |
| RDATA | variable | a variable length string of octets that describes the resource. |
NAME 的长度最少为 2 Byte，当 NAME 中的字节前两 Bit 都为 1 时，表示后面的 14 Bit 是一个偏移量，代表从 Message 开始部分偏移。Label 的长度编码前两 Bit 需要是 0（01 和 10 作为保留），也就是 Label 长度最大为 63 的原因。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
RDATA 的大小根据不同类型的记录格式有所不同， A 记录以 32 Bit 来表示一个 IPV4 地址。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
传输层 - UDP
参考资料：
虽然 DNS 支持 UDP 和 TCP，不过最常用的是 UDP，根据 RFC 768 中 UDP 报文结构的定义可以得到 UDP 报文会为数据增加 8 Byte 的头部信息。
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source Port | Destination Port|
+--------+--------+--------+--------+
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
| 字段 | 长度 | 说明 |
|---|---|---|
| Source Port | 2 Byte | Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. |
| Destination Port | 2 Byte | Destination Port has a meaning within the context of a particular internet destination address. |
| Length | 2 Byte | Length is the length in octets of this user datagram including this header and the data. |
| Checksum | 2 Byte | Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. |
由于 Length 的大小是 2 Byte，因此 UDP 包理论最大为 2^16 Byte，减去 8 Byte 的首部，有效负载数据大小为 2^16 - 8 Byte。
网络层 - IP
参考资料：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL 大小为 4 Bit，使用十进制表示 IP 协议头部的长度为多少个 32 Bit，最小值为 5，最大值为 15，因此 IP 协议头部的最大长度为 60 Byte。当 IHL 大于 5 时，Options 才会有数据，并且需要 Padding 来保证 IP 协议头部大小一定是 32 Bit 的整数倍。通常情况下 IP 协议头部的大小为 20 Byte。
IPv4 中是在 IP 协议中根据 MTU 进行分片，虽然 UDP 包的理论大小限制远大于 MTU 的 1500 Byte(注1)，但是分片会带来额外的消耗，使用 UDP 协议时需根据 MTU 设置包大小。
- 注1：1500 Byte 需要减去网络层 IP 协议使用的 20 Byte 与 UDP Header 使用的 8 Byte ，实际可负载的数据大小为 1472 Byte。
链路层
参考资料：
以太网的帧格式事实标准是 Ethernet II Type，在这个阶段会增加 14 Bytes 的 MAC Header 和 4 Byte 的 CRC Checksum。
计算
根据以上的所有信息计算请求流量和响应流量。
查询请求
以查询 example.com 的 A 记录为例进行计算。
- 应用层
查询的 Message 只有 Header 与 Question 两个部分，Header 长度固定为 12 Byte。Question 部分中 QNAME 因为 example.com 会被编码为 7example3com0 占用长度为 13 Byte，而 QTYPE 与 QCLASS 长度合计为 4 Byte，最终 DNS 应用层产生的数据大小为 27 Byte。
- 传输层
传输层使用 UDP 协议，因此需要增加 8 Byte UDP Header，这时的数据大小为 35 Byte。
- 网络层
网络层使用 IP 协议，增加 20 Byte IP Header，此时的数据大小为 55 Byte。
- 链路层
链路层使用 Ethernet II Type 帧格式封装，增加 14 Byte MAC Header 和 4 Byte 的 CRC Checksum，最终的数据为 73 Byte。
响应结果
为了方便计算，假设仅返回一条记录。
- 应用层
相对查询的 Message 增加了 Answer 部分，由 Header、Question、Answer 三个部分组成。因为 Header 与 Question 没有变化，因此只需要计算 Answer 的大小即可。
NAME 长度因为 example.com 已经在 Question 中出现过，因此为 2 Byte。TYPE、CLASS、TTL 与 RDLENGTH 为固定大小，合计为 10 Byte。A 记录的 RDATA 大小为 4 Byte，Answer 部分总大小为 16 Byte，DNS 应用层的数据大小为 43 Byte。
- 传输层
传输层使用 UDP 协议，因此需要增加 8 Byte UDP Header，这时的数据大小为 51 Byte。
- 网络层
网络层使用 IP 协议，增加 20 Byte IP Header，此时的数据大小为 71 Byte。
- 链路层
链路层使用 Ethernet II Type 帧格式封装，增加 14 Byte MAC Header 和 4 Byte 的 CRC Checksum，最终的数据为 89 Byte。
总结
对 example.com 的 A 记录进行一次查询，客户端会发出 73 Byte 的数据，接收 89 Byte 的数据，发出、接收各一个 UDP 包。
验证
可以使用抓包工具 Wireshark 来进行验证，安装好 Wireshark 之后，设置过滤器为 udp port 53 进行抓包，由于 DNS 有缓存机制，推荐使用命令行工具发起 DNS 查询请求。
另外需要注意，根据官方文档 7.10.2. Checksum offloading 的说法，网卡驱动会将 CRC Checksum 的处理交给硬件完成，因此 Wireshark 无法获取到。