《计算机网络:自顶向下方法(原书第6版)》一2.5 DNS:因特网的目录服务

简介:

本节书摘来华章计算机《计算机网络:自顶向下方法(原书第6版)》一书中的第2章 ,第2.5节,(美)James F.Kurose Keith W.Ross 著 陈 鸣 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.5 DNS:因特网的目录服务

人类能以很多方式来标识。例如,我们能够通过出生证书上的名字来标识;能够通过社会保险号码来标识;也能够通过驾驶执照上的号码来标识。尽管这些标识办法都可以用来识别一个人,但是在特定环境下,某种识别方法可能比另一种方法更为适合。例如,IRS(美国的一个声名狼藉的税务征收机构)的计算机更喜欢使用定长的社会保险号码而不是出生证书上的姓名。另一方面,普通人乐于使用更好记的出生证书上的姓名而不是社会保险号码。(毫无疑问,你能想象人们之间以这种方式说话吗?如“你好,我叫132-67-9875。请找一下我的丈夫178-87-1146”。)
因特网上的主机和人类一样,可以使用多种方式进行标识。主机的一种标识方法是用它的主机名(hostname),如cnn.com、www.yahoo.com、gaia.cs.umass.edu以及cis.poly.edu等,这些名字便于记忆也乐于被人们接受。然而,主机名几乎没有提供(即使有也很少)关于主机在因特网中位置的信息。(一个名为www.eurecom.fr的主机以国家码.fr结束,告诉我们该主机很可能在法国,仅此而已。)况且,因为主机名可能由不定长的字母数字组成,路由器难以处理。由于这些原因,主机也可以使用所谓IP地址(IP address)进行标识。
我们将在第4章更为详细地讨论IP地址,但现在简略地介绍一下还是有必要的。一个IP地址由4个字节组成,并有着严格的层次结构。例如121.7.106.83这样一个IP地址,其中的每个字节都被句点分隔开来,表示了0~255的十进制数字。我们说IP地址具有层次结构,是因为当我们从左至右扫描它时,我们会得到越来越具体的关于主机位于因特网何处的信息(即在众多网络的哪个网络里)。类似地,当我们从下向上查看邮政地址时,我们能够获得该地址位于何处的越来越具体的信息。

2.5.1 DNS提供的服务

我们刚刚看到了识别主机有两种方式,通过主机名或者IP地址。人们喜欢便于记忆的主机名标识方式,而路由器则喜欢定长的、有着层次结构的IP地址。为了折衷这些不同的偏好,我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统(Domain Name System,DNS)的主要任务。DNS是:①一个由分层的DNS服务器(DNS server)实现的分布式数据库;②一个使得主机能够查询分布式数据库的应用层协议。DNS服务器通常是运行BIND(Berkeley Internet Name Domain)软件[BIND 2012]的UNIX机器。DNS协议运行在UDP之上,使用53号端口。
image

DNS通常是由其他应用层协议所使用的,包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址。举一个例子,考虑当某个用户主机上的一个浏览器(即一个HTTP客户)请求URL www.someschool.edu/index.html页面时会发生什么现象。为了使用户的主机能够将一个HTTP请求报文发送到Web服务器www.someschool.edu,该用户主机必须获得www.someschool.edu的IP地址。其做法如下。

  • 同一台用户主机上运行着DNS应用的客户端。
  • 浏览器从上述URL中抽取出主机名www.someschool.edu,并将这台主机名传给DNS应用的客户端。
  • DNS客户向DNS服务器发送一个包含主机名的请求。
  • DNS客户最终会收到一份回答报文,其中含有对应于该主机名的IP地址。
  • 一旦浏览器接收到来自DNS的该IP地址,它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。

