【转载】DNS查询报文和应答报文抓包分析

  • A+
所属分类:lcx

    这个学期开始上计算机网络课,第一份与协议有关的作业就是DNS报文分析,那就分别抓一个DNS查询报文和应答报文看一下吧。

    我使用的抓包软件是科来网络分析系统2010技术交流版,可以从http://www.colasoft.com.cn/download/capsatech.exe免费下载,只需在线填写几项信息过几分钟就可以收到科来发送过来的序列号了,只用了一会但是感觉很不错,推荐一下。

    首先在科来里面新建一个工程,只需要DNS报文,然后打开浏览器,输入http://www.chd.edu.cn/,回车就可以在科来里面看到捕获的数据了,捕获到的DNS查询报文为82个字节,前50个字节是目标MAC地址、源MAC地址、IP和UDP之类的东西,不理会它们,从第51个字节开始看。

    科来网络分析系统给出了一份自动分析报告,很详细,但是现在是手工分析,就不看它了。

    第51-82字节的内容如下 :

21 FE 01 00 00 01 00 00 00 00 00 00 03 77 77 77 03 63 68 64 03 65 64 75 02 63 6E 00 00 01 00 01

    开始时根据习惯按小端法分析,但是从科来的分析结果可以看到网络上传输的数据是按大端法传输的,与Intel架构下的二进制分析不一样,这点在分析时要注意。

    先来看一下DNS报文的格式:

    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | the question for the name server
    +---------------------+
    |        Answer       | RRs answering the question
    +---------------------+
    |      Authority      | RRs pointing toward an authority
    +---------------------+
    |      Additional     | RRs holding additional information
    +---------------------+

Header的格式如下:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    先来看Header,每一位的作用就不贴在这里了,可以对照着http://www.rfc-editor.org/rfc/rfc1035.txt的第四小节MESSAGES看(下面也是这样)。

    分析结果如下:

    前两个字节是标识,为0x21FE,此标识为发出请求的客户端随意设置的,这个查询报文对应的应答报文也带有相同的标识,这样客户端就可以区分不同的请求的应答而不会搞混了。

    然后是两个字节为报文参数,为0x0100,分解为二进制是0000 0001 0000 0000b,代表的含义如下表:

参数名

QR

操作码

AA

TC

RD

RA

保留

Recode

0

0000

0

0

1

0

000

0000

含义

查询

标准查询

见下面描述

报文未截断

期望递归解析

见下面描述

保留

没有出错

    起初看不懂课本上对AA位的描述,在网上搜了一下发现这一位在DNS应答报文中才有意义,代表给出应答的DNS服务器是不是被查询域名的授权解析服务器(权威服务器)。

    RA位也是在应答报文中才有意义,以说明做出应答的DNS服务器是否支持递归解析。

    后面的两个字节是问题数,为0x0001,即只要求解析一个域名。

    后面的六个字节分别是应答数、授权机构数和附加信息数,这个报文是查询报文,全部为0x0000。

    然后是问题部分,格式如下:


                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QCLASS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    开始由多组4个字节构成,值为03 77 77 77 03 63 68 64 03 65 64 75 02 63 6E 00,即“www.chd.edu.cn”,根据ASCII码表可知,“www”、“chd”、“edu”、“cn”的ASCII编码是正确的,但是开头却添加了一个字节的0x03,而且前两个“.”的编码是0x03,最后一个“.”的编码是0x02,不明白这样做是为什么,因为“.”的ASCII码是0x2E。后来经过多次对不同域名的DNS查询报文抓包比较发现,原来这根本不是ASCII码,这个值指的是与下一个点之间有几个ASCII码,例如hi.baidu.com就应该编码成02 68 69 05 62 61 69 64 75 03 63 6F 6D 00,把RFC-1035中的解释放在下面,“a domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root.  Note that this field may be an odd number of octets; no padding is used.”。

    然后的两个字节是查询类型,值为0x0001,即将要求域名转换为IPv4地址。

    最后的两个字节是查询类,值为0x0001,即查询的是因特网的域名。

    至此,DNS查询报文的所有域已经手工分析完毕。

    捕获到的对应的DNS应答报文如下(去掉了前50个字节):

