点不一定代表委托

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 记录 - 继续这个例子，它们会告诉您在哪里可以找到 的 NS 记录google.co.uk。在这些服务器上，您最终会找到主机名www.google.co.uk和 IP 地址之间的映射。

作为一个额外的问题，每一层还将提供“粘合”记录。每个 NS 记录将一个域映射到一个主机名 - 例如，列表的 NS 记录.uk作为nsa.nic.uk服务器之一。要进入下一级，我们需要找出 的 NS 记录nic.uk，结果发现它们nsa.nic.uk也包括。所以现在我们需要知道 的 IP nsa.nic.uk，但要找出它，我们需要对 进行查询nsa.nic.uk，但我们无法在知道 IP 之前进行该查询nsa.nic.uk...

为了解决这个难题，服务器将的.ukA 记录添加到响应中（下面的响应为简洁起见被删减）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 使用大量缓存来加快速度并减少 NS 的负载。如果没有缓存，每次您访问google.co.uk计算机时都必须通过网络查找服务器.uk，然后.co.uk，然后.google.co.uk，然后www.google.co.uk。这些答案实际上不会有太大变化，因此每次查找它们都是在浪费时间和网络流量。相反，当 NS 将记录返回到您的计算机时，它将包含一个 TTL 值，该值会告诉您的计算机将结果缓存几秒钟。

例如，的 NS 记录的.ukTTL 为 172800 秒 - 2 天。Google 甚至更加保守 - 的 NS 记录的google.co.ukTTL 为 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

这里的 flags 部分不包含aaflag，因此我们可以看到这个结果来自缓存，而不是直接来自权威来源。事实上，我们可以看到它来自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。我可以看到，此域的权威来源将 TTL 设置为 600 秒。我之前从本地缓存获得的结果的 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% 的请求。

Answer 3

如果你使用的是 *nix 系统，请从以下网址下载 Dan Bernstein 的 djbdnshttp://cr.yp.to/djbdns.html并运行他的 dnstrace 程序来查看递归查询系统如何工作。它非常有用。

Answer 4

詹姆斯的回答很好，但现在已有 10 年历史了，我认为有些观点值得重新审视，我更愿意在这里陈述它们，而不是编辑他的答案。

点不一定代表委托

这些服务器仅包含下一级的 NS 记录。举一个例子，.uk 域名的名称服务器仅包含 .co.uk、.ac.uk 和英国使用的其他二级区域的条目。

也许这只是为了简化一些事情，但出于谨慎，存在着非常普遍的虚假陈述，需要予以纠正，因为它会造成各种其他误解。

名称中的点并不一定表示委派（NS记录）。

现在的情况就是如此，如下所示的示例：

$ dig uk. NS +short
dns1.nic.uk.
nsc.nic.uk.
dns3.nic.uk.
dns2.nic.uk.
nsb.nic.uk.
nsa.nic.uk.
dns4.nic.uk.
nsd.nic.uk.
$ dig @dns1.nic.uk. co.uk. NS +short
nsa.nic.uk.
nsb.nic.uk.
nsc.nic.uk.
nsd.nic.uk.
dns1.nic.uk.
dns2.nic.uk.
dns3.nic.uk.
dns4.nic.uk.

但也有反例，gouv.fr比如不是委派出去fr（没有NS记录），如下所示（但两个区域都由同一组织管理）：

$ dig fr. NS +short
g.ext.nic.fr.
d.nic.fr.
f.ext.nic.fr.
e.ext.nic.fr.
$ dig @d.nic.fr. gouv.fr. NS +short
$

确实没有显示，因为完整的答复只有：

