周末凌晨两点某开发者被一个电话叫醒线上服务异常用户反馈APP一直转圈。登服务器先ping一下域名解析不了再ping IP通了。问题基本锁定在DNS环节。这时候用什么工具排查我第一个想到的永远是dig。dig全称domain information groper名字看着有点萌实际是个狠角色。它是DNS排查场景里最趁手的工具能查解析、看记录类型、指定服务器、追踪完整链路几乎所有域名解析相关的疑难杂症都能用它定位。这篇文章就以“dig使用”为主线把日常用得上的查询姿势、实战排查思路、还有我踩过的坑一次讲清楚适合运维、后端开发以及所有需要跟网络解析打交道的人。1. dig到底能干什么先把它看透1.1 为什么偏偏是dig很多人在Windows上习惯了nslookup到了Linux服务器上却不知道还有个更好用的工具。nslookup不是不行但它输出格式固定、默认查询类型容易让人糊涂交互模式的体验也比较老派。host命令倒是简洁可信息太单薄复杂排查基本帮不上忙。dig的优势在于输出结构完整参数控制粒度细而且脚本友好方便批处理。dig本质上就是一个DNS客户端。它向指定的DNS服务器发送查询报文默认走UDP 53端口收到响应后把报文里的各个字段拆开、格式化展示。当响应数据量较大时DNS协议会自动切换到TCP传输dig也会如实反映这种切换。理解这一点后面看它的输出就不会慌。用一句话概括nslookup是便利店host是自动售货机dig是后厨你想看哪一层、想加什么料都能自己掌控。1.2 第一次看到dig输出别懵很多人第一次敲dig example.com会被屏幕上的一大片内容吓到。其实每一段都有明确含义。以这条命令为例dig example.com输出大致长这样; DiG 9.18.19 example.com ;; global options: cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 3600 IN A 192.0.2.1 ;; ADDITIONAL SECTION: example.com. 3600 IN A 192.0.2.1 ;; Query time: 23 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 22 10:00:00 UTC 2024 ;; MSG SIZE rcvd: 56先看HEADER这一行这里藏着最关键的state信息。status: NOERROR表示查询正常完成如果是NXDOMAIN表示域名不存在SERVFAIL表示上游解析失败REFUSED表示服务器拒绝查询。这些状态码是排查时的第一步判断依据。QUESTION SECTION是“我们问了什么”这里显示查询类型是A记录。ANSWER SECTION是“对方答了什么”就是最终解析出来的IP地址。AUTHORITY SECTION记录的是权威域名服务器信息ADDITIONAL SECTION则是附加信息比如权威服务器的IP地址。最后几行是查询统计Query time显示这次查询耗时多少毫秒SERVER显示你实际请求的是哪个DNS服务器MSG SIZE是响应报文大小。这些字段在判断“到底慢在哪、查到了谁”的时候非常有用。提示输出里域名后面的那个点是根域标志。example.com. 和 example.com 在书写上等价但后者省略了根域规范输出里都会带上这个点。看到它不用紧张这不是格式错误。2. 日常用得最多的查询姿势2.1 基础查询先让dig跑起来最基础的用法就是直接在dig后面跟域名dig example.com默认情况下它会查A记录也就是IPv4地址。如果你只想快速拿到结果不关心那些花里胡哨的字段可以加shortdig short example.com输出会精简到只剩IP非常适合在脚本里直接使用。如果只想看答案部分不想看QUESTION和统计信息可以用dig noall answer example.com这个组合很常用noall的意思是关闭所有输出answer的意思是只打开答案段。想连权威段一起看再补一个authoritydig noall answer authority example.com我个人的习惯是日常快速验证用short做详细排查时用noall answer authority。这样不至于被大量字段干扰视线。2.2 指定DNS服务器排查问题最关键的一条默认情况下dig会读取系统配置的DNS服务器也就是/etc/resolv.conf里的设置。但很多时候问题恰恰出在这台DNS服务器上。比如你本地解析出来的IP是错的但你不知道是域名配置错了还是本地DNS缓存了旧数据。这时候就要手动指定DNS服务器dig 8.8.8.8 example.com后面跟的是你指定的DNS服务器IP。8.8.8.8是公共DNS解析结果不经过本地缓存适合用来做对照实验。为什么这一步如此重要因为“本地解析不对”和“全球解析都不对”是两种完全不同的故障。如果8.8.8.8查出来是正常的而默认查询不正常问题就出在本地DNS链路或者缓存上如果指定公共DNS查出来也不对那就要怀疑域名配置本身了。注意指定DNS服务器时还可以配合-p参数指定端口比如dig 8.8.8.8 -p 53 example.com默认就是53一般不用写。但如果你的DNS服务跑在非标准端口上这个参数就很有用了。另外两个和网络稳定性相关的参数也值得记住time5表示单个查询的超时时间为5秒tries2表示超时后重试2次。排查网络不稳定的服务器时加上这两个参数能帮你减少等待时间。2.3 想查什么记录就查什么记录A记录只是DNS记录类型中的一种。实际工作中MX、NS、TXT、CNAME都是高频查询对象。查询方式是在域名后面直接加记录类型dig example.com MX dig example.com NS dig example.com TXT dig example.com CNAME dig example.com SOA不同记录类型对应的场景我用一个表格简单整理记录类型作用典型排查场景AIPv4地址网站解析是否正确AAAAIPv6地址双栈部署是否生效MX邮件服务器收发信异常时确认邮件路由NS权威域名服务器确认域名的权威服务器是谁TXT文本信息SPF、DKIM等邮件防伪造配置是否生效CNAME别名指向子域名是否被正确别名到目标域名SOA起始授权记录含序列号、TTL等确认主从DNS同步状态PTR反向解析通过IP查域名反查IP归属、邮件服务器反向验证每种记录类型对应不同的故障形态。比如收不到邮件先查MX对不对怀疑域名被劫持对比不同服务器返回的A记录SPF验证失败查TXT里有没有vspf1开头的记录。排查方向不一样查询的记录类型就要跟着变。还有一个查询PTR的快捷方式不用手动计算反向域名的写法dig -x 192.0.2.1-x参数会自动把IP转成反向解析的查询格式非常省事。2.4 批量场景脚本里怎么用dig排查单个域名只是基础操作真正常碰到的是几十个域名批量验证。比如批量检查一批业务域名的解析是否正常可以写个简单的循环for d in example.com example.org example.net; do echo $d: $(dig short $d A) done这个循环会遍历每个域名只提取A记录结果。如果是A记录查询失败short输出为空结合退出码和状态码就能判断是哪种失败。如果想从文件里批量读域名把域名每行一个放入domains.txt然后while read d; do [ -z $d ] continue dig short $d A | sed s/^/ - / done domains.txt批量查询时我建议统一加上time3 tries1避免某个域名无响应导致整个脚本卡住。比如dig short time3 tries1 example.com还有一个小技巧配合awk从完整输出里提取TTL。TTL值能反映这条记录的缓存时长对判断“刚改的DNS记录多久能全球生效”很有帮助dig example.com A | awk /^example.com.*IN.*A/ {print $2}这条命令会从答案段里找出A记录那一行打印TTL字段。3. 实战用dig完成一次完整的DNS排查3.1 场景一线上服务域名解析异常假设某天业务方反馈某个核心服务域名解析不了APP一直转圈。我的排查顺序是这样的先看默认解析dig example.com如果返回status: NOERROR但答案里没有IP或者直接提示超时接着做对照实验指定公共DNS再查一次dig 8.8.8.8 example.com这时会出现三种情况一是公共DNS正常、默认查询异常。那问题基本出在本地DNS链路。可能是本地DNS服务器缓存了错误结果也可能是resolv.conf指向的DNS不通。我会顺手解析一下nsloopup的服务器地址再检查一下resolv.conf内容cat /etc/resolv.conf二是两边结果都不正常。这种情况要往域名本身查。先确认NS记录是否配置正确dig example.com NS如果NS记录返回空或者查询超时大概率是域名注册商或者权威服务器侧出了问题。三是两边结果不一致。比如默认查询返回一个IP公共DNS返回另一个IP这就要警惕DNS劫持或中间链路污染了。进一步确认可以通过short对比两个命令的输出dig short example.com dig short 8.8.8.8 example.com3.2 场景二刚改完解析记录怎么确认生效改完DNS记录最烦的就是“我在自己电脑上查还是老地址”。这通常是因为缓存还没过期。DNS缓存由TTL决定TTL是这条记录在缓存里允许存活的秒数。假设TTL是300秒那最多5分钟就会过期如果TTL是86400秒那就是24小时。想确认权威服务器上的记录是否已经更新最直接的办法是绕开所有缓存直接查权威域名服务器。先找出NSdig example.com NS short拿到NS列表后指定其中一个权威服务器去查询dig ns1.example.com example.com A short因为我这里用的是示例域名真实的NS主机名以实际返回为准。这样查到的结果就是这个域名的真实记录不受任何中间缓存影响。经验之谈计划变更解析记录时提前把待变更记录的TTL调低比如从86400调到300等一天让旧记录在全球缓存中过期再改解析地址。这样能最大程度缩短切换过程中的生效等待时间。这个操作需要在DNS服务商的控制台上做dig只是帮你“看到”TTL的变化。3.3 场景三从根到叶子追踪完整解析链路有时候问题不在最终答案而在于解析链路中的某一环。比如某些网络环境下顶级域服务器的访问受限导致域名怎么都解析不出来。这种时候用trace可以看到完整链路dig trace example.com输出会依次展示根域名服务器返回的顶级域服务器列表顶级域服务器返回的权威服务器列表最后是权威服务器返回的最终答案。每一段都标明了查询耗时和来源。这个命令对理解DNS递归过程非常直观。相当于把“你问本地DNS本地DNS问根根说去找顶级域顶级域说去找权威权威给出答案”的每一步都摊开给你看。哪一步耗时最长哪一步无响应一目了然。我在实际排查中遇到过一种情况某个域名在本地一直超时用trace之后发现根和顶级域都能正常响应但到了某权威服务器这一步就卡住了。后来确认是权威服务器防火墙出了问题。没有trace的话这个结论很难快速定位。4. 常见问题与排查技巧实录4.1 我踩过的一些坑第一个坑是查询超时。dig默认等待时间可能比较长在部分网络环境里UDP 53端口被防火墙拦截或者网络质量差查询就会一直卡住。这时候除了加time5 tries1之外还可以尝试强制使用TCP协议dig tcp 8.8.8.8 example.comUDP 53被限制但TCP 53放行的情况并不罕见把协议换一下往往就能查通过。第二个坑是status: SERVFAIL。这个状态说明DNS服务器本身已经收到请求但上游解析失败。常见原因包括权威服务器不可达、SOA记录配置异常、DNSSEC签名校验失败。处理思路是先确认NS记录是否正常再用trace逐段定位。第三个坑是NOERROR但答案为空。这种情况其实“正常”只是当前域名没有你查询的那个记录类型。比如你查AAAA但网站没有IPv6地址结果就是空的。下次看到NOERROR却无答案先确认一下查询类型是不是写对了。第四个坑是解析结果里出现多个IP。这通常是因为域名配置了多A记录做负载均衡不是故障。用short看会更直观dig short example.com输出会列出所有IP配合负载均衡策略来看属于正常现象。4.2 新手最容易忽略的几个细节有几个细节我见过不少同事栽过跟头。一是忘记指定DNS服务器导致查询结果永远来自本地DNS排障方向跑偏。排障时一定要有意识地做“对照实验”指定一个公共DNS做二次确认。二是不知道dig默认查什么类型。dig example.com默认查A记录没错但dig example.com MX和dig example.com A是完全不同的查询。如果你要查邮件服务器却忘了写MX那结果肯定不是你想要的。三是混淆TTL和实际生效时间的关系。TTL是缓存存活时间上限不是固定的“多久后一定生效”。不同DNS服务器刷新缓存的时间可能不一致所以会出现“部分用户已经生效、部分用户还在用旧IP”的现象。这在解析切换场景中非常常见要学会用指定权威服务器的方式来判断真实状态。四是脚本里直接解析完整输出。有些人写脚本时喜欢grep整个dig输出这很容易因为输出格式微调而炸掉。尽量用short让输出保持在一个干净的状态。4.3 常用参数速查表参数作用示例域名后加记录类型指定查询类型dig example.com MXDNS服务器指定查询的DNS服务器dig 8.8.8.8 example.comshort简化输出保留核心结果dig short example.comnoall关闭所有输出段dig noall answer example.comanswer仅显示答案段dig noall answer example.comauthority显示权威段dig noall answer authoritytrace追踪完整解析链路dig trace example.comtcp强制使用TCP协议dig tcp 8.8.8.8 example.comtimeN设置超时时间秒dig time5 example.comtriesN设置重试次数dig tries2 example.com-x IP反向解析dig -x 192.0.2.1-p 端口指定端口dig 8.8.8.8 -p 5353 example.com这个表基本覆盖了日常80%的使用场景。用熟了以后再查文档会发现dig还有更多奇技淫巧比如multiline让输出更易读、dnssec查看DNSSEC签名信息等。我个人在实际操作中最大的体会是dig不只是“查个IP”的工具而是一把完整的DNS手术刀。排查问题的时候不要上来就乱猜先按“默认查询到底、公共DNS对照、权威DNS确认、整链路追踪”这个顺序走一遍绝大多数DNS问题都能被压缩到一个很小的范围内。特别是和缓存相关的问题很多人一慌就去重启服务、刷新缓存实际上先用dig ns服务器查一下权威记录十几秒就能判断出到底是不是配置的问题。最后再分享一个小技巧在服务器上设置一个快捷别名把最常用的对照查询写成一串命令比如同时查询默认和公共DNS两个结果alias dnscheckdig short example.com; dig short 8.8.8.8 example.com当然把example.com替换成你的常用域名会更实用。遇到解析问题直接敲一下两个结果并排一对比心里就有数了。工具是死的排查思路是活的dig用得越熟DNS类故障对你来说就越透明。