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

问题描述 投票：1回答：2

当我使用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来自哪个（权威服务器？），它用于什么？

dns bind
2个回答
4
投票

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

你会在那里读到：

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

以及3.3中的各种格式解释了哪个记录将触发特定的“额外”处理。

您还可以在RFC 1034第6.2和6.3节中找到一些查询和回复示例，您将在其中查看“附加”部分的填写方式。

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

在这种情况下，你看到：

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

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

$ 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列表以及“Additional”部分中具有A / AAAA记录的namservers列表。您将意识到只有那些以.com或.net结尾的那些（因为这是一个特殊情况，这两个TLD都由同一个注册表处理）这里有IP地址，因为.COM / .NET的权威名称服务器对名称和IP地址一无所知其他TLD。

对于这个例子，这看起来更多：

$ 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

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

2
投票

ADDITIONAL SECTION包含您没有明确要求的数据，但无论如何服务器都给了您。

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

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

随着互联网草案“在DNS响应中返回更多答案”（https://tools.ietf.org/id/draft-fujiwara-dnsop-additional-answers-00.html）在介绍中总结了它：

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

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.