DNS 查询，免费

工作原理

1. 输入域名：在输入框中键入域名 · 也支持子域名。
2. 选择记录类型：选择要查询的 DNS 记录类型：A、AAAA、MX、CNAME、TXT、NS、SOA 或全部。
3. 查看结果：结果来自公共的 DNS-over-HTTPS 提供者，并显示 TTL 值和数据。
4. 诊断问题：对比不同类型记录的结果，以识别配置错误、传播延迟或缺失的记录。

为什么使用 DNS 查询？

DNS 问题是网站宕机、邮件投递失败和域名迁移问题最常见的原因之一。能够直接在浏览器中查询 DNS 记录 · 无需借助 dig 或 nslookup 等命令行工具 · 对开发者、DevOps 和系统管理员来说非常有价值。此工具通过 DNS-over-HTTPS 查询记录，兼顾隐私并可绕过防火墙。可用于在更换邮件服务商后检查 MX 记录、在 DNS 迁移后确认 A/CNAME 记录、验证用于 SPF/DKIM 认证的 TXT 记录，以及诊断传播延迟。

DNS 记录类型

• A ， 域名的 IPv4 地址
• AAAA ， 域名的 IPv6 地址
• MX ， 用于邮件路由的邮件服务器记录
• CNAME ， 指向另一个域名的规范别名
• TXT ， 用于 SPF、DKIM、域名验证的文本记录
• NS ， 域名的权威名称服务器

40 年 DNS 史:从 RFC 882 到 DNS over QUIC

域名系统由 Paul Mockapetris 在 USC/ISI 设计,并在 RFC 882 和 RFC 883(1983 年 11 月)中规范,取代了 ARPANET 已经超出能力的扁平 HOSTS.TXT 文件。该系统在 RFC 1034 和 RFC 1035(1987 年 11 月)中得到全面改造和正式化,这些文档至今仍被引用。Jon Postel 协调分配了最初的 13 个根名称服务器,标记为 a.root-servers.net 到 m.root-servers.net,这个数量并非由容量决定,而是由当时 512 字节的 UDP 数据包大小限制决定的。本世纪以来有两次重大冲击重塑了 DNS。在 2008 年 7 月,Dan Kaminsky 披露了一种缓存投毒攻击,攻击者可在几秒内向解析器注入伪造记录。业界以协调补丁(源端口随机化)和对 DNSSEC(RFC 4033-4035,2005 年 3 月)的兴趣重新升温作为回应,DNSSEC 以密码学方式签署记录。第二次冲击是隐私:35 年来查询以明文形式在 UDP 53 端口上传输。DNS over TLS(DoT,RFC 7858,2016 年 5 月)在 853 端口用 TLS 包装查询。DNS over HTTPS(DoH,RFC 8484,2018 年 10 月)通过 443 端口的 HTTPS 隧道传输查询,甚至隐藏 DNS 正在发生这一事实。DNS over QUIC(RFC 9250,2022 年 5 月)是最新的,使用与 HTTP/3 相同的传输。公共解析器 1.1.1.1(Cloudflare,2018 年 4 月 1 日推出)、8.8.8.8(Google Public DNS,2009 年 12 月)和 9.9.9.9(Quad9,2017 年 11 月)如今都支持 DoH 和 DoT。

深度解读记录类型

