From：http://blog.csdn.net/yipiankongbai/article/details/25031461

一、域名系统

1、域名系统概述

        域名系统DNS(Domain Name System)是因特网使用的命名系统，用来把便于人们使用的机器名字转换成为IP地址。域名系统其实就是名字系统。为什么不叫“名字”而叫“域名”呢？这是因为在这种因特网的命名系统中使用了许多的“域(domain)”，因此就出现了“域名”这个名词。“域名系统”明确地指明这种系统是应用在因特网中。

        我们都知道，IP地址是由32位的二进制数字组成的。用户与因特网上某台主机通信时，显然不愿意使用很难记忆的长达32位的二进制主机地址。即使是点分十进制IP地址也并不太容易记忆。相反，大家愿意使用比较容易记忆的主机名字。但是，机器在处理IP数据报时，并不是使用域名而是使用IP地址。这是因为IP地址长度固定，而域名的长度不固定，机器处理起来比较困难。

        因为因特网规模很大，所以整个因特网只使用一个域名服务器是不可行的。因此，早在1983年因特网开始采用层次树状结构的命名方法，并使用分布式的域名系统DNS。并采用客户服务器方式。DNS使大多数名字都在本地解析(resolve)，仅有少量解析需要在因特网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机除了故障，也不会妨碍整个DNS系统的正常运行。

        域名到IP地址的解析是由分布在因特网上的许多域名服务器程序共同完成的。域名服务器程序在专设的结点上运行，而人们也常把运行域名服务器程序的机器称为域名服务器。

        域名到IP地址的解析过程的要点如下：当某一个应用需要把主机名解析为IP地址时，该应用进程就调用解析程序，并称为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器。本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用程序获得目的主机的IP地址后即可进行通信。

        若本地域名服务器不能回答该请求，则此域名服务器就暂时称为DNS的另一个客户，并向其他域名服务器发出查询请求。这种过程直至找到能够回答该请求的域名服务器为止。此过程在后面作进一步讨论。

2、因特网的域名结构

        由于因特网的用户数量较多，所以因特网在命名时采用的是层次树状结构的命名方法。任何一个连接在因特网上的主机或路由器，都有一个唯一的层次结构的名字，即域名(domain name)。这里，“域”(domain)是名字空间中一个可被管理的划分。

        从语法上讲，每一个域名都是有标号(label)序列组成，而各标号之间用点(小数点)隔开。

        如下例子所示：

        这是中央电视台用于手法电子邮件的计算机的域名，它由三个标号组成，其中标号com是顶级域名，标号cctv是二级域名，标号mail是三级域名。

        DNS规定，域名中的标号都有英文和数字组成，每一个标号不超过63个字符(为了记忆方便，一般不会超过12个字符)，也不区分大小写字母。标号中除连字符(-)外不能使用其他的标点符号。级别最低的域名写在最左边，而级别最高的字符写在最右边。由多个标号组成的完整域名总共不超过255个字符。DNS既不规定一个域名需要包含多少个下级域名，也不规定每一级域名代表什么意思。各级域名由其上一级的域名管理机构管理，而最高的顶级域名则由ICANN进行管理。用这种方法可使每一个域名在整个互联网范围内是唯一的，并且也容易设计出一种查找域名的机制。

        域名只是逻辑概念，并不代表计算机所在的物理地点。据2006年12月统计，现在顶级域名TLD(Top Level Domain)已有265个，分为三大类：

        (1)国家顶级域名nTLD：采用ISO3166的规定。如：cn代表中国，us代表美国，uk代表英国，等等。国家域名又常记为ccTLD(cc表示国家代码contry-code)。

        (2)通用顶级域名gTLD：最常见的通用顶级域名有7个，即：com(公司企业)，net(网络服务机构)，org(非营利组织)，int(国际组织)，gov(美国的政府部门)，mil(美国的军事部门)。

        (3)基础结构域名(infrastructure domain)：这种顶级域名只有一个，即arpa，用于反向域名解析，因此称为反向域名。

