DNSintroduce.docx

DNSintroduce.docx

《DNSintroduce.docx》由会员分享，可在线阅读，更多相关《DNSintroduce.docx（12页珍藏版）》请在冰豆网上搜索。

DNSintroduce

DNS原理介绍

Angela

1.DNS是什么？

DNS是域名系统（DomainNameSystem）的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务。

在Internet上域名与IP地址之间是一一对应的，域名虽然便于人们记忆，但机器之间只能互相认识IP地址，它们之间的转换工作称为域名解析。

DNS命名用于Internet等TCP/IP网络中，通过用户友好的名称查找计算机和服务。

当用户在应用程序中输入DNS名称时，DNS服务可以将此名称解析为与之相关的其他信息，如IP地址。

其实，域名的最终指向是IP。

图1顶级域名的分类

顶级域名TLD（TopLevelDomain）被分为三个部分：

1）arpa是一个用作地址到名字转换的特殊域。

2）7个3字符长的普通域，也有叫通用域、组织域。

域名

描述

edu

教育学术单位

org

组织机构

net

网路通讯单位

com

公司企业

gov

政府机关

mil

军事单位

int

国际组织

从2000年11月起，ICANN又新增加了七个普通域：

.aero用于航空运输企业，.biz用于公司和企业，.coop用于合作团体，.info适用于各种情况，.museum用于博物馆，.name用于个人，.pro用于会计、律师和医师等自由职业者。

3）所有2字符长的域均是基于ISO3166中定义的国家代码，这些域被称为国家域，或地理域。

现在在使用的国家域约有200个左右。

2.DNS在哪里？

提供DNS的是计算机，是安装了DNS服务器端软件的计算机。

服务器端软件即可以是基于类Unix操作系统，也可以是基于Windows操作系统的。

装好DNS服务器软件后，就可以在您指定的位置创建区域文件了，所谓区域文件就是包含了此域中名字到IP地址解析记录的一个文件。

2.1资源记录

针对任何一个有效的域名，都应该有一个该域名的权威域名服务器（DNS），在域名服务器中有一条或多条针对于该域名的资源记录。

一条资源记录共有5项，分别是域名（Domain_name）、生存时间（Time_to_live）、类别（Class）、类型（Type）和值（Value）：

{name}  {TTL}  addr-class  record-type  record-specific-data

如：

86400INMX1

name

      是这条记录指向的域记录的名字

      通常只有第一个DNS资源记录配置name栏

      对于区域文档中其他的资源记录，name也可能是空白，这种情况下，其他的资源记录接受先前的资源记录的名字

TTL

      Live栏可选择的时间，指出记录的稳定性

      他指定该数据在数据库中保管多长时间，高度稳定的信息被赋予一个很大的值，如86400（一天的秒数），变化很大的信息被赋予一个较小的值，如60（1分钟）

      此栏为空表示默认的生存周期在授权资源记录开始中指定

addr-class

      地址类

      大范围用于Internet地址和其他信息的地址类为IN

record-type

      记录类型，常为A  CNAMEMX  PTRSOANS        

A（Adress）记录

    A记录代表"主机名称"和"IP"地址的对应关系，作用是把名称转换成IP地址。

完整的主机名后应有一个点“. ” 。

每个主机至少应有一个A记录。

主机名必須使用A记录转译成IP地址，网络层才知道如何选择路由，并将数据包送到目的地

.           IN  A  192.168.100.50

www             IN  A  192.168.100.50

IN  A  192.168.100.10

.    IN  A  192.168.100.200

.       IN  A  192.168.100.5

.    IN  A  192.168.100.6

.    IN  A  192.168.100.50

.    IN  A  192.168.100.123

CNAME（CanonicalName）记录

    某些名称并没有对应的IP地址，而只是个主机名的别名。

 CNAME记录代表别名和规范主机名称（canonicalname）之间的对应关系。

如管理员可能公告他们网站的主机名称为，但其实只是个指向的CNAME记录而已。

