我们人类可以通过多种方式被识别。 例如，我们可以通过出生证明上的名字来识别。 我们可以通过我们的社会安全号码来识别。 我们可以通过我们的驾驶执照号码来识别。虽然每个都可以用来识别人，但在给定的上下文中，一个标识符可能比另一个更合适。 例如，美国国税局（美国臭名昭著的税收机构）的计算机更喜欢使用固定长度的社会安全号码而不是出生证明名称。 另一方面，普通人更喜欢更容易记忆的出生证明名称，而不是社会安全号码。 （事实上，你能想象说，“嗨。我的名字是 132-67-9875。请见见我的丈夫，178-87-1146。”）<br />正如人类可以通过多种方式识别一样，互联网主机也是如此。 主机的一个标识符是它的**主机名（hostname）**。 主机名（例如 www.facebook.com、www.google.com、gaia.cs.umass.edu）具有助记符，因此受到人们的喜爱。 但是，主机名几乎不提供有关主机 Internet 内位置的信息（如果有的话）。 （像 www.eurecom.fr 这样以国家代码 .fr 结尾的主机名告诉我们主机可能在法国，但没有说明更多。）此外，由于主机名可以由可变长度的字母数字字符组成，因此路由器将难以处理它们。 由于这些原因，主机也由所谓的 **IP 地址（IP addresses）**标识。<br />我们将在第 4 章中详细讨论 IP 地址，但现在对它们说几句简短的话很有用。 IP 地址由四个字节组成，具有严格的层次结构。 IP 地址看起来像 121.7.106.83，其中每个句点分隔一个从 0 到 255 以十进制表示的字节。 IP 地址是分层的，因为当我们从左到右扫描地址时，我们会获得越来越多关于主机在 Internet 中的位置（即，在哪个网络中，在网络中的网络中）的具体信息。 同样，当我们从下到上扫描邮政地址时，我们会获得越来越多关于收件人所在位置的具体信息。

2.4.1 DNS提供的服务 Services Provided by DNS

我们刚刚看到有两种方法可以识别主机——通过主机名和 IP 地址。 人们更喜欢更容易记忆的主机名标识符，而路由器更喜欢固定长度的、分层结构的 IP 地址。 为了协调这些偏好，我们需要一个将主机名转换为 IP 地址的目录服务。 这是互联网域名系统 (domain name system，DNS) 的主要任务。 DNS 是 (1) 在 DNS 服务器层次结构中实现的分布式数据库，以及 (2) 允许主机查询分布式数据库的应用层协议。 DNS 服务器通常是运行 Berkeley Internet Name Domain (BIND) 软件 [BIND 2020] 的 UNIX 机器。 DNS 协议在 UDP 上运行并使用端口 53。
DNS 通常被其他应用层协议（包括 HTTP 和 SMTP）用来将用户提供的主机名转换为 IP 地址。 例如，考虑当运行在某个用户主机上的浏览器（即 HTTP 客户端）请求 URL www.someschool.edu/index.html 时会发生什么。 为了使用户主机能够向 Web 服务器 www.someschool.edu 发送 HTTP 请求消息，用户主机必须首先获取 www.someschool.edu 的 IP 地址。 这是如下完成的。

1. 同一台用户机器运行 DNS 应用程序的客户端。
2. 浏览器从 URL 中提取主机名 www.someschool.edu 并将主机名传递给 DNS 应用程序的客户端。
3. DNS 客户端向 DNS 服务器发送包含主机名的查询（query）。
4. DNS 客户端最终会收到应答，其中包括主机名的 IP 地址。
5. 一旦浏览器从 DNS 接收到 IP 地址，它就可以向位于该 IP 地址的 80 端口的 HTTP 服务器进程发起 TCP 连接。

我们从这个例子中看到，DNS 给使用它的互联网应用程序增加了额外的延迟——有时是相当大的。 幸运的是，正如我们在下面讨论的，所需的 IP 地址通常缓存在“附近（nearby）”的 DNS 服务器中，这有助于减少 DNS 网络流量以及平均 DNS 延迟。
除了将主机名转换为 IP 地址之外，DNS 还提供了一些其他重要的服务：

