DNS 是什么

这一课你将能做到

1. 用 dig 或 nslookup 查出 www.coderoadmap.cn 的 A 记录，并说清楚返回的是「解析结果」而不是「网页内容」
2. 默画浏览器打开 HTTPS 站点的时序：DNS → TCP → TLS → HTTP，并指出 DNS 发生在所有网络步骤之前
3. 用一句话解释：为什么改一条 A 记录就能换服务器，而用户书签里的域名一个字都不用动

为什么要学

后端开发和运维天天遇到这类工单：「域名打不开」「证书域名对不上」「刚换了 IP，为什么部分地区访问到的还是旧站」。这些问题的第一层往往不在 Nginx，也不在 Spring Boot，而在 DNS——把人类记得住的域名翻译成机器能连的 IP 地址。

没有 DNS，你访问本站只能在浏览器敲 203.0.113.10 这样一串数字，服务器换机房、换 IP，所有用户都得重新记地址。有了 DNS，www.coderoadmap.cn 这个名字可以绑定任意机器，URL、用户书签、搜索引擎收录都不用变。

人话：DNS 就像互联网的「电话簿」。你只需要记住「张三家」这个名字（域名），电话簿（DNS）帮你查出电话号码（IP）。电话簿可以更新号码，但「张三家」这个称呼永远不变。本课先把这个直觉立住，后面 11 课再往里填记录类型、解析链路和排障方法。

先建立图像

用户在浏览器输入  https://www.coderoadmap.cn/tracks
                        │
                        ▼
                  ┌───────────┐
                  │ DNS 查询   │  问：www.coderoadmap.cn 是哪个 IP？
                  └─────┬─────┘  答：203.0.113.10（示例）
                        ▼
                  ┌───────────┐
                  │ TCP 建连   │  向 203.0.113.10:443 发起连接
                  └─────┬─────┘
                        ▼
                  ┌───────────┐
                  │ TLS 握手   │  验证证书绑定的主机名正是该域名
                  └─────┬─────┘
                        ▼
                  ┌───────────┐
                  │ HTTP 请求  │  GET /tracks → Nginx → 应用返回内容
                  └───────────┘

名词	人话解释	必须记住的一点
域名	好记的名字	给人看、给证书绑定
IP	路由器使用的数字地址	真正决定「连哪台机器」
DNS	名字到地址的查询系统	分布式、分层、可缓存
解析	查一次名字、拿一次答案	发生在建立连接之前

DNS 不负责 URL 路径路由、负载均衡算法、反向代理规则——那些是 Nginx、负载均衡器、Ingress 的职责。DNS 只回答一个问题：「这个名字此刻对应哪个（哪些）地址？」

跟着做

需要本机终端。Linux/macOS 自带 dig；Windows 用 nslookup，或在 WSL / Git Bash 中使用 dig。

步骤 1：查一个真实域名的 A 记录

# Linux / macOS：只输出 IPv4 答案
dig +short www.coderoadmap.cn A

# Windows（PowerShell / CMD 均可）
nslookup www.coderoadmap.cn

示例输出（IP 以你实际查询时为准）：

104.21.5.10
172.67.133.10

这就是「名字 → 地址」的结果。本站接入了 Cloudflare，所以公网查到的通常是 Cloudflare 的边缘 IP，而不是源站 IP——这是正常现象，后面 CDN 课会细讲。若返回 NXDOMAIN，说明该名字在公网权威侧不存在或尚未生效，此时还轮不到 HTTP 层。

步骤 2：对比不同递归解析器的答案

# 分别问谷歌和阿里的公共递归解析器
dig @8.8.8.8 www.coderoadmap.cn A +short
dig @223.5.5.5 www.coderoadmap.cn A +short

# Windows：nslookup 的第二个参数是服务器
nslookup www.coderoadmap.cn 8.8.8.8

多数情况下两边答案一致。若不一致，先怀疑缓存或传播延迟（第 3、10 课细讲），不要立刻去改应用配置。

步骤 3：用 curl 感受「DNS 失败，后面全停」

