手动执行递归 DNS 查询答案

【问题标题】：Manually doing a recursive DNS query手动执行递归 DNS 查询
【发布时间】：2014-10-20 14:34:32
【问题描述】：

在我正在进行的了解 DNS 的实验中，我试图了解名称服务器如何进行递归查询。我明白了基本的想法 - 您从顶级 dns 服务器开始，然后它会向您发送要联系的权威名称服务器列表，然后您联系这些服务器等，直到您获得权威响应。

听起来很简单。

但是当我在实践中尝试时，我在第一步之后就卡住了。我只是使用命令行工具手动执行此操作 - （我确保关闭关闭递归。）

好的，第 1 步：从根名称服务器开始。我从root name servers on Wikipedia 列表中随机选择了198.41.0.4 (Verisign)。

我向它发送解析“google.com”的请求。

它给我发回以下信息：

+---------------------------------------------------------------------------+
| 47547 | QR: 1 | OP: 00 | AA: 0 | TC: 0 | RD: 1 | RA: 0 | Z: 0 | RCODE: 00 |
+---------------------------------------------------------------------------+
| QDCOUNT:     1,   ANCOUNT:     0,   NSCOUNT:    13,   ARCOUNT:    15      |
+---------------------------------------------------------------------------+

ANSWERS : 0

AUTHORITIES:
NS: m.gtld-servers.net
NS: l.gtld-servers.net
NS: k.gtld-servers.net
NS: j.gtld-servers.net
NS: i.gtld-servers.net
NS: h.gtld-servers.net
NS: g.gtld-servers.net
NS: f.gtld-servers.net
NS: e.gtld-servers.net
NS: d.gtld-servers.net
NS: c.gtld-servers.net
NS: b.gtld-servers.net
NS: a.gtld-servers.net

ADDITIONAL:
A: 192.55.83.30
A: 192.41.162.30
A: 192.52.178.30
A: 192.48.79.30
A: 192.43.172.30
A: 192.54.112.30
A: 192.42.93.30
A: 192.35.51.30
A: 192.12.94.30
A: 192.31.80.30
A: 192.26.92.30
A: 192.33.14.30
AAAA: 2001:0503:231d:0000:0000:0000:0002:0030
A: 192.5.6.30
AAAA: 2001:0503:a83e:0000:0000:0000:0002:0030

好的，所以我不确定所有这些附加记录的意义 - 它们似乎都是本地 LAN 地址，所以我不知道它们对我有什么用。但无论如何，查看权限部分返回的结果，我看到了另一个名称服务器列表。好的，所以我想下一步是我需要选择一个返回的名称服务器，并获取它的 IP。于是我发出一个请求来解决a.gtld-servers.net，然后……

...它只是返回完全相同的名称服务器列表。

所以...我不确定如何在此处继续。我如何最终访问“google.com”的权威名称服务器？

编辑：

好的，所以看起来那些192 地址不是我错误地假设的 LAN 地址，但它们是其他名称服务器。我假设我可以联系这些名称服务器以更接近权威。但是，我应该如何知道使用这些名称服务器？我认为 ARCOUNT 部分只是为了提供更多信息......为什么所有这些名称服务器都放在 ADDITIONAL 部分而不是作为答案或权限？是否只是在附加部分中引用其他名称服务器的一些约定？

【问题讨论】：

这个问题似乎是题外话，因为它是一个一般的 DNS 问题，而不是一个编程问题。

标签： dns

【解决方案1】：

您可以使用dig +trace 命令：它将准确地向您显示典型递归名称服务器所做的每个查询。

如果你尝试例如www.google.com（如果你不指定类型，dig默认使用A，我用+nodnssec删除了DNSSEC相关信息以简化输出）：

$ dig +trace www.google.com +nodnssec

; <<>> DiG 9.12.0 <<>> +trace www.google.com +nodnssec
;; global options: +cmd
.           307678 IN NS f.root-servers.net.
.           307678 IN NS a.root-servers.net.
.           307678 IN NS m.root-servers.net.
.           307678 IN NS e.root-servers.net.
.           307678 IN NS i.root-servers.net.
.           307678 IN NS l.root-servers.net.
.           307678 IN NS c.root-servers.net.
.           307678 IN NS g.root-servers.net.
.           307678 IN NS b.root-servers.net.
.           307678 IN NS k.root-servers.net.
.           307678 IN NS h.root-servers.net.
.           307678 IN NS d.root-servers.net.
.           307678 IN NS j.root-servers.net.
;; Received 447 bytes from 192.168.10.229#53(192.168.10.229) in 5 ms

com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.
;; Received 839 bytes from 192.36.148.17#53(i.root-servers.net) in 88 ms