• 主机别名（Host aliasing）。 具有复杂主机名的主机可以有一个或多个别名。 例如，像relay1.west-coast.enterprise.com 这样的主机名可以有两个别名，例如enterprise.com 和www.enterprise.com。 在这种情况下，主机名relay1.west-coast.enterprise.com 被称为规范主机名（canonical hostname）。 别名主机名（Alias hostnames）（如果存在）通常比规范主机名更易于记忆。 应用程序可以调用 DNS 来获取提供的别名主机名的规范主机名以及主机的 IP 地址。
• 邮件服务器别名（Mail server aliasing）。 出于显而易见的原因，非常希望电子邮件地址具有助记符。 例如，如果 Bob 有一个 Yahoo Mail 帐户，则 Bob 的电子邮件地址可能与 bob@yahoo.com 一样简单。 但是，Yahoo 邮件服务器的主机名比简单的 yahoo.com 更复杂，也更不容易记忆（例如，规范主机名可能类似于 relay1.west-coast.yahoo.com）。 邮件应用程序可以调用 DNS 来获取提供的别名主机名的规范主机名以及主机的 IP 地址。 事实上，MX 记录（见下文）允许公司的邮件服务器和 Web 服务器具有相同（别名）的主机名； 例如，公司的 Web 服务器和邮件服务器都可以称为 enterprise.com。

• 负载分配（Load distribution）。 DNS 还用于在复制的（replicated）服务器（例如复制的 Web 服务器）之间执行负载分配。繁忙的站点，例如 cnn.com，被复制到多台服务器上，每台服务器运行在不同的终端系统上，每台服务器都有不同的 IP 地址。对于复制的 Web 服务器，一组 IP 地址因此与一个别名主机名相关联。 DNS 数据库包含这组 IP 地址。当客户端对映射到一组地址的名称进行 DNS 查询时，服务器会使用整个 IP 地址集进行响应，但会在每个应答中轮换地址的顺序。因为客户端通常将其 HTTP 请求消息发送到该组中最先列出的 IP 地址，所以 DNS 轮换会在复制的服务器之间分配流量。 DNS 轮换（DNS rotation）也用于电子邮件，以便多个邮件服务器可以具有相同的别名。此外，诸如 Akamai 之类的内容分发公司以更复杂的方式使用 DNS [Dilley 2002] 来提供 Web 内容分发（参见第 2.6.3 节）。

  实践原则 PRINCIPLES IN PRACTICE DNS：通过客户端-服务器范例的关键网络功能 与 HTTP、FTP 和 SMTP 一样，DNS 协议是一个应用层协议，因为它

  1. 使用客户端-服务器范式在通信终端系统之间运行，并且
  2. 依赖底层端到端传输协议在通信端系统之间传输 DNS 消息。 然而，在另一种意义上，DNS 的作用与 Web、文件传输和电子邮件应用程序完全不同。 与这些应用程序不同，DNS 不是用户直接与之交互的应用程序。 相反，DNS 提供了一项核心 Internet 功能——即将主机名转换为其底层 IP 地址，用于 Internet 中的用户应用程序和其他软件。 我们在 1.2 节中注意到，互联网架构中的大部分复杂性都位于网络的“边缘”。 DNS 使用位于网络边缘的客户端和服务器来实现关键的名称到地址转换过程，是该设计理念的另一个例子。

  DNS 在 RFC 1034 和 RFC 1035 中指定，并在几个附加的 RFC 中更新。 这是一个复杂的系统，我们在这里只涉及其操作的关键方面。 感兴趣的读者可以参考这些 RFC 以及 Albitz 和 Liu 所著的书 [Albitz 1993]； 另请参阅回顾论文 [Mockapetris 1988]，它很好地描述了 DNS 的内容和原因，以及 [Mockapetris 2005]。

  2.4.2 DNS工作原理概述 Overview of How DNS Works

  我们现在对 DNS 的工作原理进行高级概述。 我们的讨论将集中在主机名到 IP 地址的转换服务上（hostname-to-IP-address translation service）。
  假设在用户主机中运行的某些应用程序（例如 Web 浏览器或邮件客户端）需要将主机名转换为 IP 地址。 应用程序将调用 DNS 的客户端，指定需要转换的主机名。 （在许多基于 UNIX 的机器上，gethostbyname() 是应用程序为了执行转换而调用的函数调用。）然后用户主机中的 DNS 接管，将查询报文发送到网络。 所有 DNS 查询和响应报文都在 UDP 数据报中发送到端口 53。 经过几毫秒到几秒的延迟后，用户主机中的 DNS 会收到一条提供所需映射的 DNS 响应报文。然后将此映射传递给调用应用程序。 因此，从用户主机中的调用应用程序的角度来看，DNS 是一个提供简单、直接的翻译服务的黑匣子。 但实际上，实现该服务的黑匣子很复杂，由分布在全球的大量DNS服务器，以及指定DNS服务器和查询主机如何通信的应用层协议组成。
  一个简单的 DNS 设计将有一个包含所有映射的 DNS 服务器。 在这种集中式设计（centralized design）中，客户端简单地将所有查询定向到单个 DNS 服务器，DNS 服务器直接响应查询客户端。 尽管这种设计的简单性很吸引人，但它不适合当今拥有庞大（且不断增长）主机数量的 Internet。 集中式设计的问题包括：

