Linux - DNS - Command Dig

在unix和linux下，Dig用于对域名的解析及IP的反解析

基本命令
dig 最基本的用法
dig @server tristan.com
用 dig 查看 zone 数据传输
dig @server tristan.com AXFR
用 dig 查看 zone 数据的增量传输
dig @server tristan.com IXFR=N
用 dig 查看反向解析
dig -x 124.42.102.203 @server
查找一个域的授权 dns 服务器
dig tristan.com +nssearch
从根服务器开始追踪一个域名的解析过程
dig tristan.com +trace
查看您使用的是哪个 F root dns server
dig +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT
查看 bind 的版本号
dig @bind_dns_server CHAOS TXT version.bind

用途
DNS 查询实用程式。

语法

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [ -n ][-p port#] [-t type] [-x addr] [-y name:key] [name] [type] [class] [queryopt...]
dig [-h]
dig [global-queryopt...] [query...]

描述
dig（域 信息搜索器）命令是个用于询问 DNS 域名服务器的灵活的工具。他执行 DNS 搜索，显示从受请求的域名服务器返回的答复。多数 DNS 管理员利用 dig 作为 DNS 问题的故障诊断，因为他灵活性好、易用、输出清楚。虽然通常情况下 dig 使用命令行参数，但他也能够按批处理模式从文档读取搜索请求。不同于早期版本，dig 的 BIND9 实现允许从命令行发出多个查询。除非被告知请求特定域名服务器，dig 将尝试 /etc/resolv.conf 中列举的任何服务器。当未指定任何命令行参数或选项时，dig 将对“.”（根）执行 NS 查询。

标志
-b address 配置所要询问地址的源 IP 地址。这必须是主机网络接口上的某一合法的地址。
-c class 缺省查询类（IN for internet）由选项 -c 重设。class 能够是任何合法类，比如查询 Hesiod 记录的 HS 类或查询 CHAOSNET 记录的 CH 类。
-f filename 使 dig 在批处理模式下运行，通过从文档 filename 读取一系列搜索请求加以处理。文档包含许多查询；每行一个。文档中的每一项都应该以和使用命令行接口对 dig 的查询相同的方法来组织。
-h 当使用选项 -h 时，显示一个简短的命令行参数和选项摘要。
-k filename 要签署由 dig 发送的 DNS 查询连同对他们使用事务签名（TSIG）的响应，用选项 -k 指定 TSIG 密钥文档。
-n 缺省情况下，使用 IP6.ARPA 域和 RFC2874 定义的二进制标号搜索 IPv6 地址。为了使用更早的、使用 IP6.INT 域和 nibble 标签的 RFC1886 方法，指定选项 -n（nibble）。
-p port# 假如需要查询一个非标准的端口号，则使用选项 -p。port# 是 dig 将发送其查询的端口号，而不是标准的 DNS 端口号 53。该选项可用于测试已在非标准端口号上配置成侦听查询的域名服务器。
-t type 配置查询类型为 type。能够是 BIND9 支持的任意有效查询类型。缺省查询类型是 A，除非提供 -x 选项来指示一个逆向查询。通过指定 AXFR 的 type 能够请求一个区域传输。当需要增量区域传输（IXFR）时，type 配置为 ixfr=N。增量区域传输将包含自从区域的 SOA 记录中的序列号改为 N 之后对区域所做的更改。
-x addr 逆向查询（将地址映射到名称）能够通过 -x 选项加以简化。addr 是个以小数点为界的 IPv4 地址或冒号为界的 IPv6 地址。当使用这个选项时，无需提供 name、class 和 type 参数。dig 自动运行类似 11.12.13.10.in-addr.arpa 的域名查询，并分别配置查询类型和类为 PTR 和 IN。
-y name:key 您能够通过命令行上的 -y 选项指定 TSIG 密钥；name 是 TSIG 密码的名称，key 是实际的密码。密码是 64 位加密字符串，通常由 dnssec-keygen（8）生成。当在多用户系统上使用选项 -y 时应该谨慎，因为密码在 ps（1）的输出或 shell 的历史文档中可能是可见的。当同时使用 dig 和 TSCG 认证时，被查询的名称服务器需要知道密码和解码规则。在 BIND 中，通过提供正确的密码和 named.conf 中的服务器声明实现。

参数
global-queryopt… 全局查询选项（请参阅多个查询）。
查询 查询选项（请参阅查询选项）。
查询选项
dig 提供查询选项号，他影响搜索方式和结果显示。一些在查询请求报头配置或复位标志位，一部分决定显示哪些回复信息，其他的确定超时和重试战略。每个查询选项 被带前缀（+）的关键字标识。一些关键字配置或复位一个选项。通常前缀是求反关键字含义的字符串 no。其他关键字分配各选项的值，比如超时时间间隔。他们的格式形如 +keyword=value。查询选项是：
+[no]tcp
查询域名服务器时使用 [不使用] TCP。缺省行为是使用 UDP，除非是 AXFR 或 IXFR 请求，才使用 TCP 连接。
+[no]vc
查询名称服务器时使用 [不使用] TCP。+[no]tcp 的备用语法提供了向下兼容。 vc 代表虚电路。
+[no]ignore
忽略 UDP 响应的中断，而不是用 TCP 重试。缺省情况运行 TCP 重试。
+domain=somename
设定包含单个域 somename 的搜索列表，似乎被 /etc/resolv.conf 中的域伪指令指定，并且启用搜索列表处理，似乎给定了 +search 选项。
+[no]search
使用 [不使用] 搜索列表或 resolv.conf 中的域伪指令（假如有的话）定义的搜索列表。缺省情况不使用搜索列表。
+[no]defname
不建议看作 +[no]search 的同义词。
+[no]aaonly
该选项不做任何事。他用来提供对配置成未实现解析器标志的 dig 的旧版本的兼容性。
+[no]adflag
在查询中配置 [不配置] AD（真实数据）位。现在 AD 位只在响应中有标准含义，而查询中没有，但是出于完整性考虑在查询中这种性能能够配置。
+[no]cdflag
在查询中配置 [不配置] CD（检查禁用）位。他请求服务器不运行响应信息的 DNSSEC 合法性。
+[no]recursive
转换查询中的 RD（需要递归）位配置。在缺省情况下配置该位，也就是说 dig 正常情形下发送递归查询。当使用查询选项 +nssearch 或 +trace 时，递归自动禁用。
+[no]nssearch
这个选项被配置时，dig 试图寻找包含待搜名称的网段的权威域名服务器，并显示网段中每台域名服务器的 SOA 记录。
+[no]trace
转换为待查询名称从根名称服务器开始的代理路径跟踪。缺省情况不使用跟踪。一旦启用跟踪，dig 使用迭代查询解析待查询名称。他将按照从根服务器的参照，显示来自每台使用解析查询的服务器的应答。
+[no]cmd
设定在输出中显示指出 dig 版本及其所用的查询选项的初始注释。缺省情况下显示注释。
+[no]short
提供简要答复。缺省值是以冗长格式显示答复信息。
+[no]identify
当启用 +short 选项时，显示 [或不显示] 提供给答的 IP 地址和端口号。假如请求简短格式应答，缺省情况不显示提供给答的服务器的源地址和端口号。
+[no]comments
转换输出中的注释行显示。缺省值是显示注释。
+[no]stats
该查询选项设定显示统计信息：查询进行时，应答的大小等等。缺省显示查询统计信息。
+[no]qr
显示 [不显示] 发送的查询请求。缺省不显示。
+[no]question
当返回应答时，显示 [不显示] 查询请求的问题部分。缺省作为注释显示问题部分。
+[no]answer
显示 [不显示] 应答的回答部分。缺省显示。
+[no]authority
显示 [不显示] 应答的权限部分。缺省显示。
+[no]additional
显示 [不显示] 应答的附加部分。缺省显示。
+[no]all
配置或清除任何显示标志。
+time=T
为查询配置超时时间为 T 秒。缺省是5秒。假如将 T 配置为小于1的数，则以1秒作为查询超时时间。
+tries=A
配置向服务器发送 UDP 查询请求的重试次数为 A，代替缺省的 3 次。假如把 A 小于或等于 0，则采用 1 为重试次数。
+ndots=D
出 于完全考虑，配置必须出现在名称 D 的点数。缺省值是使用在 /etc/resolv.conf 中的 ndots 语句定义的，或是 1，假如没有 ndots 语句的话。带更少点数的名称被解释为相对名称，并通过搜索列表中的域或文档 /etc/resolv.conf 中的域伪指令进行搜索。
+bufsize=B
配置使用 EDNS0 的 UDP 消息缓冲区大小为 B 字节。缓冲区的最大值和最小值分别为 65535 和 0。超出这个范围的值自动舍入到最近的有效值。
+[no]multiline
以周详的多行格式显示类似 SOA 的记录，并附带可读注释。缺省值是每单个行上显示一条记录，以便于电脑解析 dig 的输出。
多条查询
dig 的 BIND9 支持在命令行上指定多个查询（支持 -f 批处理文档选项的附加功能）。每条查询能够使用自己的标志位、选项和查询选项。
在这种情况下，在上面描述的命令行语法中，每条查询自变量代表一个个别查询。每一条由任意标准选项和标志、待查询名称、可选查询类型和类连同任何适用于该查询的查询选项。
也能够使用对任何查询均有效的查询选项全局集合。全局查询选项必须位于命令行上第一个名称、类、类型、选项、标志和查询选项的元组之前。任何全局查询选项（除了 +[no]cmd 选项）能够被下面的查询特别选项重设。例如:
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr显示 dig 如何从命令行出发进行三个查询：一个针对 www.isc.org的任意查询、一个 127.0.0.1 的逆向查询，连同一个 isc.org 的 NS 记录查询。应用了 +qr 的全局查询选项，以便 dig 显示进行每条查询的初始查询。最后那个查询有一个本地查询选项 +noqr，表示 dig 在搜索 isc.org 的 NS 记录时不显示初始查询。

Dig中DNS的解析过程

[root@localhost ~]# dig www.a.com

; <<>> DiG 9.2.4 <<>> www.a.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25746
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;www.aslibra.com.               IN      A

;; ANSWER SECTION:
www.aslibra.com.        900     IN      A       222.76.215.25

;; AUTHORITY SECTION:
aslibra.com.            33024   IN      NS      k8.hkidc.com.
aslibra.com.            33024   IN      NS      b.hkidc.com.
aslibra.com.            33024   IN      NS      j6.hkidc.com.
aslibra.com.            33024   IN      NS      ns8.hkidc.com.
aslibra.com.            33024   IN      NS      ns5.hkidc.com.
aslibra.com.            33024   IN      NS      a.hkidc.com.

;; ADDITIONAL SECTION:
k8.hkidc.com.           55596   IN      A       125.65.112.32
b.hkidc.com.            53594   IN      A       221.122.64.81
j6.hkidc.com.           54375   IN      A       222.76.219.74
ns8.hkidc.com.          53598   IN      A       221.122.64.81
ns5.hkidc.com.          55596   IN      A       222.76.219.81
a.hkidc.com.            53594   IN      A       125.65.112.32

;; Query time: 71 msec
;; SERVER: 211.99.25.1#53(211.99.25.1)
;; WHEN: Mon Jun  1 12:05:17 2009
;; MSG SIZE  rcvd: 268

如何理解上面的意思？
QUESTION SECTION：查询的内容
ANSWER SECTION：相应的内容，一般会得到至少一条A记录，否则就还没定义
AUTHORITY SECTION：授权信息
ADDITIONAL SECTION：每个授权服务器的IP地址
SERVER：查询的dns服务器，可能会被缓存

过程大体是：
1 从SERVER查询www.a.com，如果有有效缓存就返回了
2 如果没有，则找到a.com的授权服务器，下面有例子介绍
3 从其中一个查询到结果(A记录)

我们来看看更加具体的解析过程

“dig www.a.com+trace”可以查看到更加具体的解析过程。
我们用一个大点的网站看看，比如 www.163.com。

先看看不加trace的情况得到什么：

[root@localhost ~]# dig www.163.com

; <<>> DiG 9.2.4 <<>> www.163.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46550
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.163.com.                   IN      A

;; ANSWER SECTION:
www.163.com.            51561   IN      CNAME   www.cache.gslb.netease.com.
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.16
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.17
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.18
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.9
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.10
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.11
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.12
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.13
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.14
www.cache.gslb.netease.com. 1604 IN     A       61.135.253.15

;; AUTHORITY SECTION:
gslb.netease.com.       1604    IN      NS      gslb1.netease.com.
gslb.netease.com.       1604    IN      NS      gslb2.netease.com.

;; ADDITIONAL SECTION:
gslb1.netease.com.      15896   IN      A       61.135.255.143
gslb2.netease.com.      15900   IN      A       220.181.28.168

;; Query time: 56 msec
;; SERVER: 211.99.25.1#53(211.99.25.1)
;; WHEN: Mon Jun  1 12:29:51 2009
;; MSG SIZE  rcvd: 298

ANSWER SECTION告诉你：
www.163.com做了别名到www.cache.gslb.netease.com
而www.cache.gslb.netease.com有这么一系列机器（A记录），你可以随便挑一个访问。

我们看看加上trace后是什么信息：

[root@localhost ~]# dig www.163.com +trace
; <<>> DiG 9.2.4 <<>> www.163.com +trace
;; global options:  printcmd
.                       223628  IN      NS      e.root-servers.net.
.                       223628  IN      NS      f.root-servers.net.
.                       223628  IN      NS      g.root-servers.net.
.                       223628  IN      NS      h.root-servers.net.
.                       223628  IN      NS      i.root-servers.net.
.                       223628  IN      NS      j.root-servers.net.
.                       223628  IN      NS      k.root-servers.net.
.                       223628  IN      NS      l.root-servers.net.
.                       223628  IN      NS      m.root-servers.net.
.                       223628  IN      NS      a.root-servers.net.
.                       223628  IN      NS      b.root-servers.net.
.                       223628  IN      NS      c.root-servers.net.
.                       223628  IN      NS      d.root-servers.net.
;; Received 512 bytes from 211.99.25.1#53(211.99.25.1) in 65 ms

com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
;; Received 501 bytes from 192.203.230.10#53(e.root-servers.net) in 212 ms

163.com.                172800  IN      NS      ns3.nease.net.
163.com.                172800  IN      NS      ns4.nease.net.
;; Received 106 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 293 ms

www.163.com.            86400   IN      CNAME   www.cache.gslb.netease.com.
gslb.netease.com.       18000   IN      NS      gslb1.netease.com.
gslb.netease.com.       18000   IN      NS      gslb2.netease.com.
;; Received 138 bytes from 61.135.255.138#53(ns4.nease.net) in 47 ms

这里的过程有点复杂，但其实很好理解，也很重要的内容，需要琢磨清楚。
要明白，域名都是按等级授权的，比如把www.163.com. 拆分一下：
. 分配 com. ，com. 分配 163.com. ，163.com. 分配 www.163.com. 。
根服务器列表是在域名服务器上都有一份的，文档是一样的，文件可以下载。
域名都是从“.”开始授权，域名根服务器是 (a-m).root-servers.net.这系列服务器分配授权
.com .cn .net各种域名都从这里开始分配授权，比如 .com 授权给 (A-G).GTLD-SERVERS.NET.
（尝试做一下 dig www.163.org +trace，就会发现 .org 是分配给 a0.org.afilias-nst.info.等服务器 了）
这批服务器又授权 163.com给另外的机器

163.com. 172800 IN NS ns3.nease.net.
163.com. 172800 IN NS ns4.nease.net.

于是查询www是哪个ip就落到了ns3.nease.net.和ns4.nease.net.上，他们给的答案是：
www.163.com. 86400 IN CNAME www.cache.gslb.netease.com.
然后没戏了，没有给出IP，还没有答案，当然了，别名就要重新查询了，我们继续查询。

我们trace检查www.cache.gslb.netease.com. ：

[root@localhost ~]# dig www.cache.gslb.netease.com. +trace
; <<>> DiG 9.2.4 <<>> www.cache.gslb.netease.com. +trace
...（省略和上面查询一样的信息）
netease.com.            172800  IN      NS      ns3.nease.net.
netease.com.            172800  IN      NS      ns4.nease.net.
;; Received 121 bytes from 192.12.94.30#53(E.GTLD-SERVERS.NET) in 468 ms

gslb.netease.com.       18000   IN      NS      gslb1.netease.com.
gslb.netease.com.       18000   IN      NS      gslb2.netease.com.
;; Received 116 bytes from 61.135.255.138#53(ns4.nease.net) in 44 ms

www.cache.gslb.netease.com. 1800 IN     A       220.181.28.53
www.cache.gslb.netease.com. 1800 IN     A       220.181.28.54
www.cache.gslb.netease.com. 1800 IN     A       220.181.28.212
www.cache.gslb.netease.com. 1800 IN     A       220.181.28.50
www.cache.gslb.netease.com. 1800 IN     A       220.181.28.51
www.cache.gslb.netease.com. 1800 IN     A       220.181.28.52
gslb.netease.com.       1800    IN      NS      gslb2.netease.com.
gslb.netease.com.       1800    IN      NS      gslb1.netease.com.
;; Received 180 bytes from 61.135.255.143#53(gslb1.netease.com) in 20 ms

gslb.netease.com. 的解析权给了 gslb1.netease.com.
最终给出了 www.cache.gslb.netease.com. 的一系列A记录，解析就算完成了。

小结
- DNS服务器会按等级授权给别的服务器解析域名
- 指定的是NS记录，同时会有该NS记录的域名的A记录指定
- 别名方式会再继续查询，一般本dns服务器不处理cdn应该可以别名到cdn功能的服务器处理
- 你可以方便的用dig检查dns服务器分配情况

DNS的工作原理及过程分下面几个步骤
第一步：客户机提出域名解析请求,并将该请求发送给本地的域名服务器。
第二步：当本地的域名服务器收到请求后,就先查询本地的缓存,如果有该纪录项,则本地的域名服务器就直接把查询的结果返回。
第三步：如果本地的缓存中没有该纪录,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域)的主域名服务器的地址。
第四步：本地服务器再向上一步返回的域名服务器发送请求,然后接受请求的服务器查询自己的缓存,如果没有该纪录,则返回相关的下第五步：重复第四步,直到找到正确的纪录。
第六步：本地域名服务器把返回的结果保存到缓存,以备下一次使用,同时还将结果返回给客户机。