最近在学习 DNS 解析流程时，我发现如果只记住“DNS 是把域名解析成 IP 地址”，其实很容易把很多关键细节忽略掉，比如域名层级、递归查询、迭代查询、权威 DNS、DNS 区以及 glue 记录之间的关系。

所以这篇文章不是只想背概念，而是尝试从完整查询链路的角度，把 DNS 解析到底是怎么一步步跑起来的梳理一遍。

阅读本文时，可以带着下面几个问题去理解 DNS 解析流程（大型连续剧）：

1. 浏览器输入一个域名后，DNS 是如何一步步找到对应 IP 地址的？
2. 根域名服务器、顶级域名服务器、权威域名服务器分别负责什么？
3. 为什么 DNS 采用分层、分布式的结构，而不是由一台服务器保存所有域名记录？
4. 递归查询和迭代查询有什么区别？现实中的 DNS 解析通常是哪种组合方式？
5. NS 记录、A 记录、AAAA 记录、CNAME 记录分别有什么作用？
6. 为什么 DNS 查询过程中，很多时候不是直接返回最终 IP，而是返回“下一步该问谁”？
7. CNAME 为什么不是直接保存 IP，而是指向另一个域名？
8. CDN 为什么经常通过 CNAME 接入？它和 DNS 解析有什么关系？
9. CDN 节点没有缓存资源时，为什么需要回源？
10. CNAME 互相指向时，为什么会形成循环依赖并导致解析失败？
11. glue 记录解决的是什么问题？为什么只知道 NS 名字还不够，还必须知道 NS 服务器的 IP？

定义

域名系统 DNS（Domain Name System） 是因特网中的一种分布式命名系统，主要作用是将人类容易记忆的域名转换为计算机网络通信所需的 IP 地址。

DNS 属于应用层协议，查询时通常使用 UDP 协议的 53 端口，因为 UDP 开销小、速度快，适合普通域名解析；但在响应数据较大、区域传送等情况下，也可能使用 TCP 的 53 端口。

域名

DNS 的树状结构让互联网上的主机或服务器可以被赋予一个唯一的层次化域名，尤其是那些需要被别人访问的公开服务器。

但普通用户主机、私网主机、临时联网设备，不一定有公开域名；它们可以只有 IP，甚至只有私网 IP，通过 NAT 访问外网。所以其实不是所有接入互联网的主机都有域名；准确说，是所有需要被 DNS 命名和公开定位的主机/服务，才会拥有域名。域名是 IP 地址之上的命名系统，不是上网本身的必要条件。

在域名管理中，每个域有不同的组织去管理，每个组织都可以将它的域再分为几个子域名，并委托给其他的组织去管理。

什么意思呢？不知道就看图吧：

我们可以看到，.com 本身就是一个域，它下面可以有 baidu.com、sina.com 等二级域。.com 域主要保存这些二级域的委托信息，告诉解析器应该去问哪个权威 DNS。

而 baidu.com 也可以继续划分自己的子域或主机名，比如 www.baidu.com、mail.baidu.com。这些记录可以由 baidu.com 自己管理，也可以在需要时继续委托给其他 DNS 服务器管理。
这就是所谓的“每个域由不同组织管理，每个组织又可以把自己的域再划分为子域，并在需要时委托给其他组织管理”。

顶级域名的分类

1. 国家级顶级域名：国家或某个地区的域名，如‘.cn’是中国，“.us”是美国
2. 通用顶级域名：常见的有.com（公司），.net（因特网），.org（非营利组织）,.gov（国家和政府），.edu(教育机构)。
3. 新通用顶级域名：也叫新顶级域名，新顶级域名后缀是在传统域名后缀资源日趋枯竭下开放注册的，首批是ICANN于2012年批准并集中于2014年开始面向全球开放注册。具体说的话就是，除了传统的.com,.net,.org这些域名外，又出现一些新的域名，如：.shop、.app、.xyz、.online、.tech。特点也很明显：
   • 选择更多：传统的 .com 好名字已经很难注册，新顶级域名提供了更多可选后缀。
   • 含义明确：比如 .shop 一看就知道和购物有关，.tech 一看就知道和技术有关。
   • 适合品牌分类：企业可以根据业务选择更贴切的后缀，比如电商用 .store，应用产品用 .app，博客用 .blog。

