尽管电子邮件应用在因特网上的独特地位可以证明SMTP有着众多非常出色的性质，但它所具有的某种陈旧特征表明它仍然是一种继承的技术限制所有邮件报文的体部分(不只是其首部)只能采用简单的7比特ASCII表示。在20世纪80年代早期，这种限制是明智的，因为当时传输能力不足，没有人会通过电子邮件发送大的附件或是大的图片、声音或者视频文件。然而，在今天的多媒体时代，7位ASCII的限制的确有点痛苦，即在用SMTP传送邮件之前，需要将二进制多媒体数据编码ASCII 码，并且在使用SMTP传输后要求将相应的ASCII码邮件解码还原为多媒体数据。

用SMTP传输一个邮件的过程
?

1) A调用她的邮件代理程序并提供B的邮件地址(例如b@ someschoo. edu)，撰写报文，然后指示用户代理发送该报文。
2) A?的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。
3)运行在A的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就创建一个到运行在B的邮件服务器上的SMTP服务器的TCP连接。
4)在经过一些初始SMTP握手后，SMTP客户通过该TCP连接发送A?的报文。
5)在B的邮件服务器上，SMTP的服务器端接收该报文。B的邮件服务器然后将该报文放人B的邮箱中。
6)在B方便的时候，他调用用户代理阅读该报文。

SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。

假设A的邮件服务器在中国香港，而B的服务器在美国圣路易斯，那么这个TCP连接也是从香港服务器到圣路易斯服务器之间的直接相连。特别是，如果B的邮件服务器没有开机，该报文会保留在A的邮件服务器上等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留。

SMTP是如何将一个报文从发送邮件服务器传送到接收邮件服务器的。

简单地说，SMTP与人类面对面交往的行为方式有许多类似性。

首先，客户SMTP (运行在发送邮件服务器主机上)在25号端口建立一个到服务器SMTP (运行在接收邮件服务器主机上)的TCP连接。如果服务器没有开机，客户会在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手，就像人们在互相交流前先进行自我介绍一样。SMTP的客户和服务器在传输信息前先相互介绍。在SMTP握手的阶段，SMTP客户指示发送方的邮件地址(产生报文的那个人)和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后，客户发送该报文。SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理;否则，它指示TCP关闭连接。

SMTP与HTTP的区别

共同点

这两个协议都用于从一台主机向另一台主机传送文件:

HTTP从Web服务器向Web客户(通常是一个浏览器)传送文件(也称为对象);

SMTP从一个邮件服务器向另一个邮件服务器传送文件( 即电子邮件报文)。

当进行文件传送时，持续的HTTP和SMTP都使用持续连接。因此，这两个协议有一些共同特征。

不同点

（1）HTTP主要是一个拉协议( pull protocol),即在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息。特别是TCP连接是由想接收文件的机器发起的。另一方面，SMTP基本上是一个推协议( push protocol),即发送邮件服务器把文件推向接收邮件服务器。特别是，这个TCP连接是由要发送该文件的机器发起的。
（2）SMTP 要求每个报文( 包括它们的体)采用7比特ASCII码格式。如果某报文包含了非7比特ASCII字符(如具有重音的法文字符)或二进制数据(如图形文件)，则该报文必须按照7比特ASCII码进行编码。HTTP 数据则不受这种限制。
（3）对于处理一个既包含文本又包含图形(也可能是其他媒体类型)的文档。HTTP 把每个对象封装到它自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文之中。

邮件报文格式

每个首部必须含有一个From:首部行和一个To:首部行;一个首部也许包含一个Subject:首部行以及其他可选的首部行。如下：

From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.

在报文首部之后，紧接着一个空白行，然后是以ACSII格式表示的报文体。

邮件访问协议

（1）如果一旦SMTP将邮件报文从A的邮件服务器交付给B的邮件服务器，该报文就被放入了B?的邮箱中。我们假定B是通过登录到服务器主机，并直接在该主机上运行一个邮件阅读程序来阅读他的邮件的。直到20世纪90年代早期，这都是一种标准方式。而在今天，邮件访问使用了一种客户——服务器体系结构，即典型的用户通过在用户端系统上运行的客户程序来阅读电子邮件，这里的端系统可能是办公室的PC、便携机或者是智能手机。通过在本地主机上运行邮件客户程序，用户享受一系列丰富的特性，包括查看多媒体报文和附件的能力。