从这个例子中,我们可以看到DNS给使用它的因特网应用带来了额外的时延,有时还相当可观。幸运的是,如我们下面讨论的那样,想获得的IP地址通常就缓存在一个“附近的”DNS服务器中,这有助于减少DNS的网络流量和DNS的平均时延。
除了进行主机名到IP地址的转换外,DNS还提供了一些重要的服务:

  • 主机别名(host aliasing)。有着复杂主机名的主机能拥有一个或者多个别名。例如,一台名为relay1.west-coast.enterprise.com的主机,可能还有两个别名为enterprise.com和www.enterprise.com。在这种情况下,relay1.west-coast.enterprise.com也称为规范主机名(canonical hostname)。主机别名(当存在时)比主机规范名更加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。
  • 邮件服务器别名(mail server aliasing)。显而易见,人们也非常希望电子邮件地址好记忆。例如,如果Bob在Hotmail上有一个账户,Bob的邮件地址就像bob@hotmail.com这样简单。然而,Hotmail邮件服务器的主机名可能更为复杂,不像hotmail.com那样简单好记(例如,规范主机名可能像relay1.west-coast.hotmail.com那样)。电子邮件应用程序可以调用DNS,对提供的邮件服务器别名进行解析,以获得该主机的规范主机名及其IP地址。事实上,MX记录(参见后面)允许一个公司的邮件服务器和Web服务器使用相同(别名化的)的主机名;例如,一个公司的Web服务器和邮件服务器都能叫做enterprise.com。
  • 负载分配(load distribution)。DNS也用于在冗余的服务器(如冗余的Web服务器等)之间进行负载分配。繁忙的站点(如cnn.com)被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上,每个都有着不同的IP地址。由于这些冗余的Web服务器,一个IP地址集合因此与同一个规范主机名相联系。DNS数据库中存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个DNS请求时,该服务器用IP地址的整个集合进行响应,但在每个回答中循环这些地址次序。因为客户通常总是向IP地址排在最前面的服务器发送HTTP请求报文,所以DNS就在所有这些冗余的Web服务器之间循环分配了负载。DNS的循环同样可以用于邮件服务器,因此,多个邮件服务器可以具有相同的别名。一些内容分发公司如Akamai也以更加复杂的方式使用DNS[Dilley 2002],以提供Web内容分发(参见第7章)。

DNS由RFC 1034和RFC 1035定义,并且在几个附加的RFC中进行了更新。DNS是一个复杂的系统,我们在这里只是就其运行的主要方面进行学习。感兴趣的读者可以参考这些RFC文档和Albitz和Liu写的书[Albitz 1993];亦可参阅文章[Mockapetris 1998]和[Mockapetris 2005],其中[Mockapetris 1998]是回顾性的文章,它提供了DNS组成和工作原理的精细的描述。

2.5.2 DNS工作机理概述

下面给出一个DNS工作过程的总体概括,我们的讨论将集中在主机名到IP地址转换服务方面。
假设运行在用户主机上的某些应用程序(如Web浏览器或邮件阅读器)需要将主机名转换为IP地址。这些应用程序将调用DNS的客户端,并指明需要被转换的主机名(在很多基于UNIX的机器上,应用程序为了执行这种转换需要调用函数gethostbyname())。用户主机上的DNS接收到后,向网络中发送一个DNS查询报文。所有的DNS请求和回答报文使用UDP数据报经端口53发送。经过若干毫秒到若干秒的时延后,用户主机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果则被传递到调用DNS的应用程序。因此,从用户主机上调用应用程序的角度看,DNS是一个提供简单、直接的转换服务的黑盒子。但事实上,实现这个服务的黑盒子非常复杂,它由分布于全球的大量DNS服务器以及定义了DNS服务器与查询主机通信方式的应用层协议组成。
DNS的一种简单设计是在因特网上只使用一个DNS服务器,该服务器包含所有的映射。在这种集中式设计中,客户直接将所有查询直接发往单一的DNS服务器,同时该DNS服务器直接对所有的查询客户做出响应。尽管这种设计的简单性非常具有吸引力,但它不适用于当今的因特网,因为因特网有着数量巨大(并持续增长)的主机。这种集中式设计的问题包括:

  • 单点故障(a single point of failure)。如果该DNS服务器崩溃,整个因特网随之瘫痪!
  • 通信容量(traffic volume)。单个DNS服务器不得不处理所有的DNS查询(用于为上亿台主机产生的所有HTTP请求报文和电子邮件报文服务)。
  • 远距离的集中式数据库(distant centralized database)。单个DNS服务器不可能“邻近”所有查询客户。如果我们将单台DNS服务器放在纽约市,那么所有来自澳大利亚的查询必须传播到地球的另一边,中间也许还要经过低速和拥塞的链路。这将导致严重的时延。
  • 维护(maintenance)。单个DNS服务器将不得不为所有的因特网主机保留记录。这不仅将使这个中央数据库非常庞大,而且它还不得不为解决每个新添加的主机而频繁更新。