域名服务器

概念

域名服务器，也叫 DNS 服务器，是负责保存、查询或转发 DNS 记录的服务器。

当我们访问一个域名时，解析器会向 DNS 服务器发起查询。DNS 服务器会根据自己掌握的数据进行回答，或者告诉解析器下一步应该去问哪一台服务器。

但注意，没有一台 DNS 服务器保存所有域名的记录。DNS 是分层管理的，不同服务器只负责自己管辖范围内的一部分 DNS 数据，这个管辖范围就叫做 DNS 区（zone）。

每个 DNS 区通常都有一组权威域名服务器，负责保存并回答该区内的 DNS 资源记录。资源记录不只包括域名到 IP 地址的映射，也可能包括 NS(权威域名服务器)、MX、CNAME、TXT 等记录。DNS 区不是网络拓扑区域，区内的域名指向的设备不一定在同一个网络中，也不要求彼此连通。

[!NOTE]
这里的区我们如何解释呢？

这里要注意了，这个区不是物理上的区域，后面所说某个域名属于某个区也不是物理意义上的。它指的是，某个组织负责管理的一份DNS数据范围，也就是说“我对哪些域名具有权威解释权”。
比如baidu.com,这可能是一个区，这个区里可能包含：

baidu.com          NS      ns1.baidu.com
www.baidu.com      A       某个 IP
mail.baidu.com     MX      某个邮件服务器
tieba.baidu.com    CNAME   某个别名

这份数据由 baidu.com 的权威 DNS 服务器保存并回答。所以简单来说就是这个权威服务器保存的是，具有权威解释权的那些数据，由baidu.com管理的那些数据被称为一个区。

我们可以想象一个人，这个人保存了一个村里人的地址和电话。我们要查那个村里某个人的地址和电话，就要先找到保管这个村通讯录的人。这个人手里保存的地址和电话，就是一个区的数据，这个人不一定认识他们或者跟他们在一起，只是管理这些数据而已。

这里我们说到这个比喻顺便讲一下缓存（TLD），缓存就是我们通过这个保存通讯录的人联系过了村里的某个人，然后我们手机的通讯记录里就有了他，下次联系他的时候就直接在通讯记录里找到直接通话就好了，但是整个记录时间长了就会消失所以缓存是有生存时间的。

我们带入这个场景去理解就是：

我们可以把 DNS 区理解成“一本由某个组织管理的通讯录”。比如 baidu.com 区就像一本“百度域名通讯录”，里面记录了 www.baidu.com、mail.baidu.com 等名字对应的资源记录。权威 DNS 服务器就像保管这本通讯录的人。我们要查询某个名字时，不是进入了某个物理区域，而是找到了保管这份通讯录的人，向他询问对应记录。这个保管人不一定和记录里指向的设备在同一个网络中，也不负责业务服务，只负责管理并回答这份 DNS 数据。

每个域名服务器不仅负责一部分域名的解析，并且还要连接其他域名服务器，当遇到自己解析不了的域名知道该去哪里查询。这句话其实是我在学习的时候照抄的，他说的更像递归解析器（下面会说到），并不是每个域名服务器，所以准确来说是：

权威域名服务器主要负责自己 DNS 区内的数据，并通过 NS 记录表示子区委托关系。它通常不会帮客户端递归查询其他域名服务器；真正负责一路查询的是递归解析器。递归解析器根据各级服务器返回的 NS 信息，继续向下一层权威服务器发起查询。（递归/迭代查询在下面，看不懂的就先了解吧）

域名服务器的分类