而在维护期间，能够临时将指向。

在有CNAMERR时，DNS软件如果查询不到与域名相关的资源，它会检查资源集中是不是有一个有匹配class的CNAME，如果有，名字服务器返回的应答中包括这个CNAME记录，并根据在CNAME中指定的数据开始新的查询。

.  IN  CNAME  .

.  IN  CNAME  .

MX（MailExchange）记录

    MX记录提供邮件路由信息。

提供网域的"邮件交换器"的主机名称连同相对应的优先值。

当MTA要将邮件送到某个网域时，会优先将邮件交给该网域的MX主机。

同一个网域可能有多个邮件交换器，所以每一个MX记录都有一个优先值，供MTA作为选择MX主机的依据

IN  MX  0  .

IN  MX  10  .

IN  MX  20  .

IN  MX  30  .

PTR（Point）记录

    PTR记录代表"IP地址"和"主机名"的对应关系，作用刚好和A记录相反。

DNS系统使用PTR记录来回答"某IP地址所对应的主机名是什么?

"。

RFC882构想，A记录和PTR记录应是互逆的，即：

从A记录能够查到域名到IP，从PTR能够查到从IP到域名。

 但当多个域名对应同一个IP时，PTR记录应指向该IP地址的规范主机名。

 某些网络使用PTR记录来检验客户端的主机名称是否可信

192.168.100.50  IN  PTR  .

SOA（startofauthority）授权的开始

该记录表明DNS名称服务器是DNS域中的数据表的信息来源,该服务器是主机名字的管理者,创建新区域时,该资源记录被自动创建,而是DNS数据库文件中的第一条记录.

每个区域必须只有一个SOA记录。

辅名字服务器在不能和主服务器通信的情况下，将提供12小时DNS服务，在指定的时间后停止为那个区域提供DNS服务;但是经仍要尝试和主服务器通信。

＠  IN  SOA  nameserver.    contact-email-address.//@是名字，并且总是被配置为@，在同一文档中别的资源记录不能重复。

指定当前域名主服务器的主机名和管理员的email

            serial_number;  //当前序列号。

这个序列号的作用是当辅域名服务器来copy这个文件时，如果号码增加了就copy。

            refresh_number;  //以秒为单位,从名字服务器和主名字服务器查询比较才决定是否要更新。

            retry_number;    //以秒为单位,由于外部原因，  从服务器重新传输一个失败的区域前要等多长时间。

            expire_number;  //以秒为单位,是从名字服务器使用区域数据有效期的上限值。

            minimum_number;//以秒为单位,是指在区域文档中没有指定生存期的资源记录上生存期TTL的限制，假如在一些区域的资源记录上有TTL值，则这里的minimum_number也是最低限度。

TTL时间只影响缓冲内的数据，不影响区内的已经保存的认证数据。

TTL通常由管理员设置，TTL=0表示禁止缓冲。

eg：

＠  IN  SOA  .  .  //（在SOA记录中邮件的＠被换成.）

        1049310513    ;serial

        10800          ;refresh

        3600          ;retry

        604800        ;expire

        900            ;ttl      

NS（Nameserver）

    名字服务器，用来为域指定名字服务器。

注意：

没有指定name和TTL，因为名字仅需要使用@字符在SOA记录中指定;  TTL使用SOA记录中的minimum； 能够指定多个NS记录

.    IN  NS  .

　　其中最常见的记录是A记录，通过A记录来解析该域名的主页所存放的服务器。

除了A记录以外，如果还有以该域名为邮件地址的邮件服务，则必须有MX记录，通过MX记录来解析该域名的邮件服务器。

record-specific-data

      记录类型的数据

2.2分布式数据库：

区域文件和委派关系

域名系统（DNS）是一种用于TCP/IP应用程序的分布式数据库。

一个DNS数据库能被分为多个区域，一个“区域”是包含有与临近的名字空间的域名等资源纪录的DNS数据库的一部分。

