51CTO下载-DNS教程

DSN 系列教程DNS 系列教程本文所有内容均出自岳雷的微软网络课堂 http://yuelei.blog.51cto.com51cto_bbs_Kirin整理汇总欢迎访问岳雷的网络课堂| http:

DSN 系列教程

DNS 系列教程

本文所有内容均出自岳雷的微软网络课堂 http://yuelei.blog.51cto.com

51cto_bbs_Kirin整理汇总

欢迎访问岳雷的网络课堂

| http://yuelei.blog.51cto.com

DSN 系列教程

目录

DSN 系列之一 浅谈DNS 体系结构

DNS 系列之二 详解DNS 的常用记录（上）

DNS 系列之三 详解DNS 的常用记录（下）

DNS 系列之四 配置DNS 辅助服务器

DNS 系列之五 揭秘DNS 后台文件

DNS 系列之六 亲手缔造DNS 体系，创建DNS 私有根

DSN 系列教程

浅谈DNS 体系结构

DNS 是目前互联网上最不可或缺的服务器之一，每天我们在互联网上冲浪都需要DNS 的帮助。DNS 服务器能够为我们解析域名，定位电子邮件服务器，找到域中的域控制器……面对这么一个重要的服务器角色，我们有必要对它进行一番深入研究，本文尝试探讨一下DNS 的体系结构，从而让大家能更好地了解D NS 的原理。

DNS 的主要工作是域名解析，也就是把计算机名翻译成IP 地址，这样我们就可以直接用易于联想记忆的计算机名来进行网络通讯而不用去记忆那些枯燥晦涩的IP 地址了。现在我们给出一个问题，在DNS 出现之前，互联网上是如何进行计算机名称解析的？这个问题显然是有实际意义的，描述DNS 的RFC882和883出现在1984年，但1969年11月互联网就诞生了，难道在DNS 出现之前互联网的先驱们都是互相用IP 地址进行通讯的？当然不是，但早期互联网的规模确实非常小，最早互联网上只有4台主机，分别在犹他大学，斯坦福大学，加州洛杉矶分校和加州圣芭芭拉分校，即使在整个70年代互联网上也只有几百台主机而已。这样一来，解决名称解析的问题就可以使用一个非常简单的办法，每台主机利用一个Hosts 文件就可以把互联网上所有的主机都解析出来。这个Hosts 文件现在我们还在使用，路径就在WindowsSystem32Driversetc目录下，如下图所示就是一个Hosts 文件的例子，我们在图中可以很清楚地看到Hosts 文件把www.baidu.com 解析为202.108.22.5。

DSN 系列教程

在一个小规模的互联网上，使用Hosts 文件是一个非常简单的解决方案，一般情况下，斯坦福大学的主机管理员每周更新一次Hosts 文件，其他的主机管理员每周都定时下载更新的Hosts 文件。但显然这种解决方案在互联网规模迅速膨胀时就不太适用了，就算现在的互联网上有一亿台主机，想想看，如果每个人的计算机中都要有一个容纳一亿台主机的Hosts 文件！呵呵，是不是快要崩溃了！

互联网的管理者们及时为Hosts 文件找到了继任者－DNS ，DNS 的设计要求使用分布式结构，既可以允许主机分散管理数据，同时数据又可以被整个网络所使用。管理的分散有利于缓解单一主机的瓶颈，缓解流量压力，同时也让数据更新变得简单。DNS 还被设计使用有层次结构的名称空间为主机命名，以确保主机域名的唯一性。

DSN 系列教程

DNS 的设计要求您已经看到了，下面我来具体解释一下。DNS 的前身Hosts 文件是一个完全的分散解析方案，每台主机都自己负责名称解析，这种方法已经被我们否定了。那我们能否使用一个完全集中的解析方案呢？也就是全世界只有一个Hosts 文件，互联网用户都利用这个文件进行名称解析！这个方案咋一听还是有可取之处的，至少大家都解脱出来了，不用每台计算机都更新那个Host s 文件了，全世界只要把这个唯一的Hosts 文件维护好就完事大吉了。实际上仔细考虑一下，有很多的问题，例如这台存放Hosts 文件的主机会成为性能瓶颈，面临巨大的流量压力，而且每个域名解析的结果都要通过这个文件进行更新，更新的速度可想而知不会太及时。因此，DNS 也没有采用这种完全集中的解析方案。

