DNS 扩展篇：从会配记录，到真正能排查 DNS 问题

上一篇聊完普通解析、泛域名解析、A 记录、TXT 记录、普通证书和通配证书之后，我对 DNS 的理解已经比以前清楚很多了。

以前我对 DNS 的理解基本停留在：

域名 -> IP

也就是：

A 记录

后来才发现，DNS 不只是“把域名解析成 IP”。

它还承担了：

命名
寻址
验证
策略
委派
缓存
排障

这些角色。

这篇算是 DNS 的扩展篇，整理一下接下来还值得补的内容。

目标不是背概念，而是让自己以后遇到 DNS、证书、域名、Caddy、Cloudflare、阿里云解析这些问题时，能知道从哪里下手排查。

一、DNS 不只是 A 记录

我以前最熟悉的是 A 记录：

abc.weini.xin A 123.123.123.123

意思是：

abc.weini.xin 解析到 123.123.123.123

但 DNS 里还有很多记录类型。

比较常见的有：

A      域名 -> IPv4
AAAA   域名 -> IPv6
CNAME  域名 -> 另一个域名
TXT    域名 -> 一段文本
MX     邮件服务器
NS     这个域名由哪些 DNS 服务器管理
CAA    允许哪些证书机构给这个域名签发证书

这里面我觉得最值得优先理解的是：

CNAME
NS
CAA
TXT

因为它们和日常建站、证书、Cloudflare、邮件、安全关系很大。

二、A 记录：最直观的寻址

A 记录是最常见的 DNS 记录。

它的作用是：

域名 -> IPv4 地址

比如：

weini.xin A 39.106.128.214

意思是：

访问 weini.xin 时，去 39.106.128.214 这台服务器

如果是泛域名：

*.dev.weini.xin A 39.106.128.214

意思是：

所有 xxx.dev.weini.xin 都去 39.106.128.214

A 记录解决的是：

这个名字应该去哪台 IPv4 服务器？

它是 DNS 里最基础的寻址能力。

三、AAAA 记录：IPv6 版本的 A 记录

AAAA 记录和 A 记录类似，只不过它指向的是 IPv6 地址。

比如：

abc.weini.xin AAAA 2408:xxxx:xxxx::1

A 记录负责 IPv4：

123.123.123.123

AAAA 记录负责 IPv6：

2408:xxxx:xxxx::1

现在很多服务器、CDN、云厂商都支持 IPv6。

如果未来自己的服务需要支持 IPv6，就会碰到 AAAA 记录。

现在不一定马上用，但要知道它存在。

四、CNAME：别名，不是直接指向 IP

CNAME 很常见。

它的作用是：

一个域名是另一个域名的别名

比如：

www.weini.xin CNAME weini.xin

意思是：

www.weini.xin 不直接写 IP
而是跟随 weini.xin 的解析结果

还有很多 CDN 或云服务会让你配置 CNAME。

比如某个平台给你一个地址：

xxx.cdn-provider.com

它会让你配置：

static.weini.xin CNAME xxx.cdn-provider.com

这样访问：

static.weini.xin

实际会跟着平台给的那个域名走。

CNAME 的好处是，目标服务的 IP 以后变化了，你不用管。因为你指向的是它的域名，不是固定 IP。

CNAME 要注意什么？

一个常见规则是：

同一个主机记录如果配置了 CNAME，一般不能再同时配置 A、MX 等其他记录。

比如你已经有：

www.weini.xin CNAME weini.xin

就不要再给 www.weini.xin 配：

www.weini.xin A 1.2.3.4

否则容易冲突。

五、TXT：不是访问用的，而是声明和验证用的

TXT 记录返回的是字符串。

比如：

_acme-challenge.dev.weini.xin TXT "abcdefg"

它不是告诉浏览器访问哪台服务器。

它只是公开声明：

_acme-challenge.dev.weini.xin 这个名字下面有一段文本 abcdefg