前面提到过，DNS 中并不存在一台保存所有域名记录的服务器。为了管理庞大的域名系统，DNS 采用了分布式、分层的设计：不同的服务器负责不同范围内的 DNS 数据，并通过委托关系协同完成解析。因此，DNS 常被看作分布式数据库的典型应用。在整个解析体系中，常见的域名服务器主要可以分为四类：

1.根域名服务器

• 根域名服务器是最高层次的域名服务器，保存的是顶级域的委托信息，并通常返回 TLD 权威服务器的 NS 及其地址信息。
• 根域名服务器也是最重要的域名服务器，因特网上的任何本地域名服务器，遇到自己解析不了的域名，递归解析器通常先从根服务器开始查询。
• 根域名服务器全球只要十三组，注意并不是物理上只有 13 台，而是有 13 组逻辑根服务器标识，实际通过任播技术在全球部署了大量实例。
• 根域名服务器只是用来管理顶级域名的，他只返回对应的的顶级域名服务器，并不会告诉你你所访问的域名的IP地址是什么。

2.顶级域名服务器

• 顶级域服务器主要保存该顶级域下各二级域的委托信息，例如某个二级域应该去问哪些权威 DNS 服务器，而不是保存这些二级域内部的全部解析记录。说人话就是：.com 是一个统一的 zone，由一组 .com 权威服务器共同提供服务。它们保存的是 .com 下面二级域的委托信息，不是保存所有顶级域名，也不是保存每个网站的最终 IP。
• 收到DNS查询请求时会返回你所查询域名的NS记录（只有发生“委托”的时候，上一层才通常返回下一层的 NS 记录。），或者给出相应的回答（这时候递归DNS需要进行一次新的查询）。根据情况可能还会返回glue记录，以防止循环查询的出现，该记录里附加了其权威服务器的IP地址等信息，最后我们会说到。

3.权威域名服务器

• 需要通过域名公开访问的主机或服务，通常需要在对应区的权威 DNS 中配置资源记录。为了更好的服务，每台主机最好至少有两台权威域名服务器
• 实际上，许多域名服务器都充当本地域名和权威域名服务器（这种双角色，如果发现要查询的域名就在自己管理的区域内，就会直接返回结果，跳过查询）
• 权威域名服务器能够对自己管辖区内的 DNS 记录给出权威回答。

4.本地域名服务器

本地域名服务器也称为递归解析器，是查询的起点，每个因特网服务提供商（ISP），一个学校甚至是学校内的一个系，都可以有一个本地域名服务器（也称为递归服务器），我们每次的查询请求报文就是发送给它。

接下来我们看一下前面知识的总结吧(可以学完迭代查询、递归查询后，再回来对着图理解一下)：

递归/迭代查询

递归查询

• 当客户端需要查询 www.example.com 的 IP 地址时，会先把查询请求发送给本地域名服务器。
  如果本地域名服务器中已有该域名的缓存记录，就会直接把对应的 IP 地址返回给客户端；如果没有缓存，本地域名服务器就会向根域名服务器发起递归查询，请求其返回最终解析结果。

• 在纯递归查询模型中，根域名服务器收到请求后会继续向下查询 .com 顶级域服务器；.com 顶级域服务器再继续查询 example.com 的权威域名服务器。

• 权威域名服务器查询到 www.example.com 对应的 A/AAAA 记录后，将最终 IP 地址原路返回给 .com 顶级域服务器，再由 .com 顶级域服务器返回给根域名服务器，根域名服务器继续返回给本地域名服务器。

• 最后，本地域名服务器将最终解析结果返回给客户端。

迭代查询

• 客户端要查询www.example.com，先去问根域名服务器，然后返回给客户端负责 .com 域的顶级域名服务器地址。
• 客户端再向顶级域名服务器查询该域名，返回 example.com 对应的权威域名服务器地址。
• 客户端再去询问权威域名服务器，权威域名服务器返回 www.example.com 的最终 IP 地址。
  因此，在纯迭代查询中，查询者需要根据每一次返回的“下一步该问谁”的信息，自己继续向下一层服务器查询，直到获得最终结果。这个模型中没有本地域名服务器作为递归解析器代替客户端完成整个查询过程。

