浅谈DNS体系结构<?XML:NAMESPACE PREFIX = O />
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。

<?XML:NAMESPACE PREFIX = V />
在一个小规模的互联网上,使用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服务器的常用记录类型。
本文出自 “岳雷的微软网络课堂” 博客,请务必保留此出处http://yuelei.blog.51cto.com/202879/106228

本文出自 51CTO.COM技术博客

转载于:https://blog.51cto.com/jianzhong/349146

浅谈DNS体系结构:DNS系列之一相关推荐

  1. 猿来小课Java视频教程讲师浅谈JAVA体系结构

    猿来小课Java视频教程讲师:Java体系结构中不仅定义了Java的开发编译环境,也定义了Java的运行环境.为运行Java应用程序和applet,计算机上应安装JVM和Java运行时解释器,这两个部 ...

  2. Android源代码目录结构分析及浅谈OS体系结构:

    附上自己工作平台代码目录结构图: Android源代码结构: Android 2.1 |– Makefile (全局的Makefile) |– bionic (bionic C库,Bionic含义为仿 ...

  3. java堆栈有序无序,浅谈Java并发编程系列(四)—— 原子性、可见性与有序性

    Java内存模型是围绕着在并发过程中如何处理原子性.可见性和有序性这3个特征来建立的,我们来看下哪些操作实现了这3个特性. 原子性(atomicity): 由Java内存模型来直接保证原子性变量操作包 ...

  4. 浅谈 Linux 高负载的系统化分析

    简介: 浅谈 Linux 高负载的系统化分析,阿里云系统组工程师杨勇通过对线上各种问题的系统化分析. 讲解 Linux Load 高如何排查的话题属于老生常谈了,但多数文章只是聚焦了几个点,缺少整体排 ...

  5. 浅谈GPU虚拟化技术(四)- GPU分片虚拟化

    让各位久等了,阿里小二这就开始上新菜:"GPU分片虚拟化". 对于"分片"的理解,相信大家已经不陌生了.此处的分片从两个维度上来定义:其一,是对GPU在时间片段 ...

  6. 浅谈前端性能优化(九)——DNS解析优化

    1.DNS缓存 DNS查询过程大约消耗20毫秒,在DNS查询过程中,浏览器什么都不会做,保持空白.如果DNS查询很多,网页性能会受到很大影响,因此需要用到DNS缓存.  不同浏览器的缓存机制不同: I ...

  7. 浅谈DNS劫持相关概念及原理

    目录 一.前言 二.什么是DNS? 三.DNS原理 1.DNS工作原理 2.DNS服务器 3.本地DNS 4.域名的层级 5.根域名服务器 四.DNS劫持 1.什么是DNS劫持 2.DNS劫持的方法 ...

  8. gif透明背景动画_前端基础系列之bmp、jpg、png、gif、svg常用图片格式浅谈(二)...

    IT客栈 作者:大腰子 bmp.jpg.png.gif.svg常用图片格式 之前为大家介绍了几种WEB前端常用的图片格式,对比了它们的特点,参见<前端基础系列之bmp.jpg.png.gif.s ...

  9. music算法_“要热爱 请深爱”系列(5)浅谈模拟退火算法

    黄乐天 浅谈模拟退火算法 背景 在实际生活中, 数学问题中,我们常常会遇到(一定范围内)函数求最值的问题.一般可以用数学方式解答,但如果遇到如下恶心的函数: 它的函数图像是这样的: 我们只好用计算机科 ...

最新文章

  1. MVC页面加载速度优化小记
  2. Django H2 文档查看
  3. 任正非公开信:投入 20 亿美元全面提升华为软件质量
  4. 高铁是如何跑起来?列车头顶高压线为什么磨不坏?
  5. 开发中遇到的java小知识
  6. 与素数有关的一些性质及证明(一)
  7. 使用tensorflow object detection API 训练自己的目标检测模型 (二)labelImg的安装配置过程
  8. CSS定位 position
  9. 入手mac后,这5个技巧和窍门你应该知道
  10. 12.结账流程(Checkout Process)
  11. 对比Windows 8模拟器(Simulator)和Windows Phone仿真器(Emulator)
  12. scrt设置右键粘贴,选中复制
  13. 中兴c语言 面试题,华为,英飞凌,中兴硬件工程师面试题
  14. 网络岗7 97用户破解图片
  15. xposed框架_免root使用xposed框架的另一种方法!
  16. 某条微博评论数据爬取
  17. 电磁屏蔽技术的三种主要方法
  18. python画动态表情包_20行代码制作字符画版小黄鸭表情包
  19. 高阶常微分方程的求解
  20. ROS通信机制~话题通信(PublisherSubscriber)·笔记2

热门文章

  1. 服务器温控系统,服务器温度监控
  2. foreach去除重复元素java_Java foreach 中List移除元素抛出ConcurrentModificationException原因全解析...
  3. 深入理解Java虚拟机(一):Java内存模型
  4. wxpython 安装_下载和安装wxPython
  5. TCP三次握手、tcp和udp对比、四表五链
  6. Linux初学(CnetOS7 Linux)之切换命令模式和图形模式的方法
  7. jquery text html width heigth的用法
  8. openssh实现key验证免密码登录
  9. springboot项目打包运行
  10. 一、安装Docker CE