前两篇介绍了 Web、文件传输与电子邮件。这些应用通常使用便于记忆的主机名，而网络传送数据需要地址。本篇接续 Chapter 2.2 Application Layer 2，介绍 DNS 如何把名字与地址等信息联系起来。
2.5 DNS：域名系统
应用可以使用 www.example.org 这样的名字表示目标服务，但要建立通信，还需要取得相应的 IP 地址。名字和地址分开后，用户可以继续使用同一个名字，服务的地址则可以调整。
2.5.1 DNS 的作用与服务
DNS 同时涉及“信息存在哪里”和“怎样查询信息”：前者是数据库结构，后者是应用层协议。
定义：DNS（Domain Name System，域名系统）
由许多域名服务器分层协作实现的分布式数据库，以及主机、域名服务器之间查询这些信息所使用的应用层协议。它保存主机名与地址等资源记录，支持名字解析。
DNS 提供的服务不只是一对一地把名字换成地址：
| 服务 | 作用 |
|---|---|
| 主机名到 IP 地址的解析 | 为应用取得目标主机的网络地址 |
| 主机别名（host aliasing） | 将便于使用的别名关联到规范名字（canonical name） |
| 邮件服务器查找 | 根据邮件地址中的域名，查找负责接收邮件的服务器 |
| 负载分配（load distribution） | 一个名字可对应多台服务器的地址，为分散访问提供基础 |
一个名字可以对应多个 IP 地址，一个 IP 地址也可以服务多个名字。DNS 为负载分配提供地址选择机制，但不保证访问流量一定均匀分配。
DNS 支撑 Internet 的重要功能，却作为应用层协议实现；解析服务并不要求每个转发数据报的路由器都维护全网的主机名数据库。这体现了把复杂功能放在网络边缘的思路。
2.5.2 为什么采用分布式层次结构
如果所有名字都由一个中心数据库回答，会同时面临单点故障、查询流量集中，以及远距离访问时延等问题。DNS 将管理与查询工作分散到不同层次。
| 角色 | 负责的信息或工作 | 解析中的作用 |
|---|---|---|
| 根域名服务器（root name server） | 根区域及顶级域的委派信息 | 指出应向哪个顶级域的服务器继续查询 |
| 顶级域服务器（TLD server） | 如 .com、.org、.edu 顶级域的相关信息 | 指出下级域的权威服务器 |
| 权威域名服务器（authoritative name server） | 所负责区域的正式 DNS 记录 | 对其负责的数据给出权威回答，或提供进一步的委派信息 |
例如，解析 www.example.com 时，可先从根找到 .com 的服务器，再找到 example.com 的权威服务器，最后查询目标地址。实际层次可能有更多委派，缓存也可能使部分步骤省略。
根服务器不需要保存所有网站的 IP 地址，它主要提供进入下一层的线索。“13 个逻辑根服务器”也不表示全球只有 13 台物理机器；每个逻辑服务可以由多个部署实例提供。
权威服务器可以由组织自行维护，也可以交给服务商维护；“权威”说明它负责相应区域的数据，不要求它与目标网站运行在同一台机器上。
2.5.3 本地域名服务器与查询入口
层次结构组织权威数据，但普通主机通常不亲自逐级查询。它先把请求交给配置好的本地域名服务器，由后者完成后续解析工作。
定义：本地域名服务器（Local Name Server）
主机首先联系的 DNS 解析服务，通常承担递归解析器的角色：接收主机的查询，利用缓存或联系其他域名服务器取得结果，再向主机返回回答。它可以由 ISP、校园或企业等提供。
本地域名服务器不严格属于“根—TLD—权威服务器”这条数据管理层次。这里的“本地”表示主机使用的解析入口，并不要求服务器就在当前局域网中。
递归解析器与权威服务器的职责也不同：前者替客户端查找结果，后者提供自己所负责区域的数据。
2.5.4 迭代查询与递归查询
查询不知道的名字时，可以让被问到的服务器继续查，也可以让它只返回下一步的线索。两种方式的区别在于谁承担后续查找。
定义：递归查询与迭代查询
- 递归查询（recursive query）：查询者要求被联系的服务器代为完成解析；接受该职责的服务器负责继续查询，并返回解析结果或失败信息。
- 迭代查询（iterative query）：被联系的服务器根据已有信息回答；若不能给出最终结果，可以返回其他服务器的线索，由原查询者继续询问。
在没有可用缓存、按简化层次查询的模型中，主机 cis.poly.edu 查询 gaia.cs.umass.edu 的过程如下：
| 步骤 | 请求方向 | 返回的信息 |
|---|---|---|
| 1 | 主机 → 本地域名服务器 | 本地服务器接收解析请求，最终向主机返回结果 |
| 2 | 本地域名服务器 → 根服务器 | 根服务器指向相关的 .edu TLD 服务器 |
| 3 | 本地域名服务器 → TLD 服务器 | TLD 服务器给出后续权威服务器的线索 |
| 4 | 本地域名服务器 → 权威服务器 | 权威服务器返回目标主机的地址记录 |
这里，主机把查找任务交给本地服务器，本地服务器再向外逐级迭代查询。不能因为整段解析包含多级服务器，就认为每一跳都是递归查询。
Iterative query (upper) and Recursive query (lower) :
若要求根、TLD 等服务器继续代查，后续查找的工作与状态就会向这些服务器集中。常见组合是“主机到递归解析器使用递归服务，解析器向层次结构中的服务器迭代查询”，以分散工作负担。
例题：查询图中的 8 条消息如何计数？
图中的简化模型中，主机与本地服务器之间有一次请求、一次回答；本地服务器还分别与根、TLD、权威服务器各交换一对请求与回答，共 8 条消息。
这不意味着每次解析固定需要 8 条消息。有缓存时可以省略某些步骤；实际存在额外委派、别名解析等情况时，也可能需要更多查询。
DNS 查询取得地址后，应用才使用该地址建立后续连接。各段 DNS 查询的往返时间不能直接视为浏览器与 Web 服务器之间同一个 RTT。
2.5.5 缓存与 TTL
反复从根开始查询会浪费通信与处理资源。解析器可以保存已经取得的记录，在其有效期内复用。
定义：TTL（Time To Live）
DNS 资源记录的缓存有效时间，以秒为单位。缓存保存并递减记录的剩余 TTL，过期后不再把该副本作为仍然有效的缓存答案使用，需要重新取得或验证相应信息。
缓存可以保存目标主机的地址，也可以保存 TLD、权威服务器等委派信息。因此，即使没有目标主机的最终地址，也可能直接从已经知道的下级服务器开始查，不必每次访问根服务器。
缓存减少查询时延和上层服务器负载，同时使记录变更不一定立即反映到所有客户端：其他解析器可能仍持有尚未过期的旧记录。
例子：没有最终地址缓存，也可以省略根查询
本地服务器已经知道
.eduTLD 服务器，但没有gaia.cs.umass.edu的地址时，可以直接从相应 TLD 继续查。若还保存着合适的权威服务器信息，则可以更进一步，直接向权威服务器询问。因此，“缓存未命中”应区分缺少最终地址，还是连中间层次的信息也没有。
2.5.6 资源记录：A、NS、CNAME 与 MX
查询流程决定去哪里问，资源记录则决定查询得到什么。不同类型的记录承担地址解析、委派和别名等不同功能。
定义：资源记录（Resource Record，RR）
DNS 数据库保存的信息单元。本章将其简记为
name是记录所属的名字，type指定记录类型，value是该类型对应的数据，ttl是缓存有效时间。name与value的具体解释取决于记录类型；这个四元组是概念模型，不是完整的报文编码格式。
| 类型 | name 的含义 | value 的主要含义 |
|---|---|---|
| A | 主机名 | 对应的 IPv4 地址 |
| NS | 域／区域的名字 | 为其提供权威服务的域名服务器名字 |
| CNAME | 别名 | 别名指向的规范名字 |
| MX | 邮件地址中的域名 | 负责接收该域邮件的服务器名字 |
A 记录给出地址；CNAME、NS 和 MX 的目标主要是名字，可能还需要查询这些名字的地址。MX 的完整数据还包含优先级，这里重点关注邮件服务器名字。
例子：名字、服务器名与地址如何关联？
用简化的记录形式表示：
www.example.org CNAME web1.example.org web1.example.org A 192.0.2.10 example.org NS ns1.example.org example.org MX mail.example.org mail.example.org A 192.0.2.20访问
www.example.org时，先沿 CNAME 找到web1.example.org，再取得它的 A 记录；向bob@example.org投递邮件时，可通过example.org的 MX 记录找到邮件服务器，再查询该服务器的地址。NS 记录指明谁为这个域提供权威 DNS 服务；这台服务器不必同时承担 Web 或邮件服务。示例省略了 TTL 和 MX 优先级。
2.5.7 DNS 查询与响应报文
资源记录通过协议消息传递。DNS 查询和响应采用相同的基本报文结构，首部说明消息属性，后续部分承载问题和记录。
基本首部为 12 byte，包含 16 bit 的标识字段、标志字段，以及问题、回答、权威记录和附加记录的数量。
- 标识（identification）：查询使用一个 16 bit 编号，对应响应使用相同编号，帮助匹配请求与响应。
- QR：区分查询和响应。
- RD（recursion desired）：请求方是否希望获得递归解析服务。
- RA（recursion available）：服务器是否提供递归解析服务。
- AA（authoritative answer）：响应是否具有权威回答的属性。
RD 表示请求意愿，RA 表示服务器能力；它们不等于当前回答来自权威数据源。缓存解析器返回结果与权威服务器对自己区域作答，也需要区分。
| 报文部分 | 内容 |
|---|---|
| Questions | 要查询的名字、记录类型等问题信息 |
| Answers | 对查询作答的资源记录 |
| Authority | 权威服务器等相关记录；转介时可用于指出应继续询问谁 |
| Additional | 可供使用的附加记录，例如相关服务器的地址 |
当 NS 记录给出域名服务器的名字时，附加部分可以同时提供相应地址信息，帮助查询者继续联系该服务器。
应用层回顾
DNS 与前面的 HTTP、FTP、邮件一起，展示了应用层设计中的共同选择：
- 体系结构：客户端—服务器、P2P，或两者结合；集中协调与分散管理各有取舍。
- 运输服务：按可靠性、吞吐量和时延需求选择服务，不能仅凭应用名称判断全部需求。
- 协议消息：约定类型、语法、语义和交互规则，用首部描述控制信息，用消息体传递内容。
- 状态与控制：区分无状态和有状态设计，以及控制信息与数据是否使用同一通道。
- 网络边缘的复杂性：由端系统和应用服务完成名字解析、会话管理等功能，网络核心侧重数据转发。