目前DNS 采用的是分布式的解析方案。具体是这样的，互联网管理委员会规定，域名空间的解析权都归根服务器所有，也就是说，根服务器对互联网上所有的域名都享有完全的解析权！且慢，有读者要提问了，那这个根服务器不就相当于全世界唯一的Hosts 文件了吗？呵呵，不要着急，根服务器用了一个简单的操作，就改变了这种结构。根服务器使用的是什么操作？委派！下图就是根服务器委派的示意图，如下图所示，根服务器把com 结尾的域名解析权委派给其他的DN S 服务器，以后所有以com 结尾的域名根服务器就都不负责解析了，而由被委派的服务器负责解析。而且根服务器还把以net ，org ，edu ，gov 等结尾的域名都一一进行了委派，这些被委派的域名被称为顶级域名，每个顶级域名都有预设的用途，例如com 域名用于商业公司，edu 域名用于教育机构，gov 域名用于政府机关等等，这种顶级域名也被称为顶级机构域名。根服务器还针对不同国家进行了域名委派，例如把所有以CN 结尾的域名委派给中国互联网管理中心，

DSN 系列教程

以JP 结尾的域名委派给日本互联网管理中心，CN ，JP 这些顶级域名被称为顶级地理域名。

每个被委派的DNS 服务器同样使用委派的方式向下发展，例如和讯公司想申请使用hexun.com 域名，这时和讯就要向负责.com 域名的DNS 服务器提出申请，只要hexun.com 还没有被其他公司或个人使用，而且申请者按时足额缴纳了费用，负责.com 域名的服务器就会把hexun.com 域名委派到和讯公司自己的DNS 服务器60.28.251.1。只要DNS 服务器使用委派，域名空间就会逐步形成现有的分布式解析架构。这种架构把域名解析权下放到各公司自己的DNS 服务器上，既有利于及时更新记录，同时对平衡流量压力也很有好处。

那么，在这种分布式的解析结构中，DNS 服务器如何进行域名解析呢？换句话说，其他的DNS 服务器怎么知道由60.28.251.1负责解析hexun.com 的域名呢？如果一个互联网用户想解析域名www.hexun.com ，过程是怎么样的呢？如下图所示，用户把解析请求发送到自己使用的DNS 服务器上，DNS 服务器发现自己无法解析www.hexun.com 这个域名，于是就把这个域名发送到根服务器请求解析，根服务器发现这个域名是以com 结尾的，于是告诉查询者这个

DSN 系列教程

域名应该询问负责com 的DNS 服务器。这时查询者会转而向负责com 的域名服务器发出查询请求，负责com 域名的DNS 服务器回答说www.hexun.co hexun.com 结尾的域名，以hexun.com 结尾的域名已经被委派到D NS 服务器60.28.251.1了，因此这个域名的解析应该询问60.28.251.1。于是查询者最后向60.28.251.1发出查询请求，这次应该可以如愿以偿了，

60. 28.251.1会告诉查询者所需要的答案，查询者拿到这个答案后，会把这个查询结果放入自己的缓存中，如果在缓存的有效期内有其他DNS 客户再次请求这个域名，DNS 服务器就会利用自己缓存中的结果响应用户，而不用再去根服务器那里跑一趟了。

以上介绍的域名解析过程我们可以通过一个实验来加以说明，Berlin 是一个DN S 服务器，IP 地址为192.168.1.200，其他IP 参数如下图所示。我们现在用Berlin 来解析一个域名，我们用抓包工具ethereal 追踪一下域名解析的轨迹。

DSN 系列教程

在DNS 服务器上查询[url]www.hexun.com[/url]，如下图所示，DNS 服务器已经解析了这个域名，但到底解析的过程是什么样的呢？向下看！

DSN 系列教程

打开抓包工具Ethereal ，如下图所示，我们看到第8条记录显示DNS 服务器B

erlin 向198.41.0.4发出了一个查询请求，请求解析www.hexun.com ，19

8.41.0.4何许人也，13个根服务器之一！

接下来看第9条记录，198.41.0.4给Berlin 一个回应，告诉了Berlin 这个域名解析问题应该询问负责com 区域的DNS 服务器，而且198.41.0.4还给出

DSN 系列教程

了负责com 区域服务器的域名和IP 地址。

接下来的第10条记录显示了Berlin 向192.55.83.30发出了域名解析请求，从上图可知，192.55.83.30就是负责com 区域的域名服务器之一，这次查询会有什么样的回应呢？