为什么DNS的工作方式呢？

实际上，它比这更复杂 – 而不是一个“中央registry（那个）拥有一个把域名（www.mysite.com）映射到DNS服务器的表格”，有几层层次结构

有一个中央registry（根服务器），其中只包含一小部分条目：所有顶级域的NS（域名服务器）logging – .com ， .net ， .org ， .uk ， .us ， .au ，等等。

这些服务器只包含下一级的NSlogging。 举一个例子， .uk域名的域名服务器只有.co.uk ， .ac.uk和其他在英国使用的二级域名。

这些服务器只包含下一级的NSlogging – 继续这个例子，他们告诉你在哪里可以findgoogle.co.uk的NSlogging。 在这些服务器上，您终于可以find像www.google.co.uk这样的主机名和IP地址之间的映射。

作为一个额外的皱纹，每层也将提供“胶水”logging。 每个NSlogging将一个域映射到一个主机名 – 例如， .uk列表nsa.nic.uk的NSlogging作为一个服务器。 为了nic.uk ，我们需要找出nic.uk的NSlogging，而且它们也包含了nsa.nic.uk 所以现在我们需要知道nsa.nic.uk的IP，但是要发现我们需要查询nsa.nic.uk ，但是直到我们知道nsa.nic.uk的IP，我们才能进行查询nsa.nic.uk …

为了解决这个问题， .uk的服务器将nsa.nic.uk的Alogging添加到响应的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 

没有这些额外的胶水logging，我们永远无法findnic.uk.的名称服务器。 所以我们永远无法查找在这里托pipe的任何域名。

回到你的问题…

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

首先，它允许编辑到每个单独的区域进行分发。 如果你想更新www.mydomain.co.uk的条目，你只需要编辑你的mydomain.co.uk的域名服务器上的信息。 没有必要通知中央.co.uk服务器， .uk服务器或根名称服务器。 如果只有一个中央注册pipe理机构将所有级别映射到层次结构中，那么必须通知每一个DNS条目的变化，这一切都会被stream量所笼罩。

在1982年之前，这实际上是如何解决名称的。 一个中央registry被通知了所有更新，并且他们分发了一个名为hosts.txt的文件，其中包含了互联网上每台机器的主机名和IP地址。 这个文件的一个新版本每隔几周发布一次，互联网上的每一台机器都必须下载一个新的副本。 在1982年之前，这个问题开始变得有问题了，所以DNS被发明出来提供一个更分散的系统。

另一方面，这将是一个单一的故障点 – 如果单一的中央registry出现故障，整个互联网将脱机。 拥有分布式系统意味着失败只影响互联网的一小部分，而不是整个事情。

（为了提供额外的冗余，实际上有13个独立的服务器集群服务于根区域，任何对顶级域名logging的更改都必须推到所有的13个;想象为每一个更改协调更新全部13个到世界任何地方的任何主机名…）

b）如果当我configurationDNS服务器指向一个不同的IP地址时需要更改的唯一logging位于DNS服务器，为什么这个过程不是即时的？

因为DNS利用了大量的caching来加快速度，减lessNSes上的负载。 如果没有caching，每次访问google.co.uk您的计算机都必须到networking上查找.uk ，然后是.co.uk ，然后是.google.co.uk ，然后是www.google.co.uk 。 这些答案实际上并没有多大的改变，所以每次查看都是浪费时间和networkingstream量。 相反，当NS将logging返回到您的计算机时，它将包含一个TTL值，告诉您的计算机将结果caching几秒钟。

例如， .uk的NSlogging的TTL为172800秒 – 2天。 Google更加保守 – google.co.uk的NSloggingTTL为4天。 依赖于能够快速更新的服务可以select一个更低的TTL – 例如， telegraph.co.uk的NSlogging的TTL仅为600秒。

如果您希望您的区域更新接近即时，则可以select将TTL降至最低。 设置的越低，服务器将看到的stream量越多，因为客户端更频繁地刷新其logging。 每当客户端需要联系你的服务器进行查询时，这会比在本地caching上查找答案要慢，所以你也要考虑快速更新和快速服务之间的折衷。

c）如果延迟的唯一原因是DNScaching，是否有可能绕过它，所以我可以实时看到发生了什么？

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

这是一个caching响应的例子：

 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部分不包含aa标志，所以我们可以看到这个结果来自caching而不是直接来自权威来源。 实际上，我们可以看到它来自97.107.133.4 ，恰好是Linode的本地DNSparsing器之一。 事实上，答案是从一个非常接近我的caching服务意味着，我花了0毫秒的时间来得到答案; 但正如我们稍后会看到的那样，我为这个速度付出的代价是答案差不多已经过了5分钟。

要绕过Linode的parsing器并直接find源代码，只需select一个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标志，这表明结果来自权威来源。 在我之前的例子中，结果来自我的本地caching，所以它们缺lessaa标志。 我可以看到，这个域的权威来源设置了600秒的TTL。 我之前从本地caching获得的结果TTL只有319秒，这告诉我他们已经坐在caching中（600-319）秒 – 差不多5分钟 – 才看到它们。

尽pipe这里的TTL只有600秒，但是一些ISP会试图通过强制他们的DNSparsing器将结果caching更长时间 – 甚至在24小时甚至更长的时间内，尝试进一步减lessstream量。 这是传统的（在我们不知道的情况下，如果这真的是必要的，但是让我们安全一些）假设你所做的任何DNS更改都不会在互联网24-48小时。

a）世界上IP – >主机名映射的数量是非常大的。 该系统将所有子域和MXlogging以及每个其他DNSlogging的责任分配给域名所有者。 这几乎是域名的重点。 .com被一个registry所保存，而.uk可以被另一个注册。 同样， example.com和otherexample.com可以分开托pipe，以便分配资源。

b）它被caching，这会减less您的DNS主机上的命中数量，只有它的一小部分。 默认情况下，logging在丢弃之前在caching中生存2天。 这可以通过改变logging的TTL（生存时间）来改变。

c）通过设置一个非常短的TTL，可以有效地阻止logging被caching。 这是不build议，除非你使用它的dynamicDNS。 高速caching会在DNS服务器上丢失很多命中。 为了从空中选出一个猜测数字，我们正在讨论的是敲掉95％的请求。

如果您使用的是* nix系统，请从http://cr.yp.to/djbdns.html下载Dan Bernstein的djbdns的副本，并运行他的dnstrace程序以查看recursion查询系统是如何工作的。 它的信息非常丰富。

a）可能的域名数量太大，一台服务器无法处理。 并不只是.com; 有.net，.org，.se，.info和其他许多。 除此之外，你可以委托一个子域的责任（这实际上是com做的）。 DNS不那么集中使得所有这些更容易pipe理。

b）从用户到用户的机器都有DNScaching，以尽量减less所需的请求数量。 例如，每当你从SF获得一个页面时，它就会阻止发送“serverfault.com”地址的请求。 这些服务器甚至可以caching“域不存在”的结果，这就是为什么即使是一个全新的域名也需要一段时间才能显示出来的原因。

c）虽然您可以禁用caching，但是您的机器和yourdomain.com的DNS服务器之间通常还有其他的DNS服务器。 例如，您的ISP的DNS服务器将尝试caching尽可能多的。 在networking上更新速度相对较快的唯一logging是TTL较短的logging（基本上说“我只有几秒钟有效;之后，再次询问我的当前信息”）。 TTL的原因是如此之高，以至于负责该域的服务器可以将一些工作卸载到其他服务器上。 如果你所有的networking都连接到你的一个或两个rinky-dink DNS服务器，那么他们几乎不可用，第二个人看到你的网站在/。，digg等等。