总的来说,在单一DNS服务器上运行集中式数据库完全没有可扩展能力。因此,DNS采用了分布式的设计方案。事实上,DNS是一个在因特网上实现分布式数据库的精彩范例。

image


1.分布式、层次数据库
为了处理扩展性问题,DNS使用了大量的DNS服务器,它们以层次方式组织,并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。相反,该映射分布在所有的DNS服务器上。大致说来,有3种类型的DNS服务器:根DNS服务器、顶级域(Top-Level Domain,TLD)DNS服务器和权威DNS服务器。这些服务器以图2-19中所示的层次结构组织起来。为了理解这3种类型的DNS服务器交互的方式,假定一个DNS客户要决定主机名www.amazon.com的IP地址。粗略说来,将发生下列事件。客户首先与根服务器之一联系,它将返回顶级域名com的TLD服务器的IP地址。该客户则与这些TLD服务器之一联系,它将为amazon.com返回权威服务器的IP地址。最后,该客户与amazon.com权威服务器之一联系,它为主机名www.amazon.com返回其IP地址。我们将很快更为详细地考察DNS查找过程。不过我们先仔细看一下这3种类型的DNS服务器。

  • 根DNS服务器。在因特网上有13个根DNS服务器(标号为A到M),它们中的大部分位于北美洲。图2-20中显示的是一张2012年的根DNS服务器分布图;通过[Root-servers 2012]可查看当前可用的根DNS服务器列表。尽管我们将这13个根DNS服务器中的每个都视为单个的服务器,但每台“服务器”实际上是一个冗余服务器的网络,以提供安全性和可靠性。到了2011年秋季,共有247个根服务器。
  • 顶级域(DNS)服务器。这些服务器负责顶级域名如com、org、net、edu和gov,以及所有国家的顶级域名如uk、fr、ca和jp。Verisign Global Registry Services公司维护com顶级域的TLD服务器;Educause公司维护edu顶级域的TLD服务器。所有顶级域的列表参见[IANA TLD 2012]。
  • 权威DNS服务器。在因特网上具有公共可访问主机(如Web服务器和邮件服务器)的每个组织机构必须提供公共可访问的DNS记录,这些记录将这些主机的名字映射为IP地址。一个组织机构的权威DNS服务器收藏了这些DNS记录。一个组织机构能够选择实现它自己的权威DNS服务器以保存这些记录;另一种方法是,该组织能够支付费用,让这些记录存储在某个服务提供商的一个权威DNS服务器中。多数大学和大公司实现和维护它们自己基本和辅助(备份)的权威DNS服务器。


image


根、TLD和权威DNS服务器都处在该DNS服务器的层次结构中,如图2-19中所示。还有另一类重要的DNS,称为本地DNS服务器(local DNS server)。一个本地DNS服务器严格说来并不属于该服务器的层次结构,但它对DNS层次结构是重要的。每个ISP(如一个大学、一个系、一个公司或一个居民区的ISP)都有一台本地DNS服务器(也叫默认名字服务器)。当主机与某个ISP连接时,该ISP提供一台主机的IP地址,该主机具有一台或多台其本地DNS服务器的IP地址(通常通过DHCP,将在第4章中讨论)。通过访问Windows或UNIX的网络状态窗口,能够容易地确定你本地DNS服务器的IP地址。主机的本地DNS服务器通常“邻近”本主机。对某机构ISP而言,本地DNS服务器可能就与主机在同一个局域网中;对于某居民区ISP来说,本地DNS服务器通常与主机相隔不超过几台路由器。当主机发出DNS请求时,该请求被发往本地DNS服务器,它起着代理的作用,并将该请求转发到DNS服务器层次结构中,我们下面将更为详细地讨论。
我们来看一个简单的例子,假设主机cis.poly.edu想知道主机gaia.cs.umass.edu的IP地址。同时假设理工大学(Polytechnic)的本地DNS服务器为dns.poly.edu,并且gaia.cs.umass.edu的权威DNS服务器为dns.umass.edu。

