用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx

上传人:b****2 文档编号:5053116 上传时间:2023-05-04 格式:DOCX 页数:20 大小:831.55KB
下载 相关 举报
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第1页
第1页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第2页
第2页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第3页
第3页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第4页
第4页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第5页
第5页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第6页
第6页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第7页
第7页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第8页
第8页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第9页
第9页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第10页
第10页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第11页
第11页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第12页
第12页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第13页
第13页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第14页
第14页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第15页
第15页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第16页
第16页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第17页
第17页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第18页
第18页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第19页
第19页 / 共20页
用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx_第20页
第20页 / 共20页
亲,该文档总共20页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx

《用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx》由会员分享,可在线阅读,更多相关《用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx(20页珍藏版)》请在冰点文库上搜索。

用协议分析工具分析DNS以及各层协议的工作机制Word文档格式.docx

TCP连接的建立采用“三次握手”的方法。

一般情况下,双方连接的建立由其中一方发起。

如图2(a)所示:

主机A首先向主机B发出连接请求报文段,其首部的SYN同步位为1,同时选择一个序号x;

主机B收到此连接请求报文后,若同意建立连接,则向主机A发连接响应报文段。

在响应报文段中,SYN同步位为1,确认序号为x+1,同时也为自己选择一个序列号y;

主机A收到此确认报文后,也向主机B确认,这时,序号为x+1,确认序号为y+1。

当连接建立后,A、B主机就可以利用TCP进行数据传输了。

图2TCP的连接和释放

(2)TCP连接的释放

在数据传输结束后,任何一方都可以发出释放连接的请求,释放连接采用所谓的“四次”方法。

如图2(b)所示,假如主机A首先向主机B提出释放连接的请求,其过程如下:

主机A向主机B发送释放连接的报文段,其中,FIN终止位为1,序号x等于前面已经发送数据的最后一个字节的序号加1;

主机B对释放连接请求进行确认,其序号等于x+1。

这时从A到B的连接已经释放,连接处于半关闭状态,以后主机B不再接收主机A的数据。

但主机B还可以向主机A发送数据,主机A在收到主机B的数据时仍然向主机B发送确认信息。

当主机B不再向主机A发送数据时,主机B也向主机A发释放连接的请求;

同样主机A收到该报文段后也向主机B发送确认。

(3)TCP数据传输

TCP可以通过检验序号和确认号来判断丢失、重复的报文段,从而保证传输的可靠性。

TCP将要传送的报文看成是由一个个字节组成的数据流,对每个字节编一个序号。

在连接建立时,双方商定初始序号(即连接请求报文段中的SEQ值)。

TCP将每次所传送的第一个字节的序号放在TCP首部的序号字段中,接收方的TCP对收到每个报文段进行确认,在其确认报文中的确认号字段的值表示其希望接收的下一个报文段的第一个数据字节的序号。

4.UDP协议

UDP是用户数据报协议(UserDatagramProtocol)的缩写,提供无连接的数据报文传输,不能保证数据完整到达目的地。

UDP数据传输不需要预先建立连接,传输过程中没有报文确认信息。

因此,UDP报文格式比TCP的报文格式简单的多。

UDP数据报也是由首部和数据两部分组成,其首部只有源端口、目的端口、消息长度和校验和四部分,各部分的意义和TCP首部对应字段的意义相同。

四、实验步骤

1、跟踪DNS

(1)

利用ipconfig命令清空主机上的DNS缓存。

启动浏览器,并将浏览器的缓存清空。

启动Wireshark,在显示过滤筛选规则编辑框处输入:

“ip.addr==your_IP_address”(如:

ip.addr==10.17.7.23)

过滤器将会删除所有目的地址和源地址与指定IP地址都不同的分组。

开始Ethereal分组捕获。

在浏览器的地址栏中输入:

http:

//www.ietf.org

停止分组捕获。

2、跟踪DNS

(2)

在www.mit.edu上进行nslookup(即执行命令:

nslookupwww.mit.edu)。

回答字段,授权字段和附加信息字段均采用资源记录RR(ResourceRecord)的相同格式。

该格式如下:

域名字段(不定长或2字节):

记录中资源数据对应的名字,它的格式和查询名字段格式相同。

当报文中域名重复出现时,就需要使用2字节的偏移指针来替换。

例如,在资源记录中,域名通常是查询问题部分的域名的重复,就需要用指针指向查询问题部分的域名。

关于指针怎么用,TCP/IP详解里面有,即2字节的指针,最签名的两个高位是11,用于识别指针。

其他14位从报文开始处计数(从0开始),指出该报文中的相应字节数。

注意,DNS报文的第一个字节是字节0,第二个报文是字节1。