• A(RFC 1035)。32 位 IPv4 地址。一个域名可以有许多 A 记录用于负载均衡;解析器会轮流使用它们(轮询 DNS)。
• AAAA(RFC 3596,2003)。128 位 IPv6 地址。读作「quad-A」。截至 2024 年,大约 45% 的 Google 流量是 IPv6。
• CNAME(RFC 1035)。别名:「跟随此名称并查找其记录」。不能与同名的任何其他记录共存。这就是为什么 example.com 不能在顶点同时拥有 CNAME 和 MX 或 A 记录;现代替代方案使用 ALIAS 或 ANAME(供应商特定)或 HTTPS 记录(RFC 9460,2023)。
• MX(RFC 1035,由 RFC 7505「null MX」更新)。带优先级值的邮件交换服务器。优先级越低越优先;并列随机化。0 .(RFC 7505,2015 年 6 月)明确表示「此域名不接收邮件」,阻止发往无邮箱域名的垃圾邮件。
• TXT(RFC 1035)。自由文本字符串。现在承载关键的身份验证:SPF(RFC 7208,2014)、DKIM(RFC 6376,2011)、DMARC(RFC 7489,2015),以及 Google Search Console、Microsoft 365、ACME(Let's Encrypt)DNS-01 挑战的所有权验证。
• NS(RFC 1035)。权威名称服务器的名称。至少两个用于冗余。父区域中的「胶水记录」提供 IP,使递归解析器可以在没有循环查找的情况下访问名称服务器。
• SOA(RFC 1035)。权威开始。每个区域的单一记录,列出主名称服务器、管理员邮箱(第一个 . 替换为 @)、序列号(更改时递增)、refresh、retry、expire 和最小 TTL。
• CAA(RFC 8659,2019;最初为 RFC 6844,2013)。证书颁发机构授权。列出哪些 CA 被允许为该域颁发证书。自 2017 年 9 月起,根据 CA/Browser Forum 基线要求必须检查。
• SRV(RFC 2782,2000)。服务位置:协议、优先级、权重、端口、目标主机。Microsoft Active Directory、XMPP、SIP、Matrix 联邦都使用 SRV 记录进行服务发现。
• PTR(RFC 1035)。反向 DNS。将 IP 映射回域名。位于 in-addr.arpa(IPv4)或 ip6.arpa(IPv6)区域。许多邮件服务器需要它来接受邮件;缺失的 PTR 是常见的垃圾邮件信号。
• DNSKEY / DS / RRSIG(RFC 4034-4035)。DNSSEC 配管。DNSKEY 发布区域的签名密钥;父区域中的 DS 是密码学的「这里是链中的下一个环节」指针;RRSIG 携带每个记录集的实际签名。

DNS 查询真正有用的场景

• 在新域名上设置电子邮件。验证 MX 记录指向正确的提供商(Google Workspace aspmx.l.google.com、Microsoft 365 example-com.mail.protection.outlook.com、Fastmail、ProtonMail)。检查 SPF(v=spf1 include:_spf.google.com ~all)、DKIM(selector._domainkey)、DMARC(_dmarc TXT)。
• 域名迁移和传播。在注册商处更新名称服务器后,查询旧的和新的权威服务器以确认变更已在全球传播。不同的解析器以不同的持续时间缓存(TTL 是提示,不是合同)。
• TLS / SSL 证书故障排查。Let's Encrypt 等使用的 ACME DNS-01 挑战需要在 _acme-challenge.example.com 放置 TXT 记录。在触发证书签发之前检查该值,以避免浪费速率限制尝试。
• 检测子域名接管风险。指向未注册服务的 CNAME(已删除的 Heroku 应用、已释放的 S3 桶)让攻击者注册并在你的子域名上提供内容。快速的 CNAME 审计可捕获悬挂指针。
• CDN 和负载均衡器验证。确认域名在部署后 CNAME 到正确的 Cloudflare、Fastly、Akamai、CloudFront 或 Vercel 端点。检测预发环境何时意外指向生产。
• 地理 DNS 比较。某些站点按区域提供不同的 A 记录(GeoDNS)。从不同的 DoH 端点(Cloudflare 1.1.1.1 与 Google 8.8.8.8)查询暗示了法兰克福与孟买的用户如何看到该站点。
• 安全和事件响应。查找意外的 NS 记录(注册商劫持)、可疑的 TXT 记录或最近添加的 MX 记录。使用 SOA 序列号跟踪区域上次更改的时间。

破坏站点和邮件的 DNS 错误

• 顶点的 CNAME。RFC 1034 禁止在 example.com 本身上放置 CNAME(仅在 www.example.com 等子域上)。Cloudflare、Route 53、DNSimple 通过 CNAME 平坦化或 ALIAS 记录解决此问题;Vercel、Netlify 使用 HTTPS 服务绑定记录(RFC 9460)。在基础注册商的 DNS 面板上尝试这样做会悄悄破坏电子邮件。
• 迁移前忘记降低 TTL。如果你的 A 记录 TTL 是 86400(24 小时),你在切换日早上更改,全球的解析器会继续分发旧 IP 长达一天。在更改前几天将 TTL 降至 300 秒。
• SPF 记录有过多 DNS 查询。RFC 7208 将 SPF 限制为每次评估 10 次 DNS 查询。链接太多 include: 指令,你的 SPF 记录会因 permerror 而失败,DMARC 将其视为失败。使用 SPF Surveyor 等工具进行扁平化或合并。
• 服务拆除后悬挂的 CNAME。删除了 Heroku 应用,但 app.example.com CNAME 仍指向 example.herokuapp.com?任何人都可以注册该应用名称并在你的子域名上托管其内容。审计并删除孤立的 CNAME。
• 无 CAA 记录。没有 CAA 记录,WebPKI 中的任何 CA(全球约 50 个)都可以为你的域签发证书。将其锁定到一个或两个可信 CA:0 issue "letsencrypt.org"。自 2017 年 9 月起强制要求 CA 检查。
• 掩盖缺失条目的通配符记录。一个 *.example.com A 记录使每个拼写错误的子域都能解析,掩盖了真正的配置错误。与显式 MX 规则仔细组合,以避免垃圾邮件发送到拼写错误的地址。
• 切换期间混合 DNSSEC 和未签名区域。在新名称服务器提供签名记录之前在注册商处启用 DNSSEC,会对每个验证解析器(Cloudflare 1.1.1.1、Quad9)产生 SERVFAIL。始终先签名,然后发布 DS 记录。

更多常见问题

相关工具