java构建TCP/IP协议:DNS,域名解析协议系统的运行流程

2019-05-10 14:59:51 浏览数 (1)

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”其实是一个别名,打个比方,一个人可以使用假名和真名,假名可以随时变,真名则要跟身份证绑定。同样的道理,pan.baidu.com这个域名可以根据需要随时变化,例如以后它可以变成pen.baidu.com,但是第二个域名就唯一绑定一台服务器,我们只有拿这个域名去查询才能找到对应的IP。

为了简单起见,其他两种资源的数据格式我们暂时放一放,以后需要的时候才研究,在下一节我们将使用代码实现本节描述的DNS域名解析流程。

0 人点赞