3、域名服务器

        如果采用上述的树状结构，每一个节点都采用一个域名服务器，这样会使得域名服务器的数量太多，使域名服务器系统的运行效率降低。所以在DNS中，采用划分区的方法来解决。

        一个服务器所负责管辖(或有权限)的范围叫做区(zone)。各单位根据具体情况来划分自己管辖范围的区。但在一个区中的所有节点必须是能够连通的。每一个区设置相应的权限域名服务器，用来保存该区中的所有主机到域名IP地址的映射。总之，DNS服务器的管辖范围不是以“域”为单位，而是以“区”为单位。区是DNS服务器实际管辖的范围。区 <= 域。

        下图是区的不同划分方法的举例。假定abc公司有下属部门x和y，部门x下面有分三个分布们u,v,w，而y下面还有下属部门t。图a表示abc公司只设一个区abc.com。这是，区abc.com和域abc.com指的是同一件事。但图b表示abc公司划分为两个区：abc.com和y.abc.com。这两个区都隶属于域abc.com，都各设置了相应的权限域名服务器。不难看出，区是域的子集。

        下图是以上图b中abc公司划分的两个区为例，给出了DNS域名服务器树状结构图。这种DNS域名服务器树状结构图可以更准确地反映出DNS的分布式结构。图中的每一个域名服务器都能够部分域名到IP地址的解析。当某个DNS服务器不能进行域名到IP地址的转换时，它就会设法找因特网上别的域名服务器进行解析。

        从下图可以看出，因特网上的DNS服务器也是按照层次安排的。每一个域名服务器只对域名体系中的一部分进行管辖。根据域名服务器所起的作用，可以把域名服务器划分为下面四种不同的类型。

根域名服务器：最高层次的域名服务器，也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。不管是哪一个本地域名服务器，若要对因特网上任何一个域名进行解析，只要自己无法解析，就首先求助根域名服务器。所以根域名服务器是最重要的域名服务器。假定所有的根域名服务器都瘫痪了，那么整个DNS系统就无法工作。需要注意的是，在很多情况下，根域名服务器并不直接把待查询的域名直接解析出IP地址，而是告诉本地域名服务器下一步应当找哪一个顶级域名服务器进行查询。

顶级域名服务器：负责管理在该顶级域名服务器注册的二级域名。

权限域名服务器：负责一个“区”的域名服务器。

本地域名服务器：本地服务器不属于下图的域名服务器的层次结构，但是它对域名系统非常重要。当一个主机发出DNS查询请求时，这个查询请求报文就发送给本地域名服务器。

4、域名的解析过程

注意：

        一、主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

       二、本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。

        下图给出了这两种查询的差别

        下面举一个例子演示整个查询过程：

        假定域名为m.xyz.com的主机想知道另一个主机y.abc.com的IP地址。例如，主机m.xyz.com打算发送邮件给y.abc.com。这时就必须知道主机y.abc.com的IP地址。下面是上图a的几个查询步骤：

        1、主机m.abc.com先向本地服务器dns.xyz.com进行递归查询。

        2、本地服务器采用迭代查询。它先向一个根域名服务器查询。

        3、根域名服务器告诉本地服务器，下一次应查询的顶级域名服务器dns.com的IP地址。

        4、本地域名服务器向顶级域名服务器dns.com进行查询。

        5、顶级域名服务器dns.com告诉本地域名服务器，下一步应查询的权限服务器dns.abc.com的IP地址。

        6、本地域名服务器向权限域名服务器dns.abc.com进行查询。

        7、权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。

        8、本地域名服务器最后把查询结果告诉m.xyz.com。

        整个查询过程共用到了8个UDP报文。

        为了提高DNS查询效率，并减轻服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

        例如，在上面的查询过程中，如果在m.xyz.com的主机上不久前已经有用户查询过y.abc.com的IP地址，那么本地域名服务器就不必向根域名服务器重新查询y.abc.com的IP地址，而是直接把告诉缓存中存放的上次查询结果(即y.abc.com的IP地址)告诉用户。

        由于名字到地址的绑定并不经常改变，为保持告诉缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项(例如每个项目两天)。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。

DNS解析过程详解

From：http://blog.chinaunix.net/uid-28216282-id-3757849.html

DNS的几个基本概念：

一． 根域

就是所谓的“.”，其实我们的网址www.baidu.com在配置当中应该是www.baidu.com.（最后有一点），一般我们在浏览器里输入时会省略后面的点，而这也已经成为了习惯。

根域服务器我们知道有13台，但是这是错误的观点。

根域服务器只是具有13个IP地址，但机器数量却不是13台，因为这些IP地址借助了任播的技术，所以我们可以在全球设立这些IP的镜像站点，你访问到的这个IP并不是唯一的那台主机。

具体的镜像分布可以参考维基百科。这些主机的内容都是一样的

二． 域的划分

根域下来就是顶级域或者叫一级域，

