平时我们进行域名解析所用到的DNS服务器,是面对客户的一线服务器。

DNS服务器是(Domain Name System或者Domain Name Service)域名系统或者域名服务,域名系统为Internet上的主机分配域名地址和IP地址。

用户使用域名地址,该系统就会自动把域名地址转为IP地址。域名服务是运行域名系统的Internet工具。执行域名服务的服务器称之为DNS服务器,通过DNS服务器来应答域名服务的查询。

在服务器家族里还有一种叫做“DNS根服务器”的服务器。

全球共有13台根域名服务器。这13台根域名服务器中名字分别为“A”至“M”,其中10台设置在美国,另外各有一台设置于英国、瑞典和日本。

根服务器主要用来管理互联网的主目录,全世界只有13台。

1个为主根服务器,放置在美国。其余12个均为辅根服务器,其中9个放置在美国,欧洲2个,位于英国和瑞典,亚洲1个,位于日本。

所有根服务器均由美国政府授权的互联网域名与号码分配机构ICANN统一管理,负责全球互联网域名根服务器、域名体系和IP地址等的管理。

DNS根服务器架构

根服务器架构

这13台根服务器可以指挥Firefox或Internet Explorer这样的Web浏览器和电子邮件程序控制互联网通信。

由于根服务器中有经美国政府批准的260个左右的互联网后缀(如.com、.net等)和一些国家的指定符(如法国的.fr、挪威的.no等),自成立以来,美国政府每年花费近50多亿美元用于根服务器的维护和运行,承担了世界上最繁重的网络任务和最巨大的网络风险。

因此可以实事求是地说:没有美国,互联网将是死灰一片。

世界对美国互联网的依赖性非常大,当然这也主要是由其技术的先进性和管理的科学性所决定的。

所谓依赖性,从国际互联网的工作机理来体现的,就在于“根服务器”的问题。

从理论上说,任何形式的标准域名要想被实现解析,按照技术流程,都必须经过全球“层级式”域名解析体系的工作,才能完成。

“层级式”域名解析体系第一层就是根服务器,负责管理世界各国的域名信息,在根服务器下面是顶级域名服务器,即相关国家域名管理机构的数据库,如中国的CNNIC,然后是在下一级的域名数据库和ISP的缓存服务器。

一个域名必须首先经过根数据库的解析后,才能转到顶级域名服务器进行解析。

作用与影响

这13台根服务器可以指挥浏览器(比如.internet explorer)和电子邮件程序(比如.Firefox)以控制互联网通信。由于根服务器中有经美国政府批准的260个左右的互联网后缀(如.com、.net等)和一些国家的指定符,美国政府对其管理拥有很大发言权。这使得我们显得相当被动。

中国用户在访问带有.com等后缀的国外网站时,大多仍需要经过国外的域名服务器进行解析,中美海底光缆一旦发生断裂,便会发生解析问题,中国东部、太平洋西海岸地区,属于地震多发地带,再加上台风等环境因素影响,形势显得更加严峻。

一位互联网资深专家解释说,美国控制了域名解析的根服务器,也就控制了相应的所有域名,如果美国不想让人访问某些域名,就可以屏蔽掉这些域名,使它们的IP地址无法解析出来,那么这些域名所指向的网站就相当于从互联网的世界中消失了。比如,2004年4月,由于“.ly”域名瘫痪,导致利比亚从互联网上消失了3天。

注意,13台中除了欧洲两台、日本一台之外,其余全部位于美国。也就是说,只要美国愿意,他就可以切断全世界的网络。虽然网络是无国界的,但服务器是有国界的。

关于DNS根镜像服务器

指的就是DNS根服务器的镜像服务器

镜像服务器(Mirror server)与主服务器的服务内容都是一样的,只是放在一个不同的地方,分担主机的负载。

简单来说就是和照镜子似的,能看,但不是原版的。在网上内容完全相同而且同步更新的两个或多个服务器,除主服务器外,其余的都被称为镜像服务器。

分布地点

下表是这些机器的管理单位、设置地点及最新的IP地址:

名称 管理单位及设置地点 IP地址
A INTERNIC.NET(美国,弗吉尼亚州) 198.41.0.4
B 美国信息科学研究所(美国,加利弗尼亚州) 128.9.0.107
C PSINet公司(美国,弗吉尼亚州) 192.33.4.12
D 马里兰大学(美国马里兰州) 128.8.10.90
E 美国航空航天管理局(美国加利弗尼亚州) 192.203.230.10
F 因特网软件联盟(美国加利弗尼亚州) 192.5.5.241
G 美国国防部网络信息中心(美国弗吉尼亚州) 192.112.36.4
H 美国陆军研究所(美国马里兰州) 128.63.2.53
I Autonomica公司(瑞典,斯德哥尔摩) 192.36.148.17
J VeriSign公司(美国,弗吉尼亚州) 192.58.128.30
K RIPE NCC(英国,伦敦) 193.0.14.129
L IANA(美国,弗吉尼亚州) 198.32.64.12
M WIDE Project(日本,东京) 202.12.27.33

