KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

03 · DNS 解析：从域名到 IP 的那一步 — keel 龙骨

本章目标：把 www.xxxxxx.cn 和 xxxxxx.cn 都正确指向你的服务器，并且能证明它生效了。验收标准：dig www.xxxxxx.cn +short 在本地和公网都返回你的服务器 IP。

本章目标：把 www.xxxxxx.cn 和 xxxxxx.cn 都正确指向你的服务器，并且能证明它生效了。
验收标准：dig www.xxxxxx.cn +short 在本地和公网都返回你的服务器 IP。

一、四种记录，你只需要记住它们各自的用途

类型	作用	本站场景
A	域名 → IPv4 地址	`www` → `203.0.113.10`，裸域名 → 同 IP
CNAME	域名 → 另一个域名	用于 CDN；或用于百度/Google 的站点验证
TXT	任意文本	搜索引擎验证、SPF/DKIM（邮件）、证书 DNS-01 校验
NS	指定权威 DNS 服务器	决定你在哪家后台改记录

MX（邮件）与 AAAA（IPv6）本章不涉及；有 IPv6 时加一条 AAAA 即可，逻辑与 A 相同。

二、最小记录集（照抄即可）

假设服务器 IP 为 203.0.113.10：

主机记录   类型    记录值              TTL
@          A      203.0.113.10        600
www        A      203.0.113.10        600

三条要点：

@ 表示裸域名（xxxxxx.cn），www 表示 www.xxxxxx.cn。两条都要加。
常见事故：只加了 www，于是 www.xxxxxx.cn 能打开而 xxxxxx.cn 打不开；用户以为站点挂了。
TTL 设 600（10 分钟），不要设默认的 3600 或更长。改解析时 TTL 决定了你要等多久——10 分钟是可调试与性能之间的平衡点。稳定后再调大。
裸域名必须用 A 记录，不能用 CNAME（RFC 禁止，且部分注册商不允许）。想让裸域名走 CDN，需要注册商支持 ALIAS/ANAME 或 CNAME Flattening。

三、改完不生效：按这个顺序排查

DNS 是整条链路上**最容易误判"已经生效"**的环节。严格按以下顺序，不要跳步：

第 1 步：确认权威 DNS 已经返回正确结果

# 直接问权威服务器（绕过本地缓存）
dig @ns1.yourdnsprovider.com www.xxxxxx.cn A +short

如果权威服务器返回错误 IP → 你改错地方了（记录加在了别的 DNS 服务商后台）。
回到第 01 章：dig xxxxxx.cn NS +short 看到的是谁，就去谁的后台改。

第 2 步：确认公网递归 DNS 已经同步

# 用公共 DNS 查（注意：如果本地 DNS 有缓存，这一步才是有意义的交叉验证）
dig @223.5.5.5 www.xxxxxx.cn A +short      # 阿里
dig @119.29.29.29 www.xxxxxx.cn A +short   # 腾讯
dig @8.8.8.8 www.xxxxxx.cn A +short        # Google

多家都返回正确 → 权威侧没问题，如果本地打不开，问题在本地缓存或后面的网络链路。

第 3 步：清本地缓存

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo systemd-resolve --flush-caches

浏览器自己也有一层 DNS 缓存：Chrome 访问 chrome://net-internals/#dns 可清理。

第 4 步：确认解析到的 IP 确实是你的服务器

dig www.xxxxxx.cn +short
# 拿输出的 IP 与云控制台里显示的公网 IP 逐位比对

这里有个高频事故：云服务器的公网 IP 在停机/续费/迁移后可能变化。解析值还是老 IP，现象是"配置没动过，突然打不开"。

四、解析对了，但仍然打不开 —— 问题不在 DNS

DNS 只负责"域名 → IP"。到这一步如果 dig 已正确但页面打不开，说明问题在网络可达性，也就是下一章的主题。这里先给你一个快速判定表：

# 1. 能 ping 通 → 主机在线、ICMP 未被拦
ping -c 4 203.0.113.10

# 2. 80 端口是否可达（DNS 问题已排除，直接测 IP）
curl -I --max-time 5 http://203.0.113.10/

# 3. 443 端口是否可达
curl -I --max-time 5 https://203.0.113.10/ -k

现象	结论
ping 通 + 80 通	主机与 Web 服务正常，问题回到应用层（nginx 配置/vhost）
ping 通 + 80 超时	防火墙/安全组拦了 80，或 nginx 没监听
ping 不通 + 80 超时	主机离线，或整个 IP 被封/被黑洞
ping 通，但只有在本机超时	你的出口 IP 被服务端单独封禁了（云平台安全策略常见）

最后一行是真实发生过的事故：云厂商的主机安全agent（如腾讯云云镜）检测到"密码爆破"特征后，会把 REJECT 规则写进服务器自建的 iptables 链，形如 -s <你的IP> -p tcp --dport 22 -j REJECT。
表现为只在这台机器上超时，别人访问正常。
排查方法：换手机热点或另一台机器访问同一地址——如果别处能开，就是你的 IP 被单点封禁了，去云控制台的主机安全/安全组里处理白名单，并把规则里已写入的存量 REJECT 删掉（加白名单只防再封，不撤销已有规则）。

五、给 HTTPS 提前准备的两条记录

后面申请证书会用到验证记录，提前了解以免临时手忙脚乱：

HTTP-01 校验：不需要 DNS 记录，但要求 http://域名/.well-known/acme-challenge/ 可访问。在 nginx 里务必保留这个 location 不被 301 到 https，否则校验必然失败。
DNS-01 校验：需要加一条 _acme-challenge 的 TXT 记录。优点是不依赖 HTTP 可达，且支持通配符证书；缺点是要等 DNS 生效（TTL）。

搜索引擎验证也会用到记录（第 05 章之后）：Google 用 TXT（google-site-verification=...），百度主推 CNAME，Bing 可直接从 GSC 导入。验证记录加完不要删，删了会导致站点所有权失效。

六、本章验收

# 三条都应返回同一个 IP：203.0.113.10
dig xxxxxx.cn +short
dig www.xxxxxx.cn +short
dig @8.8.8.8 www.xxxxxx.cn +short

裸域名与 www 都解析到服务器 IP
用公共 DNS 交叉验证通过（不是只查了本地缓存）
已确认权威 DNS 后台就是我修改记录的地方
TTL 已设为 600 便于后续调试
若 dig 正确但打不开，已按判定表定位到是防火墙还是主机问题

解析通了，下一步是让服务器真正把 80 端口的流量接住。

进入 keel 阅读