CNAME 与 A 记录：该用哪一种？

两种记录都是把主机名指向某处。区别在于它们指向的是什么，而这决定了当 IP 地址变化时，由谁来负责保证配置正确。

一个问题，决定怎么选

对大多数人来说，这确实就是全部的决策。本文其余部分讲的是那些容易踩坑的细节。

CNAME 是如何解析的

CNAME 是 Canonical Name（规范名称）的缩写。它的意思是：这个名称只是个别名，请转而去查询另一个名称。

shop.example.com.    3600    IN    CNAME    stores.myshopify.com.
stores.myshopify.com. 300    IN    A        23.227.38.65

解析器查询 shop.example.com 会先得到 CNAME，再解析 stores.myshopify.com，最后返回 23.227.38.65。原本一次查询变成两次，只多出几毫秒，而且几乎总能命中缓存。

好处在于，当 Shopify 迁移到新地址时，对方只需在自己那一侧修改一条 A 记录，您的域名就会自动跟随。如果用的是 A 记录，则在您发现并亲自修改之前，网站都会处于中断状态。

根域名的限制

这是 DNS 中最常见的困扰，而且它是协议规定，并非您的服务商的限制。

这就是为什么只提供主机名（myapp.herokuapp.com）的托管服务会在根域名上带来麻烦。有三种解决办法：

1. 1

   ALIAS / ANAME / CNAME 扁平化

   许多 DNS 服务商提供一种合成记录类型，在根域名上的行为类似 CNAME。服务商会自行解析目标，并将得到的 IP 作为普通的 A 记录提供，因此从不违反协议规则。Cloudflare 称之为 CNAME flattening，Route 53 称之为别名记录（alias record）。

2. 2

   把根域名重定向到 www

   让根域名指向一个小型重定向服务，并把 CNAME 设置在 www 上。简单且被普遍支持，代价是访问者多一次跳转。

3. 3

   使用 A 记录并接受维护成本

   如果服务商公布了稳定的 IP，并明确说明为静态地址，那么在根域名上使用 A 记录完全没问题。请先确认对方保证地址稳定，因为很多服务商明确不作此保证。

CNAME 必须单独存在

只要一个名称有 CNAME，就不能再有其他任何记录，包括 A、MX 和 TXT。

mail.example.com.    IN    CNAME    ghs.googlehosted.com.
mail.example.com.    IN    TXT      "v=spf1 include:_spf.google.com ~all"

有些服务商会直接拒绝这种配置；更糟的是，有些会接受它，但行为难以预料。如果某个名称上需要 TXT 记录，这个名称就不能是 CNAME。

各自的适用场景

适合使用 A 记录的情况

• 您的根域名，几乎在所有情况下都是如此。
• 您自己运行、使用静态 IP 的服务器，例如 VPS、独立服务器或预留的云地址。
• 同一名称上需要设置其他记录的任何场合。
• MX 目标，它们必须解析为地址。

适合使用 CNAME 的情况

• 指向托管平台（Shopify、Heroku、Netlify、Vercel）的子域名。
• www，指向您的根域名或托管服务的主机名。
• 服务商要求您创建的域名验证子域名。
• 底层 IP 不归您掌控的任何场景。

检查当前的配置

dig +short www.example.com CNAME
dig +short www.example.com A

查询工具会同时显示任意域名的 A、AAAA 和 CNAME 记录，因此很容易发现本不该同时存在两者的名称。