主要作用

在根域名服务器中虽然没有每个域名的具体信息,但储存了负责每个域(如COM、NET、ORG等)的解析的域名服务器的地址信息,如同通过北京电信你问不到广州市某单位的电话号码,但是北京电信可以告诉你去查020114。

世界上所有互联网访问者的浏览器的将域名转化为IP地址的请求(浏览器必须知道数字化的IP地址才能访问网站)理论上都要经过根服务器的指引后去该域名的权威域名服务器(authoritative name server, 如haier.com的权威域名服务器是dns1.hichina.com)上得到对应的IP地址,当然现实中提供接入服务的ISP的缓存域名服务器上可能已经有了这个对应关系(域名到IP地址)的缓存。

根域名服务器是架构因特网所必须的基础设施。

在国外,许多计算机科学家将根域名服务器称作“真理”(TRUTH),足见其重要性。

但是攻击整个因特网最有力、最直接,也是最致命的方法恐怕就是攻击根域名服务器了。

早在1997年7月,这些域名服务器之间自动传递了一份新的关于因特网地址分配的总清单,然而这份清单实际上是空白的。

这一人为失误导致了因特网出现最严重的局部服务中断,造成数天之内网面无法访问,电子邮件也无法发送。

遭遇攻击

在2002年的10月21日美国东部时间下午4:45开始,这13台服务器又遭受到了有史以来最为严重的也是规模最为庞大的一次网络袭击。

此次受到的攻击是DDoS攻击,超过常规数量30至40倍的数据猛烈地向这些服务器袭来并导致其中的9台不能正常运行。7台丧失了对网络通信的处理能力,另外两台也紧随其后陷于瘫痪。

10月21日的这次攻击对于普通用户来说可能根本感觉不到受到了什么影响。

如果仅从此次事件的“后果”来分析,也许有人认为“不会所有的根域名服务器都受到攻击,因此可以放心”,或者“根域名服务器产生故障也与自己没有关系”,还为时尚早。

但他们并不清楚其根本原因是:

  1. 并不是所有的根域名服务器全部受到了影响;
  2. 攻击在短时间内便告结束;
  3. 攻击比较单纯,因此易于采取相应措施。

由于目前对于DDoS攻击还没有什么特别有效的解决方案,设想一下如果攻击的时间再延长,攻击再稍微复杂一点,或者再多有一台服务器瘫痪,全球互联网将会有相当一部分网页浏览以及e-mail服务会彻底中断。

而且,我们更应该清楚地认识到虽然此次事故发生的原因不在于根域名服务器本身,而在于因特网上存在很多脆弱的机器,这些脆弱的机器植入DDoS客户端程序(如特洛伊木马),然后同时向作为攻击的根域名服务器发送信息包,从而干扰服务器的服务甚至直接导致其彻底崩溃。

但是这些巨型服务器的漏洞是肯定存在的,即使现在没有被发现,以后也肯定会被发现。

而一旦被恶意攻击者发现并被成功利用的话,将会使整个互联网处于瘫痪之中。

为什么只有13台dns根服务器

最后,让我们了解下全球DNS根服务器为什么只有13台。

DNS协议的最初定义要从20世纪80年代未期开始算起,它使用了端口上的UDP和TCP协议。

UDP通常用于查询和响应,TCP用于主服务器和从服务器之间的区传送.遗憾的是,在所有UDP实现中能保证正常工作的最大包长是512字节,对于在每个包中必须含有数字签名的一些DNS新特性(例如,DNSSEC)来说实在是太小了。

512字节的限制还影响了根服务器的数量和名字。

要让所有的根服务器数据能包含在一个512字节的UDP包中,根服务器只能限制在13个,而每个服务器要使用字母表中的单个字母命名。

以太网数据的长度必须在46-1500字节之间,这是由以太网的物理特性决定的。

事实上,这个1500字节就是网络层IP数据包的长度限制,理论上,IP数据包最大长度是65535字节。

这是由IP首部16比特总长度所限制的,去除20字节IP首部和8个字节UDP首部,UDP数据包中数据最大长度为65507字节。

在Internet数据传输中,UDP数据长度控制在576字节(Internet标准MTU值),而在许多UDP应用程序设计中数据包被限制成512字节或更小。这样可以防止数据包的丢失。

许多解析器首先发送一条UDP查询,如果它们接收到一条被截断的响应,则会用TCP重新发送该查询。

这个过程绕过了512字节的限制,但是效率不高。您或许认为DNS应该避开UDP,总是使用TCP,但是TCP连接的开销大得多。

一次UDP名字服务器交换可以短到两个包:一个查询包、一个响应包。一次TCP交换则至少包含7个包:三次握手初始化TCP会话、一个查询包、一个响应包以及最后一次握手来关闭连接。


摘自:

http://baike.baidu.com/view/704566.htm

http://baike.soso.com/v43303576.htm