一般响应报文中,资源部分的域名都是指针C00C(1100000000001100),刚好指向请求部分的域名。

类型(2字节)、类(2字节):

含义与查询问题部分的类型和类相同。

生存时间(4字节):

该字段表示资源记录的生命周期(以秒为单位),一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间。

资源数据长度(2字节):

表示资源数据的长度(以字节为单位,如果资源数据为IP则为0004)

资源数据:

该字段是可变长字段,表示按查询段要求返回的相关资源记录的数据。

二、数据包分析:

序列64是DNS查询报文,序列65是DNS响应报文。

可以看出,DNS为应用层协议,下层传输层采用UDP协议,再下层网络层采用IP协议,最后是数据链路层的以太网帧。

上面截获的报文:

DNS:

query,为查询报文

UDP报文中:

源端口50628,目的端口53

IPV4报文中:

源IP192.168.1.137,目的IP114.114.114.114

由上面截获的DNS响应报文,可以发现DNS报文结构:

说明:

并不是所有DNS报文都有以上各个部分的。

图中标示的“12字节”为DNS首部,这部分肯定都会有,首部下面的是正文部分,其中查询问题部分也都会有。

除此之外,回答、授权和额外信息部分是只出现在DNS应答报文中的,而这三部分又都采用资源记录(RecourceRecord)的相同格式

可以看出,DNS查询报文中是没有回答、授权和额外信息部分的。

TransactionID标识(2字节):

“由客户程序设置并有服务器返回结果。

”这个字段可以看作是DNS报文的ID,对于相关联的请求报文和应答报文,这个字段是相同的,由此可以区分DNS应答报文是哪个请求报文的响应。

Flags标志(2字节):

这部分非常重要,需要逐比特分析。

QR(1比特):

查询/响应的标志位,1为响应,0为查询。

opcode(4比特):

定义查询或响应的类型(若为0则表示是标准的,若为1则是反向的,若为2则是服务器状态请求)。

AA(1比特):

授权回答的标志位。

该位在响应报文中有效,1表示名字服务器是权限服务器

TC(1比特):

截断标志位。

1表示响应已超过512字节并已被截断

RD(1比特):

该位为1表示客户端希望得到递归回答

RA(1比特):

只能在响应报文中置为1,表示可以得到递归响应。

zero(3比特):

都是0,保留字段。

rcode(4比特):

返回码,表示响应的差错状态,通常为0和3,各取值含义如下:

0无差错

1格式差错

2问题在域名服务器上

3域参照问题

4查询类型不支持

5在管理上被禁止

6--15保留

问题数Questions、资源记录数AnswerRRs、授权资源记录数AuthorityRRs和额外资源记录数AdditionalRRs,这四个字段都是2字节,分别对应下面的查询问题、回答、授权和额外信息部分的数量。

一般问题数都为1,DNS查询报文中,资源记录数、授权资源记录数和额外资源记录数都为0.

查询问题部分格式如下:

查询名Name部分长度不定,一般为要查询的域名(也会有IP的时候,即反向查询)。

此部分由一个或者多个标示符序列组成,每个标示符以首字节数的计数值来说明该标示符长度,每个名字以0结束。

计数字节数必须是0~63之间。

该字段无需填充字节。

举个例子来说明更直观些,查询名为gemini.tuc.noao.edu的话,查询名字段如下:

查询类型Type(2字节):

通常查询类型为A(由名字获得IP地址)或者PTR(获得IP地址对应的域名),类型列表如下:

类型助记符说明

1AIPv4地址。

2NS名字服务器。

5CNAME规范名称。

定义主机的正式名字的别名。

6SOA开始授权。

标记一个区的开始。

11WKS熟知服务。

定义主机提供的网络服务。

12PTR指针。

把IP地址转化为域名。

13HINFO主机信息。

给出主机使用的硬件和操作系统的表述。

15MX邮件交换。

把邮件改变路由送到邮件服务器。

28AAAAIPv6地址。

252AXFR传送整个区的请求。

255ANY对所有记录的请求。

查询类Class(2字节):

通常为1,指Internet数据。

二、DNS查询报文分析

TransactionID标识符:

0x21be

QR查询/响应:

0,为查询报文

Opcode查询/响应类型:

0000,正向解析

Truntaced截断:

0,没有发生截断

RD期望递归:

1表示引导名称服务器做递归查询

Z:

保留将来使用,必须为0

Recode:

0表示没有错误

计数器:

questions:

1

其他:

问题部分:

Name:

www.mit.edu

长度:

11字节

标签计数:

3

Type:

A主机地址

Class:

IN查询类,两个八位位组代码,指定查询的类。

展开UDP数据(传输层)

UDP结构:

IP报文

源IP地址

8.8.8.8

协议

UDP

