DNS中的“附加部分”是什么以及它如何工作？

时间：2018-09-02 10:38:42

标签： dns bind

当我使用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的来源（授权服务器？）是用来做什么的？

2 个答案:

答案 0 :(得分：4)

请参阅RFC 1035，其中涉及DNS，尤其是第4.1节“消息格式”。

您将在此处阅读

  

其他记录部分包含RR   与查询有关，但不是严格的答案   问题。

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

您还可以在RFC 1034第6.2和6.3节中找到一些查询和答复示例，您将在其中看到如何填写“其他”部分。

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

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

  • 在“答案”中为您的查询提供准确的记录（如果您未指定任何内容，默认情况下，dig会A）
  • 在“权限”中，您可以看到递归了解到哪些域名服务器对您的记录具有权威性
  • 在“其他”中，您会获得上一部分中的名称服务器的IP地址，尤其是在这里，因为您处在“ in-bailiwick”情况下（通常称为“胶水”），因此您（作为递归名称服务器）将拥有无法连接权威的域名服务器。

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

$挖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

请密切注意“ Authority”部分中的namserver列表，以及“ Additional”部分中具有A / AAAA记录的Namserver。您将意识到，只有那些以.com或.net结尾的地址（因为这是特殊情况，其中这两个TLD都由同一个注册表处理）在这里具有IP地址，因为{{1 }} / .COM对于其他TLD中的名称和IP地址一无所知。

在此示例中，这看起来甚至更多：

.NET

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

答案 1 :(得分：2)

ADDITIONAL SECTION包含您未明确要求的数据，但服务器仍然将其提供给您。

服务器可以使用它来回答典型的后续问题，因为查找模式可以完全预测。即如果您请求MX记录，则可能接下来将对返回的MX记录执行A查找，并且如果权威服务器也恰好拥有这些记录，则可以直接将它们返回给您，而无需执行一个或多个额外的DNS往返。

在您的特定示例中，由于您询问了所有资源类型并获得了NS记录，因此同一台权威服务器也知道这些名称服务器的A和AAAA记录，并认为将其提供给您很有帮助。

作为互联网草案“在DNS响应中返回其他答案” （https://tools.ietf.org/id/draft-fujiwara-dnsop-additional-answers-00.html）在引言中对其进行了总结：

  

通过在单个响应中提供多个答案，权威名称服务器可以在存根解析器或其他客户端请求后续查询之前，协助全方位服务的解析器预先填充其缓存。除了减少最终用户的延迟之外，这还减少了全功能解析器需要发送的查询和权威服务器需要回答的查询总数。

相关问题
最新问题