什么是 DNS 中的“附加部分”及其工作原理？

Question

当我使用 dig

$ dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59489
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

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

;; ANSWER SECTION:
www.google.com.     23  IN  A   69.171.247.71

;; AUTHORITY SECTION:
google.com.     124333  IN  NS  ns4.GOoGLE.cOM.
google.com.     124333  IN  NS  ns1.GOoGLE.cOM.
google.com.     124333  IN  NS  ns3.GOoGLE.cOM.
google.com.     124333  IN  NS  ns2.GOoGLE.cOM.

;; ADDITIONAL SECTION:
ns1.google.com.     300146  IN  A   216.239.32.10
ns1.google.com.     308505  IN  AAAA    2001:4860:4802:32::a
ns2.google.com.     303470  IN  A   216.239.34.10
ns2.google.com.     124333  IN  AAAA    2001:4860:4802:34::a
ns3.google.com.     303470  IN  A   216.239.36.10
ns3.google.com.     124333  IN  AAAA    2001:4860:4802:36::a
ns4.google.com.     302836  IN  A   216.239.38.10
ns4.google.com.     302716  IN  AAAA    2001:4860:4802:38::a

有一个ADDITIONAL SECTION。

我知道DNS数据包的结构是：

+---------------------+
| Header              |
+---------------------+
| Question            | the question for the name server
+---------------------+
| Answer              | Answers to the question
+---------------------+
| Authority           | Not used in this project
+---------------------+
| Additional          | Not used in this project
+---------------------+

但我不知道ADDITIONAL SECTION.

我的意思是，ADDITIONAL SECTION从哪里来（权威服务器？）它有什么用？

Answer 1

请参阅处理 DNS 的RFC 1035，特别是第 4.1 节“消息格式”。

您将在那里阅读：

附加记录部分包含与查询相关的 RR，但不是问题的严格答案。

还有 3.3 下的各种格式，解释了哪个记录将触发特定的“附加”处理。

您还可以在 RFC 1034 部分 6.2 和 6.3 中找到一些查询和回复示例，您将在其中看到如何填写附加部分。

现在回到您的示例，问题在于您没有明确指定您查询的名称服务器，这意味着您从默认递归服务器中获得答案。

在这种情况下，您会看到：

• 在“回答”中，您查询的确切记录（A如果您未指定任何内容，则默认情况下dig 会执行）
• 在“权威”中，您会看到递归了解哪些名称服务器对您的记录具有权威性
• 在“附加”中，您将获得上一节中名称服务器的 IP 地址，尤其是在此处，因为您处于“辖区内”情况（通常称为“胶水”），因此您（作为递归名称服务器）将无法连接权威域名服务器。

让我们直接使用权威名称服务器重做查询，然后与另一种情况进行比较：

$ dig google.com NS @a.gtld-servers.net

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> google.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12149
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

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

;; 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: 68 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:23:20 EST 2018
;; MSG SIZE  rcvd: 287

所以在这里我们要求该.COM区域的一个权威域名服务器为我们提供google.com. 结果与之前类似。

让我们查询相同的名称服务器，但用于另一个域：

$ dig ultradns.com NS @a.gtld-servers.net

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> ultradns.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ultradns.com.          IN  NS

;; AUTHORITY SECTION:
ultradns.com.       172800  IN  NS  pdns196.ultradns.com.
ultradns.com.       172800  IN  NS  pdns196.ultradns.net.
ultradns.com.       172800  IN  NS  pdns196.ultradns.org.
ultradns.com.       172800  IN  NS  pdns196.ultradns.info.
ultradns.com.       172800  IN  NS  pdns196.ultradns.biz.
ultradns.com.       172800  IN  NS  pdns196.ultradns.co.uk.
ultradns.com.       172800  IN  NS  ari.alpha.aridns.net.au.
ultradns.com.       172800  IN  NS  ari.beta.aridns.net.au.
ultradns.com.       172800  IN  NS  ari.gamma.aridns.net.au.
ultradns.com.       172800  IN  NS  ari.delta.aridns.net.au.

;; ADDITIONAL SECTION:
pdns196.ultradns.com.   172800  IN  A   156.154.64.196
pdns196.ultradns.com.   172800  IN  AAAA    2001:502:f3ff::e8
pdns196.ultradns.net.   172800  IN  A   156.154.65.196
pdns196.ultradns.net.   172800  IN  AAAA    2610:a1:1014::e8

;; Query time: 72 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:25:24 EST 2018
;; MSG SIZE  rcvd: 432

密切注意“权威”部分中的 namservers 列表以及“附加”部分中具有A/AAAA记录的那些。您会意识到，只有以.comor结尾的.net（因为这是两个 TLD 都由同一注册管理机构处理的特殊情况）在此处具有 IP 地址，因为.COM/的权威名称服务器对.NET其他 TLD 中的名称和 IP 地址一无所知。

这个例子看起来更像是：

$ dig aridns.com NS @a.gtld-servers.net

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> aridns.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2552
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aridns.com.            IN  NS

;; AUTHORITY SECTION:
aridns.com.     172800  IN  NS  dns1.ausregistry.net.au.
aridns.com.     172800  IN  NS  dns1-1.ausregistry.net.au.
aridns.com.     172800  IN  NS  dns1-2.ausregistry.net.au.
aridns.com.     172800  IN  NS  dns2-1.ausregistry.net.au.

;; Query time: 68 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:28:07 EST 2018
;; MSG SIZE  rcvd: 139

根本没有“附加”部分，因为所有名称服务器都在区域外！