DNS查询工具

概述

DNS 是每一步之前的那一步。当一个站点访问不了、当邮件被退回、或者当代码已经发布出去了却谁都看不到时，第一个要问的问题几乎总是这个名字当前解析到什么——而第二个问题是，这话到底是谁告诉你的。

这个工具向一个公共的 DNS-over-HTTPS 解析器请求你最常需要的那六种记录类型，并把答案连同它们各自的 TTL 一起显示出来。因为浏览器无法打开一个 DNS 套接字，这个查询必须经过我们的 API，而不能留在本地完成；这是本站唯一一处必须离开你机器的东西，隐私政策 里写清楚了它会经历什么。

使用方法

1. 输入一个域名——应该是 example.com，而不是 https://example.com/path。
2. 读返回的那些记录。每一行会显示它的类型、名称、值和 TTL。
3. 用类型按钮过滤已经在屏幕上的内容。这些按钮不会发起新的查询。

每种记录类型回答什么问题

MX 那一列把优先级和主机分开显示，因为这个数字表示的是一种偏好，而不是对质量的排名：数字小的那个胜出，而数值相等则意味着发送方可以在它们之间任选其一。一个完全没有 MX 记录的域名，仍然可以按隐式 MX 规则在它自己的 A 记录上收信，这在规范上是合规的，而且几乎总是无意造成的结果。

读懂 TTL

TTL 表示解析器打算把这个答案保留多久，单位是秒。它是在往下倒数的，所以你看到的那个数字是某一条缓存条目的剩余寿命，而不是区域文件里配置的那个值。间隔一分钟查两次，你通常就能看见它在往下掉。

这是整个迁移过程中最有用的一个数字。一条 TTL 为 86400 的记录，在你改动它之后，仍然会被各级缓存继续服务最长一整天，不管你的 DNS 服务商多快地应用了这次编辑。也就是说，补救动作必须发生在变更之前：先把 TTL 降到 300，等旧的 TTL 过期，然后才做变更，之后再把 TTL 调回原来的值。

为什么不同工具给出的答案不一样

两个解析器完全可以在都没出错的前提下互相矛盾，而知道背后的原因能省下很多困惑：

• 缓存状态。 这个工具读的是 Cloudflare 的解析器。你 ISP 的解析器有它自己的一份缓存，也有它自己那份独立的倒数。
• 地理路由。 很多大型站点会返回离发起解析的那一方最近的地址，所以从一个 Cloudflare 数据中心拿到的答案，并不是你自己的笔记本会拿到的答案。
• 分离解析（split-horizon DNS）。 一个企业网络可以为某个在公网上解析成别的东西的名字返回内网地址。公共解析器永远看不到这份内部视图。

如果你要的是「权威服务器此刻怎么说，而且完全不经过缓存」，那就对这个工具列出来的某个 NS 主机执行 dig @<nameserver> <name> <type>。那才是基准事实；除此之外的一切都是缓存。

示例

• 邮件一直被退回。 先看 MX，再到 TXT 里找 SPF 记录。同一个域名上出现两条 SPF 记录，在规范里属于硬失败，而这恰恰是加了新的发送方、却忘了把旧的那一行删掉的常见结果。
• 发布之后某个子域名 404。 看它是不是一条 CNAME，指向一个已经被改过名字的平台主机名。
• 域名转移之后有东西过时了。 拿 NS 和注册商那边显示的内容对比。两边不一致，意味着你正在编辑的那个区域，并不是正在被实际服务的那个区域。
• 验证某个服务。 域名验证令牌住在 TXT 里，而最常见的失败是把记录加到了 www 上，而不是加在根域上。

说明

域名在发起查询之前会先按主机名模式做一次校验，所以 URL、IP 地址以及 Unicode 形式的国际化名称都会被拒绝，而不是原样放过去。如果要查的是国际化域名，请先用 IDN 转换 把它转成 Punycode。

记录是按解析器实际返回的类型标注的，而不是按你请求的类型标注。这一点对别名主机尤其重要：对一个本身就是 CNAME 的名字请求 A，会同时返回这个别名和解析出来的那些地址，而把别名错标成地址记录，会造成实质性的误导。

空结果是一个有效的答案，而不是一次失败。一个没有 AAAA 记录的域名就是没有 IPv6 地址，一个没有 TXT 记录的域名就是什么都没配——这两者都不属于值得当成错误来上报的错误。

想知道解析出来的那台服务器在 HTTP 层面实际返回什么，接着用 HTTP 头信息检查 看一眼。