实验目的
①，掌握DNS域名解析过程
②，熟悉DNS报文格式
实验原理
使用ping访问域名地址，利用wireshark网络抓包工具，抓包分析DNS域名解析协议过程
DNS域名解析原理
域名解析过程
域名到IP地址的解析过程的要点如下：当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序(resolver)，并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减少开销）。本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。
若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。这种过程直至找到能够回答该请求的域名服务器为止。
DNS客户端服务按以下顺序查询DNS服务器
-
DNS客户端服务将名称查询发送到首选适配器的DNS服务器列表上的第一个DNS服务器，并等待一秒钟以进行响应。
-
如果DNS客户端服务在一秒钟内未收到第一台DNS服务器的响应，则会将名称查询发送到仍在考虑中的所有适配器上的第一台DNS服务器，并等待两秒钟以进行响应。
-
如果DNS客户端服务在两秒钟内未收到任何DNS服务器的响应，则DNS客户端服务会将查询发送到仍在考虑中的所有适配器上的所有DNS服务器，并等待另外两秒钟以响应。
-
如果DNS客户端服务仍然没有收到来自任何DNS服务器的响应，它将名称查询发送到仍在考虑中的所有适配器上的所有DNS服务器，并等待四秒钟以进行响应。
-
如果DNS客户端服务未从任何DNS服务器接收到响应，则DNS客户端会将查询发送到仍在考虑中的所有适配器上的所有DNS服务器，并等待八秒钟以获取响应。
如果DNS客户端服务收到肯定的响应，它将停止查询名称，将响应添加到缓存中并将响应返回给客户端。
如果DNS客户端服务在8秒钟内未收到任何服务器的响应，则DNS客户端服务将超时。另外，如果尚未从指定适配器上的任何DNS服务器接收到响应，则在接下来的30秒内，DNS客户端服务将以超时响应发往该适配器上服务器的所有查询，并且不查询这些服务器。
如果DNS客户端服务在任何时候都收到来自服务器的否定响应，则它将在搜索过程中将该适配器上的每个服务器都排除在考虑范围之外。例如，如果在步骤2中，备用适配器A上的第一台服务器给出了否定响应，则DNS客户端服务将不会将查询发送到备用适配器A列表上的任何其他服务器。
DNS客户端服务跟踪哪些服务器更快速地回答名称查询，并根据服务器对名称查询的回复速度将服务器在列表中上移或下移。
准备工作
查看本机 IP
ipconfig
查看电脑配置的本地域名服务器地址
ipconfig /all
查看“必应”网站域名对应的 IP 地址
nslookup www.biying.com
DNS报文格式
整个DNS报文格式主要分为 3 部分内容，即基础结构部分、问题部分、资源记录部分。（对报文格式的具体分析，请查看下面抓包数据分析）
准备工作完成
至此，我们已经知道以下几点内容
①，本机IP地址（IP6地址 fe80::3995:c67c:ccbd:3ba4，IP4地址 192.168.1.6）
②，本地域名服务器地址（IP6地址 fe80::1，IP4地址 114.114.114，8.8.8.8）
③，“必应”网站域名所对应的IP地址（202.89.233.100，202.89.233.101）
注：以上准备工作中所获得的数据，在抓包数据中会涉及到，请明确知悉其含义
抓包操作
抓包流程
①，使用wireshark抓取网络请求包，启用开始捕获
②，访问www.biying.com网址（使用ping命令模拟访问域名）
③，查看抓包数据（记得保存抓包数据，便于后续分析）
抓包数据分析
可以看到，访问www.biying.com网址 ，产生了四条数据（将抓包报文使用了DNS过滤后的结果），两次DNS请求（请求与响应配对存在）；
第一次DNS请求查询 www.biying.com 域名对应的IP4地址（A代表IP4）；
第二次DNS请求查询 www.biying.com 域名对应的IP6地址（AAAA代表IP6）；
因为两次查询协议过程相同，故以第一次查询内容来作为数据分析。
分析第一次查询过程抓包数据
DNS请求报文数据如下
报文分析：
可以看到，网络传输层使用 UDP 协议，端口号为 53
DNS报文基础结构部分
每个字段含义如下。
- 事务 ID（Transaction ID）：DNS 报文的 ID 标识。对于请求报文和其对应的应答报文，该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。
- 标志（Flags）：DNS 报文中的标志字段。
- 问题计数（Questions）：DNS 查询请求的数目。
- 回答资源记录数（Answers RRs）：DNS 响应的数目。
- 权威名称服务器计数（Authority RRs）：权威名称服务器的数目。
- 附加资源记录数（Additional RRs）：额外的记录数目（权威名称服务器对应 IP 地址的数目）。
其中Flags字段中每个字段的含义如下：
- 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），一般是服务器由于设置的策略拒绝给出应答，如服务器不希望对某些请求者给出应答，，或者服务器不希望进行某些操作（比如区域传送zone transfer）；
- 6-15 保留值，暂时未使用。
DNS报文问题查询部分
每个字段含义如下：
- 查询名（Name）：一般为要查询的域名，有时也会是 IP 地址，用于反向查询。
- 查询类型（Type）：DNS 查询请求的资源类型。通常查询类型为 A 类型，表示由域名获取对应的 IP4 地址。（更多类型如 AAAA，CANME，SOA，PTR，NS 等）
- 查询类（Class）：地址类型，通常为互联网地址，值为 1。
那么，对于上面报文内容，翻译过后的意思就是，“该报文为标准查询(Opcode=0)请求(QR=1)报文，向本地域名服务器( IP 报文中目的地址为本地域名服务器地址，在上面准备工作中已经知道了)请求查询，发起请求内容为 ‘获取www.biying.com (Name=www.baidu.com)所对应的IP4地址(Type=A)’，期待本地域名服务器递归查询(RD=1)请求”
DNS响应报文数据如下
报文分析：
对比请求报文发现，响应报文“基础结构部分”和请求报文结构对应相同，并返回字段说明服务器支持递归查询（RA=1），服务器响应记录的名称服务器为非权威服务器（AA=0）,产生了4条响应记录（Answers RRs = 4），响应报文中多了answers字段且有4条数据
响应报文中，Queries字段完全和请求报文相同，answers字段为DNS资源记录部分的内容。
DNS资源记录
每个字段含义如下：
- Name：DNS 请求的域名。
- Type：资源记录的类型，与问题部分中的查询类型值是一样的。
- Class：地址类型，与问题部分中的查询类值是一样的。
- Time to live：生存时间，以秒为单位，表示资源记录的生命周期，一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间。它同时也可以表明该资源记录的稳定程度，稳定的信息会被分配一个很大的值。
- Data length：资源数据的长度。
- 资源数据：表示按查询段要求返回的相关资源记录的数据。（如 Address :IP地址，CNAME:服务器别名 ，等）
那么，answers字段内容，翻译过来意思就是（从第一条开始按顺序翻译），
①，'www.biying.com'域名的别名有'www-biying-com.cn.a-0001.a-msedge.net'；
②，'www-biying-com.cn.a-0001.a-msedge.net'域名的别名为'china.bing123.com'；
③，'china.bing123.com'域名对应的IP4地址有'202.89.233.101'；
④，'china.bing123.com'域名对应的IP4地址有'202.89.233.100'；
通过以上报文结果数据分析，获取到的数据结果和我们准备工作所获取的结果是一致的。
实验过程遇到的问题
问题一，为什么会同时查询域名对应的IP4地址和IP6地址；
问题二，实验过程中会出现同时向两个域名服务器查询同一内容（见截图，对8.8.8.8域名服务器重新查询了请求）；
原因：因为主服务器没有正常响应，导致DNS客户端像备用服务器重新发起啦请求。
查阅资料知晓本机域名服务器配置区分首选域名服务器和备用域名服务器，当首选服务器不能响应时候，就会由备用域名服务器响应。（我电脑配置了两个）
这个只是原理，那么从报文数据如何体现主服务器不能工作响应了呢？
起初我一直想着通过DNS的响应来查找返回错误信息，此路不通。后来查看报文发现啦ICMP协议的报文，ICMP协议的主要功能，[1]给送信者的错误通知；[2]送信者的信息查询。最后通过查找DNS请求对应的ICMP报文（通过事务ID关联报文），发现响应报文确实返回了“目标主机不可到达，目标端口不可到达”，报文截图如下
通过对比报文事务ID（截图中事务ID为0xda90）,发现以下三条报文是相互关联的
（注：如果IPv4不能将数据报传送到目标主机，则路由器上的或目标主机上的ICMP会向主机发送一条“无法到达目标”。因为是由目标主机发出的ICMP报文，所以IP报文中的src地址所代表的DNS域名服务器地址，其实也就是我们DNS通信的目标网络地址）
通过上面截图分析，可以看到，ICMP报文返回信息说首选域名服务器（114.114.114.114）不可达，从而本机向备用域名服务器重新发起了请求。
问题三，出现多个相同事务ID的DNS请求
原因，由于网络卡顿，一定时间内DNS响应没有应答的话，DNS客户端就会尝试重新发起请求。
图中标框的请求，我们可以发现，这四个请求的内容是一样的，事务ID也是一样的，但是transaction ID 是用来用来唯一标识DNS报文的，现在却出现了四个相同事务ID的请求。
通过分析请求，响应报文发现，出现如下报文内容，
请求
响应
'[Expert Info (Warning/Protocol): DNS query retransmission. Original request in frame 3]' ，意思是说DNS查询重传，原始请求在编号3的帧里面（即截图中第一个请求）
'[Expert Info (Warning/Protocol): DNS response retransmission. Original response in frame 45]'，意思是说DNS响应重传，原始响应在编号45的帧里面
由于网络不稳定导致重传（在抓包过程中，明显感觉到网络卡顿，偶尔还会出现丢包现象）
实验不足
本实验对于DNS缓存（浏览器缓存 --> 系统缓存 --> 路由器缓存 --> ISP缓存）问题未涉及分析实验
对于DNS请求转发过程（转发过程在在域名服务器上，而不在本机上进行转发）未涉及分析验证（推荐看阮老师博客文章-DNS原理入门）
实验总结
附录
参考链接
DNS报文格式解析http://c.biancheng.net/view/6457.html
https://blog.csdn.net/itermeng/article/details/77833356
https://blog.51cto.com/13444271/2125344
DNS Processes and Interactions
感谢ypxka技术指导和建议❤️