当前位置：首页 > news >正文

【BCT认证_组播DNS】 DNS SRV RR

news 2025/11/9 14:18:05

每天遇见几个罕为人知的Bug，醉了

定义

关键字“必须”、“不能”、“应该”、“不应该”和“可以”本文档中使用的术语应按照 [BCP 14] 中的规定进行解释。本文档中使用的其他术语在 DNS 中定义规范，RFC 1034。

适用性声明

一般情况下，预计 SRV 记录将被客户端使用对于相关协议规范指示的应用程序
客户端应该使用 SRV 记录。此类规范必须定义要在 SRV 的服务字段中使用的符号名称记录如下。它还必须包括安全性考虑因素。服务 SRV 记录不应在缺席时使用这样的规范。

入门示例

如果一个 SRV 认知 LDAP 客户端想要发现一个 LDAP 服务器支持TCP协议，为域提供LDAP服务example.com.，它会查找_ldap._tcp.example.com如 [ARM] 中所述。靠近结尾处的示例区域文件备忘录包含 SRV 查询的应答 RR。

注意：选择 LDAP 作为示例仅用于说明目的，不应考虑本文档中使用的 LDAP 示例关于 LDAP 使用 SRV 的推荐方式的明确声明记录。如前面的适用性部分所述，请参阅推荐过程的适当 LDAP 文档。

SRV RR的格式这是 SRV RR 的格式，其 DNS 类型代码为33：_Service._Proto.Name TTL 类 SRV 优先级权重端口目标（本文档末尾有一个示例。）

服务

所需服务的符号名称，如 Assigned 中所定义数字 [STD 2] 或本地。下划线 (_) 前置服务标识符，以避免与 DNS 标签发生冲突发生在自然界中。

响应者不断监视他们的同龄人的反应，冲突可以及时检测到网络拓扑变化引起的变化并解决了。如果响应不是通过多播发送的，则其他一些将需要冲突检测机制，强加自己的网络的额外负担。

在内存资源受限的设备上使用：使用时延迟响应以减少网络冲突，响应者需要维护一个列表记录每个答案应该发送给谁。这多播响应选项允许响应者具有有限的存储，不能存储任意长的响应列表地址，选择故障转移到单个多播响应在适当的时候放置多个单播响应。
重叠子网。在重叠子网的情况下，多播响应允许接收者确定地知道响应起源于本地链路，即使其源地址可能显然另有建议。
面对错误配置的稳健性：链路本地多播超越几乎所有可以想象的网络错误配置。即使您有一组设备，其中每个设备的 IP地址、子网掩码、默认网关和 DNS 服务器地址是都错了，这些设备中的任何一个发送的数据包都发送给了链路本地多播目标地址仍将传送到本地链路上的所有对等点。这在以下情况下非常有用诊断和纠正网络问题，因为它有助于客户端和服务器之间的直接通信通道有效不依赖 ARP、IP 路由表等。能够发现设备拥有（或认为拥有）的 IP 地址是什么
通常是诊断其原因的非常有价值的第一步无法在本地网络上通信。

附录 E. 编码否定响应的设计原理

考虑了断言不存在的替代方法，例如使用 NXDOMAIN 响应，或发出资源记录零长度 rdata。

使用 NXDOMAIN 响应不适用于多播 DNS。 A单播 DNS NXDOMAIN 响应适用于整个消息，但对于效率多播 DNS 允许（并鼓励）多重响应在一条消息中。如果标头中的错误代码是 NXDOMAIN，不清楚错误代码适用于哪些名称。

通过发出零长度的资源记录来断言不存在rdata 将意味着无法区分一个不存在的记录，一个确实存在的记录，零 -长度数据。以此类推，今天的大多数文件系统都允许空文件，因此不考虑存在零字节数据的文件相当于一个不存在的文件名。

通过 NSEC 记录断言不存在的好处而不是通过 NXDOMAIN 响应是可以将 NSEC 记录添加到DNS 响应的附加部分以提供附加信息超出查询器明确要求的范围。例如，在响应 SRV 查询，响应者应包括 A 记录在附加部分给出其 IPv4 地址，以及一个 NSEC记录表明它为此有或没有哪些其他类型姓名。如果响应程序在不支持的主机上运行IPv6（或确实支持 IPv6 但当前没有 IPv6 地址）接口）那么附加部分中的这个 NSEC 记录将表明没有 AAAA 记录。