区域文件存储在DNS服务器上，一个单独的DNS服务器能被配置成零区域、一个区域或多个区域。

每一个区域都有一个指定的域名作为这个区域的根域名。

区域里包含所有以根域名结尾的域名信息.如果一个DNS服务器有包含相应域名的区域，就由他来解析。

SOA（授权的开始）资源记录表明DNS名称服务器是DNS域中的数据的最好信息来源。

它是每个DNS数据库文件中的第一条记录。

在创建新的DNS区域时，“DNS管理器”将自动创建SOA资源记录。

一个域里的名字可以委派给其他的域，委派是将DNS名字空间的一部分的解析指定为其他不相干的项目。

其他不相干的实体可以是公司里的其他组织、部门或工作组，委派是由NS纪录来表示的，纪录中有委派的区域和那个区域的授权服务器的DNS名称。

其实，跨区域委派是设计DNS的初衷之一。

下面是DNS名字空间为什么要有委派关系的几个主要原因:

1）可以把对DNS域的管理委派给组织里的下级组织或部门。

2）可以把一个巨大的DNS数据库的负债分布在多个名字服务器上，来提高名字解析的性能，同时创造了一个DNS的容错环境。

3）通过把服务器放在相应的区域里，可以实现服务器的组织从属关系NS纪录通过为每个区域指定DNS服务器来实现委派，它们出现在所有转向和反向查询域中。

每个域都有一个序列号，当主服务器上的域数据更新时，就要调整这个序列号。

这种调整使得在服务器上检测到数据更新变得很容易。

而能够同时拥有一个以上域备份的能力可以冗余分配负载，使数据非常可靠。

　　在下图中，.域的管理被委派给两个域，.和.

图2域的管理委派

3、DNS怎么查

　　DNS分为Client和Server，Client扮演发问的角色，也就是问Server一个DomainName，而Server必须要回答此DomainName的真正IP地址。

而当地的DNS先会查自己的资料库。

如果自己的资料库没有，则会往该DNS上所设的的DNS询问，依此得到答案之后，将收到的答案存起来，并回答客户。

　　DNS服务器会根据不同的授权区（Zone），记录所属该网域下的各名称资料，这个资料包括网域下的次网域名称及主机名称。

　　在每一个名称服务器中都有一个快取缓存区（Cache），这个快取缓存区的主要目的是将该名称服务器所查询出来的名称及相对的IP地址记录快取缓存区中，这样当下一次还有另外一个客户端到次服务器上去查询相同的名称时，服务器就不用在到别台主机上去寻找，而直接可以从缓存区中找到该笔名称记录资料，传回给客户端，加速客户端对名称查询的速度。

例如当DNS客户端向指定的DNS服务器查询网际网路上的某一台主机名称DNS服务器会在该资料库中找寻用户所指定的名称如果没有，该服务器会先在自己的快取缓存区中查询有无该笔纪录，如果找到该笔名称记录后，会从DNS服务器直接将所对应到的IP地址传回给客户端，如果名称服务器在资料记录查不到且快取缓存区中也没有时，服务器首先会才会向别的名称服务器查询所要的名称。

3.1两种DNS的查询模式

DNS的查询模式分为Recursive和Interactive两种。

即在客户端查询的请求里面包含的“搜索类型”（Searchtype）的选择项。

前者是由DNS代理去问，问的方法是用Interactive方式，后者是由本机直接做Interactive式的询问。

由上例可以看出，我们一般查询名称的过程中，实际上这两种查询模式都是交互存在着的。

　　递归式（Recursive）：

DNS客户端向DNSServer的查询模式，这种方式是将要查询的封包送出去问，就等待正确名称的正确响应，这种方式只处理响应回来的封包是否是正确响应或是说是找不到该名称的错误讯息。

　　交谈式（Interactive）：

DNSServer间的查询模式，由Client端或是DNSServer上所发出去问，这种方式送封包出去问，所响应回来的资料不一定是最后正确的名称位置，但也不是如上所说的响应回来是错误讯息，他响应回来告诉你最接近的IP位置，然后再到此最接近的IP上去寻找所要解析的名称，反复动作直到找到正确位置。