image


如图2-21所示, 图2-21 各种DNS服务器的交互主机cis.poly.edu首先向它的本地DNS服务器dns.poly.edu发送一个DNS查询报文。该查询报文含有被转换的主机名gaia.cs.umass.edu。本地DNS服务器将该报文转发到根DNS服务器。该根DNS服务器注意到其edu前缀并向本地DNS服务器返回负责edu的TLD的IP地址列表。该本地DNS服务器则再次向这些TLD服务器之一发送查询报文。该TLD服务器注意到umass.edu前缀,并用权威DNS服务器的IP地址进行响应,该权威DNS服务器是负责马萨诸塞大学的dns.umass.edu。最后,本地DNS服务器直接向dns.umass.edu重发查询报文,dns.umass.edu用gaia.cs.umass.edu的IP地址进行响应。注意到在本例中,为了获得一台主机名的映射,共发送了8份DNS报文:4份查询报文和4份回答报文!我们将很快看到利用DNS缓存减少这种查询流量的方法。
我们前面的例子假设了TLD服务器知道用于主机的权威DNS服务器的IP地址。一般而言,这种假设并不总是正确的。相反,TLD服务器只是知道中间的某个DNS服务器,该中间DNS服务器依次才能知道用于该主机的权威DNS服务器。例如,再次假设马萨诸塞大学有一台用于本大学的DNS服务器,它称为dns.umass.edu。同时假设该大学的每个系都有自己的DNS服务器,每个系的DNS服务器是本系所有主机的权威服务器。在这种情况下,当中间DNS服务器dns.umass.edu收到了对某主机的请求时,该主机名是以cs.umass.edu结尾,它向dns.poly.edu返回dns.cs.umass.edu的IP地址,后者是所有以cs.umass.edu结尾的主机的权威服务器。本地DNS服务器dns.poly.edu则向权威DNS服务器发送查询,该权威DNS服务器将请求的映射发送给本地DNS服务器,该本地服务器依次向请求主机返回该映射。在这个例子中,共发送了10份DNS报文!

image


图2-21所示的例子利用了递归查询(recursive query)和迭代查询(iterative query)。从cis.poly.edu到dns.poly.edu发出的查询是递归查询,因为该查询请求dns.poly.edu以自己的名义获得该映射。而后继的3个查询是迭代查询,因为所有的回答都是直接返回给dns.poly.edu。从理论上讲,任何DNS查询既可以是迭代的也能是递归的。 图2-22 DNS中的递归查询例如,图2-22显示了一条DNS查询链,其中的所有查询都是递归的。实践中,查询通常遵循图2-21中的模式。从请求主机到本地DNS服务器的查询是递归的,其余的查询是迭代的。
2.DNS缓存
至此我们的讨论还没有涉及DNS系统的一个非常重要特色:DNS缓存(DNS caching)。实际上,为了改善时延性能并减少在因特网上到处传输的DNS报文数量,DNS广泛使用了缓存技术。DNS缓存的原理非常简单。在一个请求链中,当某DNS服务器接收一个DNS回答(例如,包含主机名到IP地址的映射)时,它能将该回答中的信息缓存在本地存储器中。例如,在图2-21中,每当本地DNS服务器dns.poly.edu从某个DNS服务器接收到一个回答,它能够缓存包含在该回答中的任何信息。如果在DNS服务器中缓存了一台主机名/IP地址对,另一个对相同主机名的查询到达该DNS服务器时,该DNS服务器就能够提供所要求的IP地址,即使它不是该主机名的权威服务器。由于主机和主机名与IP地址间的映射并不是永久的,DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。
举一个例子,假定主机apricot.poly.edu向dns.poly.edu查询主机名cnn.com的IP地址。此后,假定过了几个小时,Polytechnic理工大学的另外一台主机如kiwi.poly.edu也向dns.poly.edu查询相同的主机名。因为有了缓存,该本地DNS服务器可以立即返回cnn.com的IP地址,而不必查询任何其他DNS服务器。本地DNS服务器也能够缓存TLD服务器的IP地址,因而允许本地DNS绕过查询链中的根DNS服务器(这经常发生)。

