如何配置DNS

当你把一个域名指向服务器时，背后做的事情其实很直接：DNS 把人类能记住的名字（example.com）翻译成机器能路由的 IP 地址（203.0.113.10）。这个翻译过程由 DNS（Domain Name System）完成，而配置 DNS 记录就是你与这套系统对话的方式。

对于出海产品来说，DNS 配置几乎是上线的第一步。无论你用的是 Vercel、Cloudflare Pages 还是自己的 VPS，都需要把域名正确地指向对应的服务。配置错误轻则网站打不开，重则邮件丢失、安全验证失败。本文从 DNS 的基础概念出发，覆盖常见记录类型、Cloudflare 配置流程、传播验证和排查方法，目标是让你能独立完成从零到上线的 DNS 配置。

DNS 基础概念

域名解析的工作方式

DNS 本质上是一个分布式数据库。当你输入 app.example.com 时，系统会依次查询：

  1. 浏览器缓存 — 如果之前访问过，本地可能已经缓存了结果
  2. 操作系统缓存 — macOS 和 Linux 的 systemd-resolved，Windows 的 DNS Client 服务
  3. 递归解析器 — 通常由 ISP 提供，也可以是 8.8.8.8（Google）或 1.1.1.1（Cloudflare）
  4. 根域名服务器 — 全球 13 组根服务器，返回顶级域（TLD）的地址
  5. TLD 服务器 — 管理 .com、.io、.ai 等后缀的服务器
  6. 权威域名服务器 — 最终返回你的域名对应的 IP 地址

整个查询链条可以在几十毫秒内完成，因为每一层都有缓存机制。缓存的有效时间由 TTL（Time-to-Live）控制。

DNS 服务器角色

在配置 DNS 时你会接触到几个角色：

角色说明举例
注册商（Registrar）你购买域名的地方，管理域名所有权Namecheap、Cloudflare Registrar、阿里云万网
权威 DNS 服务器存储你域名的实际解析记录Cloudflare DNS、Route 53、DNSPod
递归解析器代替用户去各级 DNS 服务器查询8.8.8.8、1.1.1.1、ISP 默认 DNS
根/TLD 服务器维护域名系统的顶层索引由 ICANN 和各 TLD 运营商管理

对于大多数出海项目，你只需要关注注册商和权威 DNS 服务器。如果你用 Cloudflare 做 CDN，Cloudflare 同时承担权威 DNS 的角色。

TTL（Time-to-Live）

TTL 是 DNS 记录的缓存时间，单位是秒。常见的设置：

  • 300 秒（5 分钟） — 适合需要频繁变更的记录，比如故障切换场景
  • 3600 秒（1 小时） — 比较常见的默认值
  • 86400 秒（24 小时） — 适合不常变动的记录，比如 MX 记录

TTL 设短了，修改生效快，但查询量大、解析略慢；TTL 设长了，性能好，但修改后等待时间长。一个务实的做法是：日常用较长的 TTL，预计要变更前先调短，等变更稳定后再调回去。

常见 DNS 记录类型

DNS 有多种记录类型，每种承担不同的职责。出海产品最常用的四种：A、CNAME、MX、TXT。

A 记录（Address Record）

A 记录把域名指向一个 IPv4 地址。这是最基础的记录类型，几乎所有域名配置都需要它。

类型    名称              值               TTL
A       @                 203.0.113.10     3600
A       www               203.0.113.10     3600
  • @ 通常代表裸域名（apex domain），即 example.com 本身
  • www 是子域名，指 www.example.com
  • 一个主机名可以配置多条 A 记录实现负载均衡，客户端会轮询返回的多个 IP

CNAME 记录（Canonical Name）

CNAME 把一个域名别名为另一个域名。它不直接指向 IP，而是指向另一个域名，由那个域名的 A 记录最终解析到 IP。

类型     名称              值                        TTL
CNAME    shop              stores.shopify.com        3600
CNAME    blog              blog-host.cdn.vercel.app  3600

关键限制：如果某个主机名有 CNAME 记录，就不能再有其他类型的记录（MX、TXT 等都不行）。这是 RFC 标准的规定。实际配置中，裸域名（example.com）通常用 A 记录而不是 CNAME，就是因为裸域名还需要 MX、TXT 等记录共存。

