wireshark学习笔记(七)——DNS协议
DNS解析的过程
DNS的服务采用服务器/客户端（C/S）的方式工作。当客户端程序要通过一个主机名称访问网络中的一台主机时，它首先需要得到这个主机名称所对应的IP地址。因为IP数据包中允许放置的是目标主机的IP地址，而不是主机的名称。可以从本机的hosts文件中得到主机名称所对应的IP地址，但如果hosts文件不能够解析该主机的名称，则只能通过向客户机所设定的DNS服务器进行查询了。不过本机的hosts文件可能会被造假，从而为黑客打开方便之门。对此有兴趣的朋友可以学习“i春秋”的《病毒木马查杀实战》系列的课程。下面以www.ichunqiu.com域名为例讲解DNS解析的过程：
由上图可知DNS名称解析的过程为
1、客户计算机向本地域名服务器发送了一个查询请求，请求查询域名为www.ichunqiu.com的IP地址。
2、本地域名服务器查找自己保存的记录，看能否找到这个被请求的IP地址。如果本地域名服务器有这个地址，就会把这个地址返回给客户计算机。如果本地域名服务器没有这个地址，则会发起查找地址的过程。本地域名服务器发送请求给根域名服务器，询问www.ichunqiu.com的IP地址。
3、根域名服务器无法提供这个地址，但是会将com的名称服务器的地址返回给本地域名服务器。
4、本地域名服务器再向com域服务器发送查询地址的请求。
5、com域服务器无法提供这个地址，就将ichunqiu.com域名服务器的地址发送给本地域名服务器。
6、本地域名服务器再向ichunqiu.com域名服务器发送地址查询的请求。
7、ichunqiu.com域名服务器找到了www.ichunqiu.com的IP地址，就将这个地址发给本地域名服务器。
8、本地域名服务器会将这个地址发给客户计算机，并将这个IP地址保存到缓存中。那么接下来，客户计算机就可以访问www.ichunqiu.com了。
以上就是DNS域名解析的过程，在这个过程中通常会用到两种查询方式，分别是递归查询和迭代查询：
1、递归查询
客户计算机向本地域名服务器的查询一般采用的是递归查询。如果客户机所询问的本地域名服务器无法提供被查询域名的IP地址，那么本地域名服务器就会以DNS客户的身份，向其它根域名服务器继续发出查询请求的报文。
2、迭代查询
本地域名服务器向根域名服务器的查询通常采用的是迭代查询。当根域名服务器收到本地域名服务器的迭代查询请求的报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器“下一步应该向哪个域名服务器进行查询”。然后本地域名服务器就进行后续的查询。
DNS查询数据包分析
这里我们结合Lab13-1.pcap文件来分析一下DNS的查询：
首先看一下第一个数据包。它是由IP地址为192.168.0.114发往205.152.37.23的53号端口的。53号端口也正是系统默认的DNS查询的端口。并且我们还可以知道，DNS其实是基于UDP协议的。
这里我们看一下DNS头部的Flags区段。可以发现这个数据包是一个典型的DNS请求。再展开查询区段，从Name的值可以知道客户端其实是想查询wireshark.org的网络地址。接下来的Type:A表示域名类型为A，也就是主机地址。并且地址的类型是IN，也就是互联网地址。那么其实这个数据包就是在向本地域名服务器询问wireshark.org的IP地址是什么。下面看一下第二个数据包：
03
这个数据包是对第一个数据包的回应，从标识码的值也可以知道它与第一个数据包是对应的。在 Flags区段可以看到这是一个响应数据包，并且允许必要的递归。接下来的Questions以及Answer RRs的值都是1，说明接下来的区段会包含一个询问和一个回答。询问的内容与上一个数据包一致，回答的内容就是对询问的问题做一个回应。也就是回复了wireshark.org的IP地址是128.121.50.122。客户计算机获取了这个回应信息，就可以开始构建IP数据包，并与wireshark.org进行通信了。
DNS递归数据包分析
这里我们研究一下DNS的递归数据包。实验文件Lab13-2.pcap是从客户端捕获的两个DNS数据包：
首先，第一个数据包是从客户端172.16.0.8发往DNS服务器172.16.0.102的初始查询。展开这个数据包的DNS区段，可以发现这是一条用于查找域名为www.nostarch.com的标准查询，并且在Flags区段中还看到了期望递归的标志。
第二个数据包是我们所期望看到的对于初始数据包的响应：
这个数据包的事务ID和我们前一个数据包相匹配，并且在Answers区段得到了www.nostarch.com所对应IP地址。
仅仅在客户计算机进行抓包分析，我们只能知道成功获取了IP地址，并不知道这个IP地址的查询过程是否进行了递归的操作。因此这里我们需要研究一下在服务器端获取的实验文件Lab13-3.pcap。这个文件包含有在查询开始时，在本地DNS服务器上捕获到的数据包。这里的第一个数据包和我们之前捕获文件中的初始查询相同。
此时，DNS服务器接收到了这个查询数据包，检索本地数据库之后，发现自己并不知道关于所查询域名的IP地址。由于这个数据包被设置了期望递归，那么我们在第二个数据包中就可以看到这个DNS服务器为了获取IP地址，于是就向其它的DNS服务器进行查询：
在这个数据包中，位于172.16.0.102的DNS服务器向位于4.2.2.1的DNS服务器发起了查询请求，这个服务器就是本地DNS服务器所设定的要转发上行请求的服务器。这个请求其实是原始请求的镜像，此时其自身相当于一个DNS客户端。 由于这个事务ID与之前捕获文件中的事务ID不同，所以我们可以将这个DNS查询作为一个新的查询。这个数据包被4.2.2.1服务器接收以后，本地DNS服务器就收到了回应，也就是第三个数据包的内容：
接收到了这个响应之后，本地DNS服务器就将IP地址传递给了发起DNS请求的客户端。虽然这里只展示了一层递归，但事实上，对于一个DNS请求来说，可能会出现多次递归的情况。在这个例子中，我们是从4.2.2.1服务器中获取IP地址的，但是那个服务器可能为了寻求答案也向其它的服务器执行了递归查询的操作。一个简单的查询在得到最终结果之前，可能会游历全世界。
DNS区域传送分析
DNS区域是一个DNS服务器所授权管理的名字空间（或是一组DNS名称）。举个例子来说，ichunqiu这个网站可能由一个DNS服务器对ichunqiu.com负责。这样，不论是ichunqiu内部还是外部的设备，如果希望将ichunqiu.com解析成IP地址，都需要和这个域的DNS服务器联系。现在ichunqiu又多了一个社区功能，那么它可能会增加一个DNS服务器，专门用来处理其名字空间中的bbs部分，比如bbs.ichunqiu.com。那么这个服务器，就成为了这个社区子区域的权威。如果有必要的话，还可以为子域名添加更多的DNS服务器，如下图所示：
区域传送指的是出于冗余备份的需要，在两台设备之间传送区域数据。比如在拥有多个DNS服务器的组织中，管理员通常都会配置一台备用DNS服务器，用于维护一份主服务器的DNS信息拷贝，以防止主DNS服务器不可用的情况出现。但如果配置不当，就会导致任何匿名用户都可以获取DNS服务器某一域的所有记录，将整个企业的基础业务以及网络架构对外暴露，从而造成严重的信息泄露，甚至导致企业网络被渗透。区域传送主要包含有两种形式：
1、完整区域传送（AXFR）
这个类型的传送将整个区域在设备间进行传送。
2、增量区域传送（IXFR）
这个类型的传送仅仅传送区域信息的一部分。
实验文件Lab13-4.pcap就包含有一个区域传送的例子。首先我们会发现，数据包的类型是TCP而不是UDP。而我们之前也说了，DNS是基于UDP协议的，但事实上，DNS在如同区域传送这样的一些任务中，会使用TCP协议，因为TCP对于规模化的数据传输更为有效。那么很明显，这个捕获文件中的前三个数据包其实就是TCP的三次握手。
接下来的第四个数据包就开始在172.16.16.164和172.16.16.139之间进行实际的区域传送了。需要注意的是，这个数据包里面并不包含任何DNS信息。而这个数据包被标记为“TCP segment of a reassembled PUD”，即“重组PUD的TCP分片”。第五个数据包是对于第四个数据包成功接收的确认。而第六个数据包则可以作为完整的DNS区域传送请求的参考：
在这里可以看到，区域传送是典型的查询，并且请求的是AXFR类型，也就是完整区域传送，意味着它希望从服务器接收全部DNS区域。接下来服务器在第七个数据包中回复了区域记录：
可见，区域传送包含了相当多的数据。如果是复杂的网络情况，还会包含有更多的数据，这就彰显了保证区域传送安全的重要性。在传送完毕之后，捕获文件以TCP的连接终止作为结束。