客户端查询的默认情况是递归查询。

当DNS服务器被客户端要求递归查询而去查询其他DNS服务器时，默认是迭代查询的。

图3DNS的查询模式

3.2UDP还是TCP

客户端的查询使用的是UDP协议和端口53。

响应通过UDP返回，除非他们大于512K，这种情况使用TCP。

服务器之间的“区传送”则都使用TCP。

注意到DNS名字服务器使用的熟知端口号无论对UDP还是TCP都是53。

当名字解析器发出一个查询请求，并且返回响应中的TC（删减标志）比特被设置为1时，它就意味着响应的长度超过了512个字节，而仅返回前512个字节。

在遇到这种情况时，名字解析器通常使用TCP重发原来的查询请求，它将允许返回的响应超过512个字节。

既然TCP能将用户的数据流分为一些报文段，它就能用多个报文段来传送任意长度的用户数据。

此外，当一个域的辅助名字服务器在启动时，将从该域的主名字服务器执行区域传送。

我们也说过辅助服务器将定时（通常是3小时）向主服务器进行查询以便了解主服务器数据是否发生变动。

如果有变动，将执行一次区域传送。

区域传送将使用TCP，因为这里传送的数据远比一个查询或响应多得多。

3.3报文格式

图4IP报文的格式

DNS定义了一个用于查询和响应的报文格式。

这个报文由12字节长的首部和4个长度可变的字段组成。

图5显示这个报文的总体格式。

图5DNS报文的格式

标识字段由客户程序设置并由服务器返回结果。

客户程序通过它来确定响应与查询是否匹配。

16bit的标志字段被划分为若干子字段，如图6所示。

图6DNS查询报文中的标志字段

我们从最左位开始依次介绍各子字段：

1）QR是1bit字段：

0表示查询报文，1表示响应报文。

2）opcode是一个4bit字段：

通常值为0（标准查询），其他值为1（反向查询）和2（服务器状态请求）。

3）AA是1bit标志，表示“授权回答（authoritativeanswer）”。

该名字服务器是授权于该域的。

4）TC是1bit字段，表示“可截断的（truncated）”。

使用UDP时，它表示当应答的总长度超过512字节时，只返回前512个字节。

5）RD是1bit字段表示“期望递归（recursiondesired）”。

该比特能在一个查询中设置，并在响应中返回。

这个标志告诉名字服务器必须处理这个查询，也称为一个递归查询。

如果该位为0，且被请求的名字服务器没有一个授权回答，它就返回一个能解答该查询的其他名字服务器列表，这称为迭代查询。

6）RA是1bit字段，表示“可用递归”。

如果名字服务器支持递归查询，则在响应中将该比特设置为1。

大多数名字服务器都提供递归查询，除了某些根服务器。

7）随后的3bit字段必须为0。

8）rcode是一个4bit的返回码字段。

通常的值为0（没有差错）和3（名字差错）。

名字差错只有从一个授权名字服务器上返回，它表示在查询中制定的域名不存在。

随后的4个16bit字段说明最后4个变长字段中包含的条目数。

对于查询报文，问题（question）数通常是1，而其他3项则均为0。

类似地，对于应答报文，回答数至少是1，剩下的两项可以是0或非0。

3.3.1DNS查询报文中的问题部分

问题部分中每个问题的格式如图7所示，通常只有一个问题。

图7DNS查询报文中的问题部分格式

查询名是要查找的名字，它是一个或多个标识符的序列。

每个标识符以首字节的计数值来说明随后标识符的字节长度，每个名字以最后字节为0结束，长度为0的标识符是根标识符。

计数字节的值必须是0~63的数，因为标识符的最大长度仅为63（在后面我们将看到计数字节的最高两比特为1，即值192~255，将用于压缩格式）。

不像我们已经看到的许多其他报文格式，该字段无需以整32bit边界结束，即无需填充字节。

