DNS为什么以这种方式工作？

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

如果我对DNS系统的理解是正确的，则.com注册表中包含一个表，该表将域（www.example.com）映射到DNS服务器。

1. 有什么好处？为什么不直接映射到IP地址？

2. 如果在将DNS服务器配置为指向其他IP地址时唯一需要更改的记录位于DNS服务器上，为什么流程不会即时进行？

3. 如果造成延迟的唯一原因是DNS缓存，是否有可能绕过它们，因此我可以实时查看发生了什么？

实际上，它比这复杂得多-而不是一个“中央注册表拥有一个将域（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记录都将一个域映射到一个主机名-例如，作为.uk列表nsa.nic.uk之一的NS记录作为服务器之一。要进入下一个级别，我们需要找出nic.ukare 的NS记录，并且它们也包括在内nsa.nic.uk。因此，现在我们需要知道的IP nsa.nic.uk，但是要找出该地址，我们需要对进行查询nsa.nic.uk，但是直到知道IP的IP后才能进行查询nsa.nic.uk。

为了解决这个难题，服务器.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，其中包含Internet上每台计算机的主机名和IP地址。该文件的新版本每隔几周发布一次，互联网上的每台计算机都必须下载新副本。早在1982年之前，这就开始成为问题，因此发明了DNS，以提供一种更加分布式的系统。

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

（为提供额外的冗余，实际上有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的解析器并直接进入源代码，只需选择其中一个NSes并告诉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小时。

a）世界上IP->主机名映射的数量确实很大。该系统将托管所有子域和MX记录以及所有其他DNS记录的责任分配给域名所有者。这几乎就是域名的重点。 .com由一个注册机构持有，而另一个注册机构.uk可以持有。同样example.com，otherexample.com可以单独托管，因此可以分配资源。

b）已缓存，这将DNS主机上的命中次数减少到其他情况的一小部分。默认情况下，记录在缓存中保存2天，然后被丢弃。可以通过更改记录的TTL（生存时间）来更改。

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

如果您使用的是* nix系统，请从http://cr.yp.to/djbdns.html下载Dan Bernstein的djbdns副本，然后运行其dnstrace程序以查看递归查询系统的工作方式。它非常有用。

a）可能的域名数量太大，一台服务器无法处理。而且不只是.com。有.net，.org，.se，.info以及其他任意数量。除此之外，您可以委派对子域的责任（实际上就是这样com做的）。DNS的集中程度降低，所有这些都变得更易于管理。

b）从用户到您的所有机器都具有DNS缓存，以最大程度地减少所需的请求数。例如，它可以防止每次您从SF获取页面时，通过向地址“ serverfault.com”的请求发送垃圾邮件。这些服务器甚至可以缓存“域不存在”结果，这就是为什么即使是全新的域也要花费一段时间才能显示出来的原因。

c）尽管可以禁用缓存，但是计算机和yourdomain.com的DNS服务器之间通常还有其他DNS服务器。例如，您的ISP的DNS服务器将尝试尽可能多地缓存。唯一在网络上相对较快更新的记录是短TTL记录（基本上说“我只在几秒钟内有效；此后，再询问我当前信息”）。但是，TTL之所以很高，是因为负责该域的服务器可以将一些工作分担给其他服务器。如果您每次访问网站时都通过网络与您的一两个溜溜的DNS服务器联系，那么第二个人在/.、digg等网站上看到您的站点时，它们将几乎无法使用。