Cloudflare 提供了 CNAME Flattening 功能，可以在保持 CNAME 语义的同时在裸域名上使用，绕开这个限制。

MX 记录（Mail Exchange）

MX 记录指定接收邮件的服务器。如果你需要用自己的域名收发邮件（比如 [email protected]），就必须配置 MX 记录。

类型     名称     优先级    值                       TTL
MX       @        10       mx1.improvmx.com         3600
MX       @        20       mx2.improvmx.com         3600
  • 优先级（Priority）：数字越小越优先。客户端先尝试优先级最低的服务器，失败后尝试下一个
  • 如果你的邮箱服务是 Google Workspace、Zoho Mail 或 ImprovMX，它们都会提供具体的 MX 记录值

TXT 记录（Text Record）

TXT 记录存储任意的文本信息，最常见的用途是域名验证和邮件安全。

类型     名称              值                                                      TTL
TXT      @                 v=spf1 include:_spf.google.com ~all                     3600
TXT      google._domainkey v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA...        3600
TXT      @                 v=DMARC1; p=quarantine; rua=mailto:[email protected]    3600
TXT      @                 claude-site-verification=abc123xyz                      3600

常见用途：

  • SPF（Sender Policy Framework）：声明哪些 IP 有权以你的域名发邮件，防止伪造
  • DKIM（DomainKeys Identified Mail）：邮件签名验证，证明邮件没有被篡改
  • DMARC：定义当 SPF/DKIM 验证失败时邮件服务器应该怎么处理
  • 域名所有权验证：各种第三方服务（Google Search Console、SSL 证书签发等）通过让你添加特定 TXT 记录来验证你对域名的控制权

记录类型对比

记录类型指向目标典型用途能否用于裸域名注意事项
AIPv4 地址网站、API 服务✅ 可以最基础的记录类型
AAAAIPv6 地址与 A 记录类似，支持 IPv6✅ 可以与 A 记录并存实现双栈
CNAME另一个域名子域名别名、第三方服务⚠️ 受限不能与其他记录共存；Cloudflare 有 CNAME Flattening
MX邮件服务器域名邮件收发✅ 可以需要优先级字段
TXT任意文本SPF/DKIM/DMARC/域名验证✅ 可以单条记录有长度限制（通常 255 字符一段，可多段拼接）
NS域名服务器子域委派✅ 可以修改需谨慎，错误会导致整个域名不可解析
CAACA 颁发策略限制哪些 CA 能为你的域名签发证书✅ 可以安全加固用，不配则任何 CA 均可签发
SRV服务定位指定特定服务的地址和端口✅ 可以用于 Matrix、XMPP 等协议

Cloudflare DNS 配置步骤

Cloudflare 是目前出海项目使用最多的 DNS 服务商之一。免费套餐已经包含权威 DNS、CDN、DDoS 防护和 SSL 证书，对早期产品来说足够用。

第一步：添加域名

  1. 登录 Cloudflare Dashboard
  2. 点击「Add a domain」（添加域名）
  3. 输入你的域名（例如 example.com），选择计划（Free 即可）
  4. Cloudflare 会扫描已有的 DNS 记录并导入，确认无误后继续

第二步：更换 Name Server

Cloudflare 会给你两个 Name Server 地址，格式类似：

bob.ns.cloudflare.com
alice.ns.cloudflare.com

去你的域名注册商（Namecheap、阿里云、GoDaddy 等），找到「Name Server」或「自定义 DNS」设置，把原来的 NS 替换为 Cloudflare 提供的两个地址。

更换 NS 后，域名解析的权威服务器就从注册商默认的变成了 Cloudflare。此后所有 DNS 记录都在 Cloudflare 管理，注册商处的旧解析记录不再起作用。

第三步：配置 DNS 记录

在 Cloudflare Dashboard → DNS → Records 页面添加记录。一个典型的出海产品配置：

类型     名称      内容                    代理状态     TTL
A        @         203.0.113.10            已代理(橙云)  自动
A        www       203.0.113.10            已代理(橙云)  自动
CNAME    api       api-service.vercel.app  仅 DNS(灰云)  自动
MX       @         mx1.improvmx.com (优先级 10)          自动
MX       @         mx2.improvmx.com (优先级 20)          自动
TXT      @         v=spf1 include:_spf.google.com ~all   自动
TXT      _dmarc    v=DMARC1; p=quarantine; ...           自动