1. 单点故障（A single point of failure）。 如果 DNS 服务器崩溃，整个 Internet 也会崩溃！
2. 通信容量（Traffic volume）。 单个 DNS 服务器必须处理所有 DNS 查询（针对从数亿台主机生成的所有 HTTP 请求和电子邮件消息）。
3. 远程集中式数据库（Distant centralized database）。 单个 DNS 服务器不能“接近”所有查询客户端。 如果我们将单个 DNS 服务器放在纽约市，那么来自澳大利亚的所有查询都必须传输到地球的另一端，可能是通过缓慢和拥塞的链接。 这可能会导致严重的延迟。
4. 维护（Maintenance）。 单个 DNS 服务器必须保留所有 Internet 主机的记录。 这个集中式数据库不仅会很大，而且必须经常更新以应对每台新主机。

总之，单个 DNS 服务器中的集中式数据库根本无法扩展。 因此，DNS 是按设计分布的。 事实上，DNS 是一个很好的例子，说明如何在 Internet 中实现分布式数据库。

一个分布式、分层数据库 A Distributed, Hierarchical Database

为了解决规模问题，DNS 使用了大量服务器，以分层方式组织并分布在世界各地。没有一个 DNS 服务器拥有 Internet 中所有主机的所有映射。相反，映射分布在 DNS 服务器上。粗略地说，有三类 DNS 服务器——根 DNS 服务器（root DNS servers）、顶级域 (TLD) DNS 服务器（top-level domain (TLD) DNS servers）和权威 DNS 服务器（authoritative DNS servers）——按层次结构组织，如图 2.17 所示。

Figure 2.17 ♦ Portion of the hierarchy of DNS servers
要了解这三类服务器如何交互，假设 DNS 客户端想要确定主机名 www.amazon.com 的 IP 地址。大致上，将发生以下事件。客户端首先联系其中一个根服务器，它返回顶级域 com 的 TLD 服务器的 IP 地址。然后客户端联系这些 TLD 服务器之一，它返回 amazon.com 的权威服务器的 IP 地址。最后，客户端联系 amazon.com 的权威服务器之一，它返回主机名 www.amazon.com 的 IP 地址。我们很快就会更详细地检查这个 DNS 查找过程。但让我们首先仔细看看这三类 DNS 服务器：

• 根 DNS 服务器（Root DNS servers）。 全球有1000多个根服务器实例，如图2.18所示。 这些根服务器是 13 个不同根服务器的副本，由 12 个不同的组织管理，并通过互联网号码分配机构（Internet Assigned Numbers Authority） [IANA 2020] 进行协调。 根名称服务器（root name servers）的完整列表以及管理它们的组织及其 IP 地址可以在 [Root Servers 2020] 中找到。 根名称服务器提供 TLD 服务器的 IP 地址。
• 顶级域 (TLD) 服务器（Top-level domain (TLD) servers）。 对于每个顶级域——顶级域，如 com、org、net、edu 和 gov，以及所有国家顶级域，如 uk、fr、ca 和 jp——都有 TLD 服务器 （或服务器集群）。 Verisign Global Registry Services 公司维护 com 顶级域的 TLD 服务器，Educause 公司维护 edu 顶级域的 TLD 服务器。 支持 TLD 的网络基础设施可能庞大而复杂； 请参阅 [Osterweil 2012] 以了解威瑞信（Verisign）网络的完整概览。 有关所有顶级域的列表，请参阅 [TLD list 2020]。 TLD 服务器为权威 DNS 服务器提供 IP 地址。
• 权威 DNS 服务器（Authoritative DNS servers）。 每个在 Internet 上拥有可公开访问的主机（publicly accessible hosts）（例如 Web 服务器和邮件服务器）的组织都必须提供可公开访问的 DNS 记录，将这些主机的名称映射到 IP 地址。 组织的权威 DNS 服务器包含这些 DNS 记录。 组织可以选择实施自己的权威 DNS 服务器来保存这些记录； 或者，组织可以付费将这些记录存储在某个服务提供商的权威 DNS 服务器中。 大多数大学和大公司实施和维护自己的主要和次要（备份）权威 DNS 服务器。