2.5.3 DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record,RR),RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。在本小节以及后续小节中,我们概要地介绍DNS资源记录和报文;更详细的信息可以在[Albitz 1993]或有关DNS的RFC文档[RFC 1034;RFC 1035]中找到。
资源记录是一个包含了下列字段的4元组:
(Name,Value,Type,TTL)
TTL是该记录的生存时间,它决定了资源记录应当从缓存中删除的时间。在下面给出的记录例子中,我们忽略掉TTL字段。Name和Value的值取决于Type:

  • 如果Type=A,则Name是主机名,Value是该主机名对应的IP地址。因此,一条类型为A的资源记录提供了标准的主机名到IP地址的映射。例如(relay1.bar.foo.com,145.37.93.126,A)就是一条类型A记录。
  • 如果Type=NS,则Name是个域(如foo.com),而Value是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。这个记录用于沿着查询链来路由DNS查询。例如(foo.com,dns.foo.com,NS)就是一条类型为NS的记录。
  • 如果Type=CNAME,则Value是别名为Name的主机对应的规范主机名。该记录能够向查询的主机提供一个主机名对应的规范主机名,例如(foo.com,relay1.bar.foo.com,CNAME)就是一条CNAME类型的记录。
  • 如果Type=MX,则Value是个别名为Name的邮件服务器的规范主机名。举例来说,(foo.com,mail.bar.foo.com,MX)就是一条MX记录。MX记录允许邮件服务器主机名具有简单的别名。值得注意的是,通过使用MX记录,一个公司的邮件服务器和其他服务器(如它的Web服务器)可以使用相同的别名。为了获得邮件服务器的规范主机名,DNS客户应当请求一条MX记录;而为了获得其他服务器的规范主机名,DNS客户应当请求CNAME记录。

如果一台DNS服务器是用于某特定主机名的权威DNS服务器,那么该DNS服务器会有一条包含该主机名的类型A记录(即使该DNS服务器不是其权威DNS服务器,它也可能在缓存中包含有一条类型A记录)。如果服务器不是用于某主机名的权威服务器,那么该服务器将包含一条类型NS记录,该记录对应于包含主机名的域;它还将包括一条类型A记录,该记录提供了在NS记录的Value字段中的DNS服务器的IP地址。举例来说,假设一台edu TLD服务器不是主机gaia.cs.umass.edu的权威DNS服务器,则该服务器将包含一条包括主机cs.umass.edu的域记录,如(umass.edu,dns.umass.edu,NS);该edu TLD服务器还将包含一条类型A记录,如(dns.umass.edu,128.119.40.111,A),该记录将名字dns.umass.edu映射为一个IP地址。
1.DNS报文
在本节前面,我们提到了DNS查询和回答报文。DNS只有这两种报文,并且,查询和回答报文有着相同的格式,如图2-23所示。DNS报文中各字段的语义如下:

image


图2-23 DNS报文格式前12个字节是首部区域,其中有几个字段。第一个字段(标识符)是一个16比特的数,用于标识该查询。这个标识符会被复制到对查询的回答报文中,以便让客户用它来匹配发送的请求和接收到的回答。标志字段中含有若干标志。1比特的“查询/回答”标志位指出报文是查询报文(0)还是回答报文(1)。当某DNS服务器是所请求名字的权威DNS服务器时,1比特的“权威的”标志位被置在回答报文中。如果客户(主机或者DNS服务器)在该DNS服务器没有某记录时希望它执行递归查询,将设置1比特的“希望递归”标志位。如果该DNS服务器支持递归查询,在它的回答报文中会对1比特的“递归可用”标志位置位。在该首部中,还有4个有关数量的字段,这些字段指出了在首部后的4类数据区域出现的数量。

  • 问题区域包含着正在进行的查询信息。该区域包括:①名字字段,指出正在被查询的主机名字;②类型字段,它指出有关该名字的正被询问的问题类型,例如主机地址是与一个名字相关联(类型A)还是与某个名字的邮件服务器相关联(类型MX)。
  • 在来自DNS服务器的回答中,回答区域包含了对最初请求的名字的资源记录。前面讲过每个资源记录中有Type(如A、NS、CNAME和MX)字段、Value字段和TTL字段。在回答报文的回答区域中可以包含多条RR,因此一个主机名能够有多个IP地址(例如,就像本节前面讨论的冗余Web服务器)。
  • 权威区域包含了其他权威服务器的记录。
  • 附加区域包含了其他有帮助的记录。例如,对于一个MX请求的回答报文的回答区域包含了一条资源记录,该记录提供了邮件服务器的规范主机名。该附加区域包含一个类型A记录,该记录提供了用于该邮件服务器的规范主机名的IP地址。