# -v 打印解析与握手全过程
curl -v --max-time 5 https://www.coderoadmap.cn/ -o /dev/null

# 故意查一个不存在的主机名，观察失败停在哪一步
curl -v --max-time 5 https://no-such-host-xyz.coderoadmap.cn/ -o /dev/null

正确域名会依次看到 Trying 203.0.113.10... → SSL connection → HTTP/2 200；错误主机名直接报 Could not resolve host，证明 DNS 卡在 TCP 之前。

步骤 4：在浏览器里看 DNS 耗时

打开 Chrome/Edge，按 F12 → Network → 刷新 https://www.coderoadmap.cn → 点第一个 document 请求 → Timing 标签。其中 DNS Lookup 一项就是解析耗时（命中缓存时可能接近 0）。有连接复用（Connection Start 之前排队）时首个请求的时序最能说明问题。

步骤 5：在便签上默写五格链路

在纸上写下：域名 → DNS 得到 IP → TCP → TLS → HTTP，并标注：Nginx 监听的是「IP + 端口」，证书校验的是「主机名」，DNS 只负责填第一格。以后排障时这张便签就是分层定位图。

步骤 6：推演一次「换机器不换 URL」

假设本站云主机从 203.0.113.10 迁到 203.0.113.20：在新机器上部署好站点、验证通过后，到权威 DNS 把 A 记录改成新 IP；等旧 TTL 过期，流量自动走到新机器。URL、证书主机名、Nginx 的 server_name www.coderoadmap.cn; 都不用动。反过来，如果只迁机器不改解析，用户会一直打到旧 IP。标准迁移顺序写进笔记：先备好新站 → 再切 DNS → 观察确认 → 最后回收旧站。

讲清楚要点

1. 主机间通信最终靠 IP，因此域名必须先解析——解析失败时，Nginx 和应用的访问日志里可能一条请求都没有。
2. DNS 是分布式分层系统，不存在「全世界唯一一台电话簿」——本机缓存、操作系统、运营商递归、公共递归、权威服务器各司其职。
3. URL 里的主机名要先变成地址，所以 DNS 发生在 TCP/TLS/HTTP 之前——排障顺序永远是先 dig，再 curl，最后看应用日志。
4. 改 A/AAAA 记录就能换后端机器，这是运维做迁移最常用的手段——但 TTL 未过期时，递归服务器和用户本机仍可能返回旧答案。
5. DNS 只回答名字问题——502、证书主机名不匹配、路径 404 通常都不是 DNS 本身的问题，必须分层定位。
6. 浏览器、操作系统、递归服务器都会缓存解析结果——所以「我这边好了、同事那边还不行」是日常现象，要多解析器对比，而不是只靠刷新页面。
7. IPv4 与 IPv6 是不同的记录类型（A / AAAA）——「ping 能通」和「浏览器实际走哪条协议栈」可能完全不一致，第 2 课展开。

你可能会懵的地方

• DNS 和「域名注册」是一回事吗？ 不是。注册商（如阿里云、腾讯云、Cloudflare Registrar）卖给你的是域名所有权；DNS 托管决定「问这个域该找哪台权威服务器、记录怎么写」。你可以在 A 家买域名、在 B 家托管解析，靠修改 NS 记录衔接。

• ping 通了就说明 DNS 和网站都正常？ 不一定。ping 只验证 ICMP 与基础连通性，而且很多服务器直接禁 ping；网站正常还要 443 端口开放、证书有效、Nginx 配置正确、应用存活。DNS 正常只是整条链路的第一格。

• hosts 文件算 DNS 吗？ 严格说不算，它是本机的静态覆盖表，优先级通常高于 DNS 查询。排障时如果只有你一台机器解析异常，先查 hosts（Windows 在 C:\Windows\System32\drivers\etc\hosts，Linux/macOS 在 /etc/hosts），再查系统 DNS。

