ip域名解析查询

打开浏览器，域名输入一个域名，解析页面秒开。查询这背后有一台DNS服务器在几毫秒内完成了查询和应答。域名大多数人从不关心这个过程，解析直到某天网站打不开，查询或者被解析到了莫名其妙的域名IP上。

IP域名解析查询，解析说白了就是查询把人类记得住的域名翻译成机器能识别的IP地址。你访问 example.com，域名DNS 系统得告诉你它对应的解析是 93.184.216.34 这样的数字串。听起来简单，查询但这套系统每天要处理数千亿次查询请求，域名而且必须在极短时间内完成。解析

一次完整的查询解析过程到底发生了什么

假设你在浏览器里敲了 www.baidu.com。操作系统先查本地 hosts 文件和 DNS 缓存。没有命中，就向配置的递归 DNS 服务器发起请求——通常是运营商分配的，也可能是 8.8.8.8 或 223.5.5.5 这类公共 DNS。

递归服务器拿到请求后，先问根域名服务器。根服务器不直接给答案，只说“去问 .com 的顶级域服务器”。递归服务器再问 .com TLD 服务器，TLD 又指向 baidu.com 的权威 DNS 服务器。最后，权威服务器返回具体的 A 记录。整个过程像接力跑，一圈下来通常不超过 200 毫秒。

我用 dig 命令查过一次，从发起查询到拿到结果，花了 37 毫秒。中间经过了根、TLD、权威三层。换成 nslookup 也能看到类似结果，只是输出格式不同。命令行工具的好处是，你能清楚看到每一跳的响应时间和 TTL 值。

查询类型不止一种

A 记录返回 IPv4 地址，AAAA 记录返回 IPv6 地址。CNAME 是别名，MX 管邮件路由，TXT 常用于域名验证。查一个域名的解析情况，最好把这几种类型都过一遍。有次朋友说网站能打开但收不到邮件，我一查 MX 记录，指向的邮件服务器 IP 早就失效了。问题不在网站，在邮件解析。

还有一种常见情况：CDN 场景下，同一个域名在不同地区解析出的 IP 完全不同。你用在线工具查，可能拿到的是离你最近的节点。想验证全国各地的解析结果，得用多地 ping 或者专门的 DNS 拨测工具。

缓存是把双刃剑

TTL 决定了解析结果在缓存里存活多久。设得太短，DNS 查询压力大；设得太长，IP 变更后要等很久才生效。很多运维在迁移服务器时忘记提前调低 TTL，结果切完流量发现部分用户还指向旧 IP。这种事故我见过不止一次。

排查解析问题的时候，第一件事就是清缓存。Windows 上 ipconfig /flushdns，macOS 用 sudo dscacheutil -flushcache。浏览器也有自己的 DNS 缓存，Chrome 可以进 chrome://net-internals/#dns 手动清理。别小看这一步，有时候问题就出在本地缓存上。

选哪个 DNS 服务器

运营商默认 DNS 的解析速度不一定差，但劫持和广告插入是常有的事。公共 DNS 里，阿里 DNS（223.5.5.5）和 DNSPod（119.29.29.29）在国内表现稳定，Google 的 8.8.8.8 在国内访问延迟偏高。Cloudflare 的 1.1.1.1 主打隐私，但在部分网络环境下会被干扰。

我自己的做法是路由器上同时配两个不同厂商的 DNS，主用阿里，备用 DNSPod。遇到解析异常时切换一下，通常能快速定位是 DNS 服务器的问题还是域名本身的问题。

IP 域名解析查询看起来是个小话题，但排障的时候，它往往是第一个要查的环节。掌握几个基本命令，理解解析链路，能省下不少瞎折腾的时间。