图8显示了如何存储域名gemini.tuc.noao.edu。

图8DNS查询报文中域名的存储

每个问题有一个查询类型，而每个响应（也称一个资源记录）也有一个类型。

大约有20个不同的类型值，其中的一些目前已经过时，常用的如前介绍。

图9显示了其中的一些值。

查询类型是类型的一个超集（superset）：

图中显示的类型值中有两个只能用于查询类型。

图9查询类型与类型

查询类通常是1，指互联网地址（某些站点也支持其他非IP地址）。

3.3.2DNS响应报文中的资源记录部分

DNS报文中最后的三个字段，回答字段、授权字段和附加信息字段，均采用一种称为资源记录RR（ResourceRecord）的相同格式。

图10显示了资源记录的格式。

图10DNS查询报文中资源记录的格式

域名是记录中资源数据对应的名字。

它的格式和前面介绍的查询名字段格式（图8）相同。

类型说明RR的类型码。

它的值和前面介绍的查询类型值是一样的。

类通常为1，指Internet数据。

生存时间字段是客户程序保留该资源记录的秒数。

资源记录通常的生存时间值为2天。

资源数据长度说明资源数据的数量。

该数据的格式依赖于类型字段的值。

对于类型1（A记录）资源数据是4字节的IP地址。

3.4Windows下DNSID欺骗的原理

我们可以看到，在DNS数据报头部的id（标识）是用来匹配响应和请求数据报的。

现在，让我们来看看域名解析的整个过程。

客户端首先以特定的标识向DNS服务器发送域名查询数据报，在DNS服务器查询之后以相同的ID号给客户端发送域名响应数据报。

这时客户端会将收到的DNS响应数据报的ID和自己发送的查询数据报ID相比较，如果匹配则表明接收到的正是自己等待的数据报，如果不匹配则丢弃之。

假如能够伪装DNS服务器提前向客户端发送响应数据报，那么客户端的DNS缓存里域名所对应的IP就是自定义的IP了，同时客户端也就被带到了所希望的网站。

条件只有一个，那就是发送的ID匹配的DSN响应数据报在DNS服务器发送的响应数据报之前到达客户端。

那么如何才能实现呢？

这要分两种情况：

1）本地主机与DNS服务器，本地主机与客户端主机均不在同一个局域网内,方法有以下几种：

向客户端主机随机发送大量DNS响应数据报，命中率很低；向DNS服务器发起拒绝服务攻击，太粗鲁；BIND漏洞，使用范围比较窄。

2）本地主机至少与DNS服务器或客户端主机中的某一台处在同一个局域网内：

我们可以通过ARP欺骗来实现可靠而稳定的DNSID欺骗。

首先我们进行DNSID欺骗的基础是ARP欺骗，也就是在局域网内同时欺骗网关和客户端主机（也可能是欺骗网关和DNS服务器，或欺骗DNS服务器和客户端主机）。

我们以客户端的名义向网关发送ARP响应数据报，不过其中将源MAC地址改为我们自己主机的MAC地址；同时以网关的名义向客户端主机发送ARP响应数据报，同样将源MAC地址改为我们自己主机的MAC地址。

这样以来，网关看来客户端的MAC地址就是我们主机的MAC地址；客户端也认为网关的MAC地址为我们主机的MAC地址。

由于在局域网内数据报的传送是建立在MAC地址之上了，所以网关和客户端之间的数据流通必须先通过本地主机。

在监视网关和客户端主机之间的数据报时，如果发现了客户端发送的DNS查询数据报（目的端口为53），那么我们可以提前将自己构造的DNS响应数据报发送到客户端。

注意，必须提取有客户端发送来的DNS查询数据报的ID信息，因为客户端是通过它来进行匹配认证的，这就是一个可以利用的DNS漏洞。

这样客户端会先收到我们发送的DNS响应数据报并访问我们自定义的网站，虽然客户端也会收到DNS服务器的响应报文，不过已经来不及了。