DNS 协议规范 | 报文解析 | 代码实现

原创已于 2024-12-16 07:50:44 修改

· 1.4k 阅读

26 ·

版权

文章标签：

#DNS

于 2024-12-14 01:46:42 首次发布

network 专栏收录该内容

205 篇文章

订阅专栏

注：本文为 “ DNS 协议规范 | 报文解析 | 代码实现” 相关文章合辑。

未整理去重。

图片清晰度异常受原文所限。

DNS 协议（DNS 规范、DNS 报文、DNS 智能选路）

静下心来敲木鱼于 2023-12-05 23:21:55 发布

DNS 协议基本概念

DNS 的背景

我们知道主机通信需要依靠 IP 地址，但是每次通过输入对方的 IP 地址和对端通信不够方便，IP 地址不好记忆。

因此提出了通过主机名（也就是后面定义的域名中的某个部分）来和 IP 地址对应，通过访问主机名来实现访问 IP 地址，达到通信的效果；由于最开始网络上的主机比较少，通过使用本地的 HOSTS.TXT 文件来记录域名和 IP 地址之间的关系，并定期手动更新（Windows 下的 Host 主机文件在：C:\Windows\System32\drivers\etc\hosts）

但是后来随着主机数量的增加，人工更新 HOSTS.TXT 文件不再适用，因此后面就提出了 DNS 规范

DNS 协议的作用

DNS 是一种具有层次结构的将域名和 IP 地址互相映射的分布式数据库（分布式：可以理解为通过大量的服务器来实现 DNS 解析 — 因为域名越来越多，少量服务器不够用）

其中记录了各种主机域名与 IP 地址的对应关系，能够使得用户更加方便的访问网站

即：

用户直接输入域名登录网站，通过 DNS 服务器将域名解析为 IP 地址，然后用户根据该 IP 地址进行报文封装和传输

DNS 协议端口号

DNS 端口号为 53，支持 TCP 和 UDP（TCP 能够提供可靠的连接，并且可以处理更大的数据量）

使用 UDP 情况：

一般普通 DNS 查询为 UDP 协议

使用 TCP 情况：

区域传输的时候会使用 TCP（即 DNS 服务器之间迁移记录的时候会使用到 TCP 协议）

在 DNS 记录的 TTL 为 0 时，服务器重新请求该记录也会使用到 TCP

当 DNS 的响应报文大于 512 字节而使得 TC 标志位置位（表示被截断）时，会使用 TCP 重新查询

DNS 相关规范

域名的分类

根域名

. 就是根域（不过一般在书写时省略）

顶级域名（又分为国家顶级域名和国际顶级域名）

国家顶级域名

中国 cn

美国 us 等

国际顶级域名

.com 表示网络提供商提供的域名

.net 表示非盈利组织

.org 等

二级域名（又分为国际域名下的二级域名和国家域名下的二级域名）

国际顶级域名下的二级域名

一般指域名注册人的网上名称（一般为企业名称）；、

例如 ibm、yahoo、microsoft、sangfor 等

国家顶级域名下的二级域名（以下针对中国来说）

我国二级域名又分为类别域名和行政区域名两大类

类别域名 6 个

ac 用于科研机构

edu 用于教育机构

gov 用于政府部分

net 用于互联网信息中心

org 用于非盈利组织

com 工商金融企业

行政区域有 34 个，分别对应我国各省、自治区、直辖市

三级域名

使用字母、数字、连接符组成（各级域名之间用实点。连接）

DNS 服务器类型

按照地域性划分

根域名服务器：最高层次的域名服务器（每一个根域名副武器都要存储所有顶级域名服务器的 IP 地址和域名）

顶级域名服务器：顶级域名服务器负责管理在本顶级域名服务器上注册的所有二级域名

权威域名服务器：负责将区域管辖内的主机域名转换为该主机的 IP 地址

本地域名服务器：默认域名服务器，离用户较近

根据工作性质划分

主域名服务器：负责维护某一个特定 DNS 区域的所有域名信息（对其中的解析记录具有自主控制权）；是指定区域中唯一存在的权威服务器

辅助域名服务器：作为主域名服务器的备份，自动同步主域名服务器的域名信息（即从域名服务器提供的解析结果来自于主域名服务器 — 一般辅助服务器会定时向主域服务器进行查询 - 来了解记录是否发生变化通过 TCP 协议）

缓存域名服务器：没有自己的域名数据库，只提供域名解析结果的缓存功能；它从某个远程服务器取得每次域名服务器的查询回答（因此需要设置根域或其他 DNS 服务器作为解析来源）, 并将答案放在高速缓存中；以后查询相同的信息就会从缓存中的信息进行回答，提高查询速度和效率

转发域名服务器：负责所有非区域的本地查询；接到查询请求后，在本地缓存中查找，如找不到就将请求依次转发到指定的域名服务器，直到查找到结果为止

常用 DNS 服务器地址

114.114.114.114 国内通用 DNS 服务器地址

223.5.5.5 阿里云服务器

8.8.8.8 美国谷歌

DNS 服务器的记录

DNS 相关记录

记录名称	记录内容	补充说明
SOA（Start of Authority）记录	是授权机构起使记录（记录有关区域的重要信息）	例如：管理员相关信息、上次更新时间参数等信息所有的 DNS 区域都需要一个 SOA 记录
A（Address）记录	主机记录（将 DNS 域名解析为 IPv4 地址）	–
AAAA 记录	主机记录（将 DNS 域名解析为 IPv6 地址）	–
NS（Name Server）记录	域名服务器记录（记录域名和 DNS 服务器的关系，一般为 DNS 服务器为权限域名服务器；表示想要查询该域名，你需要去找这个 DNS 服务器来查询对应域名的 IP 地址）	该记录只能设置为域名（即：记录的 DNS 服务器是以域名的形式显示的，不能通过 IP 地址的形式显示）因此，该记录一般会结合 A 记录使用（通过 A 记录来指明该 DNS 服务器域名对应的 IP 地址）
PTR（Pointer Record）记录	逆向查询记录（将 IP 地址解析成域名，主要用于判断垃圾邮件）	具体判断垃圾邮件的原理：垃圾邮件一般是伪造邮件头部的 ‘From’ 字段（邮件的 From 字段有 IP 地址、域名等信息）；当发送方发送邮件过来时，服务器通过 PTR 记录将 IP 地址解析为该 IP 地址对应的邮件域名，如果该邮件域名与发送方的邮件头中的 ‘From’ 字段不一致（或者将邮件域名通过 MX 记录或 A 记录解析为 IP 地址，该 IP 地址与 ‘From’ 字段不一致），则认为该邮件为垃圾邮件
MX（Mail eXchange）记录	邮件交换机器（告诉用户哪个邮件服务器负责接收特定域名的电子邮件，用于电子邮件系统发邮件时根据收信人的地址后缀来定位邮件服务器）	例子：当某用户要发送邮件到 12313@qq.com 时，该用户的邮件系统就会通过 DNS 查找 qq.com 这个邮件后缀的 MX 记录；如果 MX 记录存在则用户将邮件发送到该邮件后缀所对应的邮件服务器上（可以是 IP 地址，也可以是域名 – 如果是域名则需要 A 记录来记录域名对应的 IP 地址）
CNAME（Canonical Name）记录	别名记录（将一个域名指向另一个域名，然后再解析关于另一个域名的 IP 地址）	多个域名可以对应相同的 IP 地址（可以减少 A 记录条数）
SPF 记录	用于防范垃圾邮件而提出来的一种 DNS 记录类型，是一种 TXT 类型的记录（记录了一个域名所拥有的用来发送邮件的所有 IP 地址）	通过 IP 地址来进行邮件的身份认证（如果发件人的 IP 地址被包含在 SPF 记录里面，就认为是正确的邮件）

记录域名映射信息的格式

记录一般为以下格式

Name（域名或 IP 地址等）、TTL（生存周期）、Class（网路协议类型）、Type（资源记录类型）、Data（记录包含的数据）

TTL：将该 DNS 记录缓存在 DNS 服务器的时间（以 s 为单位），当 TTL 为 0 时，该记录会被认为过期，服务器会重新查询该记录的并进行更新（重新查询时使用的 TCP 协议）

以 CNMA 记录为例

DNS 报文

DNS Query DNS 请求

包含域名、DNS 服务器地址

Transaction ID：事务 ID（DNS 报文的 ID 标识）

Flags：标志位

Questions：DNS 请求的记录数量

Answer RRs：DNS 响应的记录数量

Authority RRs：权威名称服务器的数量

Additional RRs：额外的记录数目（指的是权威名称服务器对应的 IP 地址的数目）

Queries：请求的记录信息以及请求的记录类型

DNS Response DSN 应答

包含域名对应的 1 个或多个地址（也有可能是 DNS 服务器地址）

Transaction ID：事务 ID（DNS 报文的 ID 标识）

Flags：标志位

Questions：DNS 请求的记录数量

Answer RRs：DNS 响应的记录数量

Authority RRs：权威名称服务器的数量

Additional RRs：额外的记录数目（指的是权威名称服务器对应的 IP 地址的数目）

Queries：请求的记录信息以及请求的记录类型

Answers：响应的记录信息以及响应的记录类型

具体的标志位讲解

Response（QR）：查询响应标志位（1 为响应，0 为查询）

Opcode：操作码（0 标识标准查询、1 标识方向查询、2 表示服务器状态请求）

Authoritative（AA）：授权应答，在响应报文有效（1 表示位权威服务器的回应，0 表示不是）

Thruncated（TC）：表示是否被截断（1 表示响应超过 512 字节被截断，此时使用 TCP 重新查询）

Recursion desired（RD）：期望递归（为 1 表示请求为递归查询、需要返回结果；为 0 表示请求为迭代查询，可以返回能够查询的 DNS 服务器）

Recursion available（RA）：可用递归，在响应报文有效（1 表示服务器支持递归查询）

Authenticated：身份认证和认证数据

Reply code（rcode）：表示响应的差错状态（0 表示没有错误、1 表示报文格式错误、2 表示域名服务器失败、3 表示域名错误、4 表示查询类型不支持、5 表示拒绝响应）

DNS 域名查询的两种方式

递归查询（客户端只需要发送一次 DNS 请求就可以得到结果）

主要用于主机向本地域名服务器请求时使用（要求本地域名服务器返回给主机结果，本地域名服务器如何获得该结果主机不需要知道 — 即要返回给主机域名对应的 IP 地址）

迭代查询（服务器只需要查询自己本地的数据库）

主要用于 DNS 服务器和 DNS 服务器之间的请求（要求服务器返回可以返回域名对应结果，也可以返回能够解析该域名的域名服务器地址）

如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，则本地域名服务器以 DNS 客户端的身份向其它根域名服务器继续发出查询请求报文（替主机查询）

根域名服务器收到本地域名服务器发出的迭代查询请求时，要么给出所查询域名的 IP 地址，要么告诉本地服务器下一步应该向哪一个域名服务器进行查询；就这样本地服务器依次发送 DNS 请求；最后本地域名服务将结果返回给主机

DNS 工作过程

本地 DNS 服务器收到用户发来的 DNS 递归请求后具体如何工作

服务器收到 DNS 请求报文后，查看该域名自己是否能够解析

如果可以解析，查找对应记录返回结果给请求方

如果无法解析，则进行 DNS 请求（选择递归或者迭代 — 不过一般是迭代）

如果选择迭代，则发送 DNS 请求给其它服务器；其它服务器收到后，可以回应能够解析该域名的域名服务器地址，也可以回应结果（如果服务器回应能够解析该域名的域名服务器地址，则自身需要再发送 DNS 去请求 — 再此选择是迭代还是递归）
最后将得到的结果返回给主机
如果选择递归，则发送 DNS 请求给其它服务器；需要其它服务器回应具体的结果给自己（至于其它服务器如何获得结果自己不管）

DNS 查询过程

当在浏览器中输入 URL 时，浏览器会先检查自己的缓存是否有域名 IP 的映射关系，有则直接使用 IP 进行通信；如浏览器没有缓存，则操作系统检查本地 Hosts 文件是否有域名 IP 的映射关系，有则使用 IP 进行通信；如果 hosts 没有这个域名的映射，则查找本地 DNS 解析器缓存是否有映射关系，有则直接返回完成域名解析；
如果还未找到映射关系，首先会找本地 DNS 服务器，如果服务器已缓存了映射关系，则使用这个 IP 地址映射返回完成域名解析（此解析不具有权威性）
如果本地 DNS 服务器缓存已经失效，进行递归查询，然后将结果返回给主机。

DNS 智能选路

如何实现 DNS 的智能选路

一个域名可能对应多个 IP 地址（每个运营商都有），正常情况下 DNS 服务器会随机选择一个给主机，这时主机访问就是随机访问，可能会出现跨运营商访问的问题，造成体验较差

此时就可以通过应用交付来实现 DNS 的智能选路

应用交付 AD 在 DNS 解析中的作用

AD 可以解决 DNS 域名解析跨运营商访问的问题（通过智能选路选择对应的运营商地址 – 通过 AD 产品结合 NS 记录实现）；在该场景下，AD 其实是作为一个域名解析服务器，提供最终的域名到 IP 地址的解析

具体步骤

需要先将权威服务器中关于网站的 A 记录改为 NS 记录，并指向 AD 的域名（然后再通过 A 记录来记录 AD 域名对应的 IP 地址），最后将 AD 地址发给用户

此时用户主机向此 AD 发送 DNS 请求，AD 根据主机的源 IP 地址，判断其所属的运营商；然后进行域名解析时，就解析该运营商对应域名的 IP 地址，将其返回给主机

访问网站全过程（通过 AD 智能选路）