TXT 的用途很多：

证书 DNS 验证
Google / GitHub / 各种平台的域名所有权验证
SPF 邮件防伪
DKIM 邮件签名
DMARC 邮件策略
一些服务商的配置声明

之前理解通配证书时，TXT 记录就很关键。

通配证书申请时，证书机构会要求你添加类似：

_acme-challenge.dev.weini.xin TXT "随机验证码"

证书机构查询 DNS，发现字符串一致，就证明你能控制这个域名的 DNS。

所以 TXT 很重要。

它不是寻址记录，而是：

验证 / 声明 / 策略记录

六、MX：邮件服务器

MX 记录是给邮件用的。

比如：

weini.xin MX 10 mail.weini.xin

意思是：

发给 xxx@weini.xin 的邮件，应该交给 mail.weini.xin 这台邮件服务器

如果以后自己搞企业邮箱、域名邮箱，就一定会碰到 MX。

很多邮箱服务商会让你配置：

MX
TXT
CNAME

一整套记录。

MX 负责收邮件路径。

TXT 里的 SPF、DKIM、DMARC 负责邮件防伪和信誉。

如果只是建站，MX 不重要。

如果要用自己的域名发收邮件，它就很重要。

七、NS：谁负责管理这个域名的解析

NS 记录非常关键。

它回答的问题是：

这个域名由哪些 DNS 服务器负责解析？

比如：

weini.xin NS ns1.alidns.com
weini.xin NS ns2.alidns.com

这说明：

weini.xin 的权威 DNS 在阿里云

如果你把 DNS 托管到 Cloudflare，那么 NS 可能会变成：

xxx.ns.cloudflare.com
yyy.ns.cloudflare.com

这就意味着：

weini.xin 的解析权交给 Cloudflare 管了

这点非常重要。

因为域名注册商和 DNS 托管商不是一回事。

比如：

域名可以在阿里云买
DNS 可以交给 Cloudflare 管
服务器可以在另一家云厂商

这三个东西可以分开。

我以前容易把“在哪里买域名”和“在哪里配置 DNS”混在一起。

现在理解 NS 后，就清楚多了。

NS 决定权威 DNS 在哪里。

你应该去权威 DNS 那里改记录。

八、CAA：限制谁能给我的域名发证书

CAA 是一个和证书安全有关的 DNS 记录。

它的作用是告诉证书机构：

哪些 CA 可以给我的域名签发证书

比如：

weini.xin CAA 0 issue "letsencrypt.org"

意思是：

只允许 Let's Encrypt 给 weini.xin 签发证书

如果你还用 ZeroSSL，也可以加：

weini.xin CAA 0 issue "sectigo.com"

CAA 不是必须配置。

很多人不配也没问题。

但知道它存在很重要。

因为它说明 DNS 不只是寻址，还可以表达安全策略。

如果以后想提高域名证书安全，可以研究 CAA。

九、权威 DNS 和递归 DNS

这是 DNS 里非常关键的一层。

我以前容易以为 DNS 就是一个地方。

实际上 DNS 查询里有不同角色。

递归 DNS

你电脑、路由器、系统里常见的 DNS：

8.8.8.8
1.1.1.1
114.114.114.114
223.5.5.5

这些通常是递归 DNS。

它们的作用是：

帮你去查最终结果

你问它：

mcp.dev.weini.xin 是多少？

它会一步一步帮你查，然后返回答案。

权威 DNS

权威 DNS 才是某个域名记录的最终来源。

比如 weini.xin 的 NS 指向阿里云 DNS，那么阿里云 DNS 就是 weini.xin 的权威 DNS。

你在阿里云控制台添加：

*.dev.weini.xin A 39.106.128.214

这个记录最终存在阿里云的权威 DNS 上。

递归 DNS 只是帮别人查询和缓存。

查询链路大概是这样

你的电脑
  ↓
