为什么 DNS 的工作方式如此？

Question

这是一个关于 DNS（域名服务）的规范问题。

如果我对 DNS 系统的理解是正确的，那么 .com 注册表保存了一个将域 (www.example.com) 映射到 DNS 服务器的表。

1. 优势是什么？为什么不直接映射到 IP 地址？

2. 如果在我将 DNS 服务器配置为指向不同 IP 地址时需要更改的唯一记录位于 DNS 服务器上，为什么该过程不是即时的？

3. 如果延迟的唯一原因是 DNS 缓存，是否可以绕过它们，以便我可以实时查看正在发生的情况？

Answer 1

实际上，它比这更复杂 - 而不是一个“中央注册管理机构（那个）持有一个将域（www.mysite.com）映射到 DNS 服务器的表”，而是有几个层次结构

有一个中央注册表（根服务器），它只包含一小组条目：所有顶级域的 NS（名称服务器）记录 - .com、.net、.org、.uk、.us、.au等等。

这些服务器只包含下一级的 NS 记录。要挑一个例子，对于域名服务器.uk领域只是有条目.co.uk，.ac.uk以及在英国使用的其他二级区。

这些服务器只包含下一级的 NS 记录——继续这个例子，它们会告诉你在哪里可以找到google.co.uk. 在这些服务器上，您最终会找到类似主机名www.google.co.uk和 IP 地址之间的映射。

作为额外的皱纹，每一层还将提供“胶水”记录。每个 NS 记录将一个域映射到一个主机名 - 例如，作为其中一台服务器的.uk列表的 NS 记录nsa.nic.uk。为了进入下一个级别，我们需要找出nic.ukare的 NS 记录，结果它们也包含在内nsa.nic.uk。所以现在我们需要知道 的 IP nsa.nic.uk，但是要找到它，我们需要对 进行查询nsa.nic.uk，但是在我们知道nsa.nic.uk...的 IP 之前我们无法进行该查询。

为了解决这个困境，服务器.uk将 A 记录添加nsa.nic.uk到ADDITIONAL SECTION响应中（为简洁起见，下面的响应被修剪）：

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

如果没有这些额外的粘合记录，我们将永远无法找到名称服务器nic.uk.，因此我们永远无法查找托管在那里的任何域。

回到你的问题...

a) 优势是什么？为什么不直接映射到 IP 地址？

一方面，它允许分发对每个单独区域的编辑。如果您想更新 的条目www.mydomain.co.uk，您只需要编辑您mydomain.co.uk的名称服务器上的信息。无需通知中央.co.uk服务器、.uk服务器或根名称服务器。如果只有一个中央注册机构将所有级别一直映射到层次结构中，并且必须通知整个链中 DNS 条目的每一次更改，那么它绝对会被流量淹没。

在 1982 年之前，这实际上是名称解析的发生方式。一个中央注册中心收到所有更新的通知，他们分发了一个名为的文件hosts.txt，其中包含互联网上每台机器的主机名和 IP 地址。该文件的新版本每隔几周发布一次，互联网上的每台机器都必须下载一个新副本。早在 1982 年之前，这开始成为问题，因此发明了 DNS 以提供更加分布式的系统。

另一方面，这将是单点故障——如果单个中央注册表出现故障，整个互联网将处于脱机状态。拥有分布式系统意味着故障只会影响互联网的一小部分，而不是整个事情。

（为了提供额外的冗余，实际上有 13 个独立的服务器集群为根区提供服务。对顶级域记录的任何更改都必须推送到所有 13 个；想象一下，每次更改时必须协调更新所有 13 个到世界上任何地方的任何主机名...）

b) 如果在我配置 DNS 服务器以指向不同 IP 地址时需要更改的唯一记录位于 DNS 服务器，为什么该过程不是即时的？

因为 DNS 使用了大量缓存来加快速度并减少 NSes 的负载。如果没有缓存，您每次访问google.co.uk计算机时都必须到网络上查找服务器.uk，然后.co.uk，然后.google.co.uk，然后www.google.co.uk。这些答案实际上并没有太大变化，因此每次查找它们都是浪费时间和网络流量。相反，当 NS 向您的计算机返回记录时，它将包含一个 TTL 值，该值告诉您的计算机将结果缓存几秒钟。

例如，NS 记录.uk的 TTL 为 172800 秒 - 2 天。Google 更加保守 - NS 记录google.co.uk的 TTL 为 4 天。依赖于能够快速更新的服务可以选择一个低得多的 TTL - 例如，telegraph.co.uk它们的 NS 记录的 TTL 仅为 600 秒。

如果您希望对您的区域进行近乎即时的更新，您可以选择尽可能降低 TTL。你设置的越低，你的服务器看到的流量就越多，因为客户端更频繁地刷新他们的记录。每次客户端必须联系您的服务器进行查询时，这都会导致一些延迟，因为它比在本地缓存中查找答案要慢，因此您还需要考虑快速更新和快速服务之间的权衡。

c) 如果延迟的唯一原因是 DNS 缓存，是否可以绕过它们，以便我可以实时查看正在发生的情况？

是的，如果您使用dig或类似工具进行手动测试，这很容易- 只需告诉它要联系哪个服务器。

这是缓存响应的示例：

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

这里的标志部分不包含aa标志，所以我们可以看到这个结果来自缓存而不是直接来自权威来源。事实上，我们可以看到它来自97.107.133.4，它恰好是 Linode 的本地 DNS 解析器之一。答案是从离我很近的缓存中提供的，这意味着我花了 0 毫秒才能得到答案；但正如我们稍后会看到的，我为这种速度付出的代价是答案几乎过时了 5 分钟。

要绕过 Linode 的解析器并直接转到源，只需选择其中一个 NS 并告诉 dig 直接联系它：

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

您可以看到，这一次，结果是直接从源提供的 - 请注意aa标志，这表明结果来自权威源。在我之前的示例中，结果来自我的本地缓存，因此它们缺少aa标志。我可以看到该域的权威来源设置了 600 秒的 TTL。我之前从本地缓存中得到的结果的 TTL 仅为 319 秒，这告诉我，在我看到它们之前，它们已经在缓存中停留了 (600-319) 秒——将近 5 分钟。

尽管此处的 TTL 仅为 600 秒，但一些 ISP 会试图通过强制其 DNS 解析器将结果缓存更长时间（在某些情况下为 24 小时或更长时间）来进一步减少其流量。传统上（以一种我们不知道这是否真的是必要的但让我们保持安全的方式）假设您所做的任何 DNS 更改都不会在网络上的任何地方都可见互联网24-48小时。

Answer 2

a) 世界上 IP --> 主机名映射的数量真的很大。该系统将托管所有子域和 MX 记录以及所有其他 DNS 记录的责任分配给域名所有者。这几乎就是域名的意义所在。 .com由一个登记处.uk持有，而另一个登记处可以持有。同样example.com，otherexample.com可以单独托管，以便可以分发资源。

b) 它是缓存的，这将您的 DNS 主机上的点击次数减少到其他情况下的一小部分。默认情况下，记录在被丢弃之前在缓存中存在 2 天。这可以通过改变记录的 TTL（生存时间）来改变。

c) 您可以通过设置一个非常短的 TTL 来有效地停止缓存记录。这是不推荐，除非你使用它的动态DNS。缓存大大降低了 DNS 服务器上的命中率。为了从空中挑选一个猜测的数字，我们正在谈论取消 95% 的请求。