DNS 请求报文和响应报文解析

张嘉睿大聪明已于 2022-06-24 16:44:43 修改

DNS 分为查询请求和查询响应，请求和响应的报文结构基本相同。DNS 报文格式如图所示

在这里插入图片描述

上图中显示了 DNS 的报文格式。其中，事务 ID、标志、问题计数、回答资源记录数、权威名称服务器计数、附加资源记录数这 6 个字段是 DNS 的报文首部，共 12 个字节。

整个 DNS 格式主要分为 3 部分内容，即基础结构部分、问题部分、资源记录部分。下面将详细地介绍每部分的内容及含义。

基础结构部分

DNS 报文的基础结构部分指的是报文首部，如图所示。

在这里插入图片描述

该部分中每个字段含义如下。

事务 ID：DNS 报文的 ID 标识。对于请求报文和其对应的应答报文，该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。

标志：DNS 报文中的标志字段。

问题计数：DNS 查询请求的数目。

回答资源记录数：DNS 响应的数目。

权威名称服务器计数：权威名称服务器的数目。

附加资源记录数：额外的记录数目（权威名称服务器对应 IP 地址的数目）。

基础结构部分中的标志字段又分为若干个字段，如图所示。

在这里插入图片描述

标志字段中每个字段的含义如下：

QR（Response）：查询请求 / 响应的标志信息。查询请求时，值为 0；响应时，值为 1。

Opcode：操作码。其中，0 表示标准查询；1 表示反向查询；2 表示服务器状态请求。

AA（Authoritative）：授权应答，该字段在响应报文中有效。值为 1 时，表示名称服务器是权威服务器；值为 0 时，表示不是权威服务器。

TC（Truncated）：表示是否被截断。值为 1 时，表示响应已超过 512 字节并已被截断，只返回前 512 个字节。

RD（Recursion Desired）：期望递归。该字段能在一个查询中设置，并在响应中返回。该标志告诉名称服务器必须处理这个查询，这种方式被称为一个递归查询。如果该位为 0，且被请求的名称服务器没有一个授权回答，它将返回一个能解答该查询的其他名称服务器列表。这种方式被称为迭代查询。

RA（Recursion Available）：可用递归。该字段只出现在响应报文中。当值为 1 时，表示服务器支持递归查询。

Z：保留字段，在所有的请求和应答报文中，它的值必须为 0。

rcode（Reply code）：返回码字段，表示响应的差错状态。当值为 0 时，表示没有错误；当值为 1 时，表示报文格式错误（Format error），服务器不能理解请求的报文；当值为 2 时，表示域名服务器失败（Server failure），因为服务器的原因导致没办法处理这个请求；当值为 3 时，表示名字错误（Name Error），只有对授权域名解析服务器有意义，指出解析的域名不存在；当值为 4 时，表示查询类型不支持（Not Implemented），即域名服务器不支持查询类型；当值为 5 时，表示拒绝（Refused)，一般是服务器由于设置的策略拒绝给出应答，如服务器不希望对某些请求者给出应答。

为了能够更好地了解 DNS 数据包的基础结构部分，下面通过捕获的 DNS 数据包查看基础结构部分。

DNS 请求数据包基础结构部分，如图所示

在这里插入图片描述

图中的数据包为 DNS 请求包，Domain Name System(query) 部分方框标注中的信息为 DNS 报文中的基础结构部分。

为了方便讲解这里将信息列出进行说明：

Domain Name System(query)
    Transaction ID: 0x9ad0                              #事务 ID
    Flags: 0x0000 Standard query                        #报文中的标志字段
        0... .... .... .... = Response: Message is a query
                                                        #QR 字段，值为 0, 因为是一个请求包
        .000 0... .... .... = Opcode: Standard query(0)
                                                        #Opcode 字段，值为 0, 因为是标准查询
        .... ..0. .... .... = Truncated: Message is not truncated
                                                        #TC 字段
        .... ...0 .... .... = Recursion desired: Don't do query recursively 
                                                        #RD 字段
        .... .... .0.. .... = Z: reserved(0)           #保留字段，值为 0
        .... .... ...0 .... = Non-authenticated data: Unacceptable   
                                                        #保留字段，值为 0
    Questions: 1                                        #问题计数，这里有 1 个问题
    Answer RRs: 0                                       #回答资源记录数
    Authority RRs: 0                                    #权威名称服务器计数
    Additional RRs: 0                                   #附加资源记录数

以上输出信息显示了 DNS 请求报文中基础结构部分中包含的字段以及对应的值。这里需要注意的是，在请求中 Questions 的值不可能为 0；Answer RRs，Authority RRs，Additional RRs 的值都为 0，因为在请求中还没有响应的查询结果信息。这些信息在响应包中会有相应的值。

DNS 响应数据包基础结构部分如图所示

在这里插入图片描述

图中方框标注部分为响应包中基础结构部分，每个字段如下：