如果加入本地域名服务器，但它只是告诉客户端下一步该去问根域名服务器，那么它仍然没有承担递归解析器的职责，只是多了一次迭代式响应。真正由本地域名服务器代替客户端完成完整查询的情况，属于后面要讲的“递归 + 迭代查询”。

递归查询+迭代查询

• 客户端向本地域名服务器发起查询www.example.com的查询请求，本地域名服务器收到请求之后，代替客户端进行迭代查询，去询问根域名服务器，根域名服务器返回.com顶级域名服务器的地址
• 本地域名服务器收到地址后再去询问对应的顶级域名服务器，顶级域名服务器返回对应的example.com权威服务器的地址
• 本地域名服务器再去询问权威域名服务器，权威域名服务器返回www.example.com的最终IP地址
• 本地域名服务器将查询到的地址返回给客户端
  我们可以发现客户端到本地域名服务器这一步，我们只看这一步，客户端发起请求，本地域名服务器返回地址，这属于递归查询；然后我们往下看递归服务器去进行后续的查询，每次查询，只返回下一步要去查询的服务器的地址，直到查询到最终结果这属于迭代查询。在现实生活中一般使用的就是这种递归查询+迭代查询的方式。

拓展

CNAME 全称是 Canonical Name，中文通常叫“规范名称”或“别名记录”。它的作用是：把一个域名指向另一个域名，而不是直接指向 IP 地址。

例如：
www.example.com.  CNAME  web.example.com.
web.example.com.  A      1.2.3.4

这个CNAME一般是在权威服务器那一层，也就是在正常要返回的地址的情况下，会告诉本地域名服务器，www.example.com的别名是web.example.com，然后会继续查询web.example.com的A/AAAA记录。

这样做有什么好处呢？

当然是减少重复配置，方便管理了，使用CNAME可以将多个域名指向同一个主域名，后续只需要维护主域名的IP。比如：

blog.example.com.  CNAME  web.example.com.
shop.example.com.  CNAME  web.example.com.
web.example.com.   A      1.2.3.4

如果服务器 IP 发生变化，只需要修改 web.example.com 的 A 记录，不需要分别修改 blog.example.com和 shop.example.com。

另外一个好处就是方便接入第三方服务，比如CDN，CDN就要求用户配置CNAME。

CDN肯定就有疑问了大家，这是什么？

这就为大家解释一下CDN，全称是 Content Delivery Network，中文叫“内容分发网络”。

他的作用就是将网站内容保存到不同的服务器节点上，让用户访问离自己更近，网络状态更好的节点，提升访问速度和稳定性。听起来是不是有点像负载均衡？

比如一个网站的源服务器在北京，你让欧洲，美国的用户访问，那太远了吧，然后就会使用CDN，CDN厂商就会在欧洲，美国部署CDN节点，然后在用户访问这个网站的时候，就会将他调度到这些CDN节点上，这样访问速度就会快很多。

所以CDN和DNS关系很密切，因为很多网站接入CDN之后，会配置CNAME，这个CNAME就是用的CDN厂商的域名。

www.example.com.  CNAME  example.cdnprovider.com.
意思是：
www.example.com 不直接指向源站 IP
而是交给 CDN 厂商的域名来处理

这样在解析该网站的时候，会再去查询CDN域名，CDN的DNS系统根据地区、运营商、网络情况，返回合适的 CDN 节点 IP。

北京用户查询 → 返回 1.1.1.1
上海用户查询 → 返回 2.2.2.2
美国用户查询 → 返回 3.3.3.3

CDN 不只是能缓存网页，还可以缓存图片、CSS、JavaScript、下载文件、视频等静态资源。