有两种划分方式，一种互联网刚兴起时的按照行业性质划分的com.，net.等，一种是按国家划分的如cn.，jp.，等。

具体多少你可以自己去查，我们这里不关心。

每个域都会有域名服务器，也叫权威域名服务器。

Baidu.com就是一个顶级域名，而www.baidu.com却不是顶级域名，他是在baidu.com 这个域里的一叫做www的主机。

一级域之后还有二级域，三级域，只要我买了一个顶级域，并且我搭建了自己BIND服务器（或者其他软件搭建的）注册到互联网中，那么我就可以随意在前面多加几个域了（当然长度是有限制的）。

比如a.www.baidu.com，在这个网址中，www.baidu.com变成了一个二级域而不是一台主机，主机名是a。

三． 域名服务器

能提供域名解析的服务器，上面的记录类型可以是A(address)记录，NS记录（name server），MX（mail），CNAME等。

（详解参见博客：域名解析中A记录、CNAME、MX记录、NS记录的区别和联系）

A记录是什么意思呢，就是记录一个IP地址和一个主机名字，比如我这个域名服务器所在的域test.baidu.com，我们知道这是一个二级的域名，然后我在里面有一条A记录,记录了主机为a的IP，查到了就返回给你了。

如果我现在要想baidu.com这个域名服务器查询a.test.baidu.com，那么这个顶级域名服务器就会发现你请求的这个网址在test.baidu.com这个域中，我这里记录了这个二级域的域名服务器test.baidu.com的NS的IP。我返回给你这个地址你再去查主机为a的主机把。

这些域内的域名服务器都称为权威服务器，直接提供DNS查询服务。（这些服务器可不会做递归哦）

四．解析过程

那么我们的DNS是怎么解析一个域名的呢？

1.现在我有一台计算机，通过ISP接入了互联网，那么ISP就会给我分配一个DNS服务器，这个DNS服务器不是权威服务器，而是相当于一个代理的dns解析服务器，他会帮你迭代权威服务器返回的应答，然后把最终查到IP返回给你。

2.现在的我计算机要向这台ISPDNS发起请求查询www.baidu.com这个域名了，(经网友提醒：这里其实准确来说不是ISPDNS，而应该是用户自己电脑网络设置里的DNS，并不一定是ISPDNS。比如也有可能你手工设置了8.8.8.8)

3.ISPDNS拿到请求后，先检查一下自己的缓存中有没有这个地址，有的话就直接返回。这个时候拿到的ip地址，会被标记为非权威服务器的应答。

4.如果缓存中没有的话，ISPDNS会从配置文件里面读取13个根域名服务器的地址（这些地址是不变的，直接在BIND的配置文件中），

5.然后像其中一台发起请求。

6.根服务器拿到这个请求后，知道他是com.这个顶级域名下的，所以就会返回com域中的NS记录，一般来说是13台主机名和IP。

7.然后ISPDNS向其中一台再次发起请求，com域的服务器发现你这请求是baidu.com这个域的，我一查发现了这个域的NS，那我就返回给你，你再去查。

（目前百度有4台baidu.com的顶级域名服务器）。

8.ISPDNS不厌其烦的再次向baidu.com这个域的权威服务器发起请求，baidu.com收到之后，查了下有www的这台主机，就把这个IP返回给你了，

9.然后ISPDNS拿到了之后，将其返回给了客户端，并且把这个保存在高速缓存中。

下面我们来用 nslookup 这个工具详细来说一下解析步骤：

从上图我们可以看到:

          第一行Server是：DNS服务器的主机名--210.32.32.1

          第二行Address是： 它的IP地址--210.32.32.1#53

          下面的Name是：解析的URL--    www.jsjzx.com

          Address是：解析出来的IP--112.121.162.168

但是也有像百度这样的DNS比较复杂的解析:

你会发现百度有一个cname = www.a.shifen.com  的别名。

这是怎么一个过程呢？

我们用dig工具来跟踪一下把（linux系统自带有）

-----------------------------------------------------------------------------------------------------------------------------------------------

Dig工具会在本地计算机做迭代，然后记录查询的过程。

第一步是向我这台机器的ISPDNS获取到根域服务区的13个IP和主机名[b-j].root-servers.net.。

第二步是向其中的一台根域服务器（Servername就是末行小括号里面的）发送www.baidu.com的查询请求，他返回了com.顶级域的服务器IP（未显示）和名称，

