为什么私有网络的DNS服务发现查询会被发送到我的ISP？

我最近做了一些测试，涉及通过我的软件在个人Mac OS X机器上重新编程（代理）常规DNS查询，然后返回到我的ISP的DNS服务器。

我有机会看到正常计算机使用情况下的所有查询。这些让我很好奇：

lb._dns-sd._udp.0.1.168.192.in-addr.arpa  
db._dns-sd._udp.0.1.168.192.in-addr.arpa  
b._dns-sd._udp.0.1.168.192.in-addr.arpa  
b._dns-sd._udp.0.1.168.192.in-addr.arpa  
db._dns-sd._udp.0.1.168.192.in-addr.arpa  
lb._dns-sd._udp.0.1.168.192.in-addr.arpa

我在某处读到这些来自Apple的Bonjour服务发现。但是，这不应该只在本地网络上工作，那么将这些查询发送到ISP的DNS服务器的目的是什么？！那些家伙是否拥有来自拥有macs的人们的大量问题？！我在这里错过了什么？

更新： 我刚检查了这些查询的响应数据，它总是一样的。我看到以下内容：

prisoner.iana.org

和

hostmaster.root-servers

在每个回复中提到（注意：我正在查看原始数据，所以我可能无法正确解码。我通过谷歌搜索看到其他人正在获得 hostmaster.root-servers.org 但我看不到 org 在我的回复的原始字节中）

dns macos bonjour

— Ivan Kovacevic
source

这是ServerFault的主题。无论如何我都会回答，因为我没有在SuperUser上看到一个欺骗性的候选人。（应该迁移到哪里）

— Andrew B

这不是反向DNS查找。它确实是DNS服务发现。虽然这通常用于多播DNS，而不是单播DNS。

— Daniel B

安德鲁B将我有点丑陋的主题改为“为什么专用网络的反向DNS被发送到我的ISP？”所以我实际上从未说过它是反向DNS查询。我现在改变了话题。我还必须说这对于serverfault来说并不是那么偏离主题，因为从sys管理员的角度来看这个问题可能已经被考虑过了。例如网络/协议架构，正面/负面如何完成以及“专业系统和网络管理员”如何处理这些查询。

— Ivan Kovacevic

该 in-addr.arpa 后缀使得这是一个反向DNS问题的核心，特别是因为你也在询问 prisoner.iana.org - blackholing服务器。那时我试图将这个问题用于将来可以重复使用的问题。关于时事性，这涉及在个人设备上进行的观察和反向DNS（ in-addr.arpa 泄露给你的ISP。如果您有其他问题，请咨询meta.SF，这已经过详尽的讨论。

— Andrew B

我明白。谢谢你的回答！

— Ivan Kovacevic

您的计算机的解析程序库没有关于私有地址空间和什么不是私有地址空间的概念。任何请求反向DNS查找将发送到您的计算机配置使用的DNS服务器。

同样，您的客户端应用程序不知道您配置的DNS服务器是由您还是其他实体操作。他们能做的最好的就是尝试使用DNS进行自动发现，以及希望您正在运行自己的LAN基础架构，该局域网具有权威性。

在住宅/发烧友场景中，最常见的情况是您正在使用ISP的DNS服务器。私有网络反向DNS的查询将“泄漏”到您的ISP。在DNS规范中没有办法解决这个问题;这被认为是正常的操作。 ISP在这一点上的响应完全取决于他们。这些是最常见的情况：

ISP为私有网络空间管理自己的权威反向DNS，并将其暴露给客户。通常，这会导致您发现持有该IP地址的计算机的DNS条目其网络。（糟糕）
ISP不认为自己对该IP空间具有权威性，并且他们将查询“泄漏”到IANA的顶级域名服务器以进行反向DNS。该 prisoner.iana.org. 你看到的权威数据来自 IANA的blackholing服务器。您可以在提供的链接中阅读有关它们的更多信息，但简短版本是私有网络反向DNS的泄漏非常常见，并且这些服务器的设置可以减轻IANA真实负载的负担。
名称服务器软件（或服务器运营商）比大多数人更体贴，并且自己对查询进行黑洞处理。这是迄今为止最不可能发生的情况。 BIND在9.4.1中实现了这样的功能。它受到控制 empty-zones-enable （默认值：是），返回的数据受到影响 empty-server 和 empty-contact 选项。

— Andrew B
source