DNS 解析是如何工作的？

Question

DNS 解析是如何工作的？

IT Interview Practice · Accepted Answer

**DNS**（Domain Name System，域名系统）是互联网的电话簿：它把像 `example.com` 这样人类可读的名字翻译成像 `93.184.216.34` 这样的 IP 地址。解析是一次分层查找，通常由一个 **recursive resolver**（你的 ISP 的，或像 8.8.8.8 这样的公共 resolver）代你完成，它替你遍历 **authoritative** name server 构成的树：

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

resolver 先问 **root** 服务器（它们知道 TLD 服务器），再问 `.com` 的 **TLD** 服务器（它们知道谁对 `example.com` 具有权威），再问 **authoritative** 服务器（它持有实际记录）。为避免每次都重复这一过程，结果在每一层都被**缓存**——浏览器、OS 和 resolver——每一层都遵守记录的 **TTL**（time-to-live）。缓存命中时在微秒内即可解析；一次冷查找可能要花好几个来回。

常见的**记录类型**：`A`（name → IPv4）、`AAAA`（name → IPv6）、`CNAME`（指向另一个名字的别名）、`MX`（邮件服务器）、`TXT`（任意文本，用于 SPF/验证）和 `NS`（委派一个 zone）。你可以直接查看解析过程：

```bash
dig example.com A       # 显示 A 记录以及是哪个服务器作答
```

## 为什么这很重要

DNS 位于*每一个*从名字发起的请求的关键路径上，所以一个缓慢或配置错误的 resolver 会给一切增加延迟。面试官喜欢这个问题，因为它揭示你是否理解**分层与缓存**——正是这两个思想让一个全球性、分布式的系统能快速回答数十亿次查询。它也是真实生产事故的常见根源（“永远都是 DNS”）：过期的记录、错误的 TTL，或改动后的传播延迟——所以理解缓存和 TTL 如何运作非常实用。

为什么这很重要

相关问题