DNS 记录查询

各类记录，以及它们实际是干什么的

「传播」这个词用错了

关于 DNS 最有用的一件事，因为它把一段无法预测的等待，变成了一个由你掌控的数字。

什么都不会传播。没有推送，没有分发，也没有一波更新在互联网上滚过去。你一按保存，你的名字服务器就已经有了新值。真正耗时间的是：全世界每一台解析器都持有旧答案的一份缓存副本，而每一台都会一直留着它，直到当初给它的 TTL 到期。

所以这段延迟并不神秘——它恰好就是每台解析器上次询问时所公布的那个 TTL。如果你的记录 TTL 是 3600 秒，那么有些解析器五分钟后就会再问一次，有些则要等一小时，这就是为什么一次变更看上去是不均匀地传到人们那里的。

由此就得出了任何计划内变更的操作流程：

1. 提前一天，把 TTL 降到 300 秒。等旧的那个 TTL 过期，好让所有人都取到这个短的。
2. 做变更。现在它只需要五分钟，而不是一天。
3. 等它稳定下来之后，把 TTL 调回去。

之所以要调回去，是因为低 TTL 意味着更多查询、缓存未命中时更高的时延，以及在你的名字服务器变得不可达时更难熬的一次故障——没有人手上有一份还能用的缓存答案可以兜底。

邮件相关的记录，大部分问题都出在这儿

有三条 TXT 记录决定了你的邮件会不会被相信。它们经常被配错，而失败是无声的——邮件被投进垃圾箱而不是被退回，所以没有人会告诉你。

SPF

列出哪些服务器可以代表你的域名发信。按出错频率排序，常见的错误是：

• 两条 SPF 记录。 RFC 7208 要求接收方把这当作永久性错误，于是整个检查直接失败。把它们合并成一条。
• 超过十次 DNS 查询。 每一个 include: 都算一次，而且 include 会嵌套。一个邮件服务商加一个营销平台再加一个工单系统，很快就到了，而一旦超过，检查就失败。
• 以 `~all` 或 `?all` 结尾。 两者的意思都是「大概不是我们，不过随你便」。只有 -all 才是在请求接收方拒收。

DKIM 与 DMARC

DKIM 用一把密钥给每封信签名，而这把密钥的公开那一半住在某个选择器名字下的 TXT 记录里，比如 selector1._domainkey.example.com——你必须知道那个选择器才能查到它，这也是为什么它不在上面的默认查询里。DMARC 住在 _dmarc.example.com，它告诉接收方：当 SPF 和 DKIM 意见不一致时该怎么办，以及把报告寄到哪里。

在上面的工具里查一下 _dmarc.yourdomain.com。如果什么都没返回，那么接收方就没有得到任何指示，对于任何冒充你的邮件，它们只能自行判断。

顶点上的 CNAME 规则

同一个名字上，CNAME 不能与任何其他记录共存。而域名的顶点必须有 SOA 和 NS 记录，所以顶点不能有 CNAME——这就是为什么把 example.com 指向一个 SaaS 服务商很别扭，而 www.example.com 却轻而易举。

变通办法因服务商而异：ALIAS、ANAME 或者 CNAME 扁平化，它们都在服务器端解析目标，然后用一条 A 记录来应答。它们管用，但它们不是标准，而且值得在你为此耗掉一个下午之前就先知道。

相关

等记录都指向你想要的地方之后，去检查一下证书——主机实际出示的那张——以及它返回了哪些响应头。想知道某条记录指向的地址归哪个网络所有，ASN 查询会回答这个问题。