你愿意从正在工作的主机直接向某些DNS服务器发送一个DNS查询报文吗?使用nslookup程序(nslookup program)能够容易地做到这一点,对于多数Windows和UNIX平台,nslookup程序是可用的。例如,从一台Windows主机打开命令提示符界面,直接键入“nslookup”即可调用该nslookup程序。在调用nslookup后,你能够向任何DNS服务器(根、TLD或权威)发送DNS查询。在接收到来自DNS服务器的回答后,nslookup将显示包括在该回答中的记录(以人可读的格式)。从你自己的主机运行nslookup还有一种方法,即访问允许你远程应用nslookup的许多Web站点之一(在一个搜索引擎中键入“nslookup”就能够得到这些站点中的一个)。本章最后的DNS Wireshark实验将使你更为详细地研究DNS。
2.在DNS数据库中插入记录
上面的讨论只是关注如何从DNS数据库中取数据。你可能想知道这些数据最初是怎么进入数据库中的。我们在一个特定的例子中看看这是如何完成的。假定你刚刚创建一个称为网络乌托邦(Network Utopia)的令人兴奋的新创业公司。你必定要做的第一件事是在注册登记机构注册域名networkutopia.com。注册登记机构(registrar)是一个商业实体,它验证该域名的唯一性,将该域名输入DNS数据库(如下面所讨论的那样),对提供的服务收取少量费用。1999年前,唯一的注册登记机构是Nework Solution,它独家经营对于com、net和org域名的注册。但是现在有许多注册登记机构竞争客户,因特网名字和地址分配机构(Internet Corporation for Assigned Names and Numbers,ICANN)向各种注册登记机构授权。在http://www.internic.net上可以找到授权的注册登记机构的列表。
当你向某些注册登记机构注册域名networkutopia.com时,需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址。假定该名字和IP地址是dns1.networkutopia.com和dns2.networkutopia.com及212.212.212.1和212.212.212.2。对这两个权威DNS服务器的每一个,该注册登记机构确保将一个类型NS和一个类型A的记录输入TLD com服务器。特别是对于用于networkutopia.com的基本权威服务器,该注册登记机构将下列两条资源记录插入该DNS系统中:
image

你还必须确保用于Web服务器www.networkutopia.com的类型A资源记录和用于邮件服务器mail.networkutopia.com的类型MX资源记录被输入你的权威DNS服务器中。(直到最近,每个DNS服务器中的内容都是静态配置的,例如来自系统管理员创建的配置文件。最近,在DNS协议中添加了一个更新(UPDATE)选项,允许通过DNS报文对数据库中的内容进行动态添加或者删除。[RFC 2136]和[RFC 3007]定义了DNS动态更新。)
一旦完成所有这些步骤,人们将能够访问你的Web站点,并向你公司的雇员发送电子邮件。我们通过验证该说法的正确性来总结DNS的讨论。这种验证也有助于充实我们已经学到的DNS知识。假定在澳大利亚的Alice要观看www.networkutopia.com的Web页面。如前面所讨论,她的主机将首先向其本地DNS服务器发送请求。该本地服务器接着则联系一个TLD com服务器。(如果TLD com服务器的地址没有被缓存,该本地DNS服务器也将必须与根DNS服务器相联系。)该TLD服务器包含前面列出的类型NS和类型A资源记录,因为注册登记机构将这些资源记录插入所有的TLD com服务器。该TLD com服务器向Alice的本地DNS服务器发送一个回答,该回答包含了这两条资源记录。该本地DNS服务器则向212.212.212.1发送一个DNS查询,请求对应于www.networkutopia.com的类型A记录。该记录提供了所希望的Web服务器的IP地址,如212.212.71.4,本地DNS服务器将该地址回传给Alice的主机。Alice的浏览器此时能够向主机212.212.71.4发起一个TCP连接,并在该连接上发送一个HTTP请求。当一个人在网上冲浪时,有比满足眼球更多的事情在进行!
image