• 为什么有时浏览器能打开、服务器上 curl 反而不行？ 两边使用的递归解析器、缓存状态、是否走代理都可能不同。服务器（尤其是云主机）常用内网 DNS，行为与办公网不同。用 dig @8.8.8.8 域名 对齐「公网真相」再判断。

• DNS 查询走 53 端口，为什么也有走 443 的？ 传统 DNS 报文走 UDP/TCP 53，明文可被中间设备劫持或监听；DoH（DNS over HTTPS，走 443）和 DoT（DNS over TLS，走 853）是加密方案，第 7 课会讲。

错法对照

错法	后果	正确做法
网站打不开，第一反应改 Nginx	名字指错 IP 时全部白忙	先 dig +short 确认解析到期望 IP
把 DNS 当负载均衡器	指望轮询、会话保持、健康检查全部落空	DNS 可配多条 A，但精细调度交给 LB/Nginx
认为改完记录「全球瞬间生效」	部分地区持续连旧站，误以为没改成功	看 TTL；多解析器对比；变更前先把 TTL 降到 300
用浏览器 Ctrl+F5 当清 DNS 缓存	系统缓存、递归缓存都还在	Windows 用 ipconfig /flushdns，或换解析器验证
在 hosts 里写死线上 IP 后忘记删	下次迁移只有你这台机器访问异常	实验后立即删除，或加注释标明临时用途

卡点急救

1. 浏览器提示「找不到服务器 / DNS_PROBE_FINISHED_NXDOMAIN」：先在终端 dig 域名 复现；换 @8.8.8.8 和 @223.5.5.5 各查一次。两个公共解析器都返回 NXDOMAIN，才去权威面板检查记录是否存在、域名是否过期。
2. 公司网络打不开、手机 4G 能打开：基本锁定本地网络的递归解析器问题。临时把本机 DNS 改成公共 DNS（如 223.5.5.5）验证，再找网络管理员。
3. 迁移后部分用户仍访问旧站：这是缓存窗口，不是故障。dig 查看返回的 TTL 倒计时，等它归零；超过权威设定 TTL 很久仍旧，则检查旧记录是否真的已删除、是否有多套权威配置不一致。

面试常问

• 请说一次在浏览器输入 URL 后 DNS 做了什么？ 浏览器先查自身缓存和系统缓存；没有命中则向配置的递归解析器发起查询；递归器依次询问根、顶级域、权威服务器拿到 IP（细节第 3、4 课讲），返回给客户端并按 TTL 缓存。拿到 IP 后才开始 TCP 建连、TLS 握手和 HTTP 请求。

• DNS 为什么要设计成分布式的？ 单一中央服务器无法承载全球查询量，且存在单点故障和管理集中化问题。分布式分层设计让每个域自己维护记录、各级服务器只回答自己负责的部分，再配合缓存把查询量分散到全球递归节点，兼顾可扩展性、容错和自治管理。

• 改了 DNS 记录为什么不会立刻全部生效？ 因为解析结果会在用户本机、操作系统、递归解析器多级缓存，缓存有效期由 TTL 控制。TTL 没过期前不会重新去权威服务器查询，所以旧答案还会继续返回。标准做法是变更前 24～48 小时把 TTL 调低，变更后再恢复。

自测三问

1. 打开 https://www.coderoadmap.cn 时，DNS、TCP、TLS、HTTP 的先后顺序是什么？哪一步失败时应用日志里不会有任何请求？
2. 为什么可以说「DNS 是电话簿」，却不能说「DNS 负责网站的路由规则」？
3. dig 返回了 IP 但页面报 502，更可能是哪一层的问题？你下一步查什么？

小结一句话

DNS 把域名解析成 IP，发生在建立 TCP/HTTPS 连接之前；它是互联网的分布式电话簿，而不是 Web 服务器本身。

延伸

• RFC 1034：域名概念与设施（DNS 的奠基文档，建议读第 2 章）
• RFC 1035：DNS 实现与报文规范
• MDN：DNS 术语表
• MDN：理解域名
• 下一课预告：记录类型——A、AAAA、CNAME、MX、TXT、NS 等记录各回答什么问题。