关于代理状态：

  • 已代理（Proxied，橙色云朵图标）：流量经过 Cloudflare 的 CDN 和防护，IP 被隐藏为 Cloudflare 的 IP
  • 仅 DNS（DNS only，灰色云朵图标）：只做解析，不经过 Cloudflare 代理，直接暴露源站 IP

一般建议：网站相关记录（A、CNAME 指向 Web 服务的）开启代理，获得 CDN 和安全防护；MX、TXT 等非 Web 记录设为仅 DNS。

第四步：SSL/TLS 配置

Cloudflare 默认提供 SSL 证书。对于大多数场景，选择「Full (Strict)」模式即可——这要求源站也配置有效的 SSL 证书。如果你的源站用的是 Vercel、Netlify 这类平台，它们自带证书，直接选 Full (Strict) 就行。

第五步：验证

用以下命令检查解析是否生效：

# 查询 A 记录
dig example.com A +short
 
# 查询 MX 记录
dig example.com MX +short
 
# 查询 TXT 记录
dig example.com TXT +short
 
# 指定查询 Cloudflare 的 DNS 服务器
dig @bob.ns.cloudflare.com example.com A +short

也可以使用在线工具如 DNSChecker 从全球多个节点验证传播情况。

DNS 传播

什么是 DNS 传播

当你修改了一条 DNS 记录，这个变更不会瞬间在全球生效。变更需要从权威服务器出发，经过各级缓存节点逐步扩散，这个过程叫 DNS 传播（DNS Propagation）。

传播时间主要受两个因素影响：

  1. 你设置的 TTL — 缓存节点按 TTL 决定缓存多久。如果旧记录的 TTL 是 86400 秒，最坏情况下需要等 24 小时才能全球生效
  2. 中间缓存节点的策略 — 部分 ISP 的 DNS 服务器可能不完全遵守 TTL，导致额外延迟

典型传播时间

变更类型典型传播时间最坏情况
A 记录修改5 分钟 ~ 1 小时24 ~ 48 小时
CNAME 修改5 分钟 ~ 1 小时24 ~ 48 小时
MX 记录修改1 ~ 4 小时48 小时
NS 记录修改1 ~ 24 小时48 ~ 72 小时

NS 记录的变更传播最慢，因为它涉及 TLD 服务器缓存的更新。

减少传播等待的技巧

  • 变更前调低 TTL：提前 24 小时把 TTL 改到 300 秒，变更完成后等稳定了再改回去
  • 选择支持 API 的 DNS 服务商：Cloudflare、Route 53 等都提供 API，可以脚本化变更记录
  • 使用 DNS 传播检查工具：DNSChecker、whatsmydns.net 可以从全球数十个节点同时查询，快速确认传播进度

常见问题排查

DNS 问题排查的核心思路是：确认你在查对的记录、查对服务器、等够了时间。

解析不生效

现象：配置了 A 记录，但 dig 查询返回空或 NXDOMAIN。

排查步骤：

  1. 确认记录是否在正确的域名下（example.com 还是 www.example.com）
  2. 确认是否更换了 Name Server。如果用了 Cloudflare，但 NS 还没切换，在 Cloudflare 里配的记录不会生效
  3. 确认 NS 是否已传播完成：dig example.com NS +short
  4. 直接查询权威服务器：dig @你的NS地址 example.com A +short，如果权威服务器有结果但公共 DNS 没有，说明还在传播中

CNAME 与其他记录冲突

现象：给裸域名 example.com 配了 CNAME 后，MX 记录不生效。

原因：RFC 规定 CNAME 不能与其他记录共存于同一主机名。解决方案：

  • 用 A 记录替代 CNAME 指向裸域名
  • 使用 Cloudflare 的 CNAME Flattening
  • 把 CNAME 放在子域名上（比如 www），裸域名用 A 记录

邮件收发异常

现象：配置了域名邮箱但收不到邮件。