image

相关文章
|
7天前
|
监控 负载均衡 Cloud Native
ZooKeeper分布式协调服务详解:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析ZooKeeper分布式协调服务原理,涵盖核心概念如Server、Client、ZNode、ACL、Watcher,以及ZAB协议在一致性、会话管理、Leader选举中的作用。讨论ZooKeeper数据模型、操作、会话管理、集群部署与管理、性能调优和监控。同时,文章探讨了ZooKeeper在分布式锁、队列、服务注册与发现等场景的应用,并在面试方面分析了与其它服务的区别、实战挑战及解决方案。附带Java客户端实现分布式锁的代码示例,助力提升面试表现。
28 2
|
25天前
|
机器学习/深度学习 算法 PyTorch
RPN(Region Proposal Networks)候选区域网络算法解析(附PyTorch代码)
RPN(Region Proposal Networks)候选区域网络算法解析(附PyTorch代码)
180 1
|
26天前
|
存储 安全 网络安全
云端防御策略:融合云服务与网络安全的未来之路
在数字化浪潮的推动下,企业纷纷转向云计算以获取灵活性、可扩展性和成本效益。然而,随之而来的是日益复杂的网络威胁,它们挑战着传统的安全边界。本文将探讨如何通过创新的云服务模型和先进的网络安全措施来构建一个既可靠又灵活的安全框架。我们将分析云计算环境中的关键安全挑战,并提出一系列针对性的策略来加强数据保护,确保业务连续性,并满足合规要求。
28 2
|
28天前
|
缓存 网络协议 Linux
【Shell 命令集合 网络通讯 】Linux 配置DNS dnsconf 命令 使用教程
【Shell 命令集合 网络通讯 】Linux 配置DNS dnsconf 命令 使用教程
38 0
|
2天前
|
运维 安全 Cloud Native
安全访问服务边缘(SASE):网络新时代的安全与连接解决方案
SASE(安全访问服务边缘)是一种云基安全模型,结合了网络功能和安全策略,由Gartner在2019年提出。它强调身份驱动的私有网络、云原生架构和全面边缘支持,旨在解决传统WAN和安全方案的局限性,如高延迟和分散管理。SASE通过降低IT成本、提升安全响应和网络性能,应对数据分散、风险控制和访问速度等问题,适用于移动办公、多分支办公等场景。随着网络安全挑战的增加,SASE将在企业的数字化转型中扮演关键角色。
|
8天前
|
存储 安全 测试技术
网络奇谭:虚拟机中的共享、桥接与Host-Only模式解析
网络奇谭:虚拟机中的共享、桥接与Host-Only模式解析
15 0
|
21天前
|
缓存 网络协议 数据库连接
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
20 0
|
26天前
|
SQL 安全 网络安全
构筑数字堡垒:网络安全漏洞解析与防御策略
在数字化时代,网络安全已成为维护信息完整性、保障用户隐私和确保商业连续性的关键。本文将深入探讨网络安全领域的核心议题—安全漏洞及其防御机制。通过分析常见网络攻击手段,如SQL注入、跨站脚本攻击(XSS)及拒绝服务(DoS)攻击,揭示其背后的原理与潜在危害。同时,文章将重点介绍加密技术的种类和应用场景,以及如何通过强化安全意识,构建多层次的防御体系来有效预防和应对网络安全威胁。本研究旨在为读者提供一份系统性的网络安全防护指南,帮助个人和组织在不断演变的威胁面前保持警惕,并采取适当的安全措施。
20 2
|
29天前
|
存储 运维 安全
SDN 网络编排与服务
【2月更文挑战第30天】网络编排是基于业务需求,对逻辑网络服务进行有序组织和安排,通过控制器构建满足需求的网络服务。
|
1月前
|
域名解析 缓存 网络协议
探索Qt 网络编程:网络地址与服务类全解析
探索Qt 网络编程:网络地址与服务类全解析
54 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多