Domain Name System(response)
    Transaction ID: 0x9ad0                                    #事务 ID
    Flags: 0x8180 Standard query response, No error           #报文中的标志字段
        1... .... .... .... = Response: Message is a response
                                                              #QR 字段，值为 1, 因为是一个响应包
        .000 0... .... .... = Opcode: Standard query(0)      # Opcode 字段
        .... .0.. .... .... = Authoritative: Server is not an authority for
        domain                                                #AA 字段
        .... ..0. .... .... = Truncated: Message is not truncated
                                                              #TC 字段
        .... ...1 .... .... = Recursion desired: Do query recursively 
                                                              #RD 字段
        .... .... 1... .... = Recursion available: Server can do recursive
        queries                                               #RA 字段
        .... .... .0.. .... = Z: reserved(0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion
        was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error(0)        #返回码字段
    Questions: 1
    Answer RRs: 2
    Authority RRs: 5
    Additional RRs: 5

以上输出信息中加粗部分为 DNS 响应包比请求包中多出来的字段信息，这些字段信息只能出现在响应包中。在输出信息最后可以看到 Answer RRs，Authority RRs，Additional RRs 都有了相应的值（不一定全为 0）。

问题部分

问题部分指的是报文格式中查询问题区域（Queries）部分。该部分是用来显示 DNS 查询请求的问题，通常只有一个问题。该部分包含正在进行的查询信息，包含查询名（被查询主机名字）、查询类型、查询类。

问题部分格式如图所示

在这里插入图片描述

该部分中每个字段含义如下：

查询名：一般为要查询的域名，有时也会是 IP 地址，用于反向查询。

查询类型：DNS 查询请求的资源类型。通常查询类型为 A 类型，表示由域名获取对应的 IP 地址。

查询类：地址类型，通常为互联网地址，值为 1。

DNS 请求包的问题部分字段信息，如图所示

在这里插入图片描述

在下图中，Queries 部分的信息为问题部分信息，每个字段说明如下：

Domain Name System(query)                        #查询请求
    Queries                                       #问题部分
        baidu.com: type A, class IN
            Name: baidu.com                       #查询名字段，这里请求域名 baidu.com
            [Name Length: 9]
            [Label Count: 2]
            Type: A(Host Address)(1)            #查询类型字段，这里为 A 类型
            Class: IN(0x0001)                    #查询类字段，这里为互联网地址

其中，可以看到 DNS 请求类型为 A，那么得到的响应信息也应该为 A 类型。

DNS 响应包的问题部分字段信息，如图所示

在这里插入图片描述

从图中 Queries 部分中可以看到，响应包中的查询类型也是 A，与请求包的查询类型是一致的。

资源记录部分

资源记录部分是指 DNS 报文格式中的最后三个字段，包括回答问题区域字段、权威名称服务器区域字段、附加信息区域字段。这三个字段均采用一种称为资源记录的格式，格式如图所示

在这里插入图片描述

资源记录格式中每个字段含义如下：

域名：DNS 请求的域名。

类型：资源记录的类型，与问题部分中的查询类型值是一样的。

类：地址类型，与问题部分中的查询类值是一样的。

生存时间：以秒为单位，表示资源记录的生命周期，一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间。它同时也可以表明该资源记录的稳定程度，稳定的信息会被分配一个很大的值。

资源数据长度：资源数据的长度。

资源数据：表示按查询段要求返回的相关资源记录的数据。

资源记录部分只有在 DNS 响应包中才会出现。下面通过 DNS 响应包来进一步了解资源记录部分的字段信息。

DNS 响应包的资源记录部分的字段信息，如图所示。

在这里插入图片描述

其中，方框中标注的信息为 DNS 响应报文的资源记录部分信息。该部分信息主要分为三部分信息，即回答问题区域、权威名称服务器区域、附加信息区域，下面依次分析这三部分信息。

回答问题区域字段的资源记录部分信息如下：

Answers                                                      #“回答问题区域” 字段
    baidu.com: type A, class IN, addr 220.181.57.216         #资源记录部分
        Name: baidu.com                                      #域名字段，这里请求的域名为 baidu.com
        Type: A(Host Address)(1)                           #类型字段，这里为 A 类型
        Class: IN(0x0001)                                   #类字段
        Time to live: 5                                      #生存时间
        Data length: 4                                       #数据长度
        Address: 220.181.57.216                              #资源数据，这里为 IP 地址
    baidu.com: type A, class IN, addr 123.125.115.110        #资源记录部分
        Name: baidu.com
        Type: A(Host Address)(1)
        Class: IN(0x0001)
        Time to live: 5
        Data length: 4
        Address: 123.125.115.110

其中，Name 的值为 baidu.com，表示 DNS 请求的域名为 baidu.com；类型为 A，表示要获取该域名对应的 IP 地址。Address 的值显示了该域名对应的 IP 地址。这里获取到了 2 个 IP 地址，分别为 220.181.57.216 和 123.125.115.110。

权威名称服务器区域字段的资源记录部分信息如下：

Authoritative nameservers                           #“权威名称服务器区域” 字段
baidu.com: type NS, class IN, ns ns7.baidu.com      #资源记录部分
Name: baidu.com
Type: NS(authoritative Name Server)(2)        #类型字段，这里为 NS 类型
Class: IN(0x0001)
Time to live: 5
Data length: 6
Name Server: ns7.baidu.com                      #权威名称服务器
baidu.com: type NS, class IN, ns dns.baidu.com      #资源记录部分
Name: baidu.com
Type: NS(authoritative Name Server)(2)        #类型字段，这里为 NS 类型
Class: IN(0x0001)
Time to live: 5
Data length: 6
Name Server: dns.baidu.com                      #权威名称服务器
baidu.com: type NS, class IN, ns ns3.baidu.com      #资源记录部分
Name: baidu.com
Type: NS(authoritative Name Server)(2)
Class: IN(0x0001)
Time to live: 5
Data length: 6
Name Server: ns3.baidu.com                      #权威名称服务器
baidu.com: type NS, class IN, ns ns4.baidu.com      #资源记录部分
Name: baidu.com
Type: NS(authoritative Name Server)(2)
Class: IN(0x0001)
Time to live: 5
Data length: 6
Name Server: ns4.baidu.com                      #权威名称服务器
baidu.com: type NS, class IN, ns ns2.baidu.com      #资源记录部分
Name: baidu.com
Type: NS(authoritative Name Server)(2)
Class: IN(0x0001)
Time to live: 5
Data length: 6
Name Server: ns2.baidu.com                      #权威名称服务器

其中，Name 的值为 baidu.com，表示 DNS 请求的域名为 baidu.com；类型为 NS，表示要获取该域名的权威名称服务器名称。Name Server 的值显示了该域名对应的权威名称服务器名称。这里总共获取到 5 个，如 ns7.baidu.com。

附加信息区域字段的资源记录部分信息如下：

Additional records                                            #“附加信息区域” 字段
    dns.baidu.com: type A, class IN, addr 202.108.22.220      #资源记录部分
        Name: dns.baidu.com                                   #“权威名称服务器” 名称
        Type: A(Host Address)(1)                            #类型字段，这里为 A 类型
        Class: IN(0x0001)
        Time to live: 5
        Data length: 4
        Address: 202.108.22.220                               #“权威名称服务器” 的 IP 地址
    ns2.baidu.com: type A, class IN, addr 61.135.165.235      #资源记录部分
        Name: ns2.baidu.com                                   #“权威名称服务器” 名称
        Type: A(Host Address)(1)                            #类型字段，这里为 A 类型
        Class: IN(0x0001)
        Time to live: 5
        Data length: 4
        Address: 61.135.165.235                               #“权威名称服务器” 的 IP 地址
    ns3.baidu.com: type A, class IN, addr 220.181.37.10       #资源记录部分
        Name: ns3.baidu.com                                   #“权威名称服务器” 名称
        Type: A(Host Address)(1)                            #类型字段，这里为 A 类型
        Class: IN(0x0001)  
        Time to live: 5
        Data length: 4
        Address: 220.181.37.10                                 #“权威名称服务器” 的 IP 地址
    ns4.baidu.com: type A, class IN, addr 220.181.38.10        #资源记录部分
        Name: ns4.baidu.com                                    #“权威名称服务器” 名称
        Type: A(Host Address)(1)                             #类型字段，这里为 A 类型
        Class: IN(0x0001)
        Time to live: 5
        Data length: 4
        Address: 220.181.38.10                                 #“权威名称服务器” 的 IP 地址
    ns7.baidu.com: type A, class IN, addr 180.76.76.92         #资源记录部分
        Name: ns7.baidu.com                                    #“权威名称服务器” 名称
        Type: A(Host Address)(1)                             #类型字段，这里为 A 类型
        Class: IN(0x0001)
        Time to live: 5
        Data length: 4

        Address: 180.76.76.92                                  #“权威名称服务器” 的 IP 地址

其中，Name 的值为 “权威名称服务器” 名称，Type 的值为 A，表示获取域名对应的 IP 地址；Address 的值显示了所有获取到的权威名称服务器对应的 IP 地址。

例如，权威名称服务器名称 ns7.baidu.com 对应的 IP 地址为 180.76.76.92。

用 wireshark 抓包分析 DNS 域名解析过程

天涯海角 TYHJ 于 2023-12-09 12:01:07 发布

1. 什么是 DNS

DNS 是 Domain Name System 的简称，即域名系统，是一个记录域名和 IP 地址相互映射的系统，主要作用是为了解决域名与 IP 之间的相互转换。DNS 是一个网络服务，其端口为 53 号端口。通常 DNS 在查询时是以 UDP 协议来进行查询，一旦无法查询到完整信息时，再以 TCP 协议进行重新查询。因此，DNS 服务启动时会同时开启 UDP 和 TCP 协议的 53 号端口。

DNS 的基本作用：把域名转换成 IP 地址。

DNS 工作在应用层。

2.DNS 域名结构

域名具有一定的层次结构，从上到下依次为：根域名、顶级域名（top level domain，TLD）、二级域名 SLD、三级域名、四级域名等。根域名后面有一个小圆点。其树型结构如下：

3.DNS 的工作过程

下图描述一次完整的 DNS 请求过程：

1）用户在 Web 浏览器中键入 http://www.baidu.com，查询传输到 Internet 中，并被 DNS 递归解析器 接收。

2）解析器查询 DNS 根域名服务器 （Root Server）。

3）根域名服务器把存储其域信息的顶级域 （top-level domain，TLD）DNS 服务器的地址返回该解析器。在搜索 http://www.baidu.com 时，根域名服务器返回 .com TLD。

4）解析器向 .com TLD 发出请求。

5）TLD 服务器把存储该域 （http://www.baidu.com） 的域名服务器的 IP 地址返回给 DNS 解析器。

6）递归解析器把查询发送到存储该域（http://www.baidu.com）的域名服务器。

7）http://www.baidu.com 的 IP 地址 而后从域名服务器返回解析器。

8）DNS 解析器 把最初请求的域 （http://www.baidu.com） 的 IP 地址返回给 Web 浏览器。

9）浏览器向该 IP 地址 发出 HTTP 请求。

10）位于该 IP 的服务器返回将在浏览器中呈现的网页。

4.DNS 的查询过程

递归查询：域名服务器帮助用户进行名字解析，并返回最后的结果。【老好人】

迭代查询：域名服务器进迭代访问，反复多次，直到最后找到结果。【踢皮球】

DNS 缓存的目的是将数据临时存储在某个位置，从而提高数据请求的性能和可靠性。

DNS 高速缓存将数据存储在更靠近请求客户端的位置，以便能够更早的解析 DNS 查询，并且能够避免在 DNS 查找链中进一步向下的额外查询，从而缩短加载时间并减少带宽 / CPU的消耗。DNS 数据可缓存到各种不同的位置上，每个位置均将存储 DNS 记录并保存由生存时间 （TTL） 决定的一段限制。

浏览器缓存：浏览器在获取网站域名的实际 IP 地址 后会对其进行缓存，减少网络请求的损耗。
操作系统缓存：操作系统的缓存是用户自己配置的 hosts 文件

所以上面提到的 DNS 查询过程中，当客户端提交一个域名请求时，先查询浏览器的 DNS 缓存信息，如果没有，再找操作系统的 DNS 缓存信息，如果还没有，则开始从本地 DNS 查起。

5. 利用 wireshark 进行 `DNS` 协议抓包

下面在浏览器中输入https://www.baidu.com，进行访问，然后同时利用 wireshark 进行抓包，抓包后，通过显示过滤器显示 DNS 协议：

DNS 报文解析及代码实现

程序猿编码于 2021-10-30 20:49:18 发布

在 Internet 上，DNS 可以使用 UDP，也可以使用 TCP，在两种情况下，DNS 服务器使用的公认端口是 53。

DNS 报文封装在 UDP 数据报或 TCP 数据段中，然后封装在 IP 数据报中，最后封装成数据链路层中的帧通过物理层传输。

DNS 报文结构有哪些类型

DNS 报文可以分为查询和应答，他们的总体结构是相同的。DNS 的顶层格式分成 5 个部分：

1、首部（Header）

2、问题（Question）

3、回答（Answer）

4、权威（Authority）

5、附加（Additional）

在这里插入图片描述

大体 DNS 报文格式就是这样。这里截屏没有权威和附加的资源记录。可以通过标红框上的信息看出

在这里插入图片描述

每一类 DNS 报文都有一个首部部分。首部包括一些字段，用于规定其余部分是否存在，也是规定是查询还是响应，是标准查询还是其他类型的操作。

在这里插入图片描述

首部后面是其他部分的名称来自它们在标准查询中的使用。问题部分包括的字段用于描述发送给服务器的问题（查询请求）。这些字段时查询类型、查询类和查询域名。

在这里插入图片描述

回答部分包括问题的资源记录。权威部分包括指向权威 DNS 服务器的资源记录。

DNS 报文的首部格式说明

查询报文和应答报文都具有相同的首部格式，查询报文主要是将某些字段设置为 0，首部长度为 12 字节。

在这里插入图片描述

标志字段中每个字段的含义如下：

Response：查询请求 / 响应的标志信息。查询请求时，值为 0；响应时，值为 1。

Opcode：操作码。其中，0 表示标准查询；1 表示反向查询；2 表示服务器状态请求。

Authoritative：授权应答，该字段在响应报文中有效。值为 1 时，表示名称服务器是权威服务器；值为 0 时，表示不是权威服务器。

Truncated：表示是否被截断。值为 1 时，表示响应已超过 512 字节并已被截断，只返回前 512 个字节。

Recursion Desired：期望递归。该字段能在一个查询中设置，并在响应中返回。该标志告诉名称服务器必须处理这个查询，这种方式被称为一个递归查询。如果该位为 0，且被请求的名称服务器没有一个授权回答，它将返回一个能解答该查询的其他名称服务器列表。这种方式被称为迭代查询。

Recursion Available：可用递归。该字段只出现在响应报文中。当值为 1 时，表示服务器支持递归查询。

Z：保留字段，在所有的请求和应答报文中，它的值必须为 0。

问题部分格式说明

问题部分用在大多数查询报文中表达具体的查询问题，即定义要查什么。

在这里插入图片描述

查询域名：是可变长字段。查询名称由标签序列构成，每个标签前有一个八位位组指出该标签的长度。因为每个域名以空标签结束，因此每个域名的最后一个八位位组的值为 0.。

查询类型：两个八位位组代码，长度 16 位，它指定查询的类型。这个类型的值包括所有适用于资源记录类型。

记录类型如下（信息参考：https://www.cnblogs.com/bonelee/p/7611941.html）：

记录类型

代码	号码	定义的 RFC	描述	功能
A	1	RFC 1035	IP 地址记录	传回一个 32 比特的 IPv4 地址，最常用于映射 [主机名称](https://zh.wikipedia.org/wiki/ 主機名稱) 到 [IP 地址](https://zh.wikipedia.org/wiki/IP 地址)，但也用于 DNSBL（RFC 1101）等。
AAAA	28	RFC 3596	IPv6 IP 地址记录	传回一个 128 比特的 IPv6 地址，最常用于映射主机名称到 IP 地址。
AFSDB	18	RFC 1183	[AFS 文件系统](https://zh.wikipedia.org/w/index.php?title=AFS 檔案系統 & action=edit&redlink=1)	（Andrew File System）数据库核心的位置，于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的的 DCE/DFS（DCE Distributed File System）所使用。
APL	42	RFC 3123	地址前缀列表	指定地址列表的范围，例如：CIDR 格式为各个类型的地址（试验性）。
CAA	257	RFC 6844	权威认证授权	DNS 认证机构授权，限制主机 / 域的可接受的 CA
CDNSKEY	60	RFC 7344	子关键记录	关键记录记录的子版本，用于转移到父级
CDS	59	RFC 7344	子委托签发者	委托签发者记录的子版本，用于转移到父级
CERT	37	RFC 4398	证书记录	存储 PKIX、SPKI、PGP 等。
[CNAME](https://zh.wikipedia.org/w/index.php?title=CNAME_記錄 & action=edit&redlink=1)	5	RFC 1035	规范名称记录	一个主机名字的别名：域名系统将会继续尝试查找新的名字。
DHCID	49	RFC 4701	DHCP（动态主机设置协议）识别码	用于将 FQDN 选项结合至 DHCP。
DLV	32769	RFC 4431	DNSSEC（域名系统安全扩展）来源验证记录	为不在 DNS 委托者内发布 DNSSEC 的信任锚点，与 DS 记录使用相同的格式，RFC 5074 介绍了如何使用这些记录。
[DNAME](https://zh.wikipedia.org/w/index.php?title=DNAME_記錄 & action=edit&redlink=1)	39	RFC 2672	代表名称	DNAME 会为名称和其子名称产生别名，与 CNAME 不同，在其标签别名不会重复。但与 CNAME 记录相同的是，DNS 将会继续尝试查找新的名字。
DNSKEY	48	RFC 4034	DNS 关键记录	于 DNSSEC 内使用的关键记录，与 KEY 使用相同格式。
DS	43	RFC 4034	委托签发者	此记录用于鉴定 DNSSEC 已授权区域的签名密钥。
HIP	55	RFC 5205	主机鉴定协议	将端点标识符及 IP 地址定位的分开的方法。
IPSECKEY	45	RFC 4025	IPSEC 密钥	与 IPSEC 同时使用的密钥记录。
KEY	25	RFC 2535[[1]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-1)RFC 2930[[2]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-rfc3445_sec1_def-2)	关键记录	只用于 SIG(0)（RFC 2931）及 TKEY（RFC 2930）。[[3]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-3)RFC 3455 否定其作为应用程序键及限制 DNSSEC 的使用。[[4]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-rfc3445_sec1_subtype-4)RFC 3755 指定了 DNSKEY 作为 DNSSEC 的代替。[[5]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-rfc3755_sec3-5)
[LOC 记录](https://zh.wikipedia.org/w/index.php?title=LOC 記錄 & action=edit&redlink=1)（LOC record）	29	RFC 1876	位置记录	将一个域名指定地理位置。
[MX 记录](https://zh.wikipedia.org/wiki/MX 记录)（MX record）	15	RFC 1035	电邮交互记录	引导域名到该域名的 [邮件传输代理](https://zh.wikipedia.org/w/index.php?title = 郵件傳輸代理 & action=edit&redlink=1)（MTA, Message Transfer Agents）列表。
[NAPTR 记录](https://zh.wikipedia.org/w/index.php?title=NAPTR 記錄 & action=edit&redlink=1)（NAPTR record）	35	RFC 3403	命名管理指针	允许基于正则表达式的域名重写使其能够作为 URI、进一步域名查找等。
NS	2	RFC 1035	名称服务器记录	委托 [DNS 区域](https://zh.wikipedia.org/w/index.php?title=DNS 區域 & action=edit&redlink=1)（DNS zone）使用已提供的权威域名服务器。
NSEC	47	RFC 4034	下一代安全记录	DNSSEC 的一部分 — 用来验证一个未存在的服务器，使用与 NXT（已过时）记录的格式。
NSEC3	50	RFC 5155	NSEC 记录第三版	用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。
NSEC3PARAM	51	RFC 5155	NSEC3 参数	与 NSEC3 同时使用的参数记录。
OPENPGPKEY	61	RFC 7929	OpenPGP 公钥记录	基于 DNS 的域名实体认证方法，用于使用 OPENPGPKEY DNS 资源记录在特定电子邮件地址的 DNS 中发布和定位 OpenPGP 公钥。
PTR	12	RFC 1035	指针记录	引导至一个 [规范名称](https://zh.wikipedia.org/w/index.php?title = 規範名稱 & action=edit&redlink=1)（Canonical Name）。与 CNAME 记录不同，DNS “不会” 进行进程，只会传回名称。最常用来运行 [反向 DNS 查找](https://zh.wikipedia.org/w/index.php?title = 反向_DNS_查找 & action=edit&redlink=1)，其他用途包括引作 DNS-SD。
RRSIG	46	RFC 4034	DNSSEC 证书	DNSSEC 安全记录集证书，与 SIG 记录使用相同的格式。
RP	17	RFC 1183	负责人	有关域名负责人的信息，电邮地址的@通常写为a。
SIG	24	RFC 2535	证书	SIG(0)（RFC 2931）及 TKEY（RFC 2930）使用的证书。[[5]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-rfc3755_sec3-5)RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.[[5]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-rfc3755_sec3-5)
SOA	6	RFC 1035	权威记录的起始	指定有关 DNS 区域的权威性信息，包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。
SPF	99	RFC 4408	SPF 记录	作为 SPF 协议的一部分，优先作为先前在 TXT 存储 SPF 数据的临时做法，使用与先前在 TXT 存储的格式。
[SRV 记录](https://zh.wikipedia.org/w/index.php?title=SRV 記錄 & action=edit&redlink=1)（SRV record）	33	RFC 2782	服务定位器	广义为服务定位记录，被新式协议使用而避免产生特定协议的记录，例如：MX 记录。
SSHFP	44	RFC 4255	SSH 公共密钥指纹	DNS 系统用来发布 SSH 公共密钥指纹的资源记录，以用作辅助验证服务器的真实性。
TA	32768	无	DNSSEC 信任当局	DNSSEC 一部分无签订 DNS 根目录的部署提案，，使用与 DS 记录相同的格式 [[6]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-6)[[7]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-7)。
[TKEY 记录](https://zh.wikipedia.org/w/index.php?title=TKEY 記錄 & action=edit&redlink=1)（TKEY record）	249	RFC 2930	秘密密钥记录	为 TSIG 提供密钥材料的其中一类方法，that is 在公共密钥下加密的 accompanying KEY RR。[[8]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-8)
TSIG	250	RFC 2845	交易证书	用以认证动态更新（Dynamic DNS）是来自合法的客户端，或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。[[9]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-9)
TXT	16	RFC 1035	文本记录	最初是为任意可读的文本 DNS 记录。自 1990 年起，些记录更经常地带有机读数据，以 RFC 1464 指定：[机会性加密](https://zh.wikipedia.org/wiki/ 机会性加密)（opportunistic encryption）、Sender Policy Framework（虽然这个临时使用的 TXT 记录在 SPF 记录推出后不被推荐）、DomainKeys、DNS-SD 等。
URI	256	RFC 7553	统一资源标识符	可用于发布从主机名到 URI 的映射。

其他类型及伪资源记录

其他类型的资源记录简单地提供一些类型的消息（如：HINFO 记录提供电脑或操作系统的类型），或传回实验中之功能的数据。“type” 字段也使用于其他协议作各种操作。

代码	号码	定义的 RFC	描述	功能
*	255	RFC 1035	所有缓存的记录	传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录，该请求将被转发。而传回的记录未必完全完成，例如：当一个名称有 A 及 MX 类型的记录时，但服务器已缓存了 A 记录，就只有 A 记录会被传回。
AXFR	252	RFC 1035	全域转移	由主域名服务器转移整个区域文件至二级域名服务器。
IXFR	251	RFC 1995	增量区域转移	请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝，如果权威服务器由于配置或缺乏必要的数据而无法履行请求，一个完整的（AXFR）会被发送以作回应。
OPT	41	RFC 2671	选项	这是一个 “伪 DNS 记录类型” 以支持 EDNS。

过时的记录类型

发展呈现废弃一些最初定义的记录类型。从 IANA 的记录可见，一些记录类型由于一些原因而被限制其使用、一些被标示为明显过时的、有些是为了隐藏的服务、有些是为了旧版本的服务、有的有特别记录指出它们是 “不正确的”。

由 RFC 973 定义为过时：MD(3)、MF(4)、MAILA(254)
为了发布邮件列表订户的 DNS 记录：MB(7)、MG(8)、MR(9)、MINFO(14)、MAILB(253)。在 RFC 883 标明的意图是为了让 MB 代替 SMTP VRFY 指令、MG 代替 SMTP EXPN 指令、及让 MR 代替 “551 User Not Local” SMTP 错误。其后，RFC 2505 提议将 VRFY 及 EXPN 指令两者停用，使利用 MB 及 MG 永远不可能获得通过。
在 RFC 1123 不提议使用 “not to be relied upon”（RFC 1127 有更多的信息）：WKS(11)[[10]](https://zh.wikipedia.org/wiki/ 域名伺服器記錄類型列表 #cite_note-10)
错误: NB(32)、NBSTAT(33)（自 RFC 1002）；号码现已分配给 NIMLOC 及 SRV。
由 RFC 1035 定义为过时：NULL(10)（RFC 883 定义 “完成查询”（操作码二及可能是三）有在使用此记录，后来 RFC 1035 重新分配操作码二为 “状态” 及保留操作码三）。
定义为早期的 IPv6 但其后由 RFC 3363 降级为试验性：A6(38)
由 DNSSEC 更新（RFC 3755）定义为过时：NXT(30)。同一时间，为 KEY 及 SIG 域名的适用性限制为不包括 DNSSEC。
第一版 DNSSEC（RFC 2230、RFC 2065）的一部分，现已过时：KX(36)
目前没有任何显著的应用程序使用：HINFO(13)、RP(17)、X25(19)、ISDN(20)、RT(21)、NSAP(22)、NSAP-PTR(23)、PX(26)、EID(31)、NIMLOC(32)、ATMA(34)、APL(42)
由 Kitchen Sink [互联网草案](https://zh.wikipedia.org/w/index.php?title = 互聯網草案 & action=edit&redlink=1)，但从未达至 RFC 水平：SINK(40)
一个 LOC 记录更有限的早期版本：GPOS(27)
IANA 保留，及后未有 RFC 记录它们 [1] 而支持已由 BIND 于九零年初移除：UINFO(100), UID(101)、GID(102)、UNSPEC(103)

RP(17) 可能被使用于有关指定的主机的不同联系点、子网域其他 SOA 记录不包含的域名级别的人类可读信息。

查询类：两个八位位组代码，指定查询的类。例如：对于 Internet，查询类字段值为 1，其符号表示为 IN。

资源记录格式说明

回答部分、权威部分和附加部分都是共享相同格式，就是可变数目的资源记录，其中记录的数目在首部相应计数字段中规定。只有应答报文才提供资源记录。

在这里插入图片描述

Name：可变长字段，指该资源记录匹配的域名。它实际上就是查询报文问题部分查询名称的副本，但由于在域名重复出现的地方 DNS 使用压缩，这个字段就是到查询报文问题部分中的相应域名的指针偏移。

Type：两个八位位组代码，长度 16 位，指定资源记录的类型，说明 RDATA 字段中数据意义。该字段与问题部分的查询类型字段相同。

Class：两个八位位组，指定 RDATA 字段中数据的类，与问题部分的查询类字段相同。

TTL：生成时间，32 位无正负号整数，指定资源记录可以被缓存时间，单位是秒。值为 0 表示资源记录仅能用于正在进行的业务，不能被缓存。

Data length：资源数据长度，无符号 16 位整数，指定 RDATA 字段长度，以八位位组为字节。

资源数据：可变长字段，是资源记录的具体内容。其格式取决于资源记录的 TYPE 和 CLASS 字段。

资源数据格式种类包含如下：

数字：八位位组表示数，例如，IPv4 地址是 4 个八位组整数，而 IPv6 地址是一个 16 个八位组整数。
域名：可用标签序列来表示。每一个标签前面有 1 个字节长度字段，它定义标签中的字段数。长度字段的两个高位永远是 0，标签的长度不能超过 63 字节。
偏移指针：域名可以用偏移指针来替换。偏移指针是 2 字节字段，它的两个高位置为 1
字符串：用 1 字节的长度字段后面跟着长度字段数。长度字段并不像域名长度字段那样受限。字符串可以多达 256 个字符。

DNS 报文传输

使用 UDP 进行传输

使用 UDP 用户服务器端口 53 发送消息。由 UDP 携带的 DNS 报文长度被限制在 512 字节之内，其中不包括 IP 首部或 UDP 首部。较长的 DNS 报文被截断，TCP 字段在首部中被设置为 1。

UDP 是 DNS 的 Internet 标准查询的推荐方式，但不包括区域传输。使用 UDP 发送的查询可能丢失，因此需要考虑传策略。查询或查询的应答可能由网络重新排序，或者经 DNS 服务器处理过，因此解析程序不能依赖按顺序返回的应答。

使用 TCP 进行传输

通过 TCP 传输的 DNS 报文使用两个字节长度字段做前缀。这个长度字段给出报文长度，计算长度不包括这个长度字段。该长度字段使得在开始解析报文之前，底层处理能够组装好完整的报文。

DNS 协议解析

int main(int argc, char *argv [])
{
	char errbuf [100];
	pcap_t *desc = 0;
    char *filename = argv [1];
    if(argc != 2)
    {
        printf("usage: ./dissect_pppoe [pcap file]\n");
        return -1;
    }
    printf("ProcessFile: process file: % s\n", filename);
    if((desc = pcap_open_offline(filename, errbuf)) == NULL)
    {   
        printf("pcap_open_offline: % s error!\n", filename);
        return -1; 
    }   	
    pcap_loop(desc, -1, got_packet, NULL);
    pcap_close(desc);
    return 0;
}

在这里插入图片描述

总结

在分析 DNS 报文时，可以使用 nslookup 工具来测试 DNS 解析，要获取 DNS 报文的详细数据信息，需要使用 Wrieshark 捕获 DNS 流量进行分析。

参考：RFC 973、RFC 1886

DNS 的 TCP 53 号端口究竟什么时候会用到

老沈再改教科书 2017-05-29 18:41:58

1. 问题背景

学校网络中心为加固校园网内网安全，在数据中心出入口升级 ACL，只放行到 DNS 服务器 UDP 的 53 号端口的访问。之后用户反映手机端腾讯新闻 APP 部分图片显示不全，经排查发现是 DNS 的 TCP 53 号端口被拦截所致。

2. UDP 协议包大小问题

以太网 MTU 为 1500 字节，UDP 报文理论最大值为 1480 字节（无 IP 选项字段时），但在 Internet 上标准 MTU 值为 576 字节。由于 UDP 无重传机制，为避免分片丢失导致服务不可用，DNS 协议将 UDP 包大小限制在 576 字节以下（有效数据 548 字节），实际 MAX 值为 512 字节。

3. DNS 域名服务中 TCP 53 号端口的应用场景

当客户端请求如腾讯新闻 APP 主页或栏目页的 DNS 解析时，若服务器应答内容超过 512 字节，UDP 包无法承载全部解答。此时服务器返回的响应报文中 TC 标志位被置为 1，表示应答被裁减，客户端需使用 TCP 53 号端口重发查询请求，以获取完整解析结果。

4. 数据抓包分析过程

用户向 DNS 服务器发出 DNS 解析请求，服务器返回 552 字节的解析结果（TC 标志位置 1）。随后客户端与 DNS 服务器进行 TCP 三次握手，并向 TCP 53 号端口发起 DNS 解析请求，服务器回复 642 字节的查询结果，超出了 DNS UDP 包的承载范围。

DNS（Domain Name System）是互联网的一项服务，用于将易于人们记忆的域名转换为计算机可识别的 IP 地址，其涉及 UDP（User Datagram Protocol）和 TCP（Transmission Control Protocol）两种传输协议，具体如下：

UDP 协议与 DNS 服务

UDP 是一种无连接的传输层协议，具有简单、高效但不可靠的特点。在 DNS 服务中，UDP 常用于用户查询请求，主要基于以下考量：

查询请求的特性

多数情况下，用户对域名的查询请求相对简单，数据量较小，UDP 协议能够快速地将查询请求发送到 DNS 服务器。例如，当用户在浏览器中输入一个网址时，浏览器会向本地 DNS 服务器发送一个 UDP 数据包形式的查询请求，询问该域名对应的 IP 地址。这种简单快速的查询方式足以满足大多数日常上网场景中对域名解析的需求。
效率优先原则

UDP 协议无需建立连接，减少了建立和维护连接的开销，从而在查询请求时能够提供更高的效率。相比于 TCP 协议，UDP 在处理大量小规模的查询请求时，能够更快地响应，减少用户等待时间，提升用户体验。

TCP 协议与 DNS 服务

TCP 是一种面向连接的可靠传输协议，在 DNS 服务中，TCP 的 53 号端口主要用于特定场景，原因如下：

区域传输同步

传统上，TCP 的 53 号端口在主辅 DNS 服务器之间进行区域传输同步时发挥作用。主 DNS 服务器负责维护域名解析的权威数据，辅 DNS 服务器需要从主服务器获取这些数据以提供备份和负载均衡功能。在这个过程中，TCP 协议确保数据传输的可靠性，防止数据丢失或损坏，保证主辅 DNS 服务器之间的数据一致性。
大响应数据传输

当 DNS 服务器的应答数据量超过 UDP 包的承载能力时，需要使用 TCP 的 53 号端口。如腾讯新闻 APP 主页或栏目页的 DNS 解析，由于页面内容丰富，对应的 DNS 应答内容较多，超过了 UDP 的 512 字节限制。此时，服务器会在 UDP 应答中设置 TC（删减标志）比特为 1，表示应答被裁减，客户端收到后会通过 TCP 的 53 号端口重新发起查询请求，以获取完整的应答数据。这是因为 TCP 协议具有可靠的重传机制，能够保证大数据包在网络传输中的完整性，避免因分片丢失导致服务不可用的问题。

UDP 和 TCP 协议在 DNS 服务中各自扮演着重要角色，根据不同的需求选择合适的协议，以确保 DNS 服务在高效性和可靠性之间达到平衡，从而保障整个互联网域名解析系统的稳定运行。

via:

DNS 协议（DNS 规范、DNS 报文、DNS 智能选路）-优快云博客 静下心来敲木鱼于 2023-12-05 23:21:55 发布
https://blog.youkuaiyun.com/m0_49864110/article/details/134819638
DNS 请求报文和响应报文解析 - 优快云博客 张嘉睿大聪明已于 2022-06-24 16:44:43 修改
https://blog.youkuaiyun.com/weixin_45975575/article/details/115561913
用 wireshark 抓包分析 DNS 域名解析过程_wireshark dns-优快云博客 天涯海角 TYHJ 于 2023-12-09 12:01:07 发布
https://blog.youkuaiyun.com/m0_73576645/article/details/134890351
DNS 报文解析及代码实现（详细）-优快云博客 程序猿编码于 2021-10-30 20:49:18 发布
https://blog.youkuaiyun.com/chen1415886044/article/details/121054801
用C语言实现DNS - 奇热行 - 博客园 posted @ 2017-12-13 20:36 奇热行
https://www.cnblogs.com/qrxqrx/articles/8034781.html
DNS RR 代码和含义 - bonelee - 博客园 posted @ 2017-09-29 17:24 bonelee
https://www.cnblogs.com/bonelee/p/7611941.html
老沈再改教科书：DNS 的 TCP 53 号端口究竟什么时候会用到_一网无前_新浪博客 2017-05-29 18:41:58
https://blog.sina.com.cn/s/blog_4c86552f0102wyfc.html