排查清单：

  1. MX 记录是否正确：dig example.com MX +short
  2. SPF 的 TXT 记录是否存在，包含的 IP 或域名是否正确
  3. DKIM 的 TXT 记录是否配置，选择器（selector）是否匹配
  4. DMARC 策略是否过于激进——初期建议 p=none 或 p=quarantine，观察一段时间再收紧
  5. 邮件服务器自身的日志

SSL 证书错误

现象：访问网站时浏览器提示证书无效或不受信任。

常见原因和解决：

症状可能原因解决方法
证书域名不匹配Cloudflare SSL 模式设为「Flexible」但源站有重定向循环改为「Full」或「Full (Strict)」
证书过期源站自签证书过期更新源站证书；或让 Cloudflare 签发边缘证书
ERR_TOO_MANY_REDIRECTSFlexible 模式下源站强制 HTTPS，导致循环改为 Full (Strict)；或在源站去掉强制 HTTPS 重定向

DNS 服务商对比

在出海项目中，选择 DNS 服务商需要考虑全球覆盖、API 支持、免费额度和安全性。

服务商免费套餐Anycast 全球节点API 支持DNSSEC适合场景
Cloudflare✅ 功能丰富✅ 200+ 城市✅ REST + Terraform✅大多数出海项目首选，CDN + DNS + 安全一体化
AWS Route 53❌ 按量付费✅✅ SDK + Terraform✅已在 AWS 生态的项目，需要与 ALB/CloudFront 深度集成
Google Cloud DNS✅ 有限额度✅✅ gcloud CLI + Terraform✅GCP 用户，需要与 GKE/Cloud Load Balancing 集成
Namecheap✅ 随域名附赠✅✅ 基础 API✅小型项目，域名注册和 DNS 在同一平台管理
DNSPod（腾讯云）✅ 免费版✅ 国内节点多✅ API + Terraform✅面向中国大陆用户的项目，国内解析速度快
Vercel DNS✅ 随域名附赠✅✅ Vercel CLI❌部署在 Vercel 的项目，零配置集成

实战案例

案例一：Next.js 产品部署到 Vercel + Cloudflare DNS

一个 AI SaaS 产品，前端部署在 Vercel，自定义域名为 app.example.com。

配置方案：

类型     名称     内容                       代理状态     TTL
A        @        76.76.21.21               仅 DNS       自动
CNAME    app      cname.vercel-dns.com      仅 DNS       自动
CNAME    www      cname.vercel-dns.com      仅 DNS       自动
MX       @         mx1.improvmx.com (10)                 自动
MX       @         mx2.improvmx.com (20)                 自动
TXT      @         v=spf1 include:_spf.google.com ~all   自动
TXT      _dmarc    v=DMARC1; p=none; ...                 自动

要点：

  • Vercel 自带 SSL 和 CDN，所以 Cloudflare 这边代理状态选「仅 DNS」（灰云），避免双重代理导致缓存和重定向问题
  • @ 的 A 记录指向 Vercel 提供的 IP（76.76.21.21），也可以不配，直接用 CNAME 指向 cname.vercel-dns.com
  • 邮件用 ImprovMX 转发到团队 Gmail，MX 和 SPF 记录配合使用

案例二：API 服务 + 邮件服务完整配置

一个 AI 产品的后端 API 部署在自有 VPS（203.0.113.10），邮件通过 Google Workspace 发送。

类型     名称               内容                                         代理状态     TTL
A        @                  203.0.113.10                                 已代理       自动
A        api                203.0.113.10                                 已代理       自动
CNAME    docs               docs-host.cdn.vercel.app                     仅 DNS       自动
MX       @                  aspmx.l.google.com (1)                                    自动
MX       @                  alt1.aspmx.l.google.com (5)                               自动
MX       @                  alt2.aspmx.l.google.com (5)                               自动
MX       @                  aspmx2.googlemail.com (10)                                自动
MX       @                  aspmx3.googlemail.com (10)                                自动
TXT      @                  v=spf1 include:_spf.google.com ~all                       自动
TXT      google._domainkey  v=DKIM1; k=rsa; p=MIGfMA0GCS...  (从 Google Admin 获取)  自动
TXT      _dmarc             v=DMARC1; p=quarantine; rua=mailto:[email protected]      自动
CAA      @                  0 issue "letsencrypt.org"                                 自动

