如何查询 DNS 记录
DNS 是将域名翻译成 IP 地址的系统。当出现问题时,网站无法加载、邮件迟迟不到、SSL 证书失败,检查 DNS 记录几乎总是第一步排查。理解每种记录类型的作用、查询如何在系统中流动、结果不一致时该看哪里,就能把神秘的故障转化为可解决的问题。
DNS 简史
在 DNS 出现之前,早期互联网上的每台计算机都共享一个名为 HOSTS.TXT 的文件,由斯坦福研究所维护。每个站点定期下载该文件,以获知其他机器的 IP 地址。当网络只有几百台主机时这个系统还能工作,但它无法扩展。
1983 年,Paul Mockapetris 发布了 RFC 882 和 RFC 883,描述了一个分层分布式命名系统:域名系统(Domain Name System)。规范在 1987 年精炼为 RFC 1034(概念与功能)和 RFC 1035(实现与规范),它们至今仍是基础文档。命名空间不再是一个巨大文件,而是被划分为区域,每个区域由其自身的权威服务器管理,树顶则是一小组根服务器。
此后 DNS 不断扩展。AAAA 记录(RFC 3596,2003)增加了 IPv6 支持。DNSSEC(RFC 4033 至 4035,2005)增加了密码学签名以防止欺骗。DNS-over-TLS(RFC 7858,2016)和 DNS-over-HTTPS(RFC 8484,2018)对查询加密,使窃听者和中间设备无法看到或篡改查询。系统的每一层都保持向后兼容,这就是为什么一个四十年的协议仍在运行现代网络。
DNS 记录类型
DNS 记录类型有几十种,但少数几种覆盖了绝大多数实际查询。了解每种记录的作用能加快分诊。
| 记录 | 用途 | 示例值 |
|---|---|---|
| A | 将域名映射到 IPv4 地址 | 93.184.216.34 |
| AAAA | 将域名映射到 IPv6 地址 | 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | 将一个域名别名为另一个 | www CNAME example.com |
| MX | 域名的邮件服务器 | 10 mail.example.com |
| TXT | 自由文本(SPF、DKIM、验证) | v=spf1 include:_spf.google.com ~all |
| NS | 域名的权威名称服务器 | ns1.example.com |
| SOA | Start of Authority(区域元数据) | 主 NS、管理员邮箱、序列、刷新 |
| SRV | 服务定位(主机加端口) | _sip._tcp.example.com 0 5 5060 sip.example.com |
| PTR | 反向 DNS(IP 到名称) | 34.216.184.93.in-addr.arpa PTR example.com |
| CAA | 哪些 CA 可以签发证书 | 0 issue "letsencrypt.org" |
| DNSKEY | 用于验证 DNSSEC 的公钥 | (二进制密钥数据) |
| NAPTR | 用于 ENUM 和 SIP 的基于正则的重写 | (复杂的 flag/regex 元组) |
A、AAAA、CNAME 和 MX 回答了大多数日常问题。TXT、NS、SOA 和 CAA 在配置和安全审计时出现。SRV 和 NAPTR 对 VoIP、XMPP 和其他服务发现协议很重要。PTR 对邮件服务器很重要,因为大多数垃圾邮件过滤器会拒绝没有有效反向 DNS 的发件人。
如何查询 DNS 记录
- 输入域名:在查询工具中输入任何域名(例如 example.com)。如果你想要某个特定标签的记录,也可以输入子域名,如 mail.example.com。
- 选择记录类型:选择 A、AAAA、MX、TXT、CNAME、NS、SOA 或 CAA。工具也支持一次查询所有常见类型以获得快速概览。
- 查看结果,响应列出每条匹配记录及其值、TTL(解析器可以缓存多长时间),以及任何额外字段,如 MX 优先级或 SOA 序列号。
- 与预期比对:如果你刚改了一条记录,检查新值是否出现。如果你在排查第三方,把你看到的与他们说他们配置的进行比较。
用 DNS 排查真实问题
网站无法加载?检查 A 和 AAAA 记录。如果缺失,域名就没有连接;如果指向旧 IP,流量到达的是不再托管该站点的服务器。也要确认 NS 记录与注册商列出的名称服务器一致,因为不匹配意味着整个区域是从过时来源提供的。
邮件没收到?先检查 MX 记录;缺失或错误的 MX 记录意味着什么都送不到。然后检查 TXT 记录中的 SPF(v=spf1)、DKIM(default._domainkey 或类似)和 DMARC(_dmarc.example.com)。现代邮件提供商会拒绝或隔离未通过这些检查的邮件,所以缺一条记录就能悄悄把你的邮件送进垃圾邮件。
SSL 证书错误?检查 A 记录是否指向安装了证书的服务器。如果站点在 CDN 后面,A 记录应解析到 CDN 边缘,而不是源站。也要检查 CAA 记录;只列出一个证书机构的 CAA 会阻止所有其他机构签发,即使域名所有者期望它们能工作。
域名验证失败?Google Workspace、Microsoft 365、Cloudflare 以及大多数 SaaS 平台会要求你添加一条 TXT 记录以证明域名所有权。查询 TXT 记录,确认确切的字符串存在,包括平台要求的任何引号或前缀。
DNS 传播感觉很慢?更改记录后,世界各地的解析器会继续提供缓存的值,直到 TTL 过期。在计划变更的前一天把 TTL 降到 300 秒,可以让切换快得多。查询工具在每条记录旁显示当前 TTL,让你可以预测过时的值还会持续多久。
SPF、DKIM 和 DMARC
三种基于 TXT 的记录保护邮件免受欺骗。SPF 列出哪些服务器被授权代表你的域发信。DKIM 发布一个公钥,收件人用它来验证每条消息的密码学签名。DMARC 告诉收件人在 SPF 或 DKIM 失败时该怎么做:什么都不做、隔离或拒收。三者都存在于 DNS 中,三者都在每条入站消息时被查询,任何一处拼写错误都会让送达率瘫痪。DNS 查询工具是最快的方式来读取实际发布的内容,与配置界面声称的完全分离。
证书签发与 CAA
当你请求 TLS 证书时,证书机构会查询 DNS 以验证控制权。大多数使用 dns-01 挑战:它们要求你在 _acme-challenge 下发布一条特定的 TXT 记录,然后检查它是否出现。CAA 记录增加了一层;它们声明哪些机构可以为该域签发证书。错误配置的 CAA 可能会阻塞合法的续签,所以每当 Let's Encrypt 的 cron 突然停止工作时,都要检查 CAA。
常见陷阱
- 混淆递归响应和权威响应,你的 ISP 的解析器可能提供一份落后于现实数小时的缓存副本。查询工具使用 Cloudflare 的 DNS-over-HTTPS 端点,直接查询权威服务器,绕过 ISP 缓存。
- 忽视 TTL,如果一条记录的 TTL 是 86400 秒(24 小时),变更可能需要整整一天才能在各处可见。在任何切换前一天计划 TTL 降低。
- 顶级使用 CNAME,CNAME 记录不允许在区域的根(example.com 本身)使用。提供商提供 ALIAS 或 ANAME 记录作为变通,但它们不是标准 DNS,行为各异。
- 堆叠多条 SPF 记录,SPF 要求恰好一条以 v=spf1 开头的 TXT 记录。两条 SPF 记录会使接收服务器将结果标记为 PermError,这会断送送达率。
- 忘记尾部的点,在区域文件中,没有尾部点的名称被视为相对于区域,所以漏掉点会把 mail.example.com 变成 mail.example.com.example.com。
- 混淆 IPv4 与 IPv6 的 A 记录,A 只用于 IPv4。把 IPv6 地址放进 A 记录(而不是 AAAA)是一种某些界面无法捕获的配置错误。
- CNAME 链循环,CNAME 指向另一个 CNAME 又指回来,就会形成解析循环。解析器在大约八跳后会放弃。
- 多层缓存,浏览器、操作系统、路由器和解析器各自独立缓存 DNS。只清空其中一处很少够用;使用查询工具来完全绕过这条链。
- 通配符记录掩盖缺失条目,通配符 A 记录(*.example.com)会匹配任何没有显式记录的子域,这可能会掩盖配置错误。
- 只信任一个解析器,传播并不均匀。在验证全局变更时查询几个解析器(1.1.1.1、8.8.8.8、9.9.9.9)。
查询 DNS 的其他方式
基于浏览器的查询工具是大多数检查的最快路径,但命令行工具在你需要时能提供更丰富的细节。
| 工具 | 平台 | 优势 | 劣势 |
|---|---|---|---|
| 网页查询工具 | 浏览器(任何系统) | 快速、免安装、格式化输出 | 限于常见记录类型 |
| dig | macOS、Linux、Windows(WSL) | 最详尽的输出,完整的 RFC 保真度 | 冗长,语法挑剔 |
| nslookup | 所有主流系统 | 每个系统都自带,交互模式 | 输出稀疏,解读各异 |
| host | macOS、Linux | A/AAAA/MX 的紧凑摘要 | 细节少于 dig |
| drill | BSD、Linux | 支持 DNSSEC 的 dig 替代品 | 不太常见,社区较小 |
| "what's my DNS" 类站点 | 浏览器 | 显示按地区的传播情况 | 常有大量广告,无批量查询 |
每种都有取舍。dig +trace 从根开始遍历 DNS 树并显示每一步,这对证明链在哪里断开非常宝贵。nslookup 无处不在,适合快速心智检查。网页工具的优势在于速度和完全不需要终端。
隐私与 DNS
普通的 DNS 查询以明文传输,这意味着你的 ISP 和网络上的任何人都能看到你访问的每一个域。两种加密变体解决了这一点:DNS-over-HTTPS(DoH)将查询包裹在 HTTPS 中,DNS-over-TLS(DoT)将查询包裹在专用端口的 TLS 中。查询工具使用 Cloudflare 的 DoH 端点,所以你向解析器发出的查询在传输中是加密的。你查询的域名对解析器本身仍然可见;如果这让你担心,运行你自己的解析器(Unbound、Pi-hole)或使用承诺不记录的付费隐私服务。
基于浏览器的查询从不在我们的服务器上存储你的请求。请求从你的浏览器直接发到 DoH 解析器,响应在客户端渲染。没有可被传唤的日志,没有关于你检查了哪些域的分析,也没有任何东西可能在未来的泄露中外泄。对于像 DNS 排查这样的日常任务,这正是工作应当得到的隐私级别。
常见问题
什么是 DNS？
DNS（Domain Name System）将 example.com 这样的域名翻译为 93.184.216.34 这样的 IP 地址，计算机用它们彼此连接。它常被称为互联网的「电话簿」。
A 记录是什么？
A 记录将域名映射到 IPv4 地址。当您访问网站时，浏览器进行 DNS 查询以找到 A 记录，再连接到该 IP。
A 记录和 AAAA 记录有什么区别？
A 记录指向 IPv4 地址（如 93.184.216.34）。AAAA 记录指向 IPv6 地址（如 2606:2800:220:1:248:1893:25c8:1946）。大多数现代网站两者都有。
MX 记录的用途是什么？
MX（Mail Exchange）记录指定处理某个域邮件的服务器。当有人给 user@example.com 发邮件时，发送服务器查找 example.com 的 MX 记录以知道把邮件送到哪。
Why do DNS changes take so long to propagate?
When you change a DNS record, resolvers around the world keep serving the previous value until the cached entry's TTL (Time to Live) expires. TTLs commonly range from 5 minutes to 24 hours. Lowering the TTL a day before a planned change helps the new value appear faster.
What is the difference between authoritative and recursive DNS?
An authoritative nameserver is the official source of truth for a domain. A recursive resolver (your ISP, Google 8.8.8.8, Cloudflare 1.1.1.1) is what your device queries; it walks the DNS tree and caches answers. A DNS lookup tool typically queries a recursive resolver, which forwards the question to the authoritative server.