域名DNS解析配置教程：A记录指向服务器IP、CNAME绑定子域名的操作
DNS 解析就是给域名填一张指路表：A 记录把主机名指向服务器 IP，CNAME 把子域名指向另一个域名。搞清这两条记录的区别，再按下面几个问题逐个配置，就能完成绝大部分解析需求。
问：A 记录和 CNAME 各自解决什么问题？
A 记录是"域名指向 IP"。主机记录填 @（代表主域名本身）或 www、mail 这类前缀，记录值填服务器的 IPv4 地址，比如 203.0.113.10。访客请求 www.example.com 时，递归 DNS 问到权威 DNS，拿回这个 IP 再建立连接。IP 一变，就得回来改记录。
CNAME 是"域名指向域名"。记录值必须写另一个域名，通常是服务商分配的，例如 CDN 给的 example.com.w.kunlunsl.com，或者对象存储、SaaS 建站平台下发的目标域名。解析时先命中这条 CNAME，再继续查目标域名的 A 记录，最后才落到 IP。好处是目标域名背后的 IP 怎么调整，你这边都不用动。
两者的字段长得一样：记录类型、主机记录、记录值、TTL（缓存秒数）。真正的差别在于记录值填 IP 还是填域名，以及日后由谁来维护这条映射。
问：什么时候该用 A 记录，什么时候该用 CNAME？
- 手上有固定公网 IP 的独立服务器、云主机，直接上 A 记录。解析链路最短，排查问题也最直观。
- 接了 CDN、WAF、对象存储、第三方建站平台的，用服务商给的目标域名做 CNAME。这类服务背后的 IP 会频繁调整，写死 IP 迟早失效。
- 主域名（裸域）要留意：按 RFC 规范，根域名上不能放 CNAME，会和 MX、NS、SOA 等记录冲突。既要 CDN 又必须用裸域时，看服务商是否提供 ALIAS/ANAME 或 CNAME 展平（Flatten）能力，Cloudflare 的 CNAME Flattening、部分国内厂商的别名解析都属于这类折中方案。
- 企业邮箱、域名所有权验证这类一次性用途，按对方文档给的记录照抄即可，别自己发挥。
一个主机记录只能有一条 CNAME，也不能同时存在 CNAME 和同名的其他记录类型——这是最常见的配置报错来源。
问：在控制台里具体怎么加这两条记录？
先确认域名的 NS 已经指向你要操作的那家 DNS 服务商，否则改了也不生效。以下路径是常见平台的位置，具体菜单以平台页面为准：
- 阿里云：控制台 → 域名 → 找到目标域名 → 解析设置 → 添加记录，选记录类型、填主机记录和记录值，TTL 通常默认 10 分钟。
- 腾讯云 DNSPod：控制台 → DNS 解析 DNSPod → 我的域名 → 解析 → 添加记录。
- Cloudflare：DNS → Records → Add record，注意代理状态开关——橙色云朵走 Cloudflare 代理（本质上是 CNAME 展平），灰色云朵是 DNS only，会直接暴露源站 IP。
添加 A 记录的填写示例：主机记录 @、类型 A、记录值 203.0.113.10。添加 CNAME 的填写示例：主机记录 www、类型 CNAME、记录值 example.com.w.cdngslb.com（末尾是否带点，各平台要求不同，按界面提示填）。
TTL 建议：日常保持默认值即可；准备迁移 IP 或切 CDN 之前，提前把 TTL 调到 60～300 秒，等旧值过期再动手，切换窗口能短很多。
问：怎么验证解析是否生效，不生效该查什么？
命令行最快。Linux / macOS 上用：
dig www.example.com A +short
dig www.example.com CNAME +short
dig example.com NS +short
Windows 上用 nslookup -type=CNAME www.example.com 8.8.8.8，或 nslookup www.example.com 223.5.5.5 指定公共 DNS 查询。想模拟不同地区的返回结果，可以用多节点查询工具，或者直接用站内的 DNS解析查询 看各地递归 DNS 的表现。
不生效时按下面顺序排查：
- 本地缓存：先
ipconfig /flushdns（Windows）或sudo dscacheutil -flushcache（macOS）再查一次。 - TTL 未过期：刚改完记录，旧值可能还留在各地缓存里，等一个 TTL 周期再看。
- 记录冲突：同一主机记录上既加了 CNAME，又加了 A、TXT、MX，平台可能直接报错或静默失败。
- NS 不对：域名 NS 指向的不是你正在操作的那家服务商，记录自然不会生效。
- 合规拦截：国内主机对应的域名未完成备案、域名未实名，解析可能被服务商暂停。
问：配置时最容易踩的坑有哪些？
泛解析 * 的优先级低于具体记录，写 * 兜底时别指望它能覆盖已有记录。CNAME 链拉得越长，首次解析耗时越高，生产环境尽量避免多级跳转。改完 NS 之后，原服务商那边的解析记录全部作废，需要在新服务商重建。CDN 场景下，CNAME 只是把流量引到边缘节点，回源地址还得在 CDN 控制台单独配，别以为加完 CNAME 就完事了。迁移前把当前记录截图或导出，真出问题时能快速回滚。