Figure 2.18 ♦ DNS root servers in 2020
根、TLD 和权威 DNS 服务器都属于 DNS 服务器的层次结构，如图 2.17 所示。 还有另一种重要的 DNS 服务器类型，称为本地 DNS 服务器（local DNS server）。 本地 DNS 服务器并不严格属于服务器层次结构，但仍然是 DNS 架构的核心。 每个 ISP（例如住宅 ISP 或机构 ISP）都有一个本地 DNS 服务器（也称为默认名称服务器）。 当主机连接到 ISP 时，ISP 会向主机提供一台或多台本地 DNS 服务器的 IP 地址（通常通过 DHCP，这将在第 4 章中讨论）。 您可以通过访问 Windows 或 UNIX 中的网络状态窗口（network status windows）轻松确定本地 DNS 服务器的 IP 地址。主机的本地 DNS 服务器通常“靠近”主机。 对于机构 ISP，本地 DNS 服务器可能与主机在同一局域网内； 对于住宅 ISP，它通常与主机之间仅隔着几个路由器。 当主机进行 DNS 查询时，查询被发送到本地 DNS 服务器，该服务器充当代理，将查询转发到 DNS 服务器层次结构中，我们将在下面更详细地讨论。
我们来看一个简单的例子。 假设主机 cse.nyu.edu 需要 gaia.cs.umass.edu 的 IP 地址。 还假设纽约大学的 cse.nyu.edu 本地 DNS 服务器称为 dns.nyu.edu，而 gaia.cs.umass.edu 的权威 DNS 服务器称为 dns.umass.edu。 如图 2.19 所示，主机 cse.nyu.edu 首先向其本地 DNS 服务器 dns.nyu.edu 发送 DNS 查询报文（query message）。 查询报文包含要翻译的主机名，即 gaia.cs.umass.edu。 本地 DNS 服务器将查询报文转发到根 DNS 服务器。 根 DNS 服务器记录 edu 后缀，并将负责 edu 的 TLD 服务器的 IP 地址列表返回给本地 DNS 服务器。 然后本地 DNS 服务器将查询报文重新发送到这些 TLD 服务器之一。TLD 服务器记录 umass.edu 后缀，并以马萨诸塞大学的权威 DNS 服务器的 IP 地址进行响应，即 dns.umass.edu。 最后，本地 DNS 服务器将查询报文直接重新发送到 dns.umass.edu，后者以 gaia.cs.umass.edu 的 IP 地址进行响应。 请注意，在此示例中，为了获取一个主机名的映射，发送了 8 条 DNS 报文：4 条查询报文和 4 条应答报文！ 我们很快就会看到 DNS 缓存如何减少这种查询流量。

