DNS域名解析协议系统的运行流程详解

DNS协议的运转需要客户端和服务器进行交互。由于服务器端需要存储大量的域名信息，同时每天需要应答海量的解析请求，因此它的设计必须遵循分布式系统。客户端向一台服务器请求解析服务时，对方可能没有相应的域名信息，于是它会向上一层查询，获得拥有给定域名信息的服务器，然后把对应服务器的信息归还给客户端，然后客户端再重新发起请求。

我们还需要关注域名信息如何在服务器上存储。在域名服务器上，信息存储有两种方式，一种是域名信息以二进制格式存储，这种格式对应的名称叫Resource Record Filed Format，同时为了方便管理员管理，这些信息又通过文本形式展现出来，对应的格式称为Master File Representation,管理员通过修改后者就能使得对应的二进制信息进行相应变换：

Resource Record 是一种特定数据结构，专门用于存储域名解析相关信息，例如域名对应的服务器IP，域名解析服务器地址等，在后面我们解析数据包时再深入探讨。

域名解析其实有三种形式，第一种是我们熟悉的，将域名发给服务器然后获得域名对应IP;第二种叫反向解析，将IP发给服务器然后获得对应域名;第三种叫电子邮件解析，将邮件地址发给服务器然后获得邮件的接收对象IP。我们将主要关注第一种形式的原理和实现。

当我们执行第一种域名解析时，首先要做的是获得域名服务器地址。这个过程并非一撮而就，有可能我们查询第一个服务器时，它给我们返回另一个服务器的地址，然后我们继续查询;第二步是确定服务器后，我们要解析它返回来的数据内容。在这个过程中，第二步相对容易，而第一步则比较棘手。

在查询对应域名服务器时有两种方式，一种是循环式，第一个域名没有对应信息，但返回另一个它认为有对应信息的服务器，接着客户端向第二个服务器请求，第二个服务器又返回另一个服务器信息，该过程依次循环直到找到对应服务器为止：

第二种叫递归式，它与一种的区别在于，服务器承担起客户端查找对应服务器的职责，服务器会反复向其他服务器查询，直到拿到对应域名信息后，直接返回给客户端：

接下来我们看看DNS数据包的基本格式，首先第一部分叫头部，用于描述消息类型，以及后续数据结构的相关信息;第二部分叫”问题“，它用来包含客户端想向服务器查询的信息;第三部分叫”答案“，是服务器用于回复客户端查询;第四部分叫Authority，如果请求没有得到全部答复，这部分内容告诉客户端向哪个服务器进行查询;第五部分叫Additional，这部分包含客户端查询信息的附加说明，它并非必须，所以数据包的基本结构如下：

我们用wireshark抓取dns有关的消息包后，对照上面描述的条目进行解析。启动wireshark，然后使用关键词dns过滤，然后在浏览器里输入一个你以前没有访问过的网址，如果输入已经访问过的，浏览器会有缓存，因此不会走dns协议。以下是我抓取到的一个DNS解析请求包：

首先是头部，它包含12字节，从Transaction ID 到 Additional RRs,每个字段2字节。ID用来标志一次会话，一个会话内的数据包拥有相同ID。Flags分为两部分，第一部分一字节叫做QR，用来表示该数据包是查询还是回答，如果是查询就设置为0，如果是回答就设置为1.如果是查询，那么第二个字节就是OpCode，进一步表明具体查询，它分为若干部分，前四个比特位用于表明查询类型，0表示查询域名对应IP，1不再使用;2表示查询域名服务器状态;3目前不使用，4用于服务器之间的交互;5也是用于服务器之间的交互。

第五个比特位叫AA,它只在回复包中设置，用于表明回复的权威性，它的具体内容我们暂时忽略。第六个比特位叫TC，它用于表明数据是否被截断，用于DNS支持UDP和TCP，但使用UDP时数据包不能超过512字节，如果超过数据包就得截断成多个小数据包，如果该位设置成1，它表明双方需要通过TCP来建立连接。第8位叫RD，如果设置成1，它意味着客户端请求递归式查询，也就是让服务器帮忙向其他服务器询问，得到最终消息后再返还给客户端。

接下来字节的比特位是RA，如果设置为1表示服务器支持递归式查询，也就是服务器把所有累活都承担了，0则是不支持。接下来三个比特位必须设置为0，接着4个比特位表示返回码，如果值为0表示返回数据正常，非0表示出现错误，其中取值1表示查询数据包格式错误;2表示服务器自身故障;3表示解析错误;4表示不支持所要求的查询;5表示拒绝查询请求;其他值我们暂时忽略。

接下来用于表示相应条目的数量，Questions表示有几个查询条目，Answer RRs表示有几个回复条目，Authority RRs表示有几个权威信息条目，所谓“权威”是指真正能够解析域名的服务器，如果当前服务器不能解析域名请求，它需要把请求转发给其他服务器时，它自己就不是Authoritive，我们家用路由器其实承担域名解析服务器的职责，但是它本身不可能包含所需要的域名信息，它会把请求转发给上一层服务器，因此路由器就不是”权威“域名解析服务器。由此一个DNS域名解析数据包的轮廓如下：

接下来我们看看问题段数据结构，它结构如下：

首先是问题名字，这个字段长度可变，存储的是要查询的域名，以0作为结尾。第二个是问题类型，它是2字节，用于表明查询的类型，取值1表示查询域名对应IP，取值2查询服务器名称，具体类型在后面我们用到时再详细讨论。最后是问题类别，一般而言写死为1。

这里我们讲解一下Question Name对应的字符串结构，例如对于字符串：www.baidu.com，它的对应格式为[3]www[5]baidu[3]com,其中[]内表示接下来字符个数，例如[3]表示后面跟着3个字符www,[5]表示接下来跟着5个字符，注意到这些数字所在位置正好对应字符串中符号点所在位置。

接下来我们看Answer Resource Records 的结构，服务器收到客户端请求，完成解析工作后，把解析信息存储在该结构里发回给客户端。它的结构如下，第一个是名字字符串，可变长，它对应要解析的域名或服务器名称。接着是资源类型，2字节，表明资源的类型，如果取值是5，那么接下来对应着域名服务器对应的字符串名称，接着是资源类别，2字节，一般设置成1;接着是TTL(Time To Live)，4字节，表明这些信息能在缓存中存储多久;接着是RDLength，2字节，用于表明接下来内容的长度;最后是相应内容，如果资源类型是5，那么内容就是字符串，如果是1，那么内容就是4字节的IP地址，该数据类型对应的格式轮廓如下：

这里值得提到的是，如果资源类型5，那么对应的字符串才是“真正”域名，例如下面显示内容：

它显示的是，一开始我们使用域名“pan.baidu.com”去进行域名解析，此时解析服务器没有直接返回该域名对应的IP，而是返回另一个域名yiyun.n.shifen.com，前面”pan.baidu.com”其实是一个别名，打个比方，一个人可以使用假名和真名，假名可以随时变，真名则要跟SFZ绑定。同样的道理，pan.baidu.com这个域名可以根据需要随时变化，例如以后它可以变成pen.baidu.com，但是第二个域名就唯一绑定一台服务器，我们只有拿这个域名去查询才能找到对应的IP。

以上就是软件云为大家带来的DNS域名解析协议系统的运行流程详解的全部内容，希望能对您有所帮助，小伙伴们 有空可以来软件云网站，我们的网站上还有许多其它的资料等着小伙伴来挖掘哦 ！