google.com.     172800 IN NS ns2.google.com.
google.com.     172800 IN NS ns1.google.com.
google.com.     172800 IN NS ns3.google.com.
google.com.     172800 IN NS ns4.google.com.
;; Received 291 bytes from 192.5.6.30#53(a.gtld-servers.net) in 145 ms

www.google.com.     300 IN A 172.217.7.196
;; Received 48 bytes from 216.239.34.10#53(ns2.google.com) in 83 ms

每个段落都是一个查询，显示回复和回复者（我们查询的人）。

让我们回到第一个查询，重做你对198.41.0.4（又名a.root-servers.net：

$ dig A www.google.com @198.41.0.4 +nodnssec

; <<>> DiG 9.12.0 <<>> A www.google.com @198.41.0.4 +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b56cbe6c8ffd3856
;; QUESTION SECTION:
;www.google.com.        IN A

;; QUERY SIZE: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.google.com.        IN A

;; AUTHORITY SECTION:
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30

;; Query time: 134 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Wed Aug 15 09:39:43 EST 2018
;; MSG SIZE  rcvd: 839

那么这里发生了什么：

你在回复中没有aa标志，这表明回复的名称服务器NOT对此查询具有权威性（例如，如果你要求它提供. NS，它将是权威的）李>
在AUTHORITY SECTION中告诉你下一步的权威是谁，即com.；这意味着为您提供一组名称服务器（NS 记录）
为了帮助您更快地使用 ADDITIONAL SECTION，它为您提供了上述域名服务器的 IP 地址，否则您首先需要将其名称解析为 IP 才能与他们联系。

这些部分在 RFC1034 中定义：

四个部分是：

Question 携带查询名称和其他查询参数。

Answer 包含直接回答查询的 RR。

Authority 携带描述其他权威的 RR 服务器。可以选择为权威机构携带 SOA RR 答案部分的数据。

Additional Carries RRs 可能有助于在这其他部分。

所以数据不能放在“答案”部分，因为它不直接回答提出的查询，也不能放在“权威”部分，因为您查询的名称服务器对gtld-servers.net没有权威

这也解释了为什么dig A e.gtld-servers.net. @198.41.0.4 +nodnssec 将返回基本相同的答案，但这主要是因为.com 和.net 由同一个注册表（VeriSign）处理并且它们共享相同的权威域名服务器（VeriSign 还处理两个根域名服务器 - a 和 j - 但这是不相关的）

所以，是的，下一步是连接到为 gtld-servers.net 名称服务器提供的任何 IP 以重做查询并确定它是否对 www.google.com 具有权威性，既然不是，它将提供下一步在“权威”部分。

像这样：

$ dig A www.google.com @a.gtld-servers.net. +norecurse +nodnssec

; <<>> DiG 9.12.0 <<>> A www.google.com @a.gtld-servers.net. +norecurse +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 22d54e7533355129
;; QUESTION SECTION:
;www.google.com.        IN A

;; QUERY SIZE: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.        IN A

;; AUTHORITY SECTION:
google.com.     172800 IN NS ns2.google.com.
google.com.     172800 IN NS ns1.google.com.
google.com.     172800 IN NS ns3.google.com.
google.com.     172800 IN NS ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com.     172800 IN A 216.239.34.10
ns1.google.com.     172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com.     172800 IN A 216.239.32.10
ns3.google.com.     172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com.     172800 IN A 216.239.36.10
ns4.google.com.     172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com.     172800 IN A 216.239.38.10

;; Query time: 142 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Aug 15 09:54:27 EST 2018
;; MSG SIZE  rcvd: 291

等等。

你也搞错了：

它们似乎都是本地 LAN 地址，所以我不知道它们对我有什么用。

RFC 1918 描述了私有地址空间，其中列出了：

10.0.0.0 - 10.255.255.255（10/8 前缀）

172.16.0.0 - 172.31.255.255（172.16/12 前缀）

192.168.0.0 - 192.168.255.255（192.168/16 前缀）

谢天谢地，这些区块中没有任何 IP。

【讨论】：

我不知道为什么这个答案被否决了，但它完美地解释了问题的答案。

【解决方案2】：

您对 Verisign 服务器的查询有问题。试试这个：

dig @<VeriSign-nameserver> google.com NS. ：这应该为您提供google.com 的权威名称服务器
dig @<NS for google.com> www.google.com A. ：这将为您从 google.com 名称服务器获取 www.google.com 的 A 记录。

注意：如果google.com 域名服务器与google.com 位于同一区域，#1 应该会返回粘合记录，这意味着它也会解析域名服务器的 IP 地址。

【讨论】：