如何在现代本地网络上解析名称？

Question

在现代局域网中，设备使用几种不同的技术来解析名称。具体来说，仅举几例，例如 DNS、Avahi、zeroconf、mDNS、Bonjour、NetBIOS、WINS，甚至手动主机文件。我相信，其中一些是基本相同事物的不同术语。有些使用分散技术，有些则依靠 DHCP 来分配中央地址。

当前常见的操作系统如何通过这些不同的、可能相互冲突的名称解析技术？他们使用什么顺序？不同的操作系统有不同的行为吗？

当询问 的 IPfoobar时，本地搜索域何时附加到名称上——在初始名称解析失败之后，在它询问网络上的某些内容之前，还是其他时间？尝试在其表中查找条目时，DNS 解析器可以（和/或做）添加搜索域吗？

当我在路由器中指定本地搜索域（而不是空白域）时，为什么我的客户端的行为会发生变化？

其中一些方法支持和/或使用.localtld/search 域。这只是Avahi的事情吗？

.在域的末尾添加 a 会如何改变事情？这是否只是阻止搜索“本地域”？当我查找时google.com，为什么不需要尾随.？

为什么我的 DNS 解析器不搜索google.com.local或google.com.MyLocalSearchDomain？

你可以有嵌套的搜索域吗？

NetBIOS 和 WINS 是一回事吗？avahi、bonjour 和其他的呢？

后续问题：这些服务是如何运作的？我知道 DNS 使用更传统的风格（基本上）每个客户端都配置为使用一个中央服务器。但是，分散式方法必须使用其他一些技术来自动发现名称。这些是如何工作的？

Answer 1

简而言之，它是由不同操作系统、产品、应用程序、服务和 API 使用的不同名称解析协议集的非常混乱的组合。

IETF ZeroConf 定义了 mDNS（多播 DNS）协议和 DNS-SD（DNS 服务发现）协议。Bonjour（née Rendezvous，又名 mDNSResponder）和 Avahi 是 ZeroConf 的两个实现。我听说 OpenWrt 社区也有一个实现，它简单地称自己为“mDNS”。自从苹果创造了这个，苹果产品就专注于此，尽管 Mac 也可以使用 NetBIOS Name Service 和 WINS 进行名称解析，尤其是在使用 macOS 的 SMB 客户端连接到 SMB 文件服务器（Windows Server、Linux SaMBA 服务器）时。

Microsoft 专有名称服务协议以基于 LAN 本地（不可路由）广播的 NetBIOS 名称服务开始。我说的是“Microsoft 专有”，但从技术上讲，它起源于 IBM，作为服务器消息块 (SMB) 协议的一部分。随着 SMB 文件服务成为事实上的行业标准，许多操作系统至少必须在其 SMB 客户端和服务器中采用 NetBIOS 名称服务。后来，Microsoft 创建了 WINS 来为这种 Microsoft 专有名称解析提供基于服务器的单播解决方案。当 Apple 创建名为“Rendezvous”（后来更名为 Bonjour）的 mDNS 并将其带到 IETF 最终成为 IETF ZeroConf 时，Microsoft 令人困惑地决定做他们自己的略有不同、不兼容的类似 mDNS 的想法，他们称之为“

Linux，包括 Google Android，现在似乎倾向于使用 ZeroConf 来进行基于 LAN 的无服务器名称解析。Google 将 Apple 的符合 POSIX 标准的开源“mDNSResponder”守护程序移植到 Linux，以便在 Android 中使用；它实现了 Android 的“网络服务发现”(NSD) API。

与 macOS 一样，Linux 使用 NetBIOS 名称服务和 WINS 来连接到 SMB 服务器。

这是一个巨大的混乱，用于特定事物的协议取决于您使用的操作系统，您的软件调用的 API 以及许多其他事情。