域名与DNS管理：解析记录、TTL、迁移与故障排查
一、四类记录各管什么
独立站常用的DNS记录就四类，职责不能混。A记录把域名指向IPv4，AAAA指向IPv6，CNAME把域名指向另一个域名，MX管邮件，TXT放SPF和域名验证。
最常见的错误是用CNAME把裸域（example.com）指到CDN。DNS协议规定裸域上不能有CNAME，否则会和MX记录冲突。CDN厂商通常给裸域提供ALIAS或ANAME记录，或直接给IP段走A记录。
裸域和www要统一。建议裸域301到www，或反过来，只保留一个版本，否则会出现两套内容同时被收录。CDN怎么选属于独立站CDN选型的话题，本文只讲DNS这一层。
| 记录类型 | 作用 | 典型值 | 常见错误 |
|---|---|---|---|
| A | 域名到IPv4 | 203.0.113.10 | 裸域CNAME冲突 |
| AAAA | 域名到IPv6 | 2400:cb00::1 | 源站不支持却乱加 |
| CNAME | 域名到域名 | cdn.example.com | 加在裸域上 |
| MX | 邮件投递 | 10 mx.example.com | 切DNS时被删掉 |
| TXT | SPF / 验证 | v=spf1 include:_spf… | 多条SPF冲突 |
二、TTL：切换前降，稳定后恢复
TTL是递归DNS缓存这条记录的秒数。TTL设3600秒，意味着全球用户最多一小时后才看到新解析；设300秒，5分钟就刷新。
反直觉点在于，TTL和网站访问速度几乎无关。用户第一次访问时多一次DNS查询而已，后续命中缓存。把TTL调大并不会让网站更快，只会让下次切换时更慢。
正确节奏是：预计要切服务器或换CDN的前7天，把TTL降到300秒；切换当天改记录；观察7天无误后，再把TTL恢复到3600秒。常年挂着300秒，权威DNS查询量会变成原来的12倍，小服务商可能扛不住。
场景示例一：从阿里云搬到AWS，提前一周把example.com的A记录TTL从3600改成300。第7天把A记录指向AWS新IP，半小时后用dig @8.8.8.8 example.com确认生效，再开CDN回源。
有个细节容易被忽略：TTL生效是渐进的。你今天改成300秒，不代表全球递归立刻就按300秒缓存，已经在缓存里的旧值还是要等满原来的3600秒才过期。
这就是为什么要提前一周降，而不是切换当天才降。提前一周改TTL，等一周后切换时，大部分递归缓存已经按300秒在缓存新记录了。
| 阶段 | TTL设置 | 目的 |
|---|---|---|
| 日常稳定运行 | 3600秒 | 减少权威DNS查询压力 |
| 迁移前7天 | 降到300秒 | 让缓存快速过期 |
| 切换当天 | 改A记录值 | 指向新服务器 |
| 切换后7天 | 观察无误后恢复3600 | 降低查询量 |
三、换域名与换服务器的迁移
换域名和换服务器是两件事。换服务器只改A记录的IP；换域名要在新域名上全套配置，旧域名做301，还要在Google Search Console分别验证所有权。
迁移时最容易顺手改坏的是MX记录。很多人在DNS后台删旧记录时把MX一起删了，结果第二天全公司邮件退信。操作前先导出当前所有记录备份。
换域名的301映射和权重交接方法，见站点重构与换域名。邮件SPF/DKIM这类TXT记录的配置，见询盘邮件送达率。
场景示例二：旧域名old.com换为new.com。先在new.com配好A记录、证书、301规则，确认无混合内容后，把old.com的裸域和www都301到new.com对应路径，再在GSC分别提交两个域名的资源所有权。
还有一类记录常被忽略：CAA。它限定哪家CA可以给你的域名签证书。不配CAA意味着任何CA都能签，万一某家CA被滥用签出假证书，你的域名会被钓鱼站冒用。
CAA记录一条即可，写明只允许Let’s Encrypt和你用的商业CA。配错了会导致证书续签发不下来，所以先在测试环境验证。
| 迁移动作 | 必须做 | 不能做 |
|---|---|---|
| 换服务器IP | 降TTL后改A记录 | 同时删旧记录 |
| 换域名 | 新域名全配 + 旧域名301 | 旧域名直接停解析 |
| 换邮件服务商 | 先加新MX，观察7天再删旧 | 新旧MX同时删 |
| 加CDN | CNAME到CDN，源站保留 | 删A记录只留CNAME |
| 加CAA | 列明允许的CA | 不写等于谁都能签 |
四、故障排查：先分清是哪一层的问题
用户说”网站打不开”，先不要慌着改配置。用dig分三步定位：本机递归、公共递归、权威服务器，三者对比就能定位是哪一层缓存没过期。
常见的”我这边能开你那边打不开”，90%是递归DNS缓存没过期，或者用户本机hosts文件被改过。这种情况等TTL到期自然恢复，不要反复改记录。
排查命令组合分三步。先用dig example.com +short看本机递归结果。
再用dig @8.8.8.8 example.com对比Google公共DNS的结果。最后用dig @ns1.xxx.com对比权威服务器记录。
三者一致说明全球已生效，不一致就是中间某层缓存没过期。不要反复改记录。
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 本机打不开，他人能开 | 本机hosts或缓存 | ipconfig /flushdns 后再试 |
| 部分地区打不开 | 递归缓存未过期 | 对比dig @1.1.1.1与@8.8.8.8 |
| 权威记录也是旧值 | 后台没保存生效 | 检查DNS服务商是否开了暂停 |
| 解析对但打不开 | 源站防火墙或证书 | curl -I 看状态码，见HTTPS配置 |
监控上要加一条：DNS解析值偏离预期时告警。很多故障不是解析错了，是被人恶意改了记录。可用域名监控工具每日比对，方法见独立站监控体系。
还有一个常被忽略的点：NS记录。换DNS服务商时，要在域名注册商那里把NS记录一起改掉。
否则你在新服务商后台配的记录根本不生效。NS切换后同样有传播期，最长可能48小时。
切换期间新旧两家NS都要保留记录一致，不要立刻注销旧服务商账号，否则切换到一半就断了。
| 记录管理动作 | 要点 | 常见遗漏 |
|---|---|---|
| 换DNS服务商 | 注册商改NS，新老并行48小时 | 立刻注销旧账号 |
| 加CAA | 列明允许的CA列表 | 不写等于谁都能签证书 |
| 测邮件记录 | dig TXT看SPF是否生效 | 改完不测，退信才发现 |
FAQ 常见问题
TTL设成多少合适，越大越快吗？
裸域example.com为什么不能用CNAME？
换服务器IP当天要做什么？
我这边能打开，客户那边打不开，是哪里坏了？
切DNS的时候为什么公司邮箱突然收不到信了？
Google Search Console里要分别验证旧域名和新域名吗？
写在最后
DNS故障八成不是配错了，是缓存没过期。学会用dig对比三层解析，比反复改记录有用得多。
落地三步：日常TTL保持3600秒；动服务器前一周降到300秒，动完一周恢复；操作前导出记录备份，只改该改的那一条。
还有一个新手常踩的坑：把www和裸域配成两条独立的A记录指向同一服务器，却没做301。
结果Google把两份内容都收录，自己和自己抢排名。正确做法是只保留一个版本，另一个版本301过去。
记录数量也要定期清理。域名换过几次服务商后，后台常留着一堆测试用的A记录和过期的TXT，这些僵尸记录会增加误操作风险。
每季度导出一次全量记录备份，核对哪些是在用的，哪些是可以删的。备份文件存到本地，不要只留在DNS服务商后台。
DNS服务商本身也要考虑可靠性。小服务商偶尔会出现后台宕机、记录同步延迟。关键域名建议同时在两家做NS冗余，或者选头部服务商。
最后记一句：DNS配置看起来是小事，但一次切错记录造成的全站不可用，可能要等几个小时才能完全恢复。慢就是快，先降TTL再切。
一句可以记住的话：DNS慢半拍是缓存的天性，不是你的配置错了——先等TTL，再动记录。