浅谈DNS体系结构
DNS是目前互联网上最不可或缺的服务器之一,每天我们在互联网上冲浪都需要DNS的帮助。DNS服务器能够为我们解析域名,定位电子邮件服务器,找到域中的域控制器……面对这么一个重要的服务器角色,我们有必要对它进行一番深入研究,本文尝试探讨一下DNS的体系结构,从而让大家能更好地了解DNS的原理。
在一个小规模的互联网上,使用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等结尾的域名都一一进行了委派,这些被委派的域名被称为顶级域名(TLD: Top Level Domain),每个顶级域名都有预设的用途,例如com域名用于商业公司,edu域名用于教育机构,gov域名用于政府机关等等,这种顶级域名也被称为顶级机构域名。根服务器还针对不同国家进行了域名委派,例如把所有以CN结尾的域名委派给中国互联网管理中心,以JP结尾的域名委派给日本互联网管理中心,CN,JP这些顶级域名被称为顶级地理域名。
每个被委派的DNS服务器同样使用委派的方式向下发展,例如和讯公司想申请使用hexun.com域名,这时和讯就要向负责.com域名的DNS服务器提出申请,只要hexun.com还没有被其他公司或个人使用,而且申请者按时足额缴纳了费用,负责.com域名的服务器就会把hexun.com域名委派到和讯公司自己的DNS服务器60.28.251.1。只要DNS服务器使用委派,域名空间就会逐步形成现有的分布式解析架构。这种架构把域名解析权下放到各公司自己的DNS服务器上,既有利于及时更新记录,同时对平衡流量压力也很有好处。
以上介绍的域名解析过程我们可以通过一个实验来加以说明,Berlin是一个DNS服务器,IP地址为192.168.1.200,其他IP参数如下图所示。我们现在用Berlin来解析一个域名,我们用抓包工具ethereal追踪一下域名解析的轨迹。
在DNS服务器上查询 ;="" mso-hansi-font-family:="" times="" new="" roman="" style="padding: 0px; margin: 0px; font-family: 'Microsoft YaHei'; font-size: 16px;">,如下图所示,DNS服务器已经解析了这个域名,但到底解析的过程是什么样的呢?向下看!
打开抓包工具Ethereal,如下图所示,我们看到第8条记录显示DNS服务器Berlin向198.41.0.4发出了一个查询请求,请求解析 style="font-family:'Microsoft YaHei';font-size:16px;">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, ;="" mso-hansi-font-family:="" times="" new="" roman="" style="padding: 0px; margin: 0px; font-family: 'Microsoft YaHei'; font-size: 16px;">对应的IP是60.28.250.55。
通过这个实验,希望大家能够更好地理解DNS的分布式结构,下篇博文中我们要讨论一下如何DNS服务器的常用记录类型。
阅读(517) | 评论(0) | 转发(0) |