在 Catchpoint 我们认为快速的 DNS （Domain Name Server）解析像内容一样重要。DNS 负责将域名( www.google.com ) 解析为 IP 地址供浏览器使用。该系统是网页性能的基础，然而大多数人并不完全理解它是如何工作的。因此，为了帮你更好的理解网站可用性及性能，我们会发布一系列博客文章，从基础知识开始，来阐明有时复杂的 DNS 世界。
为了简单期起见，本文假设不存在 DNS 缓存。因此，这是最差的场景。我们会在未来的文章中讨论 DNS 缓存。
在网页和页面资源加载之前，DNS 必须被解析为 IP 地址，然后浏览器才能建立 TCP 连接来发起 HTTP 请求。除此以外，对于每个使用 URL 引用的外部资源，DNS 解析必须在发起 HTTP 请求之前完成相同的解析步骤（针对每个域名）。当用户在浏览器地址栏输入 URL 地址并敲下回车时 DNS 解析过程就开始。此时，浏览器向操作系统请求特定页面，在例子中即为 google.com 。
- OS 向 DNS Resolver 发起 递归查询
因为操作系统并不知道 www.google.com 是什么，它向 DNS Resolver 发起请求。操作系统向 DNS Resolver 发起的请求带有特殊的标记表明它是一个 递归查询。这意味着 DNS Resolver 必须完成递归且响应必须为 IP 地址或错误。
对大多数用户而言，他们的 DNS Resolver 由他们的 ISP (网络运营商提供)。或者使用一个开源替代方案，比如：Google DNS（8.8.8.8） 或者 OpenDNS（208.67.222.222）。可以在你的网络或路由器配置查看或配置。此时，DNS Resolver 执行一个递归步骤来将域名解析为 IP 地址。
- DNS Resolver 向根服务器发起 迭代查询
Resolver 从向 一个 根 DNS Server 请求 www.google.com 的 IP 地址开始。该请求并不包含递归标记，因此是一个迭代请求，意味着它的响应必须是一个地址，权威名称服务器地址或错误。根域在域名最后以隐藏的"."表示。不需要额外输入“.”，浏览器会自动加上。
有 13 个名为 A-M 根服务器集群， 服务器分布在 380 个地区。他们被 12 个不同的组织管理，并汇报给 IANA(Internet Assigned Numbers Authority) ，比如：Verisign 管理着 A 和 J 集群。所有的服务器都是 IANA 运行的一个主服务器的副本。
- 根服务器响应
这些根服务器拥有所有顶级域名（TLDs）的位置，如 .com、.de、.io，以及较新的通用顶级域名，如 .camera。
根域并没有 "www.google.com" 的 IP 信息，但是它知道 .com 可能知道，所以它返回 .com 服务器的位置。根域返回 13 个 .com 的 gTLD 服务器的位置列表，以 NS 或者 name server 记录形式列出。
- DNS Resolver 向 TLD 服务器发起 迭代查询
下一步 resolver 请求向其中一个 .com 名称服务器请求 google.com 的位置。就像根服务器一样，每个顶级域名都有 4-13 集群的名称服务器存在于多个位置。有两种类型的顶级域名（TLD）： 由政府组织管理的国家代码(ccTLD, Country Code Top Level Domain)，以及通用域名(gTLD, Generic Top Level Domain)。每个通用顶级域名都有一个不同的商业实体负责运行这些服务器。在当前的例子中，我们将使用由 Verisign 负责运行 gTLD 服务器，Verisign 负责管理通用顶级域名中的 .com, .net, .edu, .gov。
- TLD 服务器响应
每个 TLD 服务器有 TLD 中每个域名的所有权威名称服务器列表。例如， 13 个 .com 的 gTLD 服务器中的每个服务器都有每个 .com 域名 的所有名称服务器列表。.com 的 gTLD 服务器并没有 google.com 的 IP 地址，但是知道 google.com 的名称服务器。.com 的 gTLD 服务器响应一个包含所有 google.com NS 记录的列表。当前例子中 Google 有 4 个名称服务器， 从 ns1.google.com 到 ns4.google.com。
- DNS Resolver 向 Google.com NS 发起 迭代查询
最终， DNS resolver 向 Google 其中一个名称服务器请求 www.google.com 的 IP 地址。
- Google.com NS 响应
这次被请求的名称服务器知道 IP 地址， 并分别针对 IPv4 和 IPv6（取决于请求类型） 返回 A 或 AAAA 记录。
- DNS Resolver 响应 OS
此时， resolver 完成了递归步骤并可以给最终用户的操作系统返回一个 IP 地址。
- 浏览器发起 TCP 握手
此时操作系统已经拿到 www.google.com 的 IP 地址，将其提供给应用程序（浏览器），浏览器初始化 TCP 连接开始加载页面。关于该过程的更多信息，我们写了一篇博客 剖析 HTTP。
如前所述，就完成解析的时长而言，这是最糟糕的情况。就大多数情况而言，如果用户最近访问过相同域名的 URL ， 或者其他依赖相同 DNS resolver 的用户发起过类似请求，将不需要 DNS ，或将限制在本地 DNS 解析器上的查询。 我们将在后续文章讨论这个问题。
在这种没有 DNS 缓存的情况下，涉及 4 套 DNS 服务器，所以可能会出现很多问题。最终用户并不知道幕后发生了什么；他们只是等待页面加载，所有 DNS 查询必须在浏览器请求前发生。
这就是为什么我要抢到快速 DNS 的重要性。你可以有一个快速且后见良好的站点，但如果你的 DNS 很慢，你的网页将依然响应缓慢。
