DNS作为一门基础的计算机网络基础架构应用已经有很多年了，今天我来向大家总结和梳理一下关于DNS中的一些知识。

本文阐述的：DNS用的一些原理和数据流

本文不阐述的：DNS服务器的部署和配置

     在我撰写这篇文章特意参考了一下鸟哥的私房菜《LINUX服务器架设篇-DNS服务器》和戴有炜的《WINDOWS SERVER 2008 网络专业指南-解析DNS主机名》发现了一个特别有意思的现场，在LINUX平台下的DNS更多描述的是公网的DNS，在WINDOWS平台下更多描述的是基于私网的DNS，为了在后面做更好的诠释，我在文中可能会结合LINUX平台&WINDOWS平台，可能对于一些常年在一个平台中而很少使用另一个平台的朋友优点不适应，但是为了更好的描述一些知识，只能牺牲少部分人的习惯了。

一、C/S模式的DNS

对于计算机网络应用，一般都会有三种模式进行通信，一种是无服务器概念的对等模式 （图1.1）（如WINDOWS下的工作站模式）一种是基于B/S（浏览器/服务器端）的应用模式（图1.2），而最后一种就是基于C/S （图1.3）（客户端/服务器端）的应用模式了。

（图1.1 对等模式）

（图1.2 B/S模式）

（图1.3 C/S模式）

 无疑，DNS服务属于第三种模式。只是为了方便广大用户，无论是WIN还是LINUX，DNS的CLIENT（客户端）都已经默认安装到操作系统中了，我们只需要进行设置即可。而DNS的SERVER端需要单独安装。

       之所以强调DNS的C/S模式，是为了让大家有这个概念，在排查DNS问题的时候除了考虑到DNS SERVER的问题时，也需要考虑DNS的CLIENT是否有问题（尽管根据我的个人经验，CLIENT端出现问题多半是配置的错误）另外DNS的S端也有些情况下也会转变成C端（这个在后面进行阐述）

提供查询请求的DNS客户端被称为解析器（resolver),而提供数据的DNS服务器称为名称服务器（name server)

这个时候你是不是突然明白了为什么LINUX的DNS客户端配置文件是/etc/resolv.conf了吧。

二、内部DNS和公网DNS

 其实刚才已经在文中开头说了一个有意思的现象，在很多WINDOWS平台的书籍和文章中更多的会描述的是内部的DNS，而LINUX平台的相关数据和文章搭建的更多的是公网的DNS。其中使用哪个平台下的DNS服务器都可以搭建内网和公网的DNS，但是你必须有内部DNS和公网DNS的概念，见下图2.1

（图2.1）

      内部DNS主要解析内部网络的主机地址，关于此处内网的定义就是计算机网络中的局域网，而公网DNS主要解析公网上的服务器的主机地址，公网我们可以理解为INTERNET网。在这里着重强调区别内公网的DNS是建议不要将公网和内网的DNS放在一起。无论是从安全的角度还是从业务逻辑上。内部的DNS尽量只解析内网的主机地址，如果有解析公网主机地址的需求，可以使用转发、唯缓存的方法。公网的DNS是面向所有解析公网主机地址的请求，一般用于作为权威应答的服务器。关于上文提到的几个概念，我会在下面陆续阐述。内部的DNS的实例很多人经常使用，就是作为活动目录域的基础架构。因为我们不是在阐述DNS与ADDS的关系，所以在并不会在此方面做过多的讨论。但是只要安装和部署过ADDS的人就会知道，ADDS需要DNS来定位域控和域成员主机。

三、DNS递归查询和迭代查询

关于DNS的这两种查询，网上已经有很多类似的文章了，我也找了一篇解释的相对比较全面的文章：http://zhumeng8337797.blog.163.com/blog/static/10076891420110694312990/

在这里我想补充2点：

1、关于本地DNS 我不知道有没有人会误解，文中提到的本地DNS其实就是你在DNS客户端配置的DNS，如果它在公网，那么就是一台公网DNS，如果他是你在内部部署一台DNS服务器，那么它就是一台内部DNS

2、关于迭代查询，我不知道一些人有没有过如此的疑问，当本地DNS在缓存中没有记录的时候会向13台根服务器提供查询请求，那么13台根服务器及.com顶级域服务器是通过什么来定位到如163.com是被哪个DNS服务器查询并返回解析主机记录的呢？答案是通过NS记录的权威服务器来完成的。下图3.1是我虚构的IP地址和上级授权机构，但是迭代查询的基本过程是这样的

