说在前面的话：如果不断的重复某项事情记忆就会变得牢固，当重复到了足够的次数，想忘掉也不是一件容易的事情了。反过来，如果一件事或者一个知识你没有重复足够多的次数或者无法推理、触发出来就大概不会记得它了。所以有些东西还是要写下来，整理出来，才能长久保存。有些知识点可能学到了但很长时间用不上，但一旦想找它想起来它那可真的不容易。

DNS 这里面的知识很多是有用的，但有些也是平常用不到，但关键时候还是能用到的。

DNS 专有名词与记录冲突规则

一、核心架构

二、域名结构

三、记录类型

四、查询行为

五、安全相关

六、高级与生态

七、常见配置/管理

八、记录共存与冲突规则

8.1 CNAME 的排他性（铁律一）

CNAME 记录不能与其他任何记录共享同一个 owner name。 这是 DNS 协议层面的硬性约束（RFC 1034/2181）。

✅ 正确：
  www.example.com.   CNAME   example.com.
❌ 错误（CNAME + 其他记录共存）：
  www.example.com.   CNAME   example.com.
  www.example.com.   A       1.2.3.4              ← 冲突！
  www.example.com.   MX      10 mail.example.com.  ← 冲突！
  www.example.com.   TXT     "v=spf1 ..."          ← 冲突！

原因： CNAME 的语义是"这个域名就是另一个域名的别名"，因此它的所有资源记录都应该从目标域名继承。如果 A 和 CNAME 并存，解析器无法确定返回哪个。

8.2 Zone Apex 不能有 CNAME（铁律二）

example.com 本身（根域名 / naked domain）不能设置 CNAME。因为根域名必须存在 SOA 和 NS 记录，而 CNAME 的排他性意味着它无法与这些记录共存。

云厂商提供了非标准的替代方案：Cloudflare 的 CNAME Flattening、AWS Route53 的 ALIAS、DNS Made Easy 的 ANAME。

8.3 常见记录冲突矩阵

一句话：有 CNAME 就容不下任何别的东西；没有 CNAME，基本都能共存（zone apex 除外）。

8.4 各记录类型详解

A / AAAA — 允许多条，天然轮询

✅ 合法（DNS 轮询负载均衡）:
  www.example.com.   A    1.2.3.4
  www.example.com.   A    5.6.7.8
  www.example.com.   A    9.10.11.12

CNAME — 独占，不能形成环

❌ CNAME 链太长：
  a.example.com.   CNAME   b.example.com.
  b.example.com.   CNAME   c.example.com.
  c.example.com.   CNAME   d.example.com.   ← 大多数解析器有深度限制（~8-16）
❌ CNAME 环：
  a.example.com.   CNAME   b.example.com.
  b.example.com.   CNAME   a.example.com.   ← 死循环，解析器报 SERVFAIL
⚠️ CNAME 指向不存在的域名 → 解析结果 NXDOMAIN

MX — 不能指向 CNAME，必须指向 A/AAAA

✅ 正确：
  example.com.      MX   10  mail.example.com.
  mail.example.com.  A        1.2.3.4
❌ 错误（MX 目标不能是 CNAME，RFC 2181 §10.3）：
  example.com.      MX   10  mail.example.com.
  mail.example.com. CNAME    other.example.com.   ← 很多 MTA 拒绝或报警

TXT — 几乎无限制，但注意长度和 SPF 的特殊规则

✅ 合法：
  example.com.   TXT   "v=spf1 include:_spf.google.com ~all"
  example.com.   TXT   "google-site-verification=xxxxx"
⚠️ 单条 TXT 字符串超过 255 字节会被自动拆分

NS — 子域切 Zone 的冲突

⚠️ 典型错误：
  example.com.       NS    ns1.provider.com.
  www.example.com.   NS    ns1.other.com.      ← www 成了新的 zone 切点
  www.example.com.   A     1.2.3.4              ← 这条 A 被"遮蔽"了！
如果 www.example.com 是新的 zone 切点，所有 www.example.com 的记录
都应该在切过去的权威服务器上定义。parent zone 里的 A 记录会被忽略。

九、实际踩坑场景

场景 1 — CDN 加速根域名

需求：example.com 也要走 CDN
问题：不能用 CNAME（zone apex 冲突）
方案：用 ALIAS/ANAME（Cloudflare/AWS Route53），或直接将 CDN 节点 IP 写成 A 记录

场景 2 — MX 指向了 CNAME

example.com.        MX   10  mail.example.com.
mail.example.com.   CNAME   ghs.googlehosted.com.
虽然 Google Workspace 有时会引导用户这么做，但 RFC 2181 §10.3 明确禁止。
部分 MTA 会拒绝，部分会追赶 CNAME。行为不统一，不应这样做。

场景 3 — 多条 SPF TXT 导致 PERMERROR

❌ 错误：
  example.com.   TXT   "v=spf1 include:_spf1.example.com ~all"
  example.com.   TXT   "v=spf1 include:_spf2.example.com ~all"
RFC 7208：多条 SPF 记录会导致 PERMERROR，相当于没有 SPF。
✅ 正确做法是合并成一条：
  example.com.   TXT   "v=spf1 include:_spf1.example.com include:_spf2.example.com ~all"

十、一句话速查表

一、 基础概念与架构（地基）

这部分决定了你对DNS的理解是停留在“改个IP”还是“懂原理”。

二、 核心记录类型（Records）

这是最常用的部分，不仅要背名字，要知道具体场景。

三、 解析流程与缓存（实战核心）

很多时候出问题不是因为配错了，而是因为缓存。

四、 运维与排错命令（肌肉记忆）

这些命令必须在脑子里形成反射。

五、 高级与安全（关键时刻救命）

这些平时看不见，出事就是大事。

六、 常见故障场景速查（记忆锚点）

为了帮你记住上面这些，可以对应以下场景：

1. “网站打不开，但IP能访问” → 查 A记录、Local DNS、Hosts。
2. “换了解析半天没生效” → 查 TTL、ISP缓存、Serial Number 是否递增。
3. “邮件发不出去” → 查 MX记录、PTR反向解析（SPF/DKIM通常也属于DNS范畴）。
4. “CDN回源错误” → 查 CNAME 是否指向正确，是否存在循环CNAME。
5. “部分地区访问异常” → 查 GSLB/智能解析 策略，是否有地区屏蔽。

总结：必背的“最小知识集”

1. UDP 53 端口。
2. A 记录是 IPv4，AAAA 是 IPv6。
3. CNAME 是别名，不能和 A 记录共存于根域名。
4. MX 记录决定邮件去哪。
5. TTL 决定缓存多久。
6. 解析顺序：缓存 > Hosts > DNS。
7. dig 是最好用的诊断工具。
8. SOA 里的 Serial 号不涨，从服务器不更新。
9. PTR 是用来做 IP 反解的。
10. 修改前 一定要降低 TTL。