dig查询域名怎么用？详细步骤和参数解析指南，dig命令查询域名DNS记录方法

一句话答案：dig查域名最快的方式就是 dig 域名 +short，想看得细就用 dig 域名 记录类型 @指定DNS服务器，排查解析异常再加一个 +trace 从根服务器往下追。

dig到底是个什么工具，为什么运维都爱用它

dig的全称是Domain Information Groper，随BIND工具集一起发布，是目前主流Linux发行版里最常见的DNS诊断命令之一，macOS自带，Windows需要借助WSL或者第三方包，它做的事情很朴素：把一条DNS查询从发出到返回的全过程,尽可能完整地摊开给你看。

和ping那种"能通就行"的粗放判断不同，dig关注的是解析链路本身，域名解析失败时，ping只会告诉你"找不到主机"，而dig会明确告诉你，是记录不存在、是递归服务器拒绝服务、还是权威服务器压根没响应，这种颗粒度,就是它被写进各种排障手册的原因。

dig查询域名和nslookup有什么区别

很多人第一次接触DNS查询工具是nslookup，后来才换成dig，两者的差别不在"能不能查"，而在"查完之后你能看到什么"。

业内专家指出，做DNS排障时优先选dig，本质上是在选一份信息完整的"查询回执",而不是一个只给结论的黑盒。

dig命令查询域名解析详细步骤

下面这套流程，基本覆盖了九成以上的日常使用场景,照着敲一遍就能上手。

第一步：确认机器上装了dig

先跑一条：

dig -v

有版本号输出说明已安装，如果提示command not found,按发行版装一下：

• Debian/Ubuntu：apt install dnsutils
• CentOS/RHEL：yum install bind-utils 或 dnf install bind-utils
• Alpine：apk add bind-tools
• macOS：系统自带，无需安装

第二步：查一条最基础的A记录

dig example.com

这条命令等价于 dig example.com A，默认查询A记录，默认使用系统 /etc/resolv.conf 里配置的DNS服务器，如果只想看结果，不看过程，加 +short：

dig example.com +short

输出通常就是一到几行IP地址，干净利落,特别适合塞进shell脚本里做判断。

第三步：指定记录类型和DNS服务器

这是dig最实用的组合技，格式是 dig 域名 记录类型 @DNS服务器：

dig example.com MX @223.5.5.5
dig example.com TXT @119.29.29.29
dig example.com AAAA @8.8.8.8

指定服务器查询的价值在于：当你怀疑本地DNS缓存脏了，或者想确认某个公共DNS的解析结果是否一致时，一条命令就能做交叉验证，国内常用的公共DNS有阿里223.5.5.5、腾讯119.29.29.29、114DNS的114.114.114.114，国际的则是Google 8.8.8.8和Cloudflare 1.1.1.1。

第四步：用配置文件批量查

要一次查几十个域名，不用写循环，建个文本文件,一行一个域名，

dig -f domains.txt +short

dig的输出结果，每个分区都别跳过

dig example.com 的输出通常分成五块，很多人只看ANSWER,其实其他几块的信息量更大。

HEADER分区：先看status和flags

第一行类似这样：

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42315

status 是判断成败的第一入口：

• NOERROR：查询正常完成，但注意这不代表一定有条目，还得看ANSWER区是不是空的
• NXDOMAIN：域名不存在，通常是拼写错误或者域名过期
• SERVFAIL：服务器处理失败，常见于上游递归故障或者DNSSEC校验不通过
• REFUSED：服务器拒绝为你提供递归查询

flags里的 qr 表示这是响应包，rd 表示请求递归，ra 表示服务器支持递归，aa 表示这是权威应答，看到 aa 就说明这条记录来自权威服务器,可信度最高。

ANSWER SECTION：你真正想要的内容

每条答案一般包含名称、TTL、类别（IN）、类型（A/MX/CNAME等）和记录值，其中TTL值得留意，它决定了这条记录还能在各级缓存里存活多久，改了解析却不生效,八成就是TTL还没走完。