如果我们访问的网页或图片，没有再CDN节点上缓存怎么办？

如果没有它会向源服务器请求，然后再将内容返回给用户，顺便自己再缓存一份，如果有其他用户来访问，就直接从CDN节点上返回内容，不用每次都去向源站点拿，节省时间，这个过程有个高端大气的名字叫做回源。

我们上面说了CNAME一般出现在权威服务器上，那么整个过程：

1. 浏览器请求 www.shop.com 的 IP。
2. DNS 发现www.shop.com是 shop.cdn-example.net 的别名。
3. 继续解析 shop.cdn-example.net。
4. CDN 的 DNS 根据你的地区和网络状况，返回最近的 CDN 节点 IP。
5. 浏览器连接这个 CDN 节点。
6. CDN 节点如果有缓存，就直接返回内容。
7. 如果没有缓存，就去源站服务器拿内容，再返回给你(回源)。

也就是说CNAME 最终要解析到 A/AAAA 记录，但不一定永远是同一个 IP，尤其是 CDN 场景。

说专业一点就是：

CNAME 表示的是“别名关系”，它本身并不保存 IP 地址。正常情况下，CNAME 链条最终应该解析到某个 A/AAAA 记录。也就是说，解析器会沿着 CNAME 指向的目标继续查询，直到拿到最终 IP。

但这里要注意，最终 IP 不一定永远固定。比如在 CDN 场景下，同一个 CDN 域名可能会根据用户所在地区、运营商、网络状态等因素，返回不同的 CDN 节点 IP。

灵光一现，既然CNAME一般指向的是同一个IP地址，那么互相指向会不会造成循环，出现bug？

答案是对的，假设发生了配置错误比如：

a.example.com.  CNAME  b.example.com.
b.example.com.  CNAME  a.example.com.

当查询 a.example.com 时，解析器发现它是 b.example.com 的别名，再查询b.example.com，然后最后发现b.example.com是a.example.com的别名，再查询a.example.com，互相指向，无限循环了，解析器永远无法得到A/AAAA记录。

但是实际的 DNS 解析器不会无限循环下去，通常会在检测到循环，或者超过最大跳转次数后停止解析，并返回解析失败。

循环依赖与 glue 记录

基本概念

PS：上面讲完其实就已经覆盖主线流程了，这一部分比较绕，但我感觉整个机制还是挺重要的，大家有兴趣可以看看

我们前面提到了 glue 记录，那么它到底是干什么的？

可以先从一种特殊的循环依赖说起。这种情况本身不是 bug，而是 DNS 迭代解析里一个非常反直觉、但又必须解决的问题。

当我要解析一个域名，比如：

www.example.com

递归解析器会先从根服务器开始查询，然后找到 .com 顶级域名服务器。到了 .com 这一层时，顶级域名服务器可能会返回这样的委托信息：

example.com. NS ns1.example.com.

这表示：example.com 这个 zone 的权威服务器是 ns1.example.com。

但问题来了：ns1.example.com 这个名字本身也在 example.com 里面。解析器还没有查询到 example.com 这个区的权威 DNS 服务器，却必须先知道 ns1.example.com 的 IP，才能去问 example.com 的权威服务器。

于是就形成了循环依赖：

我要查询 www.example.com
↓
需要先问 example.com 的权威服务器
↓
example.com 的权威服务器叫 ns1.example.com
↓
我要知道 ns1.example.com 的 IP
↓
但 ns1.example.com 的地址又属于 example.com 这个 zone
↓
要查它还是得先找到 example.com 的权威服务器

这时候如果父区 .com 只返回 NS 名字而不返回地址，解析器就会卡住。

所以 .com 父区会在返回委托信息时，额外附带一条地址记录：

example.com.      NS  ns1.example.com.
ns1.example.com.  A   1.2.3.4

这里的：

ns1.example.com. A 1.2.3.4

就是 glue 记录。

它的作用是：在解析器还没有进入子区之前，父区先提供一个可以连接到子区权威服务器的地址，从而打破循环依赖。

