浅谈
DNS
体系结构
DNS 是目前互联网上最不可或缺的服务器之一,每天 我们在互联网上冲浪都需要 DNS 的帮助。 DNS 服务器能够为我们解析域名,定位电子邮件服务器,找到域中的域控制器 …… 面对这么一个重要的服务器角色,我们有必要对它进行一番深入研究,本文尝试探讨一下 DNS 的体系结构,从而让大家能更好地了解 DNS 的原理。
DNS 的主要工作是域名解析,也就是把计算机名翻译 成 IP 地址,这样我们就可以直接用易于联想记忆的计 算机名来进行网络通讯而不用去记忆那些枯燥晦涩的 IP 地址了。现在我们给出一个问题,在 DNS 出现之前,互联网上是如何进行计算机名称解析的?这个问题显然是有实际意义的,描述 DNS 的 RFC882 和 883 出现在 1984 年,但 1969 年 11 月互联网就诞生了,难道在 DNS 出现之前互联网的先驱们都是互相用 IP 地址进行通讯的?当然不是,但早期互联网的规 模确实非常小,最早互联网上只有 4 台主机,分别在犹他大学,斯坦福大学,加州洛杉矶分校和加州圣芭芭拉分校,即使在整个 70 年代互联网上也只有几百台主机而已。这样一 来,解决名称解析的问题就可以使用一个非常简单的办法,每台主机利用一个 Hosts 文件就可以把互联网上所有的主机都解析出来。这个 Hosts 文件现在我们还在使用,路径就在 /Windows/System32/Drivers/etc 目录下,如下图所示就是一个 Hosts 文件的例子,我们在图中可以很清楚地看到 Hosts 文件把
[url]www.baidu.com[/url]
解析为 202.108.22.5 。
在一个小规模的互联网上,使用 Hosts 文件是一个非常简单的解决方案,一般情况下,斯坦福大学的主机管理员每周更新一次 Hosts 文件,其他的主机管理员每周都定时下载更新的 Hosts 文件。但显然这种解决方案在互联网规模迅速膨胀时就不太适用了,就算现在的互联网上有一亿台主机,想想看,如果每个人的计算机中都要 有一个容纳一亿台主机的 Hosts 文件!呵呵,是不是快要崩溃了!
互联网的管理者们及时为 Hosts 文件找到了继任者- DNS , DNS 的设计要求使用分布式结 构,既可以允许主机分散管理数据,同时数据又可以被整个网络所使用。管理的分散有利于缓解单一主机的瓶颈,缓解流量压力,同时也让数据更新变得简单。 DNS 还被设计使用有层次结构的名称空间为主机命 名,以确保主机域名的唯一性。
DNS 的设计要求您已经看到了,下面我来具体解释一 下。 DNS 的前身 Hosts 文件是一个完全的分散解析方案,每台主机都自 己负责名称解析,这种方法已经被我们否定了。那我们能否使用一个完全集中的解析方案呢?也就是全世界只有一个 Hosts 文件,互联网用户都利用这个文件进行名称解 析!这个方案咋一听还是有可取之处的,至少大家都解脱出来了,不用每台计算机都更新那个 Hosts 文件了,全世界只要把这个唯一的 Hosts 文件维护好就完事大吉了。实际上仔细考虑一下,有很多的问题,例如这台存放 Hosts 文件的主机会成为性能瓶颈,面临巨大的流量压力,而且每个域名解析的结果都要通过这个文件进行更新,更新的速度可想而知不会太及时。 因此, DNS 也没有采用这种完全集中的解析方 案。
目前 DNS 采用的是分布式的解析方案。具体是这样的,互联网管理委员会规定,域名空间的解析权都归根服务器所有,也就是说,根服务器对互联网上所 有的域名都享有完全的解析权!且慢,有读者要提问了,那这个根服务器不就相当于全世界唯一的 Hosts 文件了吗?呵呵,不要着急,根服务器用了一个简单的操作,就改变了这种结构。根服务器使用的是什么操作?委派!下图就是根服务器委派 的示意图,如下图所示,根服务器把 com 结尾的域名解析权委派给其他的 DNS 服务器,以后所有以 com 结尾的域名根服务器就都不负责解析了,而由被委派的服务器负责解析。而且根服务器还把以 net , org , edu , gov 等结尾的域名都一一进行了委派,这些被委派的 域名被称为顶级域名,每个顶级域名都有预设的用途,例如 com 域名用于商业公司, edu 域名用于教育机构, gov 域名用于政府机关等等,这种顶级域名也被称为顶级机构域名。根服务器还针对不同国家进行了域名委派,例如把所有以 CN 结尾的域名委派给中国互联网管理中心,以 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 的域名呢?如果一个互联网用户想解析域名 [url]www.hexun.com[/url]
,过程是怎么样的呢?如下图所示,用户把解析请求发送到自己使用的 DNS 服务器上, DNS 服务器发现自己无法解析 [url]www.hexun.com[/url] 这个域名,于是就把这个 域名发送到根服务器请求解析,根服务器发现这个域名是以 com 结尾的,于是告诉查询者这个域名应该询问负责 com 的 DNS 服务器。这时查询者会转 而向负责 com 的域名服务器发出查询请求,负责 com 域名的 DNS 服务器回答说 [url]www.hexun.com[/url] 是以 hexun.com 结尾的域名,以 hexun.com 结尾的域名已经被委派到 DNS 服务器 60.28.251.1 了,因此这个域名的解析应该询问 60.28.251.1 。于是查询者最后向 60.28.251.1 发出查询请求,这次应该可以如愿以偿了, 60.28.251.1 会告诉查询者所需要的答案,查询者拿到这个答案后,会把这个查询结果放入自己的缓存中,如果在缓存的有效期内有其他 DNS 客户再次请求这个域名, DNS 服务器就会利用自己缓存中的结果响应用户,而 不用再去根服务器那里跑一趟了。

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

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

打开抓包工具 Ethereal ,如下图所示,我们看到第 8 条记录显示 DNS 服务器 Berlin 向 198.41.0.4 发出了一个查询请求,请求解析 [url]www.hexun.com[/url] , 198.41.0.4 何许人也, 13 个根服务器之一!

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

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

从下图的第 11 条记录可以看出,负责 com 区域的域名服务器告诉 Berlin ,以 hexun.com 结尾的域名已经委派出去,现在有四个服务器负责, Berlin 可以向这四个服务器中的任何一个提出查询请求。

从第 12 条记录可以看出, Berlin 这次向 59.173.14.26 提出了查询请求, 59.173.14.26 就是上图中提到的负责 hexun.com 区域的四个服务器之一。这次查询会有什么样的 结果呢?

如下图的第 13 条记录所示,这次查询终于有了结果,负责 hexun.com 的 59.173.14.26 终于告诉 Berlin , [url]www.hexun.com[/url] 对应的 IP 是 60.28.250.55 。

通过这个实验,希望大家能够更好地理解 DNS 的分布式结构,下篇博文中我们要讨论一下如何 DNS 服务器的常用记录类型。