（2）假设B(接收方)在其本地PC上运行用户代理程序，考虑在他的本地PC上也放置一个邮件服务器是自然而然的事。在这种情况下，A的邮件服务器就能直接与B的PC进行对话了。然而这种方法会有一个问题。前面说过邮件服务器管理用户的邮箱，并且运行SMTP的客户端和服务器端。如果B的邮件服务器位于他的PC上，那么为了能够及时接收可能在任何时候到达的新邮件，他的PC必须总是不间断地运行着并一直保持在线。这对于许多因特网用户而言是不现实的。相反，典型的用户通常在本地PC上运行一个用户代理程序，而它访问存储在总是保持开机的共享邮件服务器上的邮箱。该邮件服务器与其他用户共享，并且通常由用户的ISP进行维护(如大学或公司)。

现在我们考虑当从A向B发送一个电子邮件报文时所取的路径。我们刚才已经知道，在沿着该路径的某些点上，需要将电子邮件报文存放在B的邮件服务器上。通过让A的用户代理直接向B?的邮件服务器发送报文，就能够做到这一点。这能够由SMTP来完成；实际上，SMTP被设计成将电子邮件从一台主机推到另一台主机。然而，通常A的用户代理和B的邮件服务器之间并没有一个直接的SMTP对话。相反，如图所示，A的用户代理用SMTP将电子邮件报文推入她的邮件服务器，接着她的邮件服务器(作为一个SMTP客户)再用SMTP将该邮件中继到B的邮件服务器。

?那为什么该过程要分成两步呢?

因为不通过A的邮件服务器进行中继，A的用户代理将没有任何办法到达一个不可达的目的地接收服务器。通过首先将邮件存放在自己的邮件服务器中，A的邮件服务器可以重复地尝试向B的邮件服务器发送该报文，如每30分钟一次，直到Bob的邮件服务器变得运行为止。(并且如果A的邮件服务器关机，她则能向系统管理员进行申告!) SMTP RFC文档定义了如何使用SMTP命令经过多个SMTP服务器进行报文中继。

如果像B这样的接收方，是如何通过运行其本地PC上的用户代理，获得位于他的某ISP的邮件服务器上的邮件呢?值得注意的是Bob的用户代理不能使用SMTP得到报文，因为取报文是一个拉操作，而SMTP协议是一个推协议。通过引入一个特殊的邮件访问协议来解决这个难题，该协议将Bob邮件服务器上的报文传送给他的本地PC。目前有一些流行的邮件访问协议，包括第三版的邮局协议( PostOffice Protocol Version 3，POP3)、因特网邮件访问协议( Internet Mail Access Protocol ，IMAP)以及HTTP。

POP3

POP3是一个极为简单的邮件访问协议，由RFC 1939进行定义。文档RFC 1939简短且可读性强。因为该协议非常简单，故其功能相当有限。

当用户代理(客户)打开了一个到邮件服务器(服务器)端口110上的TCP连接后，POP3 就开始工作了。随着建立TCP连接，POP3 按照三个阶段进行工作:特许( authorization)、事务处理以及更新。

特许阶段：用户代理发送(以明文形式)用户名和口令以鉴别用户。
事务处理阶段：用户代理取回报文;同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。
更新阶段：它出现在客户发出了quit命令之后，目的是结束该POP3会话;这时，该邮件服务器删除那些被标记为删除的报文。

在POP3的事务处理过程中，用户代理发出一些命令，服务器对每个命令做出回答。回答可能有两种:

+OK(有时后面还跟有服务器到客户的数据)，被服务器用来指示前面的命令是正常的;
-ERR,被服务器用来指示前面的命令出现了某些差错。

特许阶段有两个主要的命令: user < user name>和pass < password>。建议直接用Telnet登录到POP3服务器的110端口，然后发出这两个命令。假设邮件服务器的名字为mailServer,那么你将看到类似的过程:

telnet mailServer 110
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged on

如果你的命令拼写错了，该POP3服务器将返回一个ERR报文。

事务处理过程。使用POP3的用户代理通常被用户配置为“下载并删除”或者“下载并保留”方式。POP3用户代理发出的命令序列取决于用户代理程序被配置为这两种工作方式的哪一种。使用下载并删除方式，用户代理发出list、retr 和dele命令。举例来说，假设用户在他(她)的邮箱里有两个报文。在下面的对话中，C: (代表客户)是用户代理，S: (代表服务器)是邮件服务器。事务处理过程将类似于如下过程:

C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: (blah blah...
S: ...................
S: ..........blah)
S: .
C: dele 1
C: retr 2
S: (blah blah ...
S: ..................
S: ..........blah)
S: .
C: dele 2
C: quit
S: +OK POP3 server. signing off

用户代理首先请求邮件服务器列出所有存储的报文的长度。接着用户代理从邮件服务器取回并删除每封邮件。注意到在特许阶段以后，用户代理仅使用四个命令list、retr、 dele和quit,这些命令的语法定义在RFC 1939中。

在处理quit命令后，POP3服务器进入更新阶段，从用户的邮箱中删除邮件1和2。使用下载并删除方式存在的问题是，邮件接收方B可能是移动的，可能希望从多个不同的机器访问他的邮件报文，如从办公室的PC、家里的PC或他的便携机来访问邮件。下载并删除方式将对Bob的邮件报文根据这了台机器进行划分，特别是如果B最先是在他办公室的PC上收取了一条邮件，那么晚上当他在家里时，通过他的便携机将不能再收取该邮件。使用下载并保留方式，用户代理下载某邮件后，该邮件仍保留在邮件服务器上。这时，B就能通过不同的机器重新读取这些邮件;他能在工作时收取一封报文，而在工作回家后再次访问它。

在用户代理与邮件服务器之间的POP3会话期间，该POP3服务器保留了一些状态信息；特别是记录了哪些用户报文被标记为删除了。然而，POP3 服务器并不在POP3会话过程中携带状态信息。会话中不包括状态信息大大简化了POP3服务的实现。

IMAP

在使用POP3访问时，一旦B将邮件下载到本地主机后，他就能建立邮件文件夹，并将下载的邮件放人该文件夹中。然后B可以删除报文，在文件夹之间移动报文，并查询报文(通过发送方的名字或报文主题)。

如果换个一台机器，就看不到这个文件夹，能不能把这些文件夹创建在服务器呢？

使用POP3是不可能做到这一点的，POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。为了解决这个或其他一些问题，由RFC 3501定义的因特网邮件访问协议(IMAP) 应运而生。

和POP3一样，IMAP是一个邮件访问协议，但是它比POP3具有更多的特色，不过也比POP3复杂得多。( 因此客户和服务器端的实现也都复杂得多。)IMAP服务器把每个报文与一个文件夹联系起来;当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP 协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。值得注意的是，与POP3不同，IMAP服务器维护了IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联。

IMAP的另一个重要特性是它具有允许用户代理获取报文某些部分的命令。例如，一个用户代理可以只读取一个报文的报文首部，或只是一个多部分MIME报文的一部分。当用户代理和其邮件服务器之间使用低带宽连接(如一个低速调制解调器链路)的时候，这个特性非常有用。使用这种低带宽连接时，用户可能并不想取回他邮箱中的所有邮件，尤其要避免可能包含如音频或视频片断的大邮件。

基于Web的电子邮件

使用这种服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。当一个收件人(如B)，想从他的邮箱中访问一个报文时，该电子邮件报文从B的邮件服务器发送到他的浏览器，使用的是HTTP而不是POP3或者IMAP协议。当发件人(如A)要发送一封电子邮件报文时，该电子邮件报文从A的浏览器发送到她的邮件服务器，使用的是HTTP而不是SMTP。然而，Alice的邮件服务器在与其他的邮件服务器之间发送和接收邮件时，仍然使用的是SMTP。

DNS