递归 DNS，比如 8.8.8.8
  ↓
根 DNS
  ↓
顶级域 DNS，比如 .xin
  ↓
weini.xin 的权威 DNS
  ↓
返回记录

所以改 DNS 记录时，要知道：

我应该去权威 DNS 那里改
不是去递归 DNS 那里改

十、TTL：为什么 DNS 不是你一改就全世界立刻生效

TTL 是 DNS 记录的缓存时间。

比如一条记录：

mcp.dev.weini.xin A 39.106.128.214 TTL 600

意思是：

递归 DNS 查到这个结果后，可以缓存 600 秒

也就是 10 分钟。

如果 TTL 是 3600，就可以缓存 1 小时。

所以 DNS 修改不是全世界瞬间同步。

你改了权威 DNS 后，有些递归 DNS 可能还在用旧缓存。

这就是为什么经常出现：

我控制台明明改了
为什么本地还是旧 IP？
为什么我这里生效了，别人那里没生效？

可能就是 TTL 和缓存导致的。

实用经验

正式切换 IP 前，可以提前把 TTL 调低，比如：

60
300
600

等切换稳定后，再调高：

3600
7200

开发测试域名可以 TTL 短一点。

正式稳定域名可以 TTL 长一点。

十一、DNS 排障不能只看控制台，要学会 dig

只看 DNS 控制台是不够的。

因为控制台显示的是你配置了什么。

但外部真实查询结果是什么，要用工具查。

最常用的是：

dig

查 A 记录

dig mcp.dev.weini.xin

或者简洁一点：

dig +short mcp.dev.weini.xin

查 TXT 记录

dig TXT _acme-challenge.dev.weini.xin

简洁版：

dig +short TXT _acme-challenge.dev.weini.xin

查 NS

dig NS weini.xin

查 CAA

dig CAA weini.xin

指定递归 DNS 查询

dig @8.8.8.8 mcp.dev.weini.xin
dig @1.1.1.1 mcp.dev.weini.xin
dig @223.5.5.5 mcp.dev.weini.xin

这个很有用。

因为你可以比较不同递归 DNS 的结果是否一致。

查完整链路

dig +trace mcp.dev.weini.xin

这个会从根开始追踪整个查询过程。

排查复杂 DNS 问题时很有用。

十二、nslookup 也能用，但 dig 更适合排障

Windows 上很多人习惯用：

nslookup mcp.dev.weini.xin

查 TXT：

nslookup -type=TXT _acme-challenge.dev.weini.xin

查 NS：

nslookup -type=NS weini.xin

nslookup 能用，而且系统自带，方便。

但如果是认真排障，我更推荐 dig。

因为 dig 输出更清晰，也更适合指定 DNS、查 trace、查不同记录类型。

十三、DNS 解析和 HTTP 路由一定要分清楚

这个是我这次最重要的理解之一。

DNS 只负责：

这个域名应该去哪个 IP

但到了服务器之后，具体交给哪个服务，不是 DNS 决定的。

比如：

mcp.dev.weini.xin
api.dev.weini.xin
demo.dev.weini.xin

它们通过泛解析都到了同一个 IP：

39.106.128.214

DNS 的工作到这里就结束了。

后面要靠 Caddy 或 frp 根据 HTTP Host 分流：

Host: mcp.dev.weini.xin -> 服务 A
Host: api.dev.weini.xin -> 服务 B
Host: demo.dev.weini.xin -> 服务 C

所以要记住：

DNS 负责到服务器
Caddy/Nginx/frp 负责到服务

如果一个域名能 ping 到服务器，但访问 404，那不一定是 DNS 错。

可能是 Caddy 没配置对应站点。

如果 HTTPS 证书不对，也不一定是 DNS 错。

可能是证书没签好、Host 不匹配、Caddy 配置没生效。

分层看问题，排障会清楚很多。

十四、DNS 和 HTTPS 证书的关系