这里要注意，只有满足我们上面所说，子区的权威 DNS 服务器名称位于子区内部时，父区返回的地址才被称为glue记录。

但是还有另一种情况。

顶级域名服务器也可能返回：

example.com. NS ns1.cloudflare.com.

这表示 example.com 的权威服务器是 ns1.cloudflare.com。

这时候 ns1.cloudflare.com 不在 example.com 这个被委托的子区内部，而是在 cloudflare.com 下面。也就是说，它是一个 out-of-bailiwick NS。

[!补充]
in-bailiwick：管你这个区的人，名字也在你这个区里面。
out-of-bailiwick：管你这个区的人，名字在别的区里面。

这种情况下，对 example.com 这次委托来说，.com 父区不一定会返回 ns1.cloudflare.com 的 glue 记录。因为 ns1.cloudflare.com 的地址权威上属于 cloudflare.com，不是 example.com。

于是解析器会暂停主线查询，开启一轮新的支线查询：

我要查询 ns1.cloudflare.com 的 A/AAAA 记录

这个支线查询本身也会重新经历 DNS 迭代解析流程：

根服务器
↓
.com 顶级域名服务器
↓
cloudflare.com 的权威服务器
↓
返回 ns1.cloudflare.com 的 A/AAAA 地址

在这个过程中，解析器仍然要不断解决同一个核心问题：

下一跳 NS 名字如何变成可连接的 IP 地址？

如果 cloudflare.com 的权威服务器也是：

cloudflare.com. NS ns1.cloudflare.com.

那么 ns1.cloudflare.com 位于 cloudflare.com 自己内部，这又会产生类似的循环依赖。因此 .com 父区需要为 cloudflare.com 的委托提供 glue：

cloudflare.com.      NS  ns1.cloudflare.com.
ns1.cloudflare.com.  A   173.x.x.x

这样解析器才能拿到 ns1.cloudflare.com 的 IP，然后回到主线，继续查询 www.example.com。

还有一种情况，ns1.cloudflare.com 的地址不是通过 glue 得到的，而是通过权威回答得到的。

假设 .com 返回：

cloudflare.com. NS ns1.otherdns.net.

这表示 cloudflare.com 的权威服务器是 ns1.otherdns.net，而不是 ns1.cloudflare.com 本身。

那么解析器会先想办法获得 ns1.otherdns.net 的 IP。这个 IP 可能来自父区的 glue、缓存，或者继续开启新的支线查询。

当解析器成功连接到 cloudflare.com 的权威服务器后，再问：

ns1.cloudflare.com. A ?

这时候 cloudflare.com 的权威服务器正式回答：

ns1.cloudflare.com. A 173.x.x.x

这个回答就是权威回答，而不是 glue。

我们这里在用两个查询来说明是为了下面的理解，但要注意：
在完整 DNS 查询链路里，主线和支线都可能产生权威回答。权威回答的本质是：某个 DNS 服务器对自己负责的区内记录作出的正式回答。

也就是example.com. 被自己的权威服务器 ns1.example.com.回答也叫权威回答，那么我们这里为什么还要说呢？

大家还记得上面我们说：子区的权威 DNS 服务器名称位于子区内部时，父区返回的地址才被称为glue记录。然而这里是由另一个权威服务器回答的，本质上不算是glue记录。

所以整个流程可以理解成：

主线：
我要查 www.example.com
↓
.com 告诉我 example.com 的 NS 是 ns1.cloudflare.com
↓
但我不知道 ns1.cloudflare.com 的 IP
↓
主线暂停，开启支线查询

支线：
我要查 ns1.cloudflare.com 的 A/AAAA
↓
根 → .com → cloudflare.com
↓
通过 glue、权威回答或缓存，拿到 ns1.cloudflare.com 的 IP
↓
支线结束