Figure 2.19 ♦ Interaction of the various DNS servers
我们之前的示例假设 TLD 服务器知道权威 DNS 服务器的主机名。 一般来说，这并不总是正确的。 相反，TLD 服务器可能只知道中间（intermediate） DNS 服务器，而中间 DNS 服务器又知道权威 DNS 服务器的主机名。 例如，再次假设马萨诸塞大学有一个名为 dns.umass.edu 的大学 DNS 服务器。 还假设马萨诸塞大学的每个系都有自己的 DNS 服务器，并且每个系的 DNS 服务器对该系中的所有主机都是权威的（authoritative）。在这种情况下，当中间 DNS 服务器 dns.umass.edu 收到对主机名以 cs.umass.edu 结尾的主机的查询时，它将向 dns.nyu.edu 返回 dns.cs.umass.edu 的 IP 地址 ，它对所有以 cs.umass.edu 结尾的主机名具有权威性。 然后，本地 DNS 服务器 dns.nyu.edu 将查询发送到权威 DNS 服务器，后者将所需的映射返回给本地 DNS 服务器，本地 DNS 服务器又将映射返回给请求主机。 在这种情况下，总共发送了 10 条 DNS 消息！
图 2.19 中显示的示例同时使用了递归查询（recursive queries）和迭代查询（iterative queries）。 从 cse.nyu.edu 发送到 dns.nyu.edu 的查询是一个递归查询，因为该查询要求 dns.nyu.edu 代表其获取映射。 但是，随后的三个查询是迭代的，因为所有应答都直接返回到 dns.nyu.edu。 理论上，任何 DNS 查询都可以是迭代的或递归的。 例如，图 2.20 显示了一个 DNS 查询链，其中所有查询都是递归的。 在实践中，查询通常遵循图 2.19 中的模式：从请求主机到本地 DNS 服务器的查询是递归的，其余查询是迭代的。

Figure 2.20 ♦ Recursive queries in DNS

DNS缓存 DNS Caching

到目前为止，我们的讨论忽略了 DNS 缓存（DNS caching），这是 DNS 系统的一个至关重要的特征。事实上，DNS 广泛利用 DNS 缓存来提高延迟性能并减少在 Internet 上来回（ricocheting around）的 DNS 消息的数量。 DNS 缓存背后的想法非常简单。在查询链中，当 DNS 服务器收到 DNS 应答（例如，包含从主机名到 IP 地址的映射）时，它可以将映射缓存在其本地内存中。例如，在图 2.19 中，每次本地 DNS 服务器 dns.nyu.edu 收到来自某个 DNS 服务器的应答时，它可以缓存应答中包含的任何信息。如果主机名/IP 地址对缓存在 DNS 服务器中，并且另一个查询到达 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 查询之外，所有的根服务器都会被绕过。

2.4.3 DNS记录和报文 DNS Records and Messages

共同实施 DNS 分布式数据库的 DNS 服务器存储资源记录 (resource records，RR)，包括提供主机名到 IP 地址映射的 RR。 每个 DNS 响应报文携带一个或多个资源记录。 在本小节和以下小节中，我们简要概述了 DNS 资源记录和报文； 更多细节可以在 [Albitz 1993] 或 DNS RFCs [RFC 1034; RFC 1035]。
资源记录是一个四元组，包含以下字段：
(Name, Value, Type, TTL)
TTL 是资源记录的生存时间（time to live）； 它确定何时应从缓存中删除资源。 在下面给出的示例记录中，我们忽略了 TTL 字段。 Name 和 Value 的含义取决于 Type：

• 如果 Type=A，则 Name 是主机名，Value 是主机名的 IP 地址。 因此，A 类记录提供了标准的主机名到 IP 地址的映射。 例如，(relay1.bar.foo.com, 145.37.93.126, A) 是 A 类记录。
• 如果 Type=NS，则 Name 是域名（domain）（例如 foo.com），Value 是权威 DNS 服务器的主机名，该服务器知道如何获取域中主机的 IP 地址。 此记录用于在查询链中进一步路由 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 服务器将包含主机名的 A 类记录。 （即使 DNS 服务器不具有权威性，它的缓存中也可能包含 A 类记录。）如果服务器对主机名不具有权威性，则该服务器将包含包含主机名的域的 NS 类型记录； 它还将包含一个类型 A 记录，该记录提供在 NS 记录的 Value 字段中 DNS 服务器的 IP 地址。 例如，假设 edu TLD 服务器对主机 gaia.cs.umass.edu 没有权威性。 然后该服务器将包含一个域的记录，该域包括主机 gaia.cs.umass.edu，例如，(umass.edu, dns.umass.edu, NS)。 edu TLD 服务器还将包含 A 类记录，它将 DNS 服务器 dns.umass.edu 映射到 IP 地址，例如 (dns.umass.edu, 128.119.40.111, A)。

DNS报文 DNS Messages