证书这块也要重新理解。

普通证书：

abc.weini.xin

通常可以用 HTTP 验证。

证书机构访问：

http://abc.weini.xin/.well-known/acme-challenge/xxx

DNS 把它带到服务器。

Caddy 返回随机验证码。

证书机构验证通过，发证书。

通配证书：

*.dev.weini.xin

不能用 HTTP 验证，因为 * 不是具体域名。

所以要用 DNS TXT 验证：

_acme-challenge.dev.weini.xin TXT "随机验证码"

证书机构查 DNS，确认验证码一致，发通配证书。

所以 DNS 在证书体系里有两个角色：

普通证书：DNS 负责带路
通配证书：DNS 负责证明控制权

十五、DNS 也参与邮件安全

以后如果要用自己的域名发邮件，就会遇到更多 DNS 记录。

比如：

MX
SPF
DKIM
DMARC

简单理解：

MX

决定谁收邮件。

weini.xin 的邮件交给哪个邮件服务器

SPF

通过 TXT 记录声明：

哪些服务器可以代表我这个域名发邮件

DKIM

通过 TXT 记录放公钥。

收件方可以用它验证邮件签名。

DMARC

告诉收件方：

如果发现伪造邮件，应该怎么处理

比如：

直接拒收
标记垃圾邮件
只上报不处理

这块暂时不一定要深入，但要知道：

邮件系统大量依赖 DNS TXT 来证明身份和设置策略。

这也再次说明，DNS 不是简单的域名转 IP。

十六、域名规划也很重要

技术之外，域名规划本身也很重要。

我现在比较认可这种分层：

weini.xin              正式主站
www.weini.xin          正式入口
api.weini.xin          正式 API
blog.weini.xin         博客

*.dev.weini.xin        开发服务
*.test.weini.xin       测试服务

这种结构的好处是：

正式服务清晰
开发服务自由
测试服务自由
主域名空间不被污染

不要一上来就直接：

*.weini.xin

因为这个范围太大。

它会覆盖所有一级子域名：

mail.weini.xin
admin.weini.xin
cdn.weini.xin
random.weini.xin

不是不能用，但管理边界会变差。

更稳的是把泛域名放到二级命名空间下面：

*.dev.weini.xin
*.test.weini.xin

这就是一种简单的域名治理。

十七、我后面最应该补的三个方向

如果只挑三个最值得继续补的 DNS 知识，我觉得是：

1. 权威 DNS vs 递归 DNS
2. TTL 和缓存
3. dig 排障

这三个掌握以后，遇到 DNS 问题就不会只会猜。

比如遇到问题时，可以问自己：

我是在权威 DNS 改的吗？
递归 DNS 有没有缓存旧结果？
不同 DNS 查询结果一致吗？
TTL 是多少？
Caddy 是否真的收到了这个 Host？
证书是否匹配这个域名？

这就从“配置型理解”变成了“排障型理解”。

十八、最后总结

这一轮 DNS 学下来，我觉得自己的理解明显升级了。

以前：

DNS = A 记录 = 域名指向 IP

现在：

DNS = 命名系统 + 寻址系统 + 验证系统 + 策略系统

A 记录解决：

去哪个 IPv4

AAAA 记录解决：

去哪个 IPv6

CNAME 解决：

这个名字是谁的别名

TXT 解决：

这个名字公开声明了什么字符串

MX 解决：

邮件交给谁

NS 解决：

这个域名由谁管理解析

CAA 解决：

哪些证书机构可以发证书

TTL 决定：

结果能缓存多久

dig 帮助我们：

从外部真实查询 DNS

这套东西理解之后，再看 Caddy 自动 HTTPS、frp 泛域名、通配证书、Cloudflare、阿里云 DNS、邮箱验证，就不会那么迷糊了。

DNS 的确不只是“域名解析”。

它是互联网服务入口背后的基础设施层。