回到主线：
现在我知道 ns1.cloudflare.com 的 IP
↓
连接 ns1.cloudflare.com
↓
查询 www.example.com 的 A/AAAA
↓
得到最终权威回答

我们可以发现，DNS 迭代解析并不是简单地“查一个域名对应的 IP”。它的底层过程更像是：

不断找到下一层权威服务器是谁,再想办法拿到这个权威服务器的 IP,然后连接过去继续查询。

因此，所有完整的迭代 DNS 查询，都绕不开“NS 名字如何变成 NS IP”这个问题。

但需要注意，NS 地址不一定都来自 glue,它可能来自：

1. 父区 Additional 部分提供的 glue 记录；
2. 某个权威服务器返回的正式 A/AAAA 回答；
3. 递归解析器之前缓存的记录。

进阶，全局视角

glue的作用我们上面已经理解了，为什么说很重要呢，看起来不就是解决了一种特殊情况吗？

我们带入一个情况，再一次全局冷查询中，也就是没有缓存，最终需要获得权威回答。我们查询某个域名的IP，必然需要用到 glue / Additional 这类地址引导机制。比如：

example.com.      NS  ns1.example.com.
ns1.example.com.  A   1.2.3.4

为什么必然会用到，我们可以想想，是不是子区的权威 DNS 服务器名称位于子区内部时才会返回该权威的地址，从而查询最终的地址，如果不在的话比如：

cloudflare.com.      NS  ns1.cloudflare.com.
ns1.cloudflare.com.  A   173.x.x.x

是不是最终还要查询 ns1.cloudflare.com.，而这个查询最终仍然会遇到“子区权威 DNS 服务器名称位于子区内部”的情况。这种情况下返回的，那么在我们这个全局冷查询，没有缓存，最终需要权威回答的情况下是不是必然触发。

那么我们加入缓存和权威回答，在全局视角看，缓存是不是以前查询过，保存了查询结果，才有了缓存，那么在查询时是不是还是要用到glue记录这个机制；权威回答，我们就算在新的一次查询中得到了IP地址，但是我们想想我们如何连接到的对应的权威服务器，是不是还是通过glue记录。

所以 glue 记录并不是可有可无的小机制。局部看它有触发条件；全局看，它属于 DNS 完整查询链路中的关键地址引导环节。

严谨的总结：

上面所说只是为了让大家更好的理解，意识到它的普遍性，以及它对其他机制的支撑作用，下面我们来比较严谨的总结一下。

glue 记录不是 DNS 解析的全部，但它是 DNS 委托链能够继续推进的重要辅助机制，尤其用于解决 NS 名字位于被委托子区内部时产生的循环依赖。

从全局冷查询视角看，glue / Additional 地址信息不是偶然的异常补丁，而是 DNS 分布式委托体系正常推进的一部分。因为递归解析器每次要继续询问下一层权威 DNS 服务器前，都必须先获得该服务器的 IP 地址；没有这个地址，只有 NS 名称是无法真正发包查询的。
因此，局部委托关系中 glue 是有条件出现的；但在完整无缓存查询链路中，权威 DNS 地址落地过程是必然存在的，glue 是其中非常关键、非常普遍的一环（这里没有限制条件，所以除了glue，还会有缓存等机制）。

最后我们再补充一下三者之间的依赖：

可以粗略理解为，缓存是以前查过留下的，权威回答是已经找到权威服务器以后得到的；但“怎么先找到权威服务器”这个问题，很多时候就要靠 glue 这类父区提供的地址提示来解决。所以 glue 不是 DNS 解析的全部，但它确实是 DNS 委托链能走下去的重要底座。

但有一个比较特殊的地方，就是顶级域名服务器这一层

特殊之处在于：递归解析器一开始通过 root hints （提前配置好的）已经知道根服务器的 IP，所以可以直接访问根服务器。根服务器再返回对应 TLD 的 NS 名字，并通常附带这些 NS 的 A/AAAA 地址，让解析器能够继续访问顶级域名服务器。因此，根到 TLD 仍然属于“委托 + 获取下一跳地址”的逻辑，只是根服务器自己的地址不是通过 DNS 查出来的，而是预置的。