DNS:因特网的目录结构

因特网上的主机和人类一样，可以使用多种方式进行标识。主机的一种标识方法是用它的主机名( hostname)，如www. facebook. com、www. google. com、gaia. cs. umass. edu以及cis. poly. edu等，这些名字便于记忆也乐于被人们接受。然而，主机名几乎没有提供(即使有也很少)关于主机在因特网中位置的信息。(一个名为www. eurecom. fr的主机以国家码. fr结束，告诉我们该主机很可能在法国，仅此而已。)

因为主机名可能由不定长的字母数字组成，路由器难以处理。由于这些原因，主机也可以使用所谓IP地址( IP address)进行标识。

一个IP地址由4个字节组成，并有着严格的层次结构。例如121.7. 106.83这样一个IP地址，其中的每个字节都被句点分隔开来，表示了0~255的十进制数字。我们说IP地址具有层次结构，是因为当我们从左至右扫描它时，我们会得到越来越具体的关于主机位于因特网何处的信息( 即在众多网络的哪个网络里)。类似地，当我们从下向上查看邮政地址时，我们能够获得该地址位于何处的越来越具体的信息。

DNS提供的服务

识别主机有两种方式，通过主机名或者IP地址。人们喜欢便于记忆的主机名标识方式，而路由器则喜欢定长的、有着层次结构的IP地址。为了折中这些不同的偏好，我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统( Domain Name System, DNS)的主要任务。

（1）DNS 是一个由分层的DNS服务器(DNSserver)实现的分布式数据库;
（2）DNS 是一个使得主机能够查询分布式数据库的应用层协议。DNS服务器通常是运行BIND ( Berkeley Internet Name Domain) 软件[ BIND 2012]的UNIX机器。DNS协议运行在UDP之上，使用53号端口。

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址。

举一个例子，考虑运行在某用户主机上的一个浏览器( 即一个HTTP客户)请求URL www.someschool. edu/ index. html页面时会发生什么现象。为了使用户的主机能够将一个HTTP请求报文发送到Web服务器www. someschool. edu，该用户主机必须获得www. someschool. edu的IP地址。其做法如下。

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

从这个例子中，我们可以看到DNS给使用它的因特网应用带来了额外的时延，有时还相当可观。

幸运的是，想获得的IP地址通常就缓存在一个“附近的”DNS服务器中，这有助于减少DNS的网络流量和DNS的平均时延。

除了进行主机名到IP地址的转换外，DNS还提供了一些重要的服务:

主机别名(host aliasing)。有着复杂主机名的主机能拥有一个或者多个别名。例如，一台名为relay1. west- coast. enterprise. com的主机，可能还有两个别名为enter-prise. com和www.enterprise. com。在这种情况下，relayl. west- coast. enterprise. com也称为规范主机名( canonical hostname)。主机别名( 当存在时)比主机规范名更加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。
邮件服务器别名(mailserveraliasing)。显而易见，人们也非常希望电子邮件地址好记忆。例如，如果B在雅虎邮件上有一个账户，B的邮件地址就像b@ ya-hoo. com这样简单。然而，雅虎邮件服务器的主机名可能更为复杂，不像ya-hoo. 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内容分发。

DNS的工作原理

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

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

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

分布式、层次数据库

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。相反，这些映射分布在所有的DNS服务器上。大致说来，有3种类型的DNS服务器：根DNS服务器、顶级域(Top- Level Domain, TLD) DNS服务器和权威DNS服务器。这些服务器以图所示的层次结构组织起来。

假定一个DNS客户要决定主机名www. amazon. com的IP地址。粗略说来，将发生下列事件。客户首先与根服务器之一联系，它将返回顶级域名com的TLD服务器的IP地址。该客户则与这些TLD服务器之一联系，它将为amazon. com返回权威服务器的IP地址。最后，该客户与amazon. com权威服务器之一联系，它为主机名www. amazon. com返回其IP地址。我们将很快更为详细地考察DNS查找过程。不过我们先仔细看一下这3种类型的DNS服务器。

