为什么要在DNS中发送权威的域名服务器？

出于好奇，我正在检查Wireshark DNS数据包。我可以看到主机发出了DNS查询，然后是DNS服务器发出了DNS响应。一切都如预期。

但是，如果进一步检查查询，则可以看到服务器还发送了NS（权威名称服务器）。我的问题是：为什么？

作为主机，我只关心IP。这是DNS的重点，它将名称解析为IP地址。

为什么作为主机，我需要NS信息？

@downvoter，请发表评论。而且，如果您认为我的问题如此简单，那么至少回答一下然后再投票。

— 艾哈迈德·瓦斯（AhmedWas）

通过理念和设计的投票是匿名的，没有投票权了，也不投票下来需要任何强制性的解释。当鼠标指针悬停在向下按钮上时出现的工具提示指出：“此问题未显示任何研究成果；尚不清楚或没有用”。同时问题可以吸引向下投票时没有写得很好，不太切合主题或丢失的细节。

— HBruijn

Answers:

传统名称服务器不发送的查询的短的响应，但一个RFC 1034 - 1035兼容的完整的响应，其中包括一个包含资源记录的权威节点向权威名称服务器（一个或多个）。

原因可能是因为DNS具有分布式和委派的性质，当时在响应中包含“真相来源”似乎是一个好主意。

编辑：顺便说一句：发送权限部分符合RFC，但并非所有查询响应都必须包含。

在BIND中，可以使用minimal-responses yes | no;伪指令来调整此行为，该伪指令的默认值为no，并且查询响应的Authority和Additional部分将始终完全填充。
默认情况下，其他名称服务器CloudFlare，AWS Route 53，Infoblocks以及可能其他名称服务器将始终发送此类最小响应。Google的公共解析器将在Cloudflare可用时返回一个Authority部分。

我认为该传统的起源既包括授权部分，又包括实际的查询响应，其根源于现在已过时的RFC882 15-16页的（伪）代码中。

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.

— 鲁比恩
source

感谢您的编辑和其他信息。我希望我能多给你一票：)

— 艾哈迈德瓦斯（AhmedWas）

这并不能真正回答问题。我们已经知道收到了完整的回复。问题是，这样做有什么好处？为什么采用这种方式设计标准？这种响应形式的“附加”信息的价值是什么？

— Lightness Races in Orbit

@LightnessRacesinOrbit对我来说，答案是不言而喻的：DNS服务器不仅告诉我example.com是abcd，而且还告诉我。告诉我是谁说的。从认识论上讲，这是正确的，因为当我实际上只知道某个第三方断言这是事实时，我无法准确地告诉您我知道某事是事实。我发现当人们以传闻好像是观察者或他们的结论像是主要证据时，很难解决问题。将X陈述为真实与告诉Y陈述事实是巨大的差异。

— 蒙蒂·哈德

@MontyHarder是的，这很有道理，但我的意思是应该在答案中。

— Lightness Races in Orbit

@LightnessRacesinOrbit RFC并不总是包含设计动机。为了澄清“在当时看来是个好主意”-我认为，即使当前的RFC并没有强制要求在（pseudo ）从现在已过时的RFC882第15-16页开始的代码“ ...如果名称服务器不具有权威性，则该代码

— HBruijn

服务器不知道该请求是来自最终客户端，还是来自另一个名称服务器的递归请求。如果是其他名称服务器，则可以缓存“权限”部分并在将来直接查询这些名称服务器。

我相信这是该协议中的原始理由，但是它具有安全隐患。响应中可以包含列出伪造名称服务器的“授权”部分，该部分已用于缓存中毒攻击中。因此，名称服务器通常不会缓存NS记录，除非它们是您要查询的域的子域的委托记录。

— 巴尔玛
source

服务器实际上可以分辨出这些请求之间的区别。标志中有一点要求递归。

— kasperd

服务器可以发送递归查询，例如在使用该forwarders功能时。

— Barmar

但是，如果这样做，无论如何它都不在乎权威服务器。

— kasperd