;; AUTHORITY SECTION:
fr.         1h30m IN SOA nsmaster.nic.fr. hostmaster.nic.fr. (

表明gouv.fr并未被授权出去fr。

简而言之，在 DNS 的任何级别，您都可以在下面定义任何名称（区域的所有者可以根据需要example.com完全发布记录，而不必在“中间”的任何地方拥有任何记录），或者在任何时候进行委派（区域的所有者可以委派但不能例如）。foo.bar.buz.example.comNSexample.comfoo.bar.example.combar.example.com

胶水记录

更为重要的是，每一层还将提供“胶水”记录。

再说一遍，这可能只是文字上的过度简化，但就其本身而言，事实并非如此。

第一个粘合记录仅在有委托的情况下出现。由于上一点的原因，并非所有层都有以下名称的委托。

那么胶水是存在的，也是需要的仅有的如果使用的名称服务器位于辖区内。

如果example.com委托给，ns1.example.com则权威名称服务器com需要直接发布NS记录和A/AAAA记录ns1.example.com。这些记录被称为粘合记录，因为它们位于父端，而它们关注的是子端的名称。

相反，如果example.com委托给，ns1.provider.example则有不在权威名称服务器中粘贴记录com，该服务器将仅发布NS记录。

有关进一步的讨论和详细信息，请参阅RFC 8499“DNS 术语”其中有一整节关于粘合和“辖区内”名称服务器的内容，从第 7 节开始。区域。

其他相关的快速观察如下：

• 使用粘合记录既有优点也有缺点；明智的建议是，对于任何重要的名称，都应使用名称服务器的混合体，其中一些是管辖范围内的（因此需要粘合），而一些不是；这样，理论上就可以减轻每种情况的缺点
• 粘合记录在 DNSSEC 世界中是一个问题，因为它们位于ADDITIONAL未签名的部分，因此可以被篡改，即使父级和子级都完全启用了 DNSSEC（这就是为什么将所有名称服务器都设为管辖范围内存在安全风险的原因）

hosts.txt“数据库”

1982 年之前，名称解析实际上是这样进行的。一个中央注册中心会收到所有更新的通知，然后他们会分发一个名为 hosts.txt 的文件，其中包含互联网上每台机器的主机名和 IP 地址。

是的。您可以通过以下方式查看它的样子：https://rscott.org/OldInternetFiles/收集该文件的旧版本。

例如，最早的 1983 年版本中有这样的几行（语法随着时间的推移而改变）：

HOST : 14.0.0.4 : UCL-VTEST ::::
HOST : 14.0.0.6 : UK-SATNET ::::
HOST : 14.0.0.7 : WISC-IBM : IBM-4341 : VM/CMS : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP :
HOST : 14.0.0.8 : RAND-TN : VAX-11/750 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET :
HOST : 14.0.0.11 : CHALMERS-SUNET ::::

TTL

如果您希望区域更新几乎是即时的，您可以选择尽可能降低 TTL。

理论上是的，但实际上不是。否则，有些人可能会倾向于输入 0 或 1（秒），并认为这意味着没有缓存。

实际上，大型 DNS 运营商必须防范这种情况，因为这会毫无理由地显著增加他们的负载（DNS 从来没有被期望作为一种执行“即时”故障转移操作的方式，这些考虑应该在堆栈中更高的地方进行，并且更接近实际应用程序所关注的某种高速流量目的地变化），因此，即使它在理论上违反标准，太小的值也会增加。

很难确切知道谁在这里做了什么，但我认为一个合理的估计是，如果 TTL 低于“5 分钟”，解析器可能不会遵守。所以不要使用低于 300 的任何值。

专业提示dig：使用+ttlunits选项（专业提示中的专业提示：将选项一次性放入您的~/.digrc文件中，您无需再次输入它）以获得更好的 TTL 输出。

例如：

$ dig serverfault.com A +noall +ans +nottlunits
serverfault.com.    291 IN A 151.101.1.69
serverfault.com.    291 IN A 151.101.193.69
serverfault.com.    291 IN A 151.101.129.69
serverfault.com.    291 IN A 151.101.65.69

对比

$ dig serverfault.com A +noall +ans +ttlunits
serverfault.com.    4m56s IN A 151.101.193.69
serverfault.com.    4m56s IN A 151.101.1.69
serverfault.com.    4m56s IN A 151.101.129.69
serverfault.com.    4m56s IN A 151.101.65.69

绕过 TTL

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

更准确地说，为了强化一个非常重要的概念，你需要查询权威性查询之前的名称服务器递归当您进行任何类型的 DNS 故障排除时。

权威名称服务器拥有数据。无论您询问多少次和多频繁，他们给出的答复将始终具有完全相同的 TTL。

相反，递归名称服务器几乎总是使用缓存运行，因此会尝试首先从缓存中回答查询以减少网络调用。缓存由记录上的 TTL（+ 本地策略）控制。因此，每次询问递归名称服务器时，您都会看到具有不同 TTL 的答案（实际上会减少，直到缓存被逐出，然后回到原始值或接近原始值）。

例子：

1. 首先查询其（其中一个）权威名称服务器：

$ dig NS serverfault.com +short
ns-cloud-c2.googledomains.com.
ns-860.awsdns-43.net.
ns-1135.awsdns-13.org.
ns-cloud-c1.googledomains.com.

$ date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:39 EST 2022
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
$ date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:42 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.65.69
 date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:49 EST 2022
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69

此外，精明的读者会注意到 1）我+ttlunits隐式地使用了（在配置文件中）和 2）命令记录确实会发生变化，这是非常重要的一点，因为 DNS 处理套不是列表因此没有固定的顺序。

2. 现在做同样的事情，但查询特定的大型公共 DNS 解析器：

$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:45 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.65.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:48 EST 2022
serverfault.com.    4m38s IN A 151.101.65.69
serverfault.com.    4m38s IN A 151.101.193.69
serverfault.com.    4m38s IN A 151.101.1.69
serverfault.com.    4m38s IN A 151.101.129.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:53 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.1.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:58 EST 2022
serverfault.com.    4m54s IN A 151.101.129.69
serverfault.com.    4m54s IN A 151.101.193.69
serverfault.com.    4m54s IN A 151.101.65.69
serverfault.com.    4m54s IN A 151.101.1.69

精明的读者会发现，TTL 确实不再是常数，但也不是严格单调递减的。这可以通过以下事实来解释：使用大型公共解析器，我每次可能都会访问不同的实例，这些实例使用不同的缓存，因此保存和检索以获取回复的状态可能不一样。