实际上，响应者是说，“这是我的 SRV 记录，这是我的 IPv4 地址，并且不，我没有任何 IPv6 地址，所以不要浪费你的时间询问”。

如果附加部分中没有此信息，它将使查询器进行额外的往返以执行附加查询以确定目标主机没有 AAAA记录。（可以说单播 DNS 也可以从这种能力中受益在附加部分表示不存在，但那是超出本文档的范围。）

附录 F. UTF-8 的使用

经过多年的争论，由于人们认为需要适应某些显然不能的 DNS 实现处理任何非字母、数字或连字符的字符（以及显然永远不会更新以弥补此限制），单播 DNS 社区选择了一种极其古怪的编码，称为“Punycode”[RFC3492]。

Punycode 是一种非常巧妙的编码解决方案，但它很复杂，难以理解，也很难实施，使用复杂的技术，包括插入排序编码、广义可变长度整数和偏差适应。

给定约束，由此产生的编码非常紧凑，但它仍然不如简单直接的 UTF-8，而且它甚至很难预测给定的输入字符串是否会编码为符合 DNS 的 63 字节限制的 Punycode 字符串，除了只需尝试编码并查看它是否适合。

事实上，编码大小不仅取决于输入字符，还取决于它们出现的顺序，所以同一组字符可能会也可能不会编码为适合 DNS 63 字节的合法 Punycode 字符串限制，取决于字符出现的顺序。

这是极难呈现在向用户解释的用户界面中为什么允许一个名字，但另一个名字包含完全相同的字符不是。 Punycode 或任何其他“ASCII-可以使用为单播 DNS 提议的兼容编码”[RFC5890]

在多播 DNS 消息中。任何在内部表示的文本一些其他表示必须转换为规范的预合成在放入任何多播 DNS 消息之前的 UTF-8。

附录 G. 私有 DNS 命名空间

对以“.local”结尾的名称的特殊处理。已经从 Mac OS 9 开始就在 Macintosh 计算机中实现，并且
今天在 Mac OS X 和 iOS 中继续。还有实现适用于 Microsoft Windows [B4W]、Linux 和其他平台。

一些网络运营商设置私有内部网络（“内部网”）使用了未注册的顶级域，有些可能使用了“.local”顶级域。使用“.local”作为私人顶级域与多播 DNS 冲突，可能会导致问题对于用户。

客户端可以配置为同时发送多播和对这些名称并行进行单播 DNS 查询，这确实允许名称被双向查找，但这会导致额外的网络流量和名称解析的额外延迟，以及当不清楚是否有任何内容时，可能会造成用户混淆给定的结果是通过链路本地多播从对等点接收到的相同的链接，或来自配置的单播名称服务器。

因为为此，我们建议不要使用“.local”作为私有单播 DNS顶级域名。我们不建议使用未注册的顶级域，但如果网络运营商决定这样做，则以下顶级域已用于私人内部没有因尝试重用“.local”而导致的问题的网络。为了这个目的：

```
  .intranet.
```
```
  .internal.
```
```
  .private.
```
```
  .corp.
```
```
  .home.
```
```
  .lan.
```

.内联网。。内部的。。私人的。.corp.。家。局域网

附录 H. 部署历史

1997 年 7 月，在发送至 net-thinkers@thumper.vmeng.com 的电子邮件中邮件列表中，Stuart Cheshire 首先提出运行IP 上的 AppleTalk 名称绑定协议 [RFC6760]。后果这个和相关的 IETF 讨论，IETF Zeroconf 工作组1999 年 9 月获得特许。经过各种工作组讨论和其他非正式的 IETF 讨论，几个 Internet-草稿与一般主题松散相关DNS 和多播，但没有解决服务发现NBP的方面。

2000 年 4 月，Stuart Cheshire 注册了 IPv4 组播地址224.0.0.251 与 IANA [MC4] 并开始编写代码来测试和开发使用执行类似 NBP 的服务发现的想法多播 DNS，记录在一组三个 Internet-草稿：