根DNS服务器。有400多个根名字服务器遍及全世界。这些根名字服务器由13?个不同的组织管理。根名字服务器的全部清单连同管理它们的组织及其IP地址可以在[RootServers2016]中找到。根名字服务器提供TLD服务器的IP地址。
顶级域(DNS)服务器。对于每个顶级域(如com、org、net、 edu 和gov)和所有国家的顶级域(如uk、fr、ca和jp)，都有TLD服务器(或服务器集群)。VerisignGlobal Registry Services公司维护com顶级域的TLD服务器，Educause 公司维护edu顶级域的TLD服务器。支持TLD的网络基础设施可能是大而复杂的，[ Osterweil2012]对Verisign 网络进行了很好的概述。所有顶级域的列表参见[TLD list .2016]。TLD服务器提供了权威DNS服务器的IP地址。
权威DNS服务器。在因特网上具有公共可访问主机(如Web服务器和邮件服务器)的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。一个组织机构的权威DNS服务器收藏了这些DNS记录。一个组织机构能够选择实现它自已的权威DNS服务器以保存这些记录;另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威DNS服务器中。多数大学和大公司实现和维护它们自己基本和辅助( 备份)的权威DNS服务器。
?

还有另一类重要的DNS服务器，称为本地DNS服务器( local DNServer)。严格说来，一个本地DNS服务器并不属于该服务器的层次结构，但它对DNS层次结构是至关重要的。每个ISP (如一个居民区的ISP或一个机构的ISP)都有一台本地DNS服务器( 也叫默认名字服务器)。当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地DNS服务器的IP地址( 通常通过DHCP)。通过访问Windows或UNIX的网络状态窗口，用户能够容易地确定他的本地DNS服务器的IP地址。主机的本地DNS服务器通常“邻近”本主机。对某机构ISP而言，本地DNS服务器可能就与主机在同一个局域网中;对于某居民区ISP来说，本地DNS服务器通常与主机相隔不超过几台路由器。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将该请求转发到DNS服务器层次结构中，我们下面将更为详细地讨论。

?DNS缓存

DNS缓存( DNScaching)。为了改善时延性能并减少在因特网上到处传输的DNS报文数量,DNS广泛使用了缓存技术。

DNS 缓存的原理非常简单。在一个请求链中，当某DNS服务器接收一个DNS回答(例如，包含某主机名到IP地址的映射)时，它能将映射缓存在本地存储器中。如图：每当本地DNS服务器dns. nyu. edu从某个DNS服务器接收到一个回答，它能够缓存包含在该回答中的任何信息。如果在DNS服务器中缓存了一台主机名/IP地址对，另一个对相同主机名的查询到达该DNS服务器时，该DNS服务器就能够提供所要求的IP地址，即使它不是该主机名的权威服务器。由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后 (通常设置为两天)将丢弃缓存的信息。

举一个例子，假定主机apricot. nyu. edu向dns. nyu. edu查询主机名cnn. com的IP地址。此后，假定过了几个小时，纽约大学的另外一台主机如kiwi. nyu. edu也向dns. nyu. edu查询相同的主机名。因为有了缓存，该本地DNS服务器可以立即返回cnn.com的IP地址，而不必查询任何其他DNS服务器。本地DNS服务器也能够缓存TLD服务器的IP地址，因而允许本地DNS绕过查询链中的根DNS服务器。事实上，因为缓存，除了少数DNS查询以外，根服务器被绕过了。

DNS 记录和报文

DNS记录

资源记录是一个包含了下列字段的4元组:(Name, Value, Type，TTL)TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。在下面给出的记录例子中，我们忽略掉TTL字段。Name 和Value的值取决于Type:

如果Type=A,则Name是主机名，Value是该主机名对应的IP地址。因此，一条类型为A的资源记录提供了标准的主机名到IP地址的映射。例如( relayI.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, relayl.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的域记录，如( umas. edu, dns. umass. edu, NS);该edu TLD服务器还将包含一条类型A记录，如(dns. umass. edu, 128. 119. 40. 111, A),该记录将名字dns. umass. edu映射为-个IP地址。

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地址。
权威区域包含了其他权威服务器的记录。
附加区域包含了其他有帮助的记录。例如，对于一个MX请求的回答报文的回答区域包含了一条资源记录，该记录提供了邮件服务器的规范主机名。该附加区域包含一个类型A记录，该记录提供了用于该邮件服务器的规范主机名的IP地址。

在DNS数据库中插人记录

? 假定你刚刚创建一个称为网络乌托邦( Network Utopia)的令人兴奋的新创业公司。你必定要做的第一件事是在注册登记机构注册域名networkutopia. com。注册登记机构(registrar) 是一个商业实体，它验证该域名的唯一性，将该域名输入DNS数据库(如下面所讨论的那样)，对提供的服务收取少量费用。1999 年前，唯一的注册登记机构是Nework Solution，它独家经营对于com、net和org域名的注册。但是现在有许多注册登记机构竞争客户，因特网名字和地址分配机构( Internet Corporation for Assigned Names and Numbers, ICANN)向各种注册登记机构授权。在http://www. internie. 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系统中:

(ne tworkutopia. com, dns1 . ne tworkutopia. com，NS)
(dns1. networkutopia.com，212.212.212.1， A)

必须确保用于Web服务器www. networkutopia. com的类型A资源记录和用于邮件服务器mail. networkutopia. com的类型MX资源记录被输人你的权威DNS服务器中。(直到最近，每台DNS服务器中的内容都是静态配置的，例如来自系统管理员创建的配置文件。最近，在DNS协议中添加了一一个更新(UPDATE) 选项，允许通过DNS报文对数据库中的内容进行动态添加或者删除。[RFC2136]和[RFC 3007]定义了DNS动态更新。)

一旦完成所有这些步骤，人们将能够访问你的Web站点，并向你公司的雇员发送电子邮件。

DNS安全性

DNS是因特网基础设施的一个至关重要的组件，对于包括Web、电子邮件等的许，多重要的服务，没有它都不能正常工作。因此，我们自然要问，DNS怎么能够被攻击呢? DNS是一个易受攻击的目标吗?它是将会被淘汰的服务吗?大多数因特网应用会随同它一起无法工作吗?

想到的第一种针对DNS服务的攻击是分布式拒绝服务(DDoS) 带宽洪泛攻击。例如，某攻击者能够试图向每个DNS根服务器发送大量的分组，使得大多数合法DNS请求得不到回答。这种对DNS根服务器的DDoS大规模攻击实际发生在2002年10月21日。在这次攻击中，该攻击者利用一个僵尸网络向13个DNS根服务器中的每个都发送了大批的ICMP ping报文负载。运的是，这种大规模攻击所带来的损害很小，对用户的因特网体验几乎没有或根本没有影响。攻击者的确成功地将大量的
分组指向了根服务器，但许多DNS根服务器受到了分组过滤器的保护，配置的分组过滤器阻挡了所有指向根服务器的ICMP ping报文。这些被保护的服务器因此未受伤害并且与平常一样发挥着作用。此外，大多数本地DNS服务器缓存了顶级域名服务器的IP地址，使得这些请求过程通常绕过了DNS根服务器。对DNS的潜在更为有效的DDoS攻击将是向顶级城名服务器(例如向所有处理.com
域的顶级域名服务器)发送大量的DNS请求。过滤指向DNS服务器的DNS请求将更为困难，并且顶级域名服务器不像根服务器那样容易绕过。但是这种攻击的严重性通过本地DNS服务器中的缓存技术可将部分地被缓解。DNS能够潜在地以其他方式被攻击。在中间人攻击中，攻击者截获来自主机的请求并返回伪造的回答。在DNS毒害攻击中，攻击者向一台DNS服务器发送伪造的回答，诱使服务器在它的缓存中接收伪造的记录。这些攻击中的任一种，都能够将毫无疑虑的Web用户重定向到攻击者的Web站点。

然而，这些攻击难以实现，因为它们要求截获分组或扼制住服务器[ Skoudis 2006 ]。总而言之，DNS自身已经显示了对抗攻击的令人惊讶的健壮性。至今为止，还没有一个攻击已经成功地妨碍了DNS 服务。
?