Windows上的LLMNR与Zeroconf vs. Bonjour

Question

链路本地多播名称解析(LLMNR)是一种基于多播DNS的服务发现的Microsoft技术.它与Bonjour/Zeroconf兼容吗？如果是这样,API在哪里？我认为服务发现以某种方式融入了vanilla DNS解析(gethostbyname()？),但是服务广告呢？

Answer 1

LLMNR解决的问题，一个小的子集的mDNS铲球，载于该岗位。简而言之，它与Bonjour不兼容。

这是该帖子的内容，以防archive.org决定删除该页面：

来自：Marc Krochmal日期：2004年4月16日星期五，汤姆，

我正在阅读《 Linux Magazine》 2003年8月的文章（http://www.linux-mag.com/2003-08/zeroconf_01.html）在Zeroconf环境中。在文章中，他们提到IETF通过了“链接本地多播名称解析”，尽管它使用了现有标准而不是创建了一个全新的协议，但它或多或少地抛弃了mDNS。他们提到或暗示的原因之一是LLMNR比mDNS更高级，因为“包括防止链路本地地址意外传播到更大的DNS空间的规定”基于我对Rendezvous环境所做的研究，这是不正确的（是不是？），因为mDNS知道以'.local'结尾的域仅在本地链接上可用，并且主机将只能尝试解析在本地链接上以'.local'结尾的域名。

LLMNR比mDNS先进得多。LLMNR解决了一个非常小的问题。当名称服务器配置错误或返回错误时，它提供非常基本的名称解析。

mDNS提供了分布式通知和缓存一致性协议，该协议可用于基于DNS的临时服务发现。当主机名以“ .local”结尾时，无论DNS服务器处于什么状态，mDNS都可以提供可靠的本地名称解析。LLMNR不是服务发现协议。您可以说mDNS是LLMNR的超集。

在使用mDNS一年半的运营经验之后，我们从未见过本地本地链接之外的本地链接地址意外泄漏。

IETF DNSEXT工作组中有很多人希望看到LLMNR与mDNS互操作。实际上，包括Paul Vixie在内的一些人都在说应该淘汰LLMNR，并用mDNS代替。您可以在namedroppers档案中自己阅读。

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/

本文提到的另一件事是Microsoft正在推动LLMNR，据我所知，这是Win XP中Service Pack 2提供的。

我不知道Service Pack 2中包含LLMNR。

难道这不会使我们回到NetBIOS v AppleTalk的时代吗？在这里，不再致力于单一标准，而是在Zeroconf环境中使用两个名称解析功能？

这很难预测。如果Rendezvous继续获得动力，它很容易成为Zeroconf环境中的标准。如今，几乎所有具有网络功能的打印机都随附有Rendezvous。Rendezvous还启用了Mac和Windows上的iTunes音乐共享功能，使您可以零配置与家庭中的许多其他设备共享音乐。

最终，在不同的轨道上，Apple为OS X提供的mDNS响应器处理传统的DNS响应以及链接本地mDNS。用于Windows和Linux的mDNS响应器是否打算替换Windows OS和Linux OS提供的各个传统DNS处理程序，或者mDNS是否与它们现有的DNS处理结合使用（即，在安装了mDNS Responder的窗口中，如果需要发送DNS查询（针对全球域），操作系统现在将使用mDNS响应器来处理该过程，还是将使用其“现成的” DNS响应器？？？）

即使可以使用mDNSResponder代替所有DNS查询处理，也可能不会。mDNSResonder项目中包含的Windows名称空间提供程序仅适用于以“ .local”结尾的名称。

最好的祝福，

-渣

Answer 2

来自Apple 的 mDNSResponder 开源实现：

// Note: Microsoft's proposed "Link Local Multicast Name Resolution Protocol" (LLMNR) is essentially a limited version of
// Multicast DNS, using the same packet formats, naming syntax, and record types as Multicast DNS, but on a different UDP
// port and multicast address, which means it won't interoperate with the existing installed base of Multicast DNS responders.
// LLMNR uses IPv4 multicast address 224.0.0.252, IPv6 multicast address FF02::0001:0003, and UDP port 5355.