在本节前面，我们提到了 DNS 查询和应答报文。 这些是仅有的两种 DNS 报文。 此外，查询和应答报文具有相同的格式，如图 2.21 所示。 DNS 报文中各个字段的语义如下：

• 前 12 个字节是报头部分（header section），其中包含多个字段（fields）。 第一个字段是一个 16 位数字，用于标识查询。 这个标识符被复制到查询的应答报文中，允许客户端将收到的应答与发送的查询进行匹配。 标志字段（flag field）中有许多标志（flags）。 1 位查询/应答（query/reply）标志指示报文是查询 (0) 还是应答 (1)。 当 DNS 服务器是查询名称的权威服务器时，在应答报文中设置 1 位权威标志（authoritative）。 当客户端（主机或 DNS 服务器）希望 DNS 服务器在没有记录时执行递归时，会设置 1 位递归期望（recursion-desired）标志。 如果 DNS 服务器支持递归，则在应答中设置 1 位递归可用（recursion-available）字段。 在报头中，也有四个字段。 这些字段指示报头后面的四种类型的数据部分（data sections）出现的数量。
• 问题部分（question section）包含有关正在执行的查询的信息。 此部分包括 (1) 一个包含正在查询的名称的名称字段（name field），以及 (2) 一个类型字段（type field），该字段指示针对名称提出的问题类型——例如，与名称相关联的主机地址（类型 A ) 或名称的邮件服务器（类型 MX）。
• 在来自 DNS 服务器的应答（reply）中，答复部分（answer section）包含最初查询的名称的资源记录（resource records）。 回想一下，在每个资源记录中都有 Type（例如，A、NS、CNAME 和 MX）、Value 和 TTL。 一个应答（reply）可以在答复（answer）中返回多个 RR，因为一个主机名可以有多个 IP 地址（例如，对于复制的 Web 服务器，如本节前面所述）。
• 权限部分（authority section）包含其他权威服务器的记录（records）。
• 附加部分（additional section）包含其他有用的记录（records）。 例如，对 MX 查询的回复中的 answer 字段包含提供邮件服务器规范主机名的资源记录。 附加部分包含一个 A 类记录，为邮件服务器的规范主机名提供 IP 地址。

Figure 2.21 ♦ DNS message format
您希望如何将 DNS 查询报文直接从您正在使用的主机发送到某个 DNS 服务器？ 这可以通过 nslookup 程序轻松完成，该程序可从大多数 Windows 和 UNIX 平台获得。 例如，在 Windows 主机上，打开命令提示符并通过简单地键入“nslookup”来调用 nslookup 程序。 调用 nslookup 后，您可以向任何 DNS 服务器（根、TLD 或权威服务器）发送 DNS 查询。 在收到来自 DNS 服务器的回复消息后，nslookup 将显示回复中包含的记录（以人类可读的格式）。 作为从您自己的主机运行 nslookup 的替代方法，您可以访问许多允许您远程使用 nslookup 的网站之一。 （只需在搜索引擎中输入“nslookup”，您就会被带到这些站点之一。）本章末尾的 DNS Wireshark 实验将允许您更详细地探索 DNS。

在DNS数据库中插入记录 Inserting Records into the DNS Database

上面的讨论集中在如何从 DNS 数据库中检索记录。 您可能想知道记录最初是如何进入数据库的。 让我们看看这是如何在特定示例的上下文中完成的。 假设您刚刚创建了一家名为 Network Utopia 的令人兴奋的新创业公司。 您肯定想做的第一件事是在注册商处注册域名 networkutopia.com。 注册商（registrar）是一个商业实体，它验证域名的唯一性，将域名（domain name）输入 DNS 数据库（如下所述），并就其服务向您收取少量费用。 1999 年之前，单一注册商 Network Solutions 垄断了 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.2.212.1 和 212.212.212.2。 对于这两个权威 DNS 服务器中的每一个，注册商将确保将 NS 类型和 A 类型记录输入到 TLD com 服务器中。 具体来说，对于 networkutopia.com 的主要权威服务器，注册商会在 DNS 系统中插入以下两条资源记录：

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