这里再提一嘴：根服务器返回顶级域名服务器地址，本质上属于“地址引导”。它的作用和 glue 类似，都是为了让解析器能继续联系下一层 DNS 服务器。

总结

DNS 解析的核心目的，是把用户容易记住的域名转换成计算机可以连接的 IP 地址。但这个过程并不是由某一台服务器直接完成的，而是依靠分层、分布式的 DNS 体系逐步推进。

当用户访问一个域名时，客户端通常会先把查询请求交给本地域名服务器，也就是递归解析器。如果递归解析器本身没有缓存，它会代替客户端继续向外查询：先从根域名服务器开始，找到对应的顶级域名服务器；再询问顶级域名服务器，找到目标域名所在区的权威域名服务器；最后向权威域名服务器查询，获得目标域名对应的解析记录。

在这个过程中，NS 记录负责告诉解析器“下一步该问谁”，也就是某个域或子域由哪些权威 DNS 服务器负责。A 记录和 AAAA 记录则负责返回真正可以连接的 IPv4 或 IPv6 地址。如果目标域名配置了 CNAME，说明它不是直接对应 IP，而是另一个域名的别名。解析器会继续沿着 CNAME 指向的目标域名查询，直到最终拿到 A 或 AAAA 记录。

CNAME 的好处是可以减少重复配置，方便统一管理多个域名的解析结果。它也常用于接入第三方服务，比如 CDN。网站接入 CDN 后，域名通常会通过 CNAME 指向 CDN 厂商提供的域名，再由 CDN 的 DNS 系统根据用户所在地区、运营商、网络状态等因素，返回合适的 CDN 节点 IP。这样用户访问的往往不是源站服务器，而是离自己更近、网络状态更好的 CDN 节点。

如果 CDN 节点已经缓存了用户请求的内容，就可以直接返回资源；如果没有缓存，它就会向源站服务器请求内容，再返回给用户，并在节点上缓存一份，这个过程叫做回源。通过这种方式，CDN 可以提升访问速度、减轻源站压力，并提高网站的稳定性。

需要注意的是，CNAME 链条必须最终解析到 A 或 AAAA 记录。如果多个 CNAME 互相指向，比如 a.example.com 指向 b.example.com，而 b.example.com 又指回 a.example.com，解析器就会在两个域名之间来回查询，无法得到最终 IP。这种情况就是 CNAME 循环依赖，最终会导致 DNS 解析失败。

另外，在 DNS 迭代解析过程中，递归解析器不只需要知道“下一步该问哪个 NS”，还必须知道这个 NS 服务器的 IP 地址。因为 NS 记录本身只是一个域名，不能直接用于网络连接。只有把 NS 名字解析成 A 或 AAAA 地址后，解析器才能真正向下一层权威 DNS 服务器发送查询请求。

glue 记录就是为了解决这个问题中的一种典型循环依赖：当子区的权威 DNS 服务器名称位于子区内部时，解析器想进入子区查询，就必须先知道这个权威服务器的 IP；但这个权威服务器的地址本身又属于子区内部，如果没有父区提供额外的地址信息，解析过程就会卡住。因此，父区会在返回委托信息时，附带对应 NS 服务器的 A/AAAA 地址，这就是 glue 记录。

所以，DNS 解析并不是简单地“域名查 IP”，它的底层逻辑更像是：递归解析器不断根据委托关系找到下一层权威服务器，再想办法把这个权威服务器的名字变成可连接的 IP 地址，最后一步步推进，直到获得目标域名的最终解析结果。缓存、权威回答和 glue 记录，都可能参与这个“让查询链路继续走下去”的过程。

今天就先讲这么多。DNS 这块细节比较多，如果文中有不严谨或理解不到位的地方，欢迎大家讨论、补充和指正。