Windows上的LLMNR vs. Zeroconf vs. Bonjour

Question

本地链接组播名称解析（LLMNR）是一种基于多播DNS的Microsoft技术，用于服务发现。它是否与Bonjour/Zeroconf兼容？如果兼容，API在哪里？我认为，服务发现已经融入到原始DNS解析中（gethostbyname()），但服务广告呢？

- Seva Alekseyev

Answer 1

LLMNR只解决了mDNS解决方案的一小部分问题，这在此文章中有所阐述。简而言之，它与Bonjour不兼容。

以下是该文章的内容（以防存档网站删除页面）：

来自：Marc Krochmal 时间：2004年4月16日星期五，下午8:54:54 你好Tom，

我正在阅读Linux Magazine（http://www.linux-mag.com/2003-08/zeroconf_01.html）2003年8月的文章，介绍了Zeroconf环境。在文章中，他们提到Link Local组播名称解析被IETF采用，而mDNS则被摒弃了，尽管它使用现有标准而不是创建全新的协议。他们提到或暗示的原因之一是LLMNR比mDNS更先进，包括了保持本地地址不会意外传播到较大DNS空间的规定。根据我对Rendezvous环境的研究，这是错误的（不是吗？），因为mDNS知道以“.local”结尾的域仅在本地链路上可用，并且主机只会尝试解析以“.local”结尾的域名。所以，我是误读了这篇文章还是mDNS白皮书，还是有一些真相？

LLMNR比mDNS简单得多。LLMNR只提供基本的名称解析，当名称服务器配置错误或返回错误时才使用。

mDNS提供了分布式通知和缓存一致性协议。

支持即时DNS服务发现的设施。无论DNS服务器处于什么状态，mDNS也可在主机名以“.local”结尾时提供可靠的本地名称解析。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提供的功能之一。

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

这不会让我们回到NetBIOS v AppleTalk的日子吗？在Zeroconf环境中，我们现在有两个名称解析标准，而不是朝着单一标准努力？

这很难预测。如果Rendezvous继续增长势头，它很容易成为Zeroconf环境的标准。今天几乎每个网络打印机都配备了Rendezvous。Rendezvous还可以在Mac和Windows上启用iTunes音乐共享，从而使您能够在家中与许多其他设备共享音乐，而无需进行任何配置。

最后，针对另一个问题，Apple提供的mDNS响应器是否...

OS X同时处理传统DNS响应和本地链接mDNS。Windows和Linux系统的mDNS响应器是否打算替换其对应的传统DNS处理程序，还是与现有的DNS处理程序共同工作？例如，在安装了mDNS响应器的Windows系统上，如果需要发送DNS查询（针对全局域），操作系统是否会使用mDNS响应器来处理该过程，或者仍会使用其自带的DNS响应器？

尽管mDNSResponder可以用于替换所有DNS查询处理，但实际上可能不会这样做。mDNSResonder项目中包含的Windows命名空间提供程序仅适用于以".local"结尾的名称。

此致

- Marc

- Chris Mowforth

---

在Windows XP上，您可以在不安装LLMNR的情况下使用它吗？ - Gobliins

Answer 2

来自苹果的开源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.

- Colin