“替代 AppleTalk 名称绑定的协议要求协议 (NBP)” [RFC6760] 是对 AppleTalk 的概述名称绑定协议，因为 IETF 社区中的许多人都有几乎没有使用 AppleTalk 的第一手经验，并且对IETF 社区关于 AppleTalk NBP 所做的事情引起了混乱关于基于 IP 的替代品需要什么。
“使用 DNS 发现抽象服务的命名实例”[NIAS]提出了一种使用 DNS 执行类 NBP 服务发现的方法-兼容的名称和记录类型。
“多播 DNS”（本文档）指定了一种传输那些使用 IP 多播的 DNS 兼容查询和响应，用于零没有常规单播 DNS 服务器的配置环境可用。

2001 年，Mac OS 9 的更新增加了对解析器库的支持使用多播 DNS 的主机名查找。如果用户键入这样的名称作为“MyPrinter.local”。进入任何使用过的网络软件标准的 Mac OS 9 名称查找 API，然后是那些名称查找 API会将名称识别为点本地名称并通过以下方式查询向 224.0.0.251:5353 发送简单的一次性多播 DNS 查询。

例如，这使用户能够输入名称“MyPrinter.local。”进入他们的网络浏览器以查看打印机的状态和配置网页，或输入名称“MyPrinter.local。”进入打印机设置实用程序以创建打印在该打印机上打印文档的队列。多播 DNS 响应软件，具有完整的服务发现，首先随着 Mac OS X 的发布，开始向最终用户批量发货10.2 “Jaguar” 2002 年 8 月，网络打印机制造商（曾过去在其网络打印机中支持 AppleTalk，并且接受可以为他们提供类似的基于 IP 的技术易用性）此后不久开始采用多播 DNS。

2002 年 9 月，Apple 发布了源代码mDNSResponder 守护进程作为 Apple 标准 Apple 下的开源
公共源代码许可证 (APSL)。

Microsoft 可以使用多播 DNS 响应程序软件

Windows 用户在 2004 年 6 月与 Apple 的“Rendezvous for Windows”（现在是“Bonjour for Windows”），两者都是可执行形式（一个最终用户可下载的安装程序）和开源（其中之一Apple 跨平台代码主体中支持的平台可公开访问的 mDNSResponder CVS 源代码存储库）[BJ]。

2006 年 8 月，Apple 重新授权了跨平台的 mDNSResponder Apache 许可下的源代码，版本 2.0。除了运行 Mac OS X 和Microsoft Windows、Multicast DNS 现已广泛实施硬件设备，例如 Apple 的“AirPort”无线底座站、iPhone 和 iPad，以及来自其他供应商的家庭网关，网络打印机、网络摄像机、TiVo DVR 等。

开源社区产生了许多独立的多播 DNS 的实现，有些是用 C 语言编写的，比如 Apple mDNSResponder 守护进程，以及其他各种不同语言的守护进程包括 Java、Python、Perl 和 C#/Mono。

2007 年 1 月，IETF 发布了信息 RFC“Link-Local多播名称解析 (LLMNR)” [RFC4795]，它实质上是
类似于多播 DNS，但在一些小但不兼容重要途径。特别是，LLMNR 设计明确排除支持服务发现，这使得它不适合用于替代 AppleTalk NBP [RFC6760] 的协议。

虽然最初关注多播 DNS 和基于 DNS 的服务Discovery 适用于零配置环境，无需传统的单播 DNS 服务器，基于 DNS 的服务发现也使用单播 DNS 服务器工作，使用 DNS 更新 [RFC2136] [RFC3007]

创建服务发现记录和标准 DNS 查询以查询为他们。 Apple 的“回到我的 Mac”服务，随 Mac OS X 推出
10.5 “Leopard”，2007 年 10 月，使用基于 DNS 的服务发现
单播 DNS [RFC6281]。

2012年6月，谷歌Android操作系统加入原生支持使用 android.net.nsd.NsdManager 用于 DNS-SD 和多播 DNS Android 4.1“Jelly Bean”（API 级别 16）[NSD] 中的类。

定义