第三步，便向com.域的一台服务器192.33.4.12请求,www.baidu.com，他返回了baidu.com域的服务器IP（未显示）和名称，百度有四台顶级域的服务器

     【此处可以用dig @192.33.4.12 www.baidu.com查看返回的百度顶级域名服务器IP地址】。

第四步呢，向百度的顶级域服务器（202.108.22.220）请求www.baidu.com，他发现这个www有个别名，而不是一台主机，别名是www.a.shifen.com。

----------------------------------------------------------------------------------------------------------------------------------------------------

按照一般的逻辑，当dns请求到别名的时候，查询会终止，而是重新发起查询别名的请求，所以此处应该返回的是www.a.shifen.com而已。

但是为什么返回a.shifen.com的这个域的NS呢？

我们可以尝试下面的这个命令：dig +trace  shifen.com 看看有什么结果。。。。。。。。

你会发现第三步时shifen.com这个顶级域的域名服务器和baidu.com这个域的域名服务器是同一台主机（即：dns.baidu.com）！

当我拿到www.baidu.com的别名www.a.shifen.com的时候，我本来需要重新到com域查找shifen.com域的NS，但是因为这两个域在同一台NS上，所以直接向本机发起了，

shifen.com域发现请求的www.a.shifen.com是属于a.shifen.com这个域的，

于是就把a.shifen.com的这个NS和IP返回，让我到a.shifen.com这个域的域名服务器上查询www.a.shifen.com。

于是我便从ns X .a.shifen.com中一台拿到了一条A记录，最终的最终也便是www.baidu.com的IP地址了.【此处也可以用dig +trace www.a.shifen.com】跟踪一下

用一个图来说明一下(图中第三步的全世界只有13台是错误的)

以下内容为在虚拟机中搭建local dns服务器得到的实验数据，纠正上述结论

在上面的分析中，我们用dig工具进行了追踪，但是dig没有继续追踪当我们从baidu.com拿到cname和ns2.a.shifen.com的IP之后的事情。

我们就所以然的下结论认为local dns会向ns2.a.shifen.com请求www.a.shifenc.om。

其实这个想法是错误，在自己的本地搭建一个local dns，抓取整个解析过程中是所有包，看看就明白拉。

实际的结果是虽然dns.baidu.com返回了a.shifen.com域的服务器地址和IP，

但是local dns并不是直接向上述返回的IP请求www.a.shifen.com，而是再一次去请求com域，得到shifen.com域的服务器（也就是baidu.com的那四台），

然后又请求www.a.shifen.com，返回a.shifen.com的域的服务器，最后才是去请求www.a.shifen.com，

虽然上面已经返回了IP，但是实验的结果就是再走一遍shifen.com域的查询。

上图就是localdns在解析www.baidu.com的抓包全过程。蓝色那条就是在收到cname和响应的a.shifen.com的域名服务器IP地址之后，继续向com域请求shifen.com。

这个图充分说明了返回cname的同时也返回了ns2.a.shifen.com的IP。

因此总结一下便是

         ①本机向local dns请求www.baidu.com

         ②local dns向根域请求www.baidu.com，根域返回com.域的服务器IP

         ③向com.域请求www.baidu.com，com.域返回baidu.com域的服务器IP

         ④向baidu.com请求www.baidu.com，返回cname www.a.shifen.com和a.shifen.com域的服务器IP

         ⑤向root域请求www.a.shifen.com

         ⑥向com.域请求www.a.shife.com

         ⑦向shifen.com请求

         ⑧向a.shifen.com域请求

         ⑨拿到www.a.shifen.com的IP

         ⑩localdns返回本机www.baidu.com cname www.a.shifen.com 以及 www.a.shifen.com的IP

From:http://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html

在很多人看来，DNS只是为外部提供DNS解析服务（我以前也是这么认为的，直到膝盖中了一箭），但作为互联网的基础设施，DNS远没有想象的那么简单。如果你没有听说过DNS查询、反向解析、zone传输、动态更新、DNS安全，那你可以从本文中得到关于他们的最简明的诠释。

一、 DNS协议

　　DNS在53端口上监听请求并提供响应的服务。出于性能的考虑，DNS查询请求用UDP协议交互并且每个请求的大小小于512字节，但是如果返回的请求大小大于512字节，交互双方会协商使用TCP协议。

二、 DNS查询

　　DNS中的域名服务器最主要的功能就是响应域名解析器的查询请求（这个域名解析器可能是PC端的解析器，也可能是具有解析功能的另一台域名服务器）。域名解析器是安装在PC端的软件，它负责向本地DNS（local DNS）发起域名解析请求。

DNS系统中有三类查询：

　　1，递归查询

域名服务器将代替请求的客户机（下级DNS服务器）进行域名查询，如果域名服务器不能直接回答，则域名服务器会在域各树种的各个分支的上下进行递归查询，最终将查询结果返回给客户机，在域名查询期间，客户机始终处于等待状态。递归解析的过程如下图所示：

　　上图中需要注意的是，许多授权域名服务器都不会提供递归查询的功能（为什么？），比如根域名服务器.和二级域名服务器.com都不提供递归查询的功能，所以真正意义上的递归查询是由Local DNS来完成的。

　　一般情况下，递归查询的时候会收到以下三种可能的返回结果：

1），一个或若干个A记录，或者带有CNAME链的A记录。A记录即要请求的域名的IP地址，带有CNAME链的A记录就像上一篇博客“DNS开源服务器BIND最小配置详解”里面请求ftp.cobb.com时会先将ftp.cobb.comCNAME到 ljx.cobb.com，然后返回ljx.cobb.com的A记录。

2），一个标示域或主机不存在的错误信息。需要注意的是这个错误信息也可能含有CNAME记录。例如我要请求ftp.cobb.com，而我的域名服务器将ftp.cobb.comCNAME到了ljx.cobb.com，但是ljx.cobb.com这个主机不存在，这个时候就返回CNAME记录和错误信息。

　　3），暂时性的错误信息。它主要是因为网络不可达该主机，网络不可达不一定表明该主机不存在。

2，迭代查询

　　域名服务器在返回一些下一次查询的指引或者主机IP地址，域名解析器在收到指引后会再次向这些指引发起查询请求，直到收到主机IP地址。迭代解析的过程如下图所示：

　　一般情况下，递归查询的时候会收到以下三种可能的返回结果：

     1），A记录或者带有CNAME链的A记录。

     2），标示域或主机不存在的错误信息。

     3），暂时性错误。可能因为网络不可达。

     4），可以给出下一步域名解析的域名服务器（包括它的IP地址）的列表。告诉解析器再去哪里进一步解析。

3，反向查询

　　反向查询是根据一个资源记录查询域名。这个资源记录可能是A记录，CNAME记录或者MX记录（见“DNS开源服务器BIND最小配置详解”）。

为了实现反向查询，DNS中有一个特殊的域名IN-ADDR.ARPA来专门作反向查询定义。详情见RFC3425。

三、域维护

　　域维护是指通过DNS协议来在主域名服务器和从域名服务器之间维护同一个zone文件。

　　DNS中有两种域维护手段，一种是全量传输AXFR(full zone transfer)，另一种是增量传输IXFR(incremental zone transfer)。

     1，全量传输AXFR

　　全量传输时，从域名服务器从主域名服务器上请求zone文件，poll的时间间隔由SOA记录中的refresh标签定义。请求zone文件的过程是从域名服务器向主域名服务器发送查询来实现，如果主域名服务器中SOA记录中的序列号(serial number标签定义)大于从域名服务器SOA记录的序列号，从域名服务器就会向主域名服务器发送全量传输请求。所以主域名服务器一旦改变了zone文件，则需要增加它该zone中的序列号。整个SOA记录的完整格式见下图：

　　通常情况下，序列号sn遵循“年+月+日+编号”的格式，如图中的2003080803表示该zone是2003年8月8日的第三次更新。

　　全量传输时在TCP的53端口上进行。

　　2，增量传输(IXFR)

　　传递非常大的zone文件是非常耗资源的（时间、带宽等），尤其是只有zone中的一个记录改变的时候，没有必要传递整个zone文件，增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的记录。

　　需要注意的是，不是所有的域名服务器都支持增量传输，当不支持增量传输时，主从间就采用全量传输的方式。

　　3，通告(NOTIFY)

　　从上面的分析中可以看出，从服务器每隔refresh时间向主服务器发送请求，只有主服务器的SOA中的序列号大于从服务器的序列号才传输，但是如果这个时间间隔比较大的话（比如12个小时），快速变化的网络环境可能不允许有如此大时间的差异。

　　所以在实现了通告消息的DNS集群中，DNS主服务器的zone文件发生改变后，它立即向从服务器发送一个NOTIFY消息，告诉从服务器我的zone文件发生改变了，接着从服务器马上对比两者的序列号，再采用上面介绍的全量传输或者增量传输的方法请求zone文件。

BIND本身支持通告，通告的配置是在named.conf中的zone中的option中配置，配置指令是notify, also-notify和notify-source，具体见这里。

　　4，动态更新

　　每次需要更新zone文件的时候都需要停止域名服务器并重启，这样当zone文件很多的时候域名服务器重启时加载zone文件需要很多的时间。所以需要有一种不停止查询服务而且快速更新zone文件地方机制，这种机制主要有两种：

     一种是允许外部进程在服务器运行的时候更新zone文件；

　　另外一种是将zone中的资源记录RR存储在数据库中，每次查找zone中记录的时候动态读取；

四、DNS安全

　　像其他的任何公共服务一样，DNS也会受到各种各样的安全威胁。这节看看DNS服务器会受到什么样的安全威胁？聪明的人们又是怎么应对这些威胁的。

　　为了了解DNS受到的安全威胁和响应的应对措施，首先需要了解一下DNS的正常数据流。如下图所示：

　　上图中的每个数据流都会受到响应的安全威胁：

　　1）zone文件受到的威胁可能有：文件被无意或有意篡改或删除。这种威胁是较好应对的，最主要的方法是制定很好的系统管理策略，zone文件和其他的配置文件需要严格而安全的读写权限。

2）3）动态更新和域传输受到的威胁可能有：未授权的更新、zone文件在传输过程中被篡改（经常是把域名篡改为别的IP）。这种威胁通常的应对方法是TSIG(Transaction SIGnature)策略（这个策略定义在RFC2845中）。TSIG策略中会计算出一个key，这个key是通过单向散列(能轻松地从输入得出值，但很难通过值猜出输入)计算出来的，然后传输zone文件的双方在传输过程中都带上这个key，如果key不对就拒绝传输。

4）5）远程查询受到的威胁可能有：cache污染（IP欺骗、数据拦截或错误的master主机地址）。cache污染是指cache中内容可能将您的域名重定向到了一个错误的服务器。这种威胁通常的应对方法是域名系统安全扩展（DNSSEC, Domain Name System Security Extensions），它是为DNS客户端（解析器）提供的的DNS数据来源，数据完整性验证，但不提供或机密性和认证的拒绝存在扩展集。关于DNSSEC的资料见这里。关于这部分内容，我会在后续的博客中专门介绍，请关注：www.cnblogs.com/cobbliu

DNS，就是Domain Name System的缩写，翻译过来就是域名系统，是互联网上作为域名和IP地址相互映射的一个分布式数据库。DNS能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。

下面这张图，详细说明了一个DNS域名解析的全过程：

下面来详细解释DNS域名解析的过程：

网络客户端就是我们平常使用的电脑，打开浏览器，输入一个域名。比如输入www.163.com，这时，你使用的电脑会发出一个DNS请求到本地DNS服务器。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。

查询www.163.com的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果。如果没有，本地DNS服务器还要向DNS根服务器进行查询。

根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到域服务器上去继续查询，并给出域服务器的地址。

本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。

最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

关于DNS解析的TTL参数：

我们在配置DNS解析的时候，有一个参数常常容易忽略，就是DNS解析的TTL参数，Time To Live。TTL这个参数告诉本地DNS服务器，域名缓存的最长时间。用阿里云解析来举例，阿里云解析默认的TTL是10分钟，10分钟的含义是，本地DNS服务器对于域名的缓存时间是10分钟，10分钟之后，本地DNS服务器就会删除这条记录，删除之后，如果有用户访问这个域名，就要重复一遍上述复杂的流程。

其实，如果网站已经进入稳定发展的状态，不会轻易更换IP地址，我们完全可以将TTL设置到协议最大值，即24小时。带来的好处是，让域名解析记录能够更长时间的存放在本地DNS服务器中，以加快所有用户的访问。设置成24小时，其实，还解决了Googlebot在全球部署的服务器抓取网站可能带来的问题，这个问题麦新杰专门有一篇博文，请参考：“Googlebot无法访问您的站点”问题理解和处理方法

阿里云之所以只将TTL设置成10分钟，是为了让域名解析更快生效而已。因为之前的解析会在最长10分钟之后失效（本地DNS服务器将对应的解析条目删除），然后新的解析生效。如果是24小时，这个生效的时间最长就是24小时，甚至更长（本地DNS服务器要有用户请求，才会发起查询）。

相关内容：https://study.163.com/course/courseMain.htm?courseId=1210406206&share=2&shareId=480000002227524