（图3.1）

实际过程要比这个还要复杂，但总的来说，当公网查询解析主机记录的时候，从根服务器可以查到它向下授权服务器的主机地址通过（NS记录）并要记录知道向下授权服务器的IP地址（通过A记录）通过逐级向下查找授权，最后通过定位权威服务器查找自己正向解析记录ZONE，给出最终的IP地址。

下面我们通过DIG看一下www.51cto.com的解析过程图3.2

（图3.2）

3、关于递归查询 由于一般在DNS的CLIENT设置2个DNS-SERVER地址，根据递归查询的法则，名称解析服务器端要么返回正确的主机地址，要么返回错误的地址，要么说没有找到，除非在第1台DNS服务器端没有应答的时候，才会采用第2台DNS服务器做解析，见图3.3

（图3.3）

我故意写错了第1台DNS服务器的IP地址（8.8.8.9）然后使用DIG工具查询解析的时候，第二台DNS服务器（8.8.4.4）做出了应答。

四、DNS服务器三大功能：权威服务器（name server)、转发器（FORWARDING）、唯缓存服务器（CACHING-ONLY）

无论是WINDOWS平台下的DNS服务器，还是LINUX平台下的BIND，都会有这三大功能，只是在中文定义上略有差别。我们通过公网DNS和内部DNS两种情况下来阐述这三大功能。

从公网DNS服务器上来看，图3.1右下角的服务器就是一台权威服务器，权威服务器通过NS名称服务器记录资源表明z00w00.com这个区域里面的主机记录有它负责解析，当然DNS服务器需要就有正向解析的ZONE或反向解析的ZONE。而权威服务器如果想提供给解析器(DNS客户端）返回所管理域（如z00w00.com）下www.z00w00.com的IP地址，就必须得到其上级解析机构（一般是你的域名提供商）的授权（购买、域名备案）

而很多公网上的本地DNS由于并不负责管理任何区域的DNS服务器，而只是缓存DNS查询结果，所以被称为唯缓存服务器。比如很多ISP和ICP提供的DNS服务器。唯缓存服务器通过HINT或叫根提示（记录.的ZONE）像图3.1一样迭代查询返回解析记录，并在自己缓存中保存一份。在缓存中的记录失效前，再向其提交解析请求，都会从缓存中提取记录返回给客户端（解析器）而避免了以一次次迭代查询的低效率。

我们可以通过NSLOOKUP工具查看唯缓存服务器作为非权威服务器的查询结果，图4.1

（图4.1）

从内网DNS服务器上看，内部DNS如果是直接负责解析自己管理的区域也就是内部的权威服务器，如果需要解析外部（公网服务器）时就需要像唯缓存服务器一样像根提示提交查询了。如图4.2

（图4.2）

当然内部DNS直接提交查询请求给根提示服务器的时候由于网络的问题，经常会较慢(毕竟根服务器都在国外），所以为了提高查询效率，会设置转发器如图4.3

（图4.3）

内部DNS设置转发器地址为放置在外网的转发器，转发服务器像唯缓存服务器一样提供公网DNS解析，这样就提高了解析的效率。有时候为了安全，转发服务器可能也放置在内网。

五、DNS的TCP/UDP 53端口

当服务启动的时候，都会开一个监听端口，比如WWW开通的是TCP的80，而DNS比较有意思，它同时开启了TCP的53和UDP的53端口

，默认情况下：从C端到S端的查询使用UDP的53，但是有一种情况下会使用TCP的53端口。由于UDP模式下报文长度被限制在512个字节以下，如果DNS报文首部中的标志字段TC为1时（[QR][opcode][AA][TC][RD][RA][(zone)][rcode]）表示超过512字节，然后DNS 客户端会使用TCP重发原来的查询请求，TCP允许报文长度超过512字节。既然TCP能将data stream分成多个segment，它就能用更多的segment来传送任意长度的数据。那为什么DNS的回应报文会那么长呢？有一种情况是：返回的域名对应了十几条A记录（一个域名绑定多个IP）另一个情况是主/辅DNS之间的区域传送会使用TCP，因为传输的是一个地域的数据，所以数据量要大的多。关于区域复制，我们下文继续描述

本文出自 “丁胖胖的BLOG” 博客，请务必保留此出处http://z00w00.blog.51cto.com/515114/1423708