目的IP地址

125.216.218.49

总长度

210

报文

字段名

字段长度

字段值

字段表达信息

Sourceport

2bytes

53(53)

Destinationport

56585(56585)

呼叫端端口号

Length

被叫端端口号

Checksum

0x1234

报文头部的字节数

IP协议(网络层)格式:

IP报文分析:

字段

报文信息

说明

版本

4

头长

20bytes

服务类型

Ox00

Dscpox00:

Default;

ECN:

ox00

471

标识

Ox36e7

14055

标志

片偏移

生存周期

43

17

校验和

Ox1a41

Validationdisabled

源地址

114.114.114.114

目的地址

展开Ehernet数据(接口层):

源地址:

HonHaiPr_9b:

32:

59(16进制)

目的地址:

D-LinkIn_aa:

46:

80(16进制)

封装上层协议类型:

IP(0x0800)

展开物理层数据(物理层第0层):

捕获日期:

2015.06.21,21:

57:

57

时间戳:

1434895077.903509000seconds

此帧与捕获的前一帧的时间间隔:

0.001838000seconds

此帧已所显示的前一帧的时间间隔:

此帧与第一帧的时间间隔:

7.740058000seconds

帧序列号:

64

帧长度:

71bytes

捕获长度:

71bytes

染色标记的规则名称:

染色显示规则的字符串:

udp

二、DNS应答报文

展开DNS数据(应用层)

首部部分

时间:

0.004424000

标识符:

0xc3b3

标志和代码:

QR查询/应答标志:

1表示为应答报文

Opcode操作码:

0000表示正向解析

AA权威性标志:

1表示给出应答的服务器是权威服务器

TC阶段日志:

0没有超过512,不允许被截断

RD期望递归:

1引导名称服务器递归跟踪查询

RA递归可用:

1支持递归查询

Z:

保留将来使用必须置0

查询数:

指定应答部分中资源记录:

指定权威记录部分中名称服务器资源记录:

8

附加记录:

www.mit.edu

11

字节:

13bytes

标签计数:

IN查询类,两个八位位组代码,指定查询的类

应答部分:

名称:

类型:

CNAME

类:

IN查询类

生存时间:

3600

数据长度:

25

客户端名称:

源端口:

为53

目的端口:

51012;

422;

校验和:

0x281c

IP协议(网络层)分析

Version版本:

Headlength首部长度:

Typeofserves服务类型:

差分服务differentiated

Total总长度:

442

标识:

0x243b(9275)

标志:

0x00

分片偏移:

0

生岑时间:

42

协议类型:

udp(17)

首部校验和:

0xc3e2

原地址:

192.168.1.137

IP软件在存储器中维持一个计数器,每产生一个数据报,计数器就加1,并将此值赋给标识字段。

但这个“标识”并不是序号,因为IP是无连接的服务,数据报不存在按序接收的问题。

当数据报由于长度超过网络的MTU而必须分片时,这个标识字段的值就被复制到所有的数据报的标识字段中。

相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。

展开Ehernet数据(接口层)

展开物理层数据(第0层)

58

1434895078.269567000seconds

0.004424000seconds

8.106116000seconds

85

456bytes

五、总结

DNS服务器可以说是方便了我们的网络生活,访问网页时,我们不用回去记忆那些复杂的IP地址,而是那些已经转换好的方便记忆的网址,这样加快了我们队网络的操作,方便我们记忆浏览网页,而且,随着网络的发展和普及,我们越是离不开网络,DNS对我们就越是重要,没有DNS,大部分人可能就会变成网络中的睁眼瞎,可能连最基本的网页都打不开,更别说获取及时的信息了。

所以以后的网络生活我们会越来越依赖于DNS,他就是我们与网络沟通的翻译官。

经过一周的期末课程设计,让我对TCP/IP有了更加深入的认识,了解到了一个网络的工作机制,尤其是数据是如何在TCP结构中的传输模式,由上到下,逐级封装让后进行传输,让我明白到,学习TCP/IP,并不是学好某一个特定的协议就可以了,而是要掌握每一层的协议才行。

而我们选的设计题目是DNS服务器,这就让我队DNS有了更深的了解,在我们想浏览一个网页时,打开网址,这时我们会想DNS发送请求命令,DNS服务器接到请求后,通过验证会将网址转化为IP地址,在调用具体的信息让后对我们进行回应,这样我们才会看到我们想要浏览的网页。

这次实验我们是以小组模式进行,其中我们也遇到了一些问题,构建局域网,搭建DNS服务器,都是十分麻烦,老是链接不通、或是没有权限,这时需要耐性,这让我了解到,在网络工程这个专业中,耐心和细心的重要性。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 党团工作 > 入党转正申请

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2