21 FE 81 80 00 01 00 01 00 02 00 02 03 77 77 77 03 63 68 64 03 65 64 75 02 63 6E 00 00 01 00 01 C0 0C 00 01 00 01 00 00 17 63 00 04 CA 75 40 02 C0 10 00 02 00 01 00 00 FD F5 00 07 04 44 4E 53 31 C0 10 C0 10 00 02 00 01 00 00 FD F5 00 07 04 44 4E 53 32 C0 10 C0 3C 00 01 00 01 00 01 40 6E 00 04 CA 75 40 01 C0 4F 00 01 00 01 00 01 41 8A 00 04 DA C3 38 01

    标识字段也是0x21FE,跟查询报文一样,说明是对上面那个查询报文的应答,这样就不会搞混了。

    参数字段为0x8180,分解成二进制为1000 0001 1000 0000,含义如下表

参数名

QR

操作码

AA

TC

RD

RA

保留

Recode

1

0000

0

0

1

1

000

0000

含义

应答

见下面描述

不是权威服务器应答

报文未截断

期望递归解析

服务器支持递归解析

保留

没有出错

      操作码和RD在应答报文中没有意义,设置成跟查询报文一样的值就可以了。

      问题数为0x0001,跟查询报文一样。

      应答数为0x0001,即有一个应答。

      管理机构数为0x0002,即有两台权威服务器对查询报文做出应答,后面的权威机构部分可以看到这两台服务器。

      附加信息数为0x0002,即有两条附加信息,也就是管理机构服务器给出的应答结果。

      问题部分同查询报文,不再分析。

      答案部分和后面的权威机构、附加信息部分都是资源记录格式(Resource Records),格式与问题部分不一样,格式如下:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    前四个字节是域名的副本,但是经过报文压缩就变成了两个字节的指针偏移,在这里值为0xC00C。由于标号的长度被限制不能超过63个字节,所以前两位一定是00b,指针就设置为11b以区别,这个指针的偏移就是0x000C,从应答报文的标识开始数(第一个字节偏移是0x0000),第0x000C字节就是www.chd.edu.cn开头的0x03。

    域类型和域类都是0x0001,与查询报文一样。

    生存时间为0x00001763,即5987秒,很奇怪的数字,不知是根据什么设置的。

    资源数据长度为0x0004。

    资源数据为0xCA754002,转换成十进制的IP地址就是202.117.64.2,也就是www.chd.edu.cn这个域名对应的IPv4地址。

    再后面就是两个资源记录,分别对应报文头部提到的两个权威服务器,分别是DNS1.chd.edu.cn和DNS2.chd.edu.cn,与前面的答案部分不一样的部分只有域类型为0x0002,说明这两台服务器是所查询域名的授权解析服务器(权威服务器)。

    再后面是两个附加答案,即两台权威服务器给出的应答结果,DNS1.chd.edu.cn给出的IPv4地址是0xCA754001,即202.117.64.1;DNS2.chd.edu.cn给出的IPv4地址是0xDAC33801,即202.195.56.1。使用ping工具可以知道这两个地址并不是http://www.chd.edu.cn/的地址,而是两台DNS解析服务器的地址。

    OK,到这里两个DNS Messages就已经全部分析完毕了。

文章来源于lcx.cc:【转载】DNS查询报文和应答报文抓包分析

相关推荐: PHP源码中unserialize函数引发的漏洞分析

0x01 unserialize函数的概念 首先看下官方给出的解释:unserialize() 对单一的已序列化的变量进行操作,将其转换回 PHP 的值。返回的是转换之后的值,可为 integer、float、string、array 或 object。如果传…

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: