新的
不喜欢广告？ 去 无广告 今天
开发者需要的 DNS 记录 — A、CNAME、MX、TXT 以及那个让你等待 48 小时的 TTL
更新于
DNS记录类型的实际解析——A、CNAME、MX、TXT、SPF和TTL——以及在部署和域名迁移过程中会困扰开发人员的真实陷阱。
广告 移除？
你购买了一个域名，将其指向某个位置，现在你看到的浏览器仍然显示旧网站。或者你错误配置了MX记录，发现邮件开始被拒收。DNS是开发者们大多忽略的东西，直到它真正“咬”到他们为止——而一旦出现问题，反馈周期又慢又痛苦。
这不是为从未听说过DNS的人准备的教程，而是为那些知道什么是域名但每次需要添加新记录类型时都会去Stack Overflow查找的开发者提供的参考资料。
DNS是如何实际工作的（30秒版本）
当浏览器解析 example.com时，它会向一个递归解析器（通常是你的ISP或8.8.8.8）发起请求。解析器会检查其缓存。如果命中缓存，它会返回缓存的答案；如果没有命中，则会沿着DNS树向上走——从根域名服务器 → TLD域名服务器（.com）→ 你的域名的权威域名服务器——并将结果缓存一段时间，具体时长由TTL决定。
每个DNS记录都有一个类型、一个名称、一个值和一个TTL。这就是全部内容。复杂性来自于理解不同类型的作用以及记录之间以非直观方式相互作用。
你实际上会用到的记录类型
A记录 — 主机名对应的IP地址
将主机名映射到IPv4地址。这是你最常接触的记录类型。
example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN A 93.184.216.34陷阱：你可以为同一个主机名配置多个A记录。DNS会返回所有这些记录，客户端会从中选择一个（通常采用轮询方式）。这是一种常见的廉价负载均衡设置——但若其中一个IP地址宕机，DNS没有健康检查机制，它将继续提供故障IP地址，直到TTL过期你才将其移除。
对于IPv6，对应的记录是 AAAA记录。概念相同，只是地址长度从32位变为128位。
CNAME记录 — 别名指向另一个主机名
将一个主机名指向另一个主机名（而不是IP地址）。解析器会沿着链路一直追踪，直到遇到一个A记录为止。
www.example.com. 300 IN CNAME example.com.
blog.example.com. 300 IN CNAME mysite.netlify.app.CNAME与A记录——何时使用： 如果你要指向一个提供主机名的服务（如Netlify、Vercel、GitHub Pages、Heroku、大多数CDN），使用CNAME。如果你拥有静态IP地址，则使用A记录。简单明了。
硬性规则： 你不能在区域根节点上设置CNAME (即纯域名—— example.comXML没有数字类型——所有内容都是文本。你的价格字段将是 www.example.com)。RFC 1034禁止这样做，因为根节点必须包含SOA和NS记录，而同一名称下的CNAME会引发冲突。当Netlify或Vercel告诉你为根域名添加CNAME时，它们实际上的意思是使用支持ANAME或ALIAS记录的DNS服务商——这是一种专有扩展，行为类似CNAME，但会直接解析到A记录层级。
另外： 永远不要将CNAME指向另一个CNAME 除非你绝对能避免。从技术上讲是合法的，但每一步链路都会增加一次DNS查询。更重要的是，如果中间的CNAME失效，你的记录也会随之失效。
MX记录 — 邮件路由
告诉其他邮件服务器如何将邮件投递到你的域名。MX记录有一个优先级数字——数字越小，优先级越高。
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.如果mail1不可用，发送服务器将尝试mail2。这是一种合理的降级机制，而不是负载均衡——你不是在分流流量，而是在指定一个优先级顺序。
开发者常犯的错误：将MX指向IP地址或CNAME。 MX值必须指向A记录（主机名），而不是IP地址或CNAME。 一些DNS服务商会允许你保存这种错误配置而毫无警告，然后你的邮件服务会静默失败。
如果你正在设置Google Workspace或Microsoft 365，它们会提供一组MX记录。不要修改优先级数字，以为自己很聪明——邮件路由逻辑依赖这些数字的准确性。
TXT记录 — 任意文本，主要用于验证和邮件认证
TXT记录存储自由格式的文本字符串。实际上，它们主要用于以下三个方面：
- 域名验证 ——Google搜索控制台、Stripe、GitHub等数百个服务会要求你添加TXT记录以证明你拥有该域名
- SPF（发送者策略框架） ——指定哪些邮件服务器被允许代表你的域名发送邮件
- DKIM和DMARC ——用于防止邮件伪造的邮件认证记录
一个SPF记录看起来像这样：
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"这表示：Google和SendGrid被允许代表该域名发送邮件；其他任何来源都应被怀疑（~all = 软失败， -all = 硬失败）。
DMARC记录位于 _dmarc.example.com:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"重要的一点是： 每个域名只能有一个SPF TXT记录。 如果你添加了第二个记录（因为某个新服务要求你这样做），两个记录都会存在，邮件服务器会看到冲突策略，导致邮件认证失败。你应该合并它们而不是添加新的： v=spf1 include:_spf.google.com include:sendgrid.net ~all.
NS记录 — 域名服务器委派
指定哪些域名服务器是你的域名的权威服务器。你通常在域名注册商处设置这些记录，而不是直接在DNS区域中配置。当你从一个DNS服务商迁移到另一个（例如，从GoDaddy的域名服务器迁移到Cloudflare），你实际上是在注册商层面更新NS记录。
NS记录的传播是导致域名迁移缓慢的原因。NS的TTL通常为24到48小时，而注册商变更本身也有额外的传播延迟。
TTL — 那个让你等待48小时的数字
TTL（生存时间）是一个以秒为单位的数字。它告诉缓存解析器在下次查询前记住答案的时间长度。TTL为300表示五分钟，TTL为172800表示48小时。
当你修改DNS记录时，旧的答案仍会被缓存，直到最多 旧的TTL。如果你的A记录TTL为48小时，你刚刚更改了IP地址，那么部分用户可能在长达两天内仍会访问到旧服务器——一旦变更完成，你就无法做任何事情来解决这个问题。
解决方法是在进行变更前降低TTL。计划中的迁移标准做法是：
- 在迁移前至少48小时将TTL降低到300（5分钟）——你必须等待旧的高TTL过期
- 执行DNS变更
- 等待5到10分钟以确保传播完成
- 一旦确认新配置正常运行，将TTL恢复到一个合理的值（3600到86400）
如果你忘记了第一步，直接跳到第二步并使用高TTL，你就会陷入困境。你可以现在降低TTL ，但这只能缩短尚未缓存该记录的解析器的等待时间。那些已经缓存了该记录的解析器仍需等待原始TTL的过期。，但这只是缩短了尚未缓存该记录的解析器的等待时间。对于已经缓存该记录的情况，仍需等待原始TTL到期。
快速参考
| 记录 | 指向 | 常用 | 注意事项 |
|---|---|---|---|
| A | IPv4地址 | 主机名 → 服务器IP | 没有健康检查——故障IP会持续在轮询列表中，直到TTL过期 |
| AAAA | IPv6地址 | 主机名 → IPv6服务器 | 容易忘记同时添加A记录以支持双栈 |
| CNAME | 另一个主机名 | 别名，CDN或PaaS路由 | 不能用于区域根节点；MX/NS不能指向CNAME |
| MX | 主机名（A记录） | 邮件投递路由 | 值必须是主机名，而不是IP地址；优先级数字很重要 |
| TXT | 自由格式文本 | SPF、DKIM、DMARC、域名验证 | 每个域名只能有一个SPF记录——应合并，而不是添加 |
| NS | 域名服务器主机名 | DNS委派 | 变更需通过注册商完成，传播过程缓慢 |
| CAA | CA域名 | 指定哪些证书颁发机构可以为你的域名颁发SSL证书 | 错误配置很容易导致你无法续订证书 |
能节省你时间的事项
使用 dig 直接，而不是通过网页工具。 dig @8.8.8.8 example.com A 绕过本地解析器，显示Google DNS实际看到的内容。添加 +short 仅获取答案。添加 +trace 以查看完整的解析链。
# Check what Google sees right now
dig @8.8.8.8 example.com A +short
# Check MX records
dig @8.8.8.8 example.com MX
# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT
# Full resolution trace
dig @8.8.8.8 example.com A +trace在任何迁移前检查TTL。 运行 dig example.com A 并查看答案部分第三列的数值。这是如果你现在立即更改记录而没有先降低TTL，你可能需要等待的时间（以秒为单位）。
Cloudflare的代理记录不会暴露你的真实IP。 当你在记录上启用Cloudflare的橙色云时，世界看到的A记录是Cloudflare的IP，而不是你的服务器IP。这通常是你希望的DDoS防护方式——但它意味着 dig 不会显示你服务器的真实IP，直接探测你IP的工具将无法按预期工作。