要点：

  • Google Workspace 需要 5 条 MX 记录，全部配上
  • SPF 中 include:_spf.google.com 允许 Google 的服务器以你的域名发邮件，~all 表示其他来源的邮件标记为软失败
  • DKIM 的公钥值从 Google Admin 控制台的「邮件认证」页面获取
  • DMARC 初期用 p=quarantine（失败邮件进垃圾箱），观察报告一段时间后再考虑 p=reject
  • CAA 记录限制只允许 Let's Encrypt 为该域名签发证书，增加安全性

DNS 解析流程图

适读画布 · 130%
Mermaid 流程图加载中...

配置场景速查

不同的部署场景有不同的 DNS 配置模式。下表总结了常见的出海产品部署场景：

部署场景主域名记录子域名记录注意事项
Vercel 部署A 指向 76.76.21.21 或 CNAME 指向 cname.vercel-dns.comCNAME 指向 cname.vercel-dns.com不需要开 Cloudflare 代理，避免双重 CDN
Cloudflare PagesCNAME 指向 <project>.pages.dev同上可以开启 Cloudflare 代理（橙云）
自有 VPS + NginxA 指向服务器 IPA 或 CNAME 均可建议开启 Cloudflare 代理获得 DDoS 防护
AWS S3 + CloudFrontCNAME 指向 CloudFront 域名CNAME 指向 CloudFront 域名需要在 CloudFront 配置自定义域名和证书
静态站 + GitHub PagesA 指向 GitHub 的 4 个 IPCNAME 指向 <user>.github.io裸域名用 A 记录，www 用 CNAME
多区域部署多条 A 记录（不同区域 IP）使用 GeoDNS 或 Cloudflare Load Balancing需要 DNS 服务商支持地理位置路由

DNS 配置检查清单

在域名上线前，逐项检查以下内容：

  • A 记录已正确指向服务器 IP，dig 查询结果与预期一致
  • CNAME 记录没有与同主机名的其他记录冲突
  • MX 记录已配置，优先级设置正确
  • SPF 记录已添加，包含所有合法的邮件发送来源
  • DKIM 记录已从邮件服务商获取并配置
  • DMARC 记录已添加，初期策略设为 none 或 quarantine
  • TTL 设置合理——稳定记录用较长 TTL，即将变更的先调低
  • SSL 证书已配置，Cloudflare SSL 模式与源站匹配（推荐 Full Strict）
  • NS 记录已切换到正确的权威 DNS 服务商，且传播完成
  • CAA 记录已配置（可选但推荐），限制可签发证书的 CA
  • DNSSEC已启用（如果 DNS 服务商支持），防止 DNS 劫持
  • 通配符记录使用谨慎——*.example.com 会匹配所有未单独配置的子域名
  • 已使用全球多节点工具（DNSChecker 等）验证传播状态
  • 邮件收发测试通过——发一封测试邮件到 Gmail/Outlook，检查是否进垃圾箱

小结

DNS 配置是每个出海产品上线过程中绑不开的一步。它的知识点不算深，但细节不少：记录类型选错、TTL 设置不当、SPF/DKIM 漏配，都可能带来实际故障。

核心要点回顾：

  1. 用 A 记录指向 IP，用 CNAME 指向其他域名
  2. 邮件必须有 MX 记录，配合 SPF + DKIM + DMARC 才能保证投递率
  3. Cloudflare 是最常见的出海 DNS 选择，注意区分代理模式和纯 DNS 模式
  4. DNS 传播需要时间，变更前可以提前调低 TTL
  5. 排查问题从 dig 命令开始，逐层确认：记录是否存在 → 权威服务器是否返回 → 公共 DNS 是否已同步

把这些基础打扎实，后续的 CDN 配置、SSL 证书、邮件服务接入都会顺畅很多。

参考资料

  1. Cloudflare Learning Center — DNS Records
  2. Cloudflare — Primary Setup (Full)
  3. Cloudflare — Change Your Nameservers
  4. Google Cloud DNS — Best Practices
  5. Spamhaus — 10 DNS Best Practices
  6. MailerSend — Understanding DNS Records in Email
  7. CMU SEI — Six Best Practices for Securing DNS Infrastructure
  8. Cloudflare — What Is DNS?