其他分区和统计信息

AUTHORITY区通常给出该域的NS记录，ADDITIONAL区是附加信息,最后两行也很有用：

• Query time：单次查询耗时，毫秒级
• SERVER：实际应答的服务器IP

SERVER显示的不是你指定的那台，说明中间有转发器在起作用,这时候解析结果可能和你预期不一致。

dig常用参数解析，这几个背下来够用

+trace：把解析链路一层层扒开

dig example.com +trace

它会从根域服务器开始，依次询问根、顶级域、权威服务器，把每一步的应答都打印出来，什么时候用？当你看到本地查询结果是错的，但直接问权威服务器又是对的，中间那一层到底谁在捣鬼，+trace会给答案。

-x：用IP反查域名

dig -x 114.114.114.114 +short

反向解析依赖PTR记录，不是所有IP都配了，查不到很正常,别误判成故障。

进阶场景：查邮件配置和CDN指向

dig命令查询MX记录和TXT记录

邮件相关的排查几乎离不开这两条：

dig example.com MX +short
dig example.com TXT +short

MX记录会带优先级数字，数字越小优先级越高，TXT记录常见的是SPF、DKIM、DMARC这些反垃圾邮件配置，内容较长时会被拆成多个引号包裹的字符串,拼起来才是完整值。

查CNAME链，看CDN到底指到哪

dig www.example.com CNAME

如果返回的还是CNAME，说明存在多级跳转，CNAME套CNAME在CDN场景里很常见，个别服务商对CNAME层数有限制,层数过深可能导致部分递归服务器解析失败。

dig命令查询域名解析失败怎么办

失败不等于服务器坏了，先按status分类,再对症处理。

NXDOMAIN：先别怀疑服务器

绝大多数NXDOMAIN是域名本身的问题：拼写错了、域名到期没续费、子域名压根没添加解析记录，用 dig example.com NS 确认域名是否还有NS记录,没有NS基本可以判定域名状态异常。

SERVFAIL：往上游找原因

SERVFAIL意味着服务器收到了请求但处理不下去，常见原因是权威服务器不可达、DNSSEC签名过期、或者递归服务器自身负载过高，换个公共DNS再查一次，如果结果正常,问题就出在原来那台服务器上。

超时和连接失败：检查网络出口

;; connection timed out; no servers could be reached

这说明请求根本没发出去或者没回音，先用 dig example.com @223.5.5.5 换服务器试，如果换了能通，就是本地resolv.conf配置的DNS有问题；换了也不通，检查防火墙是否放行UDP 53端口，必要时加 +tcp 换协议测试。

一个容易被忽略的坑

dig查到的结果，和浏览器实际访问用的解析结果，可能不是一回事，本机hosts文件、浏览器自带的安全DNS、操作系统DNS缓存，任何一层都可能覆盖掉dig看到的内容，排查"域名明明解析了但打不开"这类问题时,别只信一条dig。

Q&A：关于dig查询域名解析的高频问题

Q1：dig查询域名时指定多个DNS服务器会怎样？

一次只能指定一个 @服务器，想对比多个服务器的结果，要么写多条命令，要么用shell循环把几个IP依次跑一遍,再人工比对ANSWER区是否一致。

Q2：dig查询域名解析结果和ping解析出的IP不一样，正常吗？

正常，域名可以配置多条A记录做负载均衡，每次查询返回的顺序可能不同；CDN还会按地域和运营商返回不同IP，ping拿到的只是其中一次查询的结果,和dig不完全一致属于预期行为。

Q3：dig和host命令哪个更适合写进自动化脚本？

行业共识认为，dig +short 的返回值最规整，一行一个结果，退出码和输出都便于判断，适合放进脚本；host的输出更接近人类阅读习惯，做临时检查够用，据BIND官方文档说明，dig设计之初就考虑了非交互式调用场景，配合 -f 和 +short 能覆盖大部分批量查询需求。