您还必须确保您的 Web 服务器 www.networkutopia.com 的 A 型资源记录和邮件服务器 mail.networkutopia.com 的 MX 型资源记录输入到您的权威 DNS 服务器中。 （直到最近，每个 DNS 服务器的内容都是静态配置的，例如，根据系统管理员创建的配置文件进行配置。 最近，UPDATE 选项已添加到 DNS 协议中，以允许通过 DNS 报文从数据库中动态添加或删除数据。 [RFC 2136] 和 [RFC 3007] 指定 DNS 动态更新。）<br />完成所有这些步骤后，人们将能够访问您的网站并向贵公司的员工发送电子邮件。 让我们通过验证此陈述是否正确来结束我们对 DNS 的讨论。 此验证还有助于巩固我们对 DNS 的了解。 **假设澳大利亚的 Alice 想要查看网页 www.networkutopia.com。 如前所述，她的主机将首先向她的本地 DNS 服务器发送 DNS 查询。 然后本地 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 的 Type A 记录。 此记录提供所需 Web 服务器的 IP 地址，例如 212.212.71.4，本地 DNS 服务器将其传回 Alice 的主机。 Alice 的浏览器现在可以发起到主机 212.212.71.4 的 TCP 连接并通过该连接发送 HTTP 请求。 哇！ 当人们上网时，发生的事情远不止眼前所见！**

关注安全 FOCUS ON SECURITY DNS漏洞 DNS VULNERABILITIES 我们已经看到 DNS 是 Internet 基础设施的重要组成部分，许多重要服务（包括 Web 和电子邮件）没有它就无法正常运行。 所以我们自然会问，DNS怎么会被攻击呢？ DNS 是一个坐着的鸭子，等待被踢出服务，同时使大多数互联网应用程序瘫痪吗？ 想到的第一种攻击类型是针对 DNS 服务器的 DDoS 带宽泛洪攻击（参见第 1.6 节）。 例如，攻击者可能会尝试向每个 DNS 根服务器发送大量数据包，数量之多以至于大多数合法的 DNS 查询永远不会得到答复。 如此大规模的针对 DNS 根服务器的 DDoS 攻击实际上发生在 2002 年 10 月 21 日。在这次攻击中，攻击者利用僵尸网络向 13 个 DNS 根 IP 地址中的每一个发送大量的 ICMP ping 报文。 （ICMP 报文在 5.6 节讨论。目前，知道 ICMP 数据包是一种特殊类型的 IP 数据报就足够了。）幸运的是，这次大规模攻击造成的损失很小，对用户的互联网体验影响很小或没有影响。攻击者确实成功地将大量数据包定向到根服务器。 但是许多 DNS 根服务器受到数据包过滤器（packet filters）的保护，配置为始终阻止所有定向到根服务器的 ICMP ping 报文。 因此，这些受保护的服务器得以幸免并正常运行。 此外，大多数本地 DNS 服务器缓存顶级域服务器的 IP 地址，允许查询过程经常绕过 DNS 根服务器。 针对 DNS 的一种可能更有效的 DDoS 攻击是将大量 DNS 查询发送到顶级域（top-level-domain）服务器，例如，发送到处理 .com 域的顶级域服务器。 过滤指向 DNS 服务器的 DNS 查询更加困难； 并且顶级域服务器不像根服务器那样容易绕过。 此类攻击发生在 2016 年 10 月 21 日，针对顶级域服务提供商 Dyn。此次DDoS攻击是由感染Mirai恶意软件的打印机、IP摄像头、住宅网关、婴儿监视器等10多万台IoT设备组成的僵尸网络，通过大量DNS查询请求完成的。几乎一整天，亚马逊、推特、Netflix、Github 和 Spotify 都被扰乱了。 DNS 可能会以其他方式受到攻击。 在中间人攻击中（man-in-the-middle attack），攻击者拦截来自主机的查询并返回虚假回复。 在 DNS 中毒攻击（DNS poisoning attack）中，攻击者向 DNS 服务器发送虚假回复，欺骗服务器接受虚假记录进入其缓存。 例如，这两种攻击中的任何一种都可用于将毫无戒心的 Web 用户重定向到攻击者的网站。 DNS 安全扩展 (DNSSEC [Gieben 2004; RFC 4033] 已被设计和部署以防止此类攻击。DNSSEC 是 DNS 的安全版本，解决了许多此类可能的攻击，并在 Internet 上越来越受欢迎。