目录
1.介绍............................................... 3 .....
2.本文档中使用的约定和术语............... 5
3.设计目标.............................................. ...... 5
4.服务实例枚举（浏览）......................... 6
4.1。结构化服务实例名称.......................... 6
4.2。用户界面演示................................ 9
4.3。名称的内部处理................................. 9
5.服务实例解决.................................... 10
6. DNS-SD TXT记录的数据语法............................. 11
6.1。DNS TXT记录的通用格式规则.................. 11
6.2。DNS-SD TXT记录的大小.................................... 12
6.3。DNS-SD中使用的DNS TXT记录格式规则.....................
6.4。DNS-SD密钥/值对中的密钥规则.................. 14
6.5。DNS-SD密钥/值对中的值规则................ 16
6.6。示例TXT记录........................................ 17
6.7。版本日............................................... 17
6.8。具有多个TXT记录的服务实例............... 18
7.服务名称.............................................. .... 19
7.1。选择性实例枚举（子类型）................. 21
7.2。服务名称长度限制................................ 23
8.旗舰命名.............................................. ..25
9.服务类型列举....................................... 27
10.使用信息填充DNS ........................... 27
11.浏览和注册域的发现（域枚 举）................................................ ..28
12. DNS附加记录生成.............................. 30
12.1。PTR记录............ 30
12.2。SRV记录.............................................. 30
12.3。TXT记录.............................................. 31
12.4。其他记录类型....................................... 31
13.工作实例.............................................. 31
13.1.从dns-sd.org上宣传了哪些网页？..... 31
13.2.有哪些打印机配置网页？.......... 31
13.3.如何访问名为“服务发现”的网页
？.............................................. 32
14. IPv6注意事项........................................... 32
15.安全考虑........................................ 32
16. IANA注意事项........................................... 32
17.致谢............................................... 33
18.参考文献............................................... ..... 33
18.1。规范性参考文献..................................... 33
18.2。信息参考................................... 34
附录A.使用DNS作为服务基础的基本原理
发现............................................. 37
附录B.服务实例的订购名称组件.......... 38
B.1。语义结构........................................ 38
B.2。网络效率........................................ 39
B.3。操作灵活性................................... 39
附录C.所见即所得.......................... 40
附录D.出厂默认名称的选择....................... 42
附录E.域名系统中的名称编码.............. 44
附录F.“连续实时更新”浏览模型............... 45
附录G.部署历史.................................... 47
1.简介
本文档指定了DNS资源记录的命名方式以及如何结构化以促进服务发现。给定一种客户端正在寻找的服务以及客户端正在寻找该服务的域，这种机制允许客户使用标准DNS查询发现一个服务期望的命名实例列表。此机制称为基于DNS的服务发现，或DNS-SD。
本文档建议不要更改DNS消息的结构和操作代码，响应代码，资源记录类型或任何其他新的DNS协议值。
本文档指定了特定的服务实例可以使用DNS SRV [RFC2782]和DNS TXT [RFC1035]记录进行描述。SRV记录的名称格式为“<Instance>.<Service>.<Domain>”
并提供服务实例能够到达的目标主机和端口。同名的DNS TXT记录提供了额外的有关此实例的信息，使用键/值对的结构化形式，在第6节中描述。客户端发现使用DNS查询的 PTR [RFC1035]，记录的名为“<Service>。<Domain>”的给定服务类型的可用实例的列表，它返回一组零个或多个名称，这些名称是上述的DNS SRV / TXT记录对。
此规范与多播DNS以及今天现有的单播DNS服务器和客户端软件兼容[RFC6762]。
与多播DNS一起使用时，DNS-SD可以提供零配置操作 - 只需连接DNS-SD / mDNS设备，其服务即可
在本地链接上公布，没有进一步的用户交互[ZC]。
当与传统的单播DNS一起使用时，一些配置通常是必需的---- 例如使用DNS配置的设备
应该在其中宣传其服务和配置的域，并且使用DNS更新[RFC2136] [RFC3007]键配置它以便授予它权限
这样做。在极少数情况下，例如防火墙背后不需要DNS更新密钥的安全的企业网络 ，
零配置操作可以通过简单地让设备以从网络中学习的默认注册域中的服务来注册它来实现（参见第11节“浏览和注册域的发现”）， 但这是例外，通常安全凭证是需要执行DNS更新的。
请注意，当使用DNS-SD与单播DNS时，单播DNS-SD服务不必由相同的DNS服务器硬件提供， 这是目前提供组织的传统主机名查找服务。虽然很多人只想到“DNS”只是将主机名映射到IP地址的上下文，事实上，“DNS是一个普通的（如果有些限制）分层数据库，并且可以存储几乎任何类型的数据，几乎用于任何目的“[RFC2181]”，通过委托“_tcp”和“_udp”子域，所有工作负载相关的 DNS-SD可以转载到不同的机器上。这种在网络上处理主DNS服务器上的DNS-SD灵活性，对于管理员的自由裁量权来说，是使用DNS的好处之一。
即使将DNS-SD功能委托给其他机器，使用DNS的好处仍然存在：它是成熟的技术，很好理解，来自不同的多个独立实现供应商，关于该主题的各种书籍，以及在其运营中经验丰富的劳动力。相反，采用其他一些服务发现技术需要每一个世界上的网站，用于安装，学习，配置，操作和维护一些全新的，不熟悉的服务器软件。面对这些障碍，似乎不太可能是任何其他服务发现技术可能希望的以及DNS已经享受了的无处不在的部署竞争。有关进一步的讨论，请参阅附录A， “使用DNS作为服务发现基础的基本原理”。
本文档面向两个受众：为开发人员创建在网络上提供或访问服务的应用软件，并为开发人员创建DNS-SD库来实现广告和发现机制。对于两个观众，理解整个文档很有帮助。对于开发者创建应用程序软件，本文档提供了指导选择实例名称，服务名称和其他方面在创造良好的整体用户体验方面的作用。但是，了解用于提供的基础DNS机制服务发现设施可帮助应用程序发现这些潜在机制的能力和局限性（例如，姓名长度限制）。对于编写软件的库开发人员构建DNS记录（宣传服务）并生成DNS查询（发现和使用服务）来说，了解 最终的用户体验目标可帮助他们提供可满足的API的那些目标。
2.本文档中使用的约定和术语
关键词“必须”，“绝不”，“必须”，“必须”，“不要”， “应该”，“不应该”，“推荐”，“可能”和“可选” 文件的解释如“使用的关键词”中所述RFC指示需求级别“[RFC2119]。
3.设计目标
在良好的服务发现协议需要的许多属性中有三个特别重要的是：
（i）查询在 某些逻辑域的某种类型的服务的能力，并在响应中接收命名列表实例（网络浏览或“服务实例枚举”）。
（ii）给定一个特定的命名实例，有效的将该实例名称解析为客户端所需的信息的能力，需要实际使用该服务，即IP地址和端口 数字，至少（服务实例解决方案）。
（iii）实例名称应相对持久。如果是用户从可用选项列表中选择其默认打印机，今天，明天他们仍然可以打印出来--即使打印机 - IP地址和/或端口号以及服务驻留已经改变 - 没有用户（或他们的 软件）必须重复步骤（i）（初始网络浏览）第二次。
另外，如果要成功，还要进行服务发现，协议应该如此简单，几乎可以实现任何设备能够实施IP不应该有任何实施的麻烦
服务发现软件也是如此。
在其余部分中将更详细地讨论这些目标文献。更全面地处理服务发现要求可在“替换议定书的要求”中找到
AppleTalk名称绑定协议（NBP）“[RFC6760]。那个文件。借鉴二十年的运作经验 AppleTalk开发了一个通用要求列表，广泛适用于任何潜在的服务发现协议。
4.服务实例枚举（浏览）
传统DNS SRV记录[RFC2782]对于定位很有用，当所有实例都是特定类型服务的实例时有效地区分提供相同的服务的客户。
例如，SRV记录了（假设的）名称“_http._tcp.example.com。” 将允许客户端发现实现“_http._tcp”服务（即Web服务器）
“example.com”。域的服务器 。没有说明的假设是所有这些服务器提供相同的网页集， 客户端使用哪个服务器并不重要，只 要它随机选择一个 根据DNS中规定的权重和优先级规则的SRV规范[RFC2782]。
其他类型服务的实例并不容易互换。如果一个文字处理应用程序要查找（假设）SRV记录“_ipp._tcp.example.com”。先找到互 联网列表，然后，在Example Co.的打印协议（IPP）[RFC2910]的打印机随意挑选一个并在上面打印什么可能不是用户想要 的。
本节的其余部分描述了如何使用SRV记录以稍微不同的方式，允许用户发现给定类型服务的所有可用实例的名称，然后从该列表中选择他们想要的特定实例。
4.1.结构化服务实例名称
本文档借用了来自DNS SRV记录逻辑服务命名语法和语义，但增加了一个间接级别。代替 请求名称 为“_ipp._tcp.example.com。”的“SRV”类型的记录， 客户端请求类型为“PTR”的记录（指针从一个名称到DNS命名空间中的另一个）[RFC1035]。
实际上，如果想到域名“_ipp._tcp.example.com”。类似于文件中目录的绝对路径系统，DNS-SD的PTR查找类似于执行该目录列表以查找它包含的所有条目。（记住那个与路径名相比，域名以相反的顺序表示 - 绝对路径名称以左侧的根开头并从左到右被读取，而完全限定的域名以 右边的根，从右到左阅读。如果完全合格域名“_ipp._tcp.example.com”.表达为 文件系统路径名，它将是“/ com / example / _tcp / _ipp”。）
此PTR查找名称“<Service>。<Domain>”的结果是一组由零个或多个PTR记录给出的服务实例名称形成：
服务实例名称= <实例>。<服务>。<域>
有关组件按此顺序排列的原因，请参阅附录B，“服务实例名称组件的排序”。
4.1.1.实例名称
服务实例名称的<Instance>部分是用户 - 友好名称由任意Net-Unicode文本[RFC5198]组成。它不得包含ASCII控制字符（字节 值0x00-0x1F和0x7F）[RFC20]但允许包含任何字符， 没有限制，包括空格，大写，小写， 标点符号 - 包括点 - 重音字符，非 罗马文字， 以及可以使用Net-Unicode表示的任何其他内容。对于讨论为什么<Instance>名称应该是用户可见的，用户 - 友好的名称，而不是一个看不见的机器生成的不透明标识符，请参阅附录C，“所见即所得”。
正在提供的服务名称的<Instance>部分网络应该由用户设置服务来配置，所以他或她可能会给它一个信息丰富的名字。但是， 该设备或服务不应要求用户在其可以使用之前配置名称。在许多情况下，默认名称的合理选择允许在没有任何手册的情况下访 问设备或服务的完全配置。默认名称应该简短具描述性的，不应该包括设备的媒体访问控制（MAC）地址，序列号或任何类似 的不可理解的十六进制字符串，试图使名称全局唯一。 讨论为什么<Instance>名称不需要（并且应该是）在工厂制造独特，见 附录D，“选择出厂默认名称“。
存储服务实例名称的<Instance>部分直接在DNS中作为规范预组合的单个DNS标签 UTF-8 [RFC3629]“Net-Unicode”（Unicode规范化表格C） [RFC5198]文字。有关文本编码的进一步讨论，请参阅 附录E，“域名系统中的名称编码”。
DNS标签目前的长度限制为63个八位字节。UTF-8 编码要求每个Unicode字符最多需要四个八位字节，这意味着在最坏的情况 下，名称的<Instance>部分可以 限制为十五个Unicode字符。但是，Unicode 在UTF-8编码下具有较长八位字节长度的字符往 往是较少使用的，往往是那些传达每个角色的更有意义。
请注意常用的16位Unicode Basic中的任何字符， 多语言平面[Unicode6]可以编码不超过三个UTF-8编码的八位字节。这意味着实例名称可以 包含多达21个汉字字符，这是一个足够表达大多数用途的名称。
4.1.2.服务名称
服务实例名称的<Service>部分由一对DNS标签组成，遵循已为SRV制定的惯例记录[RFC2782]。该货币对的第一个标签是下划线字符后跟服务名称[RFC6335]。服务名称识别服务的作用以及它的应用程序协议。第二个标签是“_tcp”（通过TCP应用程序协议）或“_udp”运行的协议（对于所有其他协议）。更多有关详细信息，请参见第7节“服务名称”。
4.1.3.网站域名
服务实例名称的<Domain>部分指定DNS 这些名称在其中注册的子域。它可能是 “local。”，意思是“链接本地多播DNS”[RFC6762]，或者它可能是 传统的单播DNS域名，例如“ietf.org。”， “cs.stanford.edu.”或“eng.us.ibm.com”。因为服务实例
名称不是主机名，它们不受通常规则的约束 ，主机名[RFC1033] [RFC1034] [RFC1035]和富文本服务 允许并鼓励子域名，例如：
Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .
此外，因为服务实例名称不受主机名的限制的约束，本文档建议它们存储在DNS中，并通过线路进行通信，编码为 直接的规范预组合UTF-8 [RFC3629]“Net-Unicode”（Unicode标准化表C）[RFC5198]文本。在有些情况下 DNS服务器返回有问题名称的否定响应， 客户端软件可以选择重试查询 ，使用“Punycode”算法[RFC3492]将UTF-8名称转换为IDNA“A-label” [RFC5890]，从顶级标签开始，然后反复发出查询，如果成功连续更多标签翻译成IDNA A标签，如果它已将所有标签转换为IDNA A标签，查询仍然失败。
4.2.用户界面演示
服务实例枚举PTR查找产生的名称 在列表中呈现给用户以供用户选择一个（或 更多）。通常，仅显示第一个标签（用户友好的
名称的<Instance>部分）。
在常见情况下，<Service>和<Domain>已为客户端软件所知，这些首先是用户由隐式提供，通过指示正在寻找的服务的行为， 以及寻找它的领域。请注意， 处理响应的软件应注意不要使其无效，但是，假设它是*可能的，尽管很少见， 在一个域中的服 务枚举以返回服务在 一个不同的领域的名称。同样，使用子类型时（参见第7.1节， “选择性实例枚举”）发现的<Service>
实例可能与请求的<Service>不完全相同 。
有关服务实例枚举（浏览）的进一步讨论的用户界面注意事项，请参阅附录F“'连续实时更新'浏览模型'。
一旦用户选择了所需的命名实例，可以立即使用服务实例名称，或者将其保存在某些实例名称中作为持久的用户偏好数据结 构，供将来使用，具体取决于适用于有关申请的内容。
4.3.名称的内部处理
如果客户端软件采用服务实例名称的<Instance>，<Service>和<Domain> 部分，并在内部连接它们一起变成单个字符串，然后因为<Instance>部分是允许包含适当的任何字符，包括点， 必须采取预防措施以确保DNS标签边界妥善保存。客户端软件可以以各种方式执行此操作方式，如角色逃避。
本文件推荐如果连接服务实例名称的三部分，<Instance>部分中的任何点都是按照文本文件的惯例DNS约定进行转义： 在字 面点前面加反斜杠（所以“.”变为“\.”）。 同样，<Instance>部分中的任何反斜杠也应该是通过在它们之前使用反斜杠进行转义（因此“\”变为“\\”）。
完成此操作后，名称的三个组成部分可能是安全的级联。反斜杠转义允许名称中的文字点（转义）与标签分隔符点（不是
转义），可以安全地传递生成的连接字符串成标准DNS API，如res_query（），它将按预期方式解释反斜杠转义字符串。
5.服务实例解决方案
当客户需要联系由服务实例名称标识的特定服务时 （此前通过服务实例枚举（浏览）发现），它将在SRV和TXT记录查询那个 名字。服务的SRV记录给出端口号和可以找到服务的目标主机名。TXT记录提供有关服务的其他信息，如第6节“DNS-SD TXT记录的数据语法”中所述。
SRV记录非常有用，因为它们不再需要预先分配的端口号。只有65535个TCP端口号可用。传统上，这些端口号分配一个应用程序协议[RFC6335]。一些协议，如X Window系统有一个分配了64个TCP端口的块（6000-6063）。用一个 给定的机器的给定服务的 每个不同实例的 不同TCP端口 是完全合理的，但分配每个应用程序它自己的大静态范围（与X Window系统一样）不是一个实用的方法。在任何给定的主机上，大多数TCP端口 保留用于在它的一生中永远不会在该特定主机上运行的服务 。这是有限端口空间的利用率很低 。使用SRV记录允许每个主机动态地分配其可用的 端口号为那些实际运行的 需要它们的主机的服务，然后 通过SRV记录通告分配的端口号。根据需要分配可用的侦听端口号 ，在每个主机上本地允许可用的端口空间比今天的集中式全球空间更好地利用 分配。
如果返回多个SRV，客户端必须
正确解释优先级和权重字段 - 即更低 -
编号优先服务器应优先使用 -
编号优先级服务器，优先级相同的服务器应该是
根据其相对权重按比例随机选择。然而，
在绝大多数情况下，单个广告的DNS-SD服务
实例仅由一个SRV记录描述，并且在此常见中
如果SRV记录的优先级和权重字段都应该是
设为零。
6. DNS-SD TXT记录的数据语法
通过Service Instance Enumeration发现的某些服务可能需要
不仅仅是一个IP地址和端口号来完全识别
服务实例。例如，通过旧的Unix LPR进行打印
（端口515）协议[RFC1179]通常指定队列名称[BJP]。
此队列名称通常较短且含糊不清，无需显示
给用户。它应该被视为与IP地址相同的方式
和端口号：它是寻址的另一个组成部分
识别特定服务实例所需的信息
由某些硬件提供。同样，文件服务器
可能有多个卷，每个卷都由自己的卷名标识。一个
Web服务器通常具有多个页面，每个页面由其自己标识
URL。在这些情况下，必要的附加数据存储在a中
与SRV记录同名的TXT记录。具体性质
这些额外数据以及如何使用，是服务 -
依赖，但TXT记录中数据的整体语法是
标准化，如下所述。
除了SRV之外，每个DNS-SD服务都必须有一个TXT记录
记录，具有相同的名称，即使该服务没有额外的
要存储的数据和TXT记录包含不超过一个零
字节。这允许服务明确控制时间
生存（TTL）其（空）TXT记录，而不是使用
默认负缓存TTL，否则将用于“否”
错误无答案“DNS响应。
请注意，强制TXT记录的此要求适用
专用于DNS-SD服务广告，即所宣传的服务
使用本文档中指定的PTR + SRV + TXT约定。它是
一般而言，不是SRV记录的要求。DNS SRV记录
数据类型[RFC2782]仍然可以在其他任何情况下使用
随附PTR和TXT记录的要求。
6.1。DNS TXT记录的通用格式规则
DNS TXT记录最长可达65535（0xFFFF）字节。总数
length由资源记录头中给出的长度表示
在DNS消息中。没有办法直接从数据中分辨出来
它有多长（例如，开始时没有长度计数，或者
最后终止NULL字节）。
注意，使用Multicast DNS [RFC6762]时最大包大小
是9000字节，包括IP头，UDP头和DNS消息
标题，对TXT记录的大小施加上限
大约8900字节。在实践中，DNS-SD的最大合理大小
TXT记录甚至比这小，通常最多几百
字节，如下面6.2节所述。
DNS TXT记录中的数据格式是一个或多个
字符串，在记忆中打包在一起，没有任何间隙或
字对齐的填充字节。
DNS TXT记录中每个组成字符串的格式为a
单长度字节，后跟0-255字节的文本数据。
TXT记录的这些格式规则在第3.3.14节中定义
DNS规范[RFC1035]并不特定于DNS-SD。
DNS-SD指定应存储哪些数据的附加规则
用于DNS-SD服务广告的那些组成字符串，
即，当用于描述使用PTR + SRV + TXT通告的服务时
本文件中规定的惯例。
不允许包含零字符串的空TXT记录[RFC1035]。
DNS-SD实现绝不能发出空的TXT记录。DNS-SD
客户必须将以下内容视为等效：
o包含单个零字节的TXT记录。
（即一个空字符串。）
o空（零长度）TXT记录。
（这不是严格合法的，但应该收到，应该
被解释为与单个空字符串相同。）
或没有TXT记录。
（即，NXDOMAIN或无错误 - 无应答响应。）
6.2。DNS-SD TXT记录大小
典型DNS-SD TXT记录的总大小旨在很小
- 200字节或更少。
在更多数据合理的情况下（例如，LPR打印[BJP]），
将总大小保持在400字节以下应该允许它适合a
单个512字节DNS消息[RFC1035]。
在极端情况下，即使这还不够，保持大小
低于1300字节的TXT记录应该允许它适合单个
1500字节的以太网数据包。
此处不推荐使用大于1300字节的TXT记录
时间。
请注意，一些以太网硬件供应商提供芯片组
多播DNS [RFC6762]卸载，以便计算机可以睡眠和
仍然可以在网络上发现。这种早期版本
芯片组有时非常有限：例如，有些是
（不明智地）限于处理不大于256字节的TXT记录
（这意味着具有更大TXT记录的LPR打印机服务确实如此
不行）。开发人员应该意识到这种现实世界的局限性，
并且应该理解即使是完美的硬件
能够具有更低限制的低功率和睡眠模式。
6.3。DNS-SD中使用的DNS TXT记录格式规则
DNS-SD使用DNS TXT记录来存储任意键/值对
传达有关指定服务的其他信息。每
键/值对被编码为其自身的组成字符串
DNS TXT记录，格式为“key = value”（不带引号）
分数）。第一个'='字符的所有内容都是关键（Section
6.4）。第一个'='字符后的所有内容到了结尾
string（包括后续的'='字符，如果有的话）是值
（第6.5节）。该值周围不需要引号，
即使它包含空格，'='字符或其他标点符号
分数。每个作者定义用于发现的DNS-SD配置文件
特定类型服务的实例应定义基本集
对该类型的服务有效的键/值属性。
在TXT记录中使用这种标准化的键/值语法
稍后通过定义来扩展这些基本定义更容易
其他命名属性。如果实现看到未知密钥
在服务TXT记录中，它必须默默地忽略它们。
目标主机名和服务的TCP（或UDP）端口号是
在SRV记录中给出。此信息 - 目标主机名和
端口号 - 不得使用中的键/值属性进行复制
TXT记录。
DNS-SD TXT记录的意图是传达少量的
有关服务的有用的其他信息。理想情况下，它应该
客户端无需检索此附加信息
在它可以有用地建立与服务的连接之前。为一个
精心设计的应用程序协议，即使没有信息
在TXT记录中，应该是可能的，只知道
与之通信的主机名，端口号和协议
听取过程然后执行版本或功能 -
协商确定任何进一步的选择或能力
服务实例。例如，连接到AFP（Apple
文件协议）服务器[AFP]通过TCP，客户端进入
协议与服务器交换以确定哪个版本的AFP
服务器实现以及哪些可选功能或功能（如果
任何）是可用的。
对于具有足够带内版本和功能的协议 -
谈判时，TXT记录中的任何信息都应视为a
性能优化 - 当客户端发现许多实例时
一项服务，TXT记录允许客户了解一些基本知识
有关每个实例的信息，而无需打开TCP
连接到每个服务实例并询问每个服务实例
分别。这样做时要小心，以确保
TXT记录中的信息与信息一致
将通过TCP连接的客户端检索。
有些旧协议不提供功能协商
能力，在这些情况下，传达必要的可能是有用的
TXT记录中的信息。例如，使用LPR打印时
[RFC1179]，LPR协议没有为客户端提供任何方法
确定特定的打印机是否接受PostScript，是什么
PostScript的版本等。在这种情况下，嵌入是合适的
这个信息在TXT记录[BJP]中，因为替代方案
会更糟 - 将书面指示传递给用户，
奥术手动配置“/ etc / printcap”文件等
关于为TXT记录定义什么键的工程决策
需要根据每种服务类型的具体情况来决定。
对于某些服务类型，适合传递信息
通过TXT记录以及（或代替）通过带内记录
应用程序协议中的通信。
6.4。DNS-SD密钥/值对中的密钥规则
关键必须至少是一个字符。DNS-SD TXT记录字符串
以'='字符开头（即，密钥丢失）必须是
默默地忽略了。
密钥不应超过九个字符。这是因为
为了网络，保持小包大小是有益的
效率。将DNS-SD与多播DNS结合使用时
[RFC6762]这很重要，因为多播流量尤其如此
在802.11无线网络[IEEEW]上很昂贵，但即使在使用时也是如此
传统的单播DNS，保持TXT记录较小有助于改善
响应将适合原始DNS 512字节的可能性
大小限制[RFC1035]。此外，DNS TXT的每个组成串
记录限制为255个字节，因此过长的密钥会减少
可用于该键值的空间。
键/值对中的键可以与单个字符一样短。
关键名称只需要在上下文中是唯一且明确的
定义它的服务类型。意图是一个关键名称
仅仅是机器可读的标识符，而不是人类可读的标识符
文章详细讨论了参数的用途，用
网页的URL，提供规范的更多详细信息。
为了便于开发和调试，使用密钥可能很有价值
名称是助记符文本名称，但过于冗长的键
浪费和低效，因此建议保留它们
到九个字符或更少。
键的字符必须是可打印的US-ASCII值（0x20-0x7E）
[RFC20]，不包括'='（0x3D）。
密钥中的空格是重要的，无论是前导，尾随还是中
中间 - 所以除非你真的想要，否则不要包含任何空格
那。
解释密钥时会忽略大小写，因此“papersize = A4”，
“PAPERSIZE = A4”和“Papersize = A4”都是相同的。
如果DNS-SD TXT记录字符串中没有“=”，则它是a
布尔属性，简单地标识为存在，没有值。
给定的密钥不应该在TXT记录中出现多次。该
这种简化规则的原因是为了促进创建
将TXT记录解析为内部数据的客户端库
结构（例如从中映射的哈希表或字典对象）
键值）然后使客户端可以使用该抽象
码。给定密钥可能不会出现多次的规则
简化这些抽象，因为它们不需要支持
为给定键返回多个值的情况。
如果客户端收到包含相同密钥的TXT记录
曾经，然后客户端必须默默地忽略除第一个之外的所有
该属性的出现。对于客户端实现
从头到尾处理DNS-SD TXT记录，放置键/值
使用密钥作为哈希表密钥对进入哈希表，这个
表示如果实现尝试添加新的键/值对
进入表并查找已存在相同键的条目，
然后应该静默地丢弃添加的新条目。
通过搜索来检索键/值对的客户端实现
请求密钥的TXT记录应从中搜索TXT记录
开始并简单地返回他们找到的第一个匹配键。
在检查给定密钥的TXT记录时，因此有四个
可能返回的结果类别：
*属性不存在（缺席）
*属性存在，没有价值
（例如，“passreq” - 此服务所需的密码）
*属性存在，空值
（例如，“PlugIns =” - 服务器支持插件，但没有插件
目前安装）
*属性存在，非空值
（例如，“PlugIns = JPEG，MPEG2，MPEG4”）
每个作者定义DNS-SD配置文件以发现实例
特定类型的服务应该定义这些解释
不同种类的结果。例如，对于某些键，可能存在
自然的真/假布尔解释：
*缺席暗示'假'
*现在暗示'真'
对于其他键，定义其他语义可能是明智的，例如
值/无值/未知：
*有价值的现在意味着价值。
（例如，四色喷墨打印机的“颜色= 4”）
或六色喷墨打印机的“颜色= 6”）
*空值表示'假'。
（例如，不是彩色打印机）
*缺席意味着'未知'。
（例如，打印服务器连接到某个未知的打印机，其中
打印服务器实际上不知道打印机是否颜色或
不是 - 这给用户带来了非常糟糕的体验，应该是
尽可能避免）
请注意，这是一个假设的例子，而不是实际的例子
DNS-SD网络打印机使用的键/值键，记录在案
在“Bonjour印刷规范”[BJP]中。
6.5。DNS-SD密钥/值对中的值规则
如果DNS-SD TXT记录字符串中有“=”，则表示一切
在第一个'='到字符串结尾之后是值。价值
可以包含任何八位值，包括'='。值绝不可以
用其他引号或任何类似的标点符号括起来;
任何引号，或前导或尾随空格，都是其中的一部分
值。
该值是不透明的二进制数据。通常是特定的价值
属性将是US-ASCII [RFC20]或UTF-8 [RFC3629]文本，但它是
合法的值是任何二进制数据。
通用调试工具通常应显示所有属性值
作为十六进制转储，伴随文本并显示UTF-8
这些字节的解释，除了属性之外
调试工具具有嵌入的知识，其价值是其他的
一种数据。
定义DNS-SD配置文件的作者不应该进行一般转换
使用十六进制将二进制属性数据类型转换为可打印文本
表示，Base-64 [RFC4648]或Unix到Unix（UU）编码，
仅仅是为了使数据看起来是可打印的文本
在通用调试工具中看到。这样做只会让人失望
TXT记录的大小，实际上不再生成数据
对于在通用调试工具中查看它的人来说，这是可以理解的。
6.6。示例TXT记录
下面的TXT记录包含三个语法上有效的键/值
字符串。（这些键/值对的含义，如果有的话）将取决于
关于有关服务的定义是
使用它们。）
-------------------------------------------------------
| 0x09 | key = value | 0x08 | 纸= A4 | 0x07 | passreq |
-------------------------------------------------------
6.7。版本日
建议定义DNS-SD配置文件的作者包括
“txtvers = x”形式的属性，其中“x”是十进制版本
US-ASCII [RFC20]文本中的数字（例如，“txtvers = 1”或“txtvers = 8”），
在他们的定义中，并要求它成为第一个键/值对
TXT记录。TXT记录中的此信息可用于
帮助客户保持与旧版本的向后兼容性
实现，如果有必要更改或更新
随着时间的推移。即使个人资料作者没有
预计任何未来不兼容的变化的必要性，有一个
TXT记录中的版本号应提供有用的保险
不兼容的变化变得不可避免[RFC6709]。客户应该
忽略TXT记录，其txtvers数字高于（或低于）
他们知道如何解释的版本。
请注意，txtvers标记中的版本号描述了该版本
管理定义键的规范和的含义
那些特定TXT记录的密钥，而不是版本的
随后将在客户端使用的应用程序协议
决定联系该服务。理想情况下，每个DNS-SD TXT记录
规范从txtvers = 1开始并永远保持这种状态。
可以通过定义旧客户端的新密钥来进行改进
默默地忽略。增加版本号的唯一原因是
如果后来发现旧的规范是如此可怕
打破了没有办法进行兼容的正向修订，所以
必须递增txtvers数字以告知所有旧客户端
他们甚至不应该试着理解这个新的TXT记录。
如果需要指明哪个版本号
服务实现的应用程序协议，推荐的密钥
这是“protovers”。
6.8。具有多个TXT记录的服务实例
一般而言，每个DNS-SD服务实例只有一个TXT
记录。但是，特定协议的DNS-SD是可能的
广告规范，声明它允许多个TXT
记录。在这种情况下，每个TXT记录描述不同的变体
使用相同的底层提供的相同逻辑服务
同一端口上的协议，由同一SRV记录描述。
有多个TXT记录来描述单个服务实例是
非常罕见的，迄今为止，已有数百个注册的DNS-SD
服务类型[SN]，只有一个使用此功能，即LPR
印刷[BJP]。在概念上打印机时使用此功能
支持多个逻辑队列名称，每个逻辑队列名称不同
队列名称实现不同的页面描述语言，例如
80列等宽纯文本，七位Adobe PostScript，八位
bit（“binary”）PostScript或某些专有页面描述
语言。当多个TXT记录用于描述多个时
相同底层服务（打印机）的逻辑LPR队列名称
在每个TXT记录中包括两个附加键：'qtotal'，其中
指定与此SRV关联的TXT记录的总数
记录和'优先级'，它给出了打印机的相对偏好
对于这个特定的TXT记录。然后客户选择最多
满足客户需求的首选TXT记录[BJP]。唯一的
使用多个TXT记录的原因是因为LPR协议
缺乏客户端的带内功能协商功能
服务器同意打印作业的数据表示，所以这
必须使用DNS-带外传送信息
SD TXT记录。未来的协议设计不应该遵循这一点
例如，通过模仿LPR打印协议的这种不足。
7.服务名称
服务实例名称的<Service>部分由一对组成
DNS标签，遵循已为SRV制定的惯例
记录[RFC2782]。
该对的第一个标签是下划线字符，后跟
服务名称[RFC6335]。服务名称标识了什么
服务和它用来执行它的应用程序协议。
对于使用TCP的应用程序，第二个标签是“_tcp”。
对于使用TCP以外的任何传输协议的应用程序，
第二个标签是“_udp”。这适用于所有其他运输
协议，包括用户数据报协议（UDP），流控制
传输协议（SCTP）[RFC4960]，数据报拥塞控制
协议（DCCP）[RFC4340]，Adobe的实时媒体流协议
（RTMFP）等。回想起来，也许SRV规范应该如此
没有使用“_tcp”和“_udp”标签，而应该使用
使用单个标签“_srv”来创建DNS的子域
这个用途的命名空间，但该规范已经发布
并部署。在这一点上，改变没有任何好处
既定的做法。虽然“_srv”可能在美学上比
“_udp”，它不是用户可见的字符串，只需要所有
协议方面是（i）它是可以形成DNS的标签
授权点，以及（ii）它是短的，所以它不需要
数据包中的空间太大，在这方面“_udp”或
“_srv”同样出色。因此，对TCP使用“_tcp”是有意义的
所有其他传输协议的基础服务和“_udp” - 其中
实际上，在今天的世界中，通常是封装在UDP上 - 而不是
而不是为每个新的传输协议定义一个新的子域。
请注意，除了使用“_udp”标签之外的所有协议
TCP仅适用于DNS-SD服务广告，即服务
使用此处指定的PTR + SRV + TXT约定进行广告宣传
文献。一般而言，这不是SRV记录的要求。其他
与DNS-SD无关的规范
与DNS-SD记录的互操作不受任何约束
DNS-SD如何工作只是因为他们也使用DNS SRV记录
数据类型[RFC2782]; 他们可以自由指定自己的命名
适当的公约。
服务名称[RFC6335]的规则声明它们可能不再存在
超过十五个字符（不包括强制性下划线），
只包含字母，数字和连字符，必须开始和结束
用字母或数字，不得包含连续的连字符，和
必须至少包含一个字母。要求包含在
至少一个字母是禁止服务名称，如“80”或
“6000-6063”，可能被误解为端口号或端口
数字范围。虽然大写和小写字母都可以
用于记忆清晰度，为了比较目的忽略大小写，
所以字符串“HTTP”和“http”指的是相同的服务。
明智地选择服务名称很重要，而选择则不然
总是尽可能明显。
在许多情况下，服务名称只是命名和引用 -
使用的有线消息格式和语义。FTP是“ftp”，IPP
打印是“ipp”，依此类推。
但是，通常“借用”现有协议并重新定位
它是一项新任务。这是完全合情合理的工程
实践，但这并不意味着新协议正在提供
与旧的语义服务相同的语义服务，即使它借用了相同的语义服务
消息格式。例如，网络音乐共享协议
iTunes在Macintosh和Windows上实现的是基于“HTTP”
获取“命令。但是，这不是*意味着它是明智的或
通过连接来尝试访问其中一个音乐服务器很有用
它使用标准的Web浏览器。因此，DNS-SD服务
iTunes宣传（和浏览）是“_daap._tcp”（数字音频
访问协议），而不是“_http._tcp”。
如果iTunes宣传它提供“_http._tcp”服务，
这将导致iTunes服务器出现在传统的网络中
浏览器（Safari，Camino，OmniWeb，Internet Explorer，Firefox，
Chrome等等，自iTunes音乐库以来一直没什么用处
不提供包含人类可读内容的HTML页面
浏览器可以显示。
同样，如果iTunes要浏览“_http._tcp”服务，那就是
会导致它发现通用的Web服务器，例如嵌入式服务器
像打印机这样的设备中的Web服务器，从那以后用处不大
打印机通常没有太多的音乐可供选择。
类似地，Sun Microsystems的网络文件系统（NFS）是建立在上面的
Sun Microsystems的远程过程调用（Sun RPC）机制的顶部，
但这并不意味着NFS服务器做广告是有意义的
它提供“Sun RPC”服务。同样，微软的服务器
消息块（SMB）文件服务建立在运行Netbios之上
通过IP，但这并不意味着它对SMB文件服务器有意义
宣传它提供“Netbios-over-IP”服务。DNS-SD
服务名称需要封装“what”（语义）
以及该服务的“如何”（协议实现）
两者的知识对于客户使用该服务是必要的
有意义。仅仅宣传服务是建立在上面的
如果客户端不知道服务的作用，则Sun RPC没有用。
另一个常见问题是广告所宣传的服务类型
iTunes应为“_daap._http._tcp”。这也是不正确的。
同样，协议设计者实现网络服务
碰巧使用简单对象访问协议[SOAP]不应该
我不得不在服务名称的某处出现“_soap”。
这里的一部分混淆是存在“_tcp”或“_udp”
在服务实例名称的<Service>部分引导人们
假设<Service>的可见结构应该反映出来
协议如何实施的私人内部结构。
这是不正确的。所需要的只是服务
由一些独特的不透明服务名称标识。提供服务
名称是英文文本，至少对内容略有描述
服务可能很方便，但绝不是必需的。
7.1。选择性实例枚举（子类型）
本文档不会尝试定义复杂的（例如，
图灵完整，甚至正则表达式）查询语言
服务发现，我们也不相信一个是必要的。
但是，在一些有限的情况下缩小集合
结果可能有用。例如，许多网络打印机提供
基于Web的用户界面，用于管理和管理，使用
HTML / HTTP。想要发现所有广告网络的Web浏览器
页面发出“_http._tcp。<Domain>”的查询。另一方面，
在某些情况下，用户希望专门管理打印机，而不是
一般来说，发现网页，这很好地适应了这一点。
在这种情况下，我们定义“_http._tcp”的“_printer”子类型，和
仅发现广告中具有该页面的子集
子类型属性，Web浏览器发出查询
“_printer._sub._http._tcp。<域>”。
Mac OS X 10.5“Leopard”上的Safari Web浏览器以及后来的用途
以这种方式的亚型。如果同时发现“_http._tcp”服务
通过“_printer._sub._http._tcp”浏览并通过“_http._tcp”浏览
然后它会显示在Safari UI的“打印机”部分中。如果一个
只有通过“_http._tcp”浏览即可发现服务
显示在Safari UI的“网页”部分。这可以看出来
通过在Mac OS X上使用以下命令宣传两个“假”
服务。服务实例“A网页”显示在
Safari的Bonjour列表的“网页”部分，而实例
“打印机的网页”显示在“打印机”部分中。
dns-sd -R“一个网页”_http._tcp local 100
dns-sd -R“打印机的网页”_http._tcp，_printer local 101
请注意，广告网页的服务实例名称是
通过使用子类型保持不变 - 它仍然是某种形式
“Server._http._tcp.example.com。”和广告网页是
仍可使用标准浏览查询获取服务
输入“_http._tcp”。HTTP服务器SRV记录的子域
已注册定义HTTP服务器名称所在的命名空间
很独特。基本的附加子类型（例如，“_printer”）
服务类型（例如，“_ http._tcp”）用于允许客户端查询
一组较窄的结果，而不是创建更多的命名空间。
使用DNS区域文件语法，服务实例“A网页”是
使用一个PTR记录做广告，而实例“打印机的网络
页面“使用两个来宣传：主要服务类型和
额外的子类型。即使是“A打印机的网页”服务
是两种不同的广告方式，两种PTR记录都是指名称
相同的SRV + TXT记录对：
; 一个PTR记录广告“A网页”
_http._tcp.local。PTR A \ 032web \ 032page._http._tcp.local。
; 两个不同的PTR记录广告“打印机的网页”
_http._tcp.local。PTR A \ 032printer的\ 032web \ 032page._http._tcp.local。
_printer._sub._http._tcp.local。
PTR A \ 032printer的\ 032web \ 032page._http._tcp.local。
当需要不同种类的亚型时，亚型是合适的
客户端能够在两个级别浏览服务
粒度。在上面的示例中，我们描述了两类HTTP
客户：对所有Web感兴趣的常规Web浏览客户端
页面，以及想要的特定打印机管理工具
仅发现打印机宣传的Web UI页面。HTTP的集合
两种情况下，网络上的服务器都是相同的; 不同的是
一些客户希望发现所有客户，而其他客户
只想找到目的是打印机的HTTP服务器子集
管理。
子类型仅适用于两级场景，例如此类
一，一些客户希望找到一整套服务
给定类型，同时其他客户只想找到一些
子集。一般来说，如果没有想要查找的客户
整套，然后使用它既不必要也不可取
子类型机制。如果所有客户都在浏览特定的内容
然后，子类型，并且不存在浏览父类型的客户端
应该是表示逻辑服务的新服务名称
定义，软件应该只是做广告和浏览
特定服务类型直接。特别是，因为一个
特定网络服务恰好以某些方式实现
其他底层协议，如HTTP，Sun RPC或SOAP，并不意味着
将该服务定义为的子类是明智的
“_http”，“_ sunpc”或“_soap”。那只会在那里有用
是一类客户，明智地说，“我想要
发现网络上的服务，我不关心它做什么，如
只要它使用SOAP XML RPC机制就可以了。“
但是，子类型字符串不需要以下划线开头
他们经常这样做。与TXT记录键/值对一样，列表为
可能的子类型，如果有的话（包括是否有一些或全部以...开头）
每个基本单独定义和指定下划线
服务类型。
子类型字符串（例如，上例中的“_printer”）可以是
使用任意8位数据值构造。在很多情况下这些
数据值可以是文本的UTF-8 [RFC3629]表示，甚至是
（如上例所示）纯ASCII [RFC20]，但它们没有
成为。但请注意，即使使用任意8位数据也是如此
子类型字符串，DNS名称比较仍然不区分大小写，所以
（例如）将考虑字节值0x41和0x61
等效于子类型比较的目的。
7.2。服务名称长度限制
如上所述，允许服务名称不超过
十五个字符长。这种限制的原因是为了保存
域名中的字节，供网络管理员使用
（选择服务域名）和最终用户（选择
实例名称）。
完全限定的域名最长可达255个字节，加上一个
最后终止根标签的字节。网站域名
DNS-SD使用以下形式：
<sn> ._ tcp。<servicedomain>。<parentdomain>。
<实例>。<sn> ._ tcp。<servicedomain>。<parentdomain>。
<sub> ._ sub。<sn> ._ tcp。<servicedomain>。<parentdomain>。
第一个示例显示了用于PTR查询的名称。第二
显示服务实例名称，即服务SRV的名称
和TXT记录。第三个显示子类型浏览名称，即
指向服务实例名称的PTR记录的名称（参见章节
7.1，“选择性实例枚举”）。
服务名称<sn>最多可以包含15个字节，加上下划线和
长度字节，共计17个。包括“_udp”或“_tcp”
及其长度字节，这使得22个字节。
实例名称<Instance>最多可以为63个字节。包括
名称存储在a中时DNS格式使用的长度字节
数据包，即64个字节。
使用子类型时，子类型标识符最多允许为63
字节，加上长度字节，使得64.包括“_sub”及其
长度字节，这使得69个字节。
通常，DNS-SD服务记录被放置在其子域中
拥有公司现有域名。由于这些子域名
旨在通过图形用户界面访问，而不是
在命令行上输入，它们通常很长且具有描述性。
包括长度字节，用户可见的服务域可能是up
到64个字节。
在我们可用的255个字节中，我们现在占69 + 22 + 64 = 155
字节。这留下100个字节以容纳组织
现有域名<parentdomain>。与Multicast DNS一起使用时，
<parentdomain>是“local。”，很容易适合。与父母一起使用时
域数为100字节或更少，DNS-SD的全部功能是
没有限制。与父域名一起使用时间更长
超过100字节，协议风险超过最大可能
域名长度，导致失败。在这种情况下，小心
选择短的<servicedomain>名称可以帮助避免溢出。如果
<servicedomain>和<parentdomain>太长，然后服务
具有长实例名称的实例将无法被发现或
可解析的，以及使用长子类型名称的应用程序
失败。
由于此约束，我们选择将服务名称限制为15
字符或更少。允许更多的字符不会增加
协议的表现力和不必要的减少
可以安全使用的最大<parentdomain>长度。
请注意，<Instance>名称长度会影响最大数量
可以在给定中发现的给定类型的服务
<servicedomain>。可以发送的最大单播DNS响应
（通常使用TCP，而不是UDP）是64 kB。使用DNS名称压缩，
服务实例枚举PTR记录需要2个字节
（压缩）名称，加上类型，类，ttl和rdata的10个字节
长度。PTR记录的rdata最多需要64个字节
<Instance>名称的一部分，加上2个字节用于名称压缩
指向公共后缀的指针，总计最多78个字节。
这意味着使用最大大小的<Instance>名称，最多839个
可以在给定的服务中发现给定服务类型的实例
<servicedomain>。
多播DNS聚合响应数据包，因此它没有
相同的硬限制，但在实践中，它也可用于多达几个
一百个给定服务类型的实例，但可能不是
数千人。
但是，在平面列表中显示甚至100个实例也可能
许多对典型用户有帮助。如果网络超过100
给定服务类型的实例，它可能适合
通过逐层构建，将这些服务划分为逻辑子域
按部门等
8.旗舰命名
在某些情况下，可能有几种可用的网络协议
所有人都执行大致相同的逻辑功能。例如，
打印世界有lineprinter（LPR）协议[RFC1179]和
互联网打印协议（IPP）[RFC2910]，这两者都有原因
以相同的方式从打印机发出的打印纸张。在
此外，许多打印机厂商都发送了自己的专有页面
TCP连接到TCP端口的描述语言（PDL）数据
9100，这里统称为“pdl-datastream”
协议。在理想的世界中，我们只有一个网络打印
协议，没有人感觉到它会足够好
迫切需要发明一个不同的。但是，在实践中，
确实存在多个传统协议和服务发现协议
必须适应这一点。
许多打印机实现所有三种打印协议：LPR，IPP和
PDL-数据流。为了客户的利益，可能只会说一个
在这些协议中，所有三个都被公布了。
但是，有些客户可能会实现其中的两个或全部三个
打印协议。当客户端查找所有三种服务类型时
在网络上，它将找到三种不同的服务 - 一种LPR
服务，IPP服务和pdl-datastream服务 - 所有这些
导致打印的纸张从同一物理打印机发出。
在这种情况下，多个协议都有效地执行
同样的功能，客户端可以浏览它的所有服务类型
支持并在一个中显示所有发现的实例名称
汇总清单。更多地发现相同的实例名称
不止一次，因为该实体支持多种服务类型
（例如，一台打印机实现多种打印协议）
应该抑制重复项，并且名称只应出现
一旦在列表中。当用户表明他们想要打印时
给定命名打印机，打印客户端负责选择
哪种可用协议最能达到预期效果
效果，例如，不需要用户制作手册
LPR和IPP之间的选择。
如上所述，这一切都很有效。但是，考虑一下
案例：一些仅支持IPP打印的未来打印机，以及
其他一些仅支持pdl-datastream打印的未来打印机。
不同服务类型的名称空间是故意不相交的
（能够同时拥有文件服务器是可以接受的，也是可取的
称为“销售部门”和称为“销售部门”的打印机。
然而，在通常情况下，不希望允许两个
不同的打印机都被称为“销售部门”
因为这两台打印机实现了不同的打印协议
为了防止这种情况，当有两个或更多网络时
执行大致相同逻辑功能的协议，其中之一
协议被宣布为相关车队的“旗舰”
协议。通常，旗舰协议是最古老的和/或
最着名的集合协议。
如果设备没有实现旗舰协议，那么它就是
创建占位符SRV记录（优先级= 0，权重= 0，端口= 0，
具有该名称的target host =设备的主机名。如果，当它
试图创建这个SRV记录，它发现了一条记录
同名已存在，然后它知道这个名字已经存在
由实现至少一个协议的其他实体采取的
从舰队，它必须选择另一个。如果没有SRV记录
存在，那么创造它的行为就是对这个名称的主张
同一协议组中的未来设备将检测到冲突
当他们试图使用它时。
注意：与Multicast DNS [RFC6762]一起使用时，目标主机字段
占位符SRV记录不能是空根标签。该
SRV记录需要包含一个真实的目标主机名
要运行的多播DNS冲突检测规则。如果两个不同
设备是使用null创建占位符SRV记录
目标主机名（只是根标签），然后是两个SRV记录
可以看出是一致的，不会发现任何冲突。
通过为班级定义一个共同的着名旗舰协议，
未来可能甚至不了解彼此协议的设备
建立一个共同点，他们可以协调验证
名字的独特性。
没有创建PTR记录来宣传空旗舰的存在
SRV记录，因为它们不代表真正的服务
广告，因此不是（也不应该）通过发现
服务实例枚举（浏览）。
9.服务类型枚举
一般来说，普通客户对查找每个*都不感兴趣
网络上的服务，只是客户端知道的服务
使用。
但是，对于问题诊断和网络管理工具，它可能会
对网络管理员有用，可以找到广告列表
网络上的服务类型，即使这些服务名称是公正的
不透明的标识符，并没有特别提供信息。
为此，定义了一个特殊的元查询。DNS查询
名为“_services._dns-sd._udp。<Domain>”的PTR记录产生一个
一组PTR记录，其中每个PTR记录的rdata是两个 -
标签<服务>名称，加上相同的域名，例如，
“_http._tcp。<域>”。包括PTR中的域rdata允许
在单播DNS响应中稍微改善名称压缩，但是
只有前两个标签与服务目的相关
类型枚举。然后可以使用这些双标签服务类型
构造后续服务实例枚举PTR查询
此<Domain>或其他，以发现该服务类型的实例。
10.使用信息填充DNS
服务的PTR，SRV和TXT记录如何进入DNS
超出了本文档的范围，但是，为了说明
目的，这里给出一些例子。
在某些网络上，管理员可能会手动输入记录
进入名称服务器的配置文件。
网络监视工具可以输出标准区域文件
读入传统的DNS服务器。例如，一个可以的工具
使用AppleTalk NBP可以找到联网的PostScript激光打印机
找到打印机列表，与每个打印机进行通信以查找其IP
地址，PostScript版本，安装选项等，然后编写
输出描述这些打印机及其功能的DNS区域文件
使用DNS资源记录。然后可以获得该信息
到仅实现DNS-SD但不支持AppleTalk NBP的纯IP客户端。
打印机管理器设备，了解打印机上的打印机
网络通过其他一些管理协议也可以输出一个
区域文件或使用DNS更新[RFC2136] [RFC3007]。
或者，打印机管理器设备可以实现足够的
DNS协议，它能够直接回答DNS查询，和
示例公司的主DNS服务器可以委托
“_ipp._tcp.example.com。” 子域到打印机管理器设备。
IP打印机可以使用动态DNS更新[RFC2136] [RFC3007]
自动注册自己的PTR，SRV和TXT记录
DNS服务器。
Zeroconf打印机在本地链路上应答多播DNS查询
他们自己的PTR，SRV和TXT名称以“.local”结尾。[RFC6762]。
11.浏览和注册域的发现（域枚举）
基于DNS的服务发现的动机之一是启用a
访问客户端（例如，配备Wi-Fi的[IEEEW]笔记本电脑，
到达新网络发现的平板电脑或移动电话
该网络上提供哪些服务，无需任何手册
组态。无需手动即可发现服务的逻辑
配置是一个好主意，也决定了发现
建议注册和浏览域名，无需手动
配置也是一个好主意。
此发现使用DNS查询，使用单播或
组播DNS。为此目的保留了五个特殊的RR名称：
b._dns-sd._udp。<域>。
db._dns-sd._udp。<域>。
r._dns-sd._udp。<域>。
dr._dns-sd._udp。<域>。
lb._dns-sd._udp。<域>。
通过对这些名称执行PTR查询，客户可以学习，
分别：
o建议浏览的域列表。
o用于浏览的单个推荐默认域。
o建议使用注册服务的域列表
动态更新。
o用于注册服务的单个推荐默认域。
o“遗留浏览”或“自动浏览”域。
精心设计的客户端应用程序，提供选择
域名给用户使用从前四个学到的答案
查询以发现要呈现的域。相比之下，很多
当前应用程序浏览时未指定显式域，
允许操作系统自动选择
适合他们的域名。这是为了这一类
提供“自动浏览”查询的应用程序
允许网络管理员与客户端通信
操作系统应该自动使用哪个域
这些应用。
这些域名纯粹是建议性的。客户或用户可以免费使用
注册服务和/或在任何域中浏览。这些目的
特殊查询是允许软件创建用户界面
向用户显示建议选项的有用列表
用户可以做出明智的选择，或忽略所提供的选择
建议并手动输入自己的选择。
域枚举查询名称的<domain>部分可能是
“本地。” （意思是“使用链接本地多播执行查询”）或
它可以通过一些其他机制学习，例如DHCP
“域”选项（选项代码15）[RFC2132]，DHCP“域搜索”
选项（选项代码119）[RFC3397]或IPv6路由器广告
选项[RFC6106]。
查询名称的<domain>部分也可以派生不同
从主机的IP地址开始。主机获取其IP地址和
计算该地址及其子网掩码的逻辑AND
导出子网的“基地”地址（“网络地址”）
该子网，或等效地，“全零”主机的IP地址
该子网上的地址）。然后它构建传统的DNS
“反向映射”名称对应于该基址，并使用
作为所描述查询的名称的<domain>部分
以上。例如，如果主机的地址为192.168.12.34，则为
子网掩码255.255.0.0，然后是子网的“基址”
192.168.0.0，并发现推荐的自动浏览
对于此子网上的设备的域，主机发出DNS PTR查询
名称为“lb._dns-sd._udp.0.0.168.192.in-addr.arpa”。
等效地址派生的域枚举查询也应该是
完成主机的IPv6地址。
地址派生的域枚举查询不应该完成
IPv4链路本地地址[RFC3927]或IPv6链路本地地址
[RFC4862]。
复杂的客户端可以执行域枚举查询
“本地。” 在一个或多个单播域中，使用名称派生
和地址派生的查询，然后向用户呈现
综合结果，汇总从所有人收到的信息
源。
12. DNS附加记录生成
DNS具有DNS服务器可以放置的效率特征
DNS消息的附加部分中的其他记录。
这些附加记录是客户没有的记录
显式请求，但服务器有合理的理由期望
客户可能很快会要求他们，所以包括他们可以
使客户端不必发出其他查询。
本节建议应该生成哪些附加记录
提高单播和多播DNS-SD的网络效率
响应。
请注意，虽然服务器应该添加这些附加记录
效率目的，与所有DNS附加记录一样，它是
客户有责任确定是否信任他们。
一般来说，存根解析器与单个递归通信
所有查询的名称服务器都会信任他们收到的所有记录
从那个递归名称服务器（他们会问谁？）。
与多个权威名称对话的递归名称服务器
服务器应验证他们从给定的任何记录
权威名称服务器是该服务器的“bailiwick”，和
如果没有，请忽略它们
客户端必须能够与DNS服务器正常运行
（和多播DNS响应程序）无法生成这些额外的
通过发出任何进一步的后续查询自动记录
他们需要的记录。附加记录生成规则
建议本节用于提高网络效率，但是
不是正确性所必需的。
12.1。PTR记录
包含DNS-SD服务实例枚举或选择性时
实例枚举（子类型）PTR记录在响应数据包中，
服务器/响应者应该包括以下附加记录：
o在PTR rdata中命名的SRV记录。
o在PTR rdata中命名的TXT记录。
o SRV rdata中命名的所有地址记录（类型“A”和“AAAA”）。
12.2。SRV记录
在响应数据包中包含SRV记录时，
服务器/响应者应该包括以下附加记录：
o SRV rdata中命名的所有地址记录（类型“A”和“AAAA”）。
12.3。TXT记录
在响应数据包中包含TXT记录时，不需要额外的
记录是必需的。
12.4。其他记录类型
在响应地址查询或其他记录类型时，没有新的
本文档建议使用其他记录。
13.工作实例
使用未改性的标准制备以下实施例
在GNU / Linux上运行的nslookup和标准的未修改BIND。
注意：在实际产品中，获取并呈现此信息
用户使用图形网络浏览器软件，而不是命令行
工具。但是，如果您愿意，可以自己尝试这些示例
在您阅读时，使用已经可用的nslookup命令
大多数Unix机器。
13.1。从dns-sd.org上宣传了哪些网页？
nslookup -q = ptr _http._tcp.dns-sd.org。
_http._tcp.dns-sd.org
name = Zeroconf._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Multicast \ 032DNS._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Service \ 032Discovery._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Stuart的\ 032Printer._http._tcp.dns-sd.org
答：有四种，称为“Zeroconf”，“多播DNS”，“服务
发现“和”斯图亚特的打印机“。
请注意，nslookup将空格转义为“\ 032”以用于显示目的，但是
图形DNS-SD浏览器不应该。
13.2。有哪些打印机配置网页？
nslookup -q = ptr _printer._sub._http._tcp.dns-sd.org。
_printer._sub._http._tcp.dns-sd.org
name = Stuart的\ 032Printer._http._tcp.dns-sd.org
答：“Stuart的打印机”是网络的Web配置UI
打印机。
13.3。如何访问名为“Service Discovery”的网页？
nslookup -q = any“Service \ 032Discovery._http._tcp.dns-sd.org”。
服务\ 032Discovery._http._tcp.dns-sd.org
priority = 0，weight = 0，port = 80，host = dns-sd.org
服务\ 032Discovery._http._tcp.dns-sd.org
text =“txtvers = 1”“path = /”
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org互联网地址= 64.142.82.154
ns1.dns-sd.org互联网地址= 64.142.82.152
答：您需要连接到dns-sd.org端口80，路径“/”。
还给出了dns-sd.org的地址（64.142.82.154）。
14. IPv6注意事项
IPv6与IPv4的差别很小。
SRV记录的目标主机的地址由
适当的IPv6“AAAA”地址记录而不是（或另外
to）IPv4“A”记录。
使用名称执行基于地址的域枚举查询
在IPv6反向映射树下，与IPv4不同
反向映射树，并在其中有更长的名称。
15.安全考虑因素
由于DNS-SD只是如何命名和使用记录的规范
在现有的DNS系统中，它没有特定的附加安全性
除已经适用于DNS查询的要求之外的要求
和DNS更新。
对于DNS查询，DNS安全扩展（DNSSEC）[RFC4033]应该是
用于信息真实性很重要的地方。
对于DNS更新，通常应该使用安全更新[RFC2136] [RFC3007]
用于控制哪些客户端有权更新DNS
记录。
16. IANA注意事项
IANA管理唯一服务名称的名称空间[RFC6335]。
当协议服务广告规范包括子类型时，
这些应记录在相关的协议规范中
和/或发送给IANA的注册请求的“注释”字段。
如果在协议之后新的子类型变得相关
规范已经发布，可以通过请求进行记录
IANA将其添加到“注释”字段中。例如，供应商
网络打印机使用它来宣传其嵌入式Web服务器
子类型_printer。这允许打印机管理客户端浏览
通过浏览_printer，仅用于与打印机相关的Web服务器
亚型。而_http._tcp的_printer子类型的存在
它与HTTP协议规范没有直接关系
用于在IANA注册表中记录此用法以帮助避免
另一个开发者社区无意中使用了相同的子类型
用于不同目的的字符串。可能的子类型的命名空间
对于每种不同的服务类型是分开的。例如，
_http._tcp的_printer子类型的存在并不意味着这一点
_printer子类型已定义或对任何其他子类型有任何意义
服务类型。
当IANA记录服务名称注册时，如果是新应用程序
协议是概念上复制现有功能的协议
一个较旧的协议，实施者希望旗舰命名
第8节中描述的行为，然后注册人应该要求
IANA在“备注”中记录旗舰协议的名称
新注册领域。例如，注册
“ipp”和“pdl-datastream”都将“打印机”作为旗舰
此系列打印相关协议的名称。
17.致谢
已经探索了本文档中描述的概念，
在Ran Atkinson，Richard的帮助下开发并实施
Brown，Freek Dijkstra，Ralph Droms，Erik Guttman，Pasi Sarolahti，
Pekka Savola，Mark Townsley，Paul Vixie，Bill Woodcock和其他人。
特别感谢Bob Bradley，Josh Graessley，Scott Herscher，
Rory McGuire，Roger Pantos和Kiren Sekar表现出色
贡献。
18.参考文献
18.1。规范性参考文献
[RFC20] Cerf，V。，“用于网络交换的ASCII格式”，RFC 20，
1969年10月。
[RFC1033] Lottor，M。，“域管理员操作指南”，RFC
1987年11月1033
[RFC1034] Mockapetris，P。，“域名 - 概念和
设施“，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris，P。，“域名 - 实施和
规范“，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner，S。，“用于RFC指示的关键词
要求等级“，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen，A.，Vixie，P。和L. Esibov，“A DNS RR for
指定服务的位置（DNS SRV）“，RFC 2782，
2000年2月。
[RFC3492] Costello，A。，“Punycode：Unicode的Bootstring编码
适用于应用程序中的国际化域名
（IDNA）“，RFC 3492，2003年3月。
[RFC3629] Yergeau，F。，“UTF-8，ISO的转换格式
10646“，STD 63，RFC 3629，2003年11月。
[RFC3927] Cheshire，S.，Aboba，B。和E. Guttman，“Dynamic
配置IPv4链路本地地址“，RFC 3927，
2005年5月。
[RFC4862] Thomson，S.，Narten，T。和T. Jinmei，“IPv6 Stateless
地址自动配置“，RFC 4862，2007年9月。
[RFC5198] Klensin，J。和M. Padlipsky，“网络的Unicode格式
Interchange“，RFC 5198，2008年3月。
[RFC5890] Klensin，J。，“Internationalized Domain Names for
应用程序（IDNA）：定义和文档框架“，
RFC 5890，2010年8月。
[RFC6335] Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M。和S.
柴郡，“互联网号码分配机构（IANA）
服务名称和管理程序
传输协议端口号注册表“，BCP 165，RFC
6335，2011年8月。
18.2。信息参考
[法新社] Mac OS X开发者库，“Apple文件协议
编程指南“，<http://developer.apple.com/
文档/网络/概念/ AFP />。
[BJ] Apple Bonjour开源软件，
<http://developer.apple.com/bonjour/>。
[BJP]你好印刷规范，
<https://developer.apple.com/bonjour/
打印规格/ bonjourprinting-1.0.2.pdf>。
[IEEEW] IEEE 802 LAN / MAN标准委员会，
<http://standards.ieee.org/wireless/>。
[NIAS] Cheshire，S。，“发现抽象的命名实例
使用DNS的服务“，正在进行中，2001年7月。
[NSD]“NsdManager | Android Developer”，2012年6月，
<http://developer.android.com/reference/android/
净/ NSD / NsdManager.html>。
[RFC1179] McLaughlin，L。，“Line printer daemon protocol”，RFC 1179，
1990年8月。
[RFC2132] Alexander，S。和R. Droms，“DHCP选项和BOOTP
“供应商扩展”，RFC 2132，1997年3月。
[RFC2136] Vixie，P.，Ed。，Thomson，S.，Rekhter，Y。和J. Bound，
“域名系统中的动态更新（DNS更新）”，
RFC 2136，1997年4月。
[RFC2181] Elz，R。和R. Bush，“对DNS的澄清
规范“，RFC 2181，1997年7月。
[RFC2910] Herriot，R.，Ed。，Butler，S.，Moore，P.，Turner，R。，and
J. Wenn，“Internet Printing Protocol / 1.1：Encoding and
Transport“，RFC 2910，2000年9月。
[RFC4960] Stewart，R.，Ed。，“Stream Control Transmission Protocol”，
RFC 4960，2007年9月。
[RFC3007] Wellington，B。，“安全域名系统（DNS）动态
更新“，RFC 3007，2000年11月。
[RFC4340] Kohler，E.，Handley，M。和S. Floyd，“数据报
拥塞控制协议（DCCP）“，RFC 4340，March
2006.
[RFC3397] Aboba，B。和S. Cheshire，“动态主机配置
协议（DHCP）域搜索选项“，RFC 3397，11月
2002.
[RFC4033] Arends，R.，Austein，R.，Larson，M.，Massey，D。和S.
Rose，“DNS安全性介绍和要求”，RFC
2005年3月4033
[RFC4648] Josefsson，S。，“Base16，Base32和Base64数据
编码“，RFC 4648，2006年10月。
[RFC4795] Aboba，B.，Thaler，D。和L. Esibov，“Link-local
多播名称解析（LLMNR）“，RFC 4795，1月
2007.
[RFC6106] Jeong，J.，Park，S.，Beloeil，L。和S. Madanapalli，
“DNS的IPv6路由器广告选项
配置“，RFC 6106，2010年11月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
“了解Apple的Back to My Mac（BTMM）服务”，
RFC 6281，2011年6月。
[RFC6709] Carpenter，B.，Aboba，B.，Ed。和S. Cheshire，“Design
协议扩展的注意事项“，RFC 6709，
2012年9月。
[RFC6760] Cheshire，S。和M. Krochmal，“要求a
替换AppleTalk名称绑定协议的协议
（NBP）“，RFC 6760，2013年2月。
[RFC6762] Cheshire，S。和M. Krochmal，“Multicast DNS”，RFC 6762，
2013年2月。
[SN] IANA，“服务名称和传输协议端口号”
登记处“，<http://www.iana.org/assignments/
服务的名称，端口号/>。
[SOAP] Mitra，N。，“SOAP Version 1.2 Part 0：Primer”，W3C
2003年6月24日提出的建议，
<http://www.w3.org/TR/2003/REC-soap12-part0-20030624>。
[Unicode6] Unicode联盟。Unicode标准，版本
6.0.0，（Mountain View，CA：Unicode Consortium，2011。
ISBN 978-1-936213-01-6）
<http://www.unicode.org/versions/Unicode6.0.0/>。
[ZC] Cheshire，S。和D. Steinberg，“零配置
网络：权威指南“，O'Reilly Media，Inc。，
国际标准书号0-596-10100-7，2005年12月。
附录A.使用DNS作为服务发现基础的基本原理
多年来，已经提出了许多建议的网络方法
使用IP进行服务发现，但没有一个在IP无处不在
市场。当然没有人取得任何接近
无处不在的今天DNS服务器，客户端和其他部署
基础设施。
使用DNS作为服务发现基础的优势在于
它利用那些现有的服务器，客户端，协议，
基础设施和专业知识。现有网络分析工具
已经知道如何解码和显示网络的DNS数据包
调试。
对于诸如Zeroconf环境之类的ad hoc网络，点对点
多播协议是合适的。使用DNS-SD运行
多播DNS [RFC6762]提供零配置ad hoc服务
发现，同时保持DNS-SD语义和记录类型
这里描述。
在较大的网络中，大量的企业级IP多播
交通可能不太理想，所以任何可靠的服务发现
用于大型网络的协议必须提供一些便利
在中央服务器（或服务器）上聚合注册和查找
而不是专门使用多播。这需要一些
要写入的服务发现聚合服务器软件，
调试，部署和维护。这也需要一些服务
要实施和部署的发现注册协议
客户端向中央聚合服务器注册。实质上
每个拥有IP网络的公司都已经运行了DNS服务器和DNS
已经有了动态注册协议[RFC2136] [RFC3007]。
鉴于几乎每家公司都必须经营和运营
无论如何都要维护一个DNS服务器，利用它是有意义的
这种专业知识，而不是必须学习，操作和维护
不同的服务注册服务器。应该再次强调
使用相同的软件和协议并不一定意味着
使用相同的物理硬件。DNS-SD服务
发现功能不必由同一块提供
目前提供公司DNS名称服务的硬件。
可以委派“_tcp。<Domain>”和“_udp。<Domain>”子域
到另一件硬件。但是，即使是DNS-SD
服务由不同的硬件提供，它是
仍然是同样熟悉的DNS服务器软件
配置文件语法，相同的日志文件格式等。
服务发现需要能够提供适当的安全性。
DNS已经存在安全机制[RFC4033]。
综上所述：
服务发现需要中央聚合服务器。
DNS已经有一个：DNS服务器。
服务发现需要服务注册协议。
DNS已经有一个：DNS动态更新。
服务发现需要查询协议。
DNS已经有一个：DNS查询。
服务发现需要安全机制。
DNS已经具有安全机制：DNSSEC。
服务发现需要ad hoc网络的多播模式。
将DNS-SD与多播DNS结合使用可提供此功能，
使用对等多播而不是DNS服务器。
使用每个网络的现有软件更有意义
需要，而不是仅仅部署整个并行系统
用于服务发现。
附录B.服务实例名称组件的排序
关于为什么使用DNS命名服务存在疑问
服务实例表单的名称：
服务实例名称= <实例>。<服务>。<域>
代替：
服务实例名称= <服务>。<实例>。<域>
命名服务有三个原因
父域作为最重要的实例（最右边）
名称的一部分，然后抽象服务类型作为次最多
重要的，然后特定的实例名称为最少 -
名称的重要（最左边）部分。讨论了这些原因
以下B.1，B.2和B.3节。
B.1。语义结构
通过浏览提供的工具（“服务实例”
枚举“）实际上是枚举树的叶子
结构体。给定域提供零个或多个服务。对于每一个
那些服务类型，可能有零个或多个实例
服务。
用户知道他们正在寻求什么类型的服务。（如果它们是
运行FTP客户端，他们正在寻找FTP服务器。如果他们
有一个要打印的文件，他们正在寻找说话的实体
一些已知的打印协议。）用户知道在哪个
他们希望搜索的组织或地理域。（用户
不希望每个打印机上都有一个单独的平面列表
行星，即使这样的事情是可能的。）用户没有
事先知道他们所寻求的服务是否在提供
给定域，或者如果是，提供的实例数和
这些实例的名称。
因此，实例名称是树的叶子是
与此语义模型一致。
让服务类型成为树的终端叶子
意味着用户知道域名和服务名称
例如，但不知道该服务的作用。我们会
认为这是一个不太有用的模型。
B.2。网络效率
当DNS响应包含多个答案时，名称压缩有效
如果所有名称都包含公共后缀，则更有效。如果很多
数据包中的答案具有相同的<Service>和<Domain>，然后是每个
发生服务实例名称只能使用
<Instance>部分后跟一个双字节压缩指针
引用先前的“<Service>。<Domain>”外观。这个
如果出现<Service>组件，则无法实现效率
每个名字的第一个。
B.3。操作灵活性
此名称结构允许沿逻辑委派子域
服务边界。例如，网络管理员在
示例公司可以选择委派“_tcp.example.com”。
子域到不同的机器，使机器处理
服务发现不一定是处理其他服务的机器
日常DNS操作。（它*可以*是同一台机器，如果
管理员如此选择，但管理员可以自由地做到这一点
选择。）此外，如果网络管理员希望
将与IPP打印机相关的所有信息委托给机器
致力于该特定任务，这可以通过委派轻松完成
“_ipp._tcp.example.com”。子域到所需的机器。它是
也可以方便地在每个区域/每个子域上设置安全策略
基础。例如，管理员可以选择启用DNS
用于打印机注册的动态更新[RFC2136] [RFC3007]
“_ipp._tcp.example.com。” 子域名，但不适用于其他子域名
区/子域。如果这样的话，就不会存在这种简单的灵
每个名称中首先出现<Service>组件。
附录C.所见即所得
某些服务发现协议将真正的服务标识符解耦
从提供给用户的名称。真正的服务标识符
协议使用的通常是不透明的唯一标识符
使用一长串十六进制数字表示，这应该是
从不被典型用户看到。提供给用户的名称是
只是其中一个装饰性的短暂属性
不透明的识别。
这种方法的问题在于它解耦了用户的感知
来自网络现实：
*如果有两个不同的服务实例会发生什么
独特的ID，但他们无意中被赋予了相同的用户 -
可见名字？如果两个实例出现在屏幕列表中
相同的名称，用户如何知道哪个是哪个？
*假设打印机发生故障，用户将其替换为
另一台相同品牌和型号的打印机，并配置新的
打印机与被替换的打印机名称完全相同：
“斯图亚特的打印机”。现在，当用户尝试打印时，
屏幕打印对话框告诉他们他们选择的默认打印机
是“斯图尔特的打印机”。当他们浏览网络看什么
在那里，他们看到一台名为“Stuart's Printer”的打印机，但是什么时候
用户试图打印，他们被告知打印机“斯图尔特的
无法找到打印机。隐藏的内部唯一标识符
该软件试图在网络上找不到匹配
甚至是新打印机的隐藏内部唯一标识符
虽然它明显的“名称”和它在那里的逻辑目的
是相同的。为了解决这个问题，用户通常必须删除
他们创建的打印队列，然后创建一个新的
（显然相同）队列为新打印机，使新的
queue将包含正确的隐藏内部唯一标识符。
拥有用户无法看到的所有隐藏信息
令人困惑和令人沮丧的用户体验，以及暴露
向用户提供长而丑陋的十六进制字符串并强制它们
明白他们的意思更糟糕。
*假设现有的打印机被移动到新的部门，并且
给出一个新名称和一个新功能。更改用户可见
该硬件的名称不会改变其隐藏的内部
唯一标识符。之前已创建打印队列的用户
因为该打印机仍将访问相同的硬件
唯一标识符，即使是以前的逻辑服务
由硬件提供已经不复存在。
解决这些问题需要用户或管理员了解
所谓隐藏的唯一标识符，并设置其值
正确地移动，重新利用或替换硬件，
从而与它是隐藏标识符的概念相矛盾
人类用户永远不需要处理。要求用户
了解这位专家的幕后知识是什么
*真正*正在进行只是给用户带来的另一个负担
他们正试图诊断他们的计算机和网络设备的原因
没有按预期工作。
这些异常和违反直觉的行为可以通过以下方式消除
保持紧密的双向一对一映射之间的关系
用户在屏幕上看到了“真正发生的事情”
窗帘“。如果配置不正确，那就是
在熟悉的日常用户界面中显而易见的是每个人
理解，而不是一些鲜为人知，很少使用的“专家”
接口。
总结：在DNS-SD中，用户可见的名称也是主要名称
服务的标识符。如果更改了用户可见的名称，那么
从概念上讲，提供的服务是一种不同的逻辑服务
- 即使提供服务的硬件可能已经停留了
相同。如果用户可见的名称没有改变，那么从概念上讲
提供的服务是相同的逻辑服务 - 即使是
提供服务的硬件是新硬件带来的替代品
一些旧设备。
这场辩论的双方肯定存在争议。
尽管如此，任何服务发现协议的设计者都必须这样做
在隐藏主要标识符之间做出选择，或者
让它们可见，这些是我们选择的原因
让它们可见。我们并没有声称没有
使主要标识符可见的缺点。我们
考虑两种选择，我们相信少数
可见标识符的缺点远远超过许多人
使用隐藏标识符导致的问题。
附录D.出厂默认名称的选择
使用多播DNS [RFC6762]通告DNS-SD服务时，如果
已有另一种同类型广告服务
同名，然后将发生自动名称冲突解决。如
在多播DNS规范[RFC6762]中描述
检测到冲突，服务应该：
1.自动选择一个新名称（通常通过附加或
递增名称末尾的数字），
2.尝试使用新名称进行广告宣传
3.成功后，将新名称记录在持久存储中。
这种重命名行为非常重要，因为它是关键
在开箱即用的工厂提供用户友好的实例名称 -
默认配置。一些产品开发商显然没有
意识到这一点，因为今天有一些产品在哪里
出厂默认名称明显不友好，包含随机 -
查找字符串，例如设备的以太网地址
十六进制。这是不必要的，也是不可取的，因为
用户可见名称的一点是它应该是友好的
对人类用户有意义。如果名称在本地不是唯一的
然后协议将根据需要对此进行补救。它是
具有讽刺意味的是，许多具有此设计错误的设备都是网络
打印机，鉴于这些相同的打印机也同时支持
AppleTalk-over-Ethernet，具有良好的用户友好默认名称（和
自动冲突检测和重命名）。好的一些例子
出厂默认名称为：
兄弟5070N
佳能W2200
HP LaserJet 4600
利盟W840
Okidata C5300
理光Aficio CL7100
Xerox Phaser 6200DX
为了说明为什么要添加长而丑陋的工厂独特系列
姓名末尾的数字既不必要也不可取，
考虑用户拥有（a）只有一台网络打印机的情况，
（b）两台网络打印机，以及（c）许多网络打印机。
（a）在用户只有一台网络打印机的情况下，
一个简单的名称（使用供应商中立的例子）
“打印机”比丑陋的名字更加用户友好
“Printer_0001E68C74FB”。附加丑陋的十六进制goop到
名称的末尾，以确保名称是唯一的无关
一个只有一台打印机的用户。
（b）在用户获得第二台网络打印机的情况下，具有
新打印机检测到名称“Printer”已在使用中
并自动将自己命名为“Printer（2）”，提供一个
良好的用户体验。对于大多数用户来说，记住那个旧的
打印机是“打印机”，新的打印机是“打印机（2）”很容易
而且直观。看到名为“Printer_0001E68C74FB”的打印机
另一个名为“Printer_00306EC3FD1C”的帮助很少。
（c）对于有十台网络打印机的网络，看到一个
所有形式为“Printer_xxxxxxxxxxxx”的十个名称列表
有效地采取了应该是一个用户名单 -
友好的富文本名称（支持混合大小写，空格，
标点符号，非罗马字符和其他符号）并转向
它只是可以想象的最糟糕的用户界面：一个列表
不可理解的随机字母和字母串
数字。在拥有大量打印机的网络中，它会是
建议人们设置打印机
给每个人一个描述性名称的时刻，但在事件中
他们没有，向用户呈现顺序列表
编号的打印机是更理想的默认用户
体验而不是显示原始以太网地址列表。
附录E.域名系统中的名称编码
虽然最初的DNS规范[RFC1033] [RFC1034]
[RFC1035]建议主机名仅包含字母，数字和
连字符（由于基于类型的用户的限制
那个时代的接口），服务实例名称不是主机名。
用户通常通过从列表中选择服务来访问服务
由用户界面呈现，而不是通过键入其服务实例
名称。“直接澄清DNS规范”[RFC2181]
讨论了第11节中允许字符集的主题（“名称
语法“），并明确说明传统的字母 - 数字 -
连字符规则仅适用于传统主机名：
有时，假设域名系统仅用于服务
将Internet主机名映射到数据和映射的目的
Internet地址到主机名。这是不正确的，DNS是
一般（如果有限）分层数据库，并且可以
存储几乎任何类型的数据，几乎可用于任何目的。
DNS本身只对特定区域设置了一个限制
可用于标识资源记录的标签。那个
限制与标签的长度和全名有关。
任何一个标签的长度限制在1到63个八位字节之间。
完整域名限制为255个八位字节（包括
分隔符）。零长度全名定义为表示
DNS树的根，通常是编写和显示的
作为“。”。抛开那些限制，任何二进制字符串都可以
用作任何资源记录的标签。同样，任何
二进制字符串可以作为包含a的任何记录的值
域名作为其部分或全部价值（SOA，NS，MX，PTR，CNAME，
和任何其他可能被添加的）。DNS的实现
协议不得对可以的标签施加任何限制
使用。特别是，DNS服务器不得拒绝提供服务
区域，因为它包含可能无法接受的标签
一些DNS客户端程序。
请注意，仅仅因为基于DNS的服务发现支持任意
UTF-8编码的名称并不意味着任何特定的用户或
管理员有义务使用该功能。任何用户都是
如果他们愿意，可以免费继续使用他们的服务
字母，数字和连字符，没有空格，大写字母或
其他标点符号。
附录F.“连续实时更新”浏览模型
在DNS-SD的设计中特别关注，特别是在使用时
与ad hoc Multicast DNS结合使用，是动态的本质
在不断变化的网络环境中发现服务。其他服务
发现协议似乎是用隐式设计的
未使用的假设使用模型是：
（a）客户端软件调用服务发现API，
（b）服务发现代码花费几秒钟获取列表
在特定时刻可用的实例，然后
（c）客户端软件显示供用户选择的列表。
从表面上看，这种使用模式似乎是合理的，但问题是
这太乐观了。它只考虑成功案例，在哪里
软件立即找到用户所在的服务实例
寻找。
在用户正在寻找（比如）特定打印机的情况下，
并且该打印机未打开或未连接，用户首先
必须尝试解决问题，然后必须单击一个
“刷新”按钮重试服务发现以查明是否
他们成功了。因为没有任何事情瞬间发生
网络，数据包可能会丢失，需要一些数据包
重传，服务发现搜索不是瞬时的
通常需要几秒钟。结果，一个相当典型的用户
经验是：
（a）显示一个空窗口，
（b）显示一些动画，如探照灯扫过
十秒钟，然后
（c）在十秒搜索结束时，显示静态列表
显示发现了什么。
每次用户点击“刷新”按钮时，他们都必须忍受
另外十秒等待，每次发现的列表都是
终于在十秒钟的等待结束时显示出来了
在它显示的那一刻开始变得陈旧和过时
屏幕。
DNS-SD设计人员具有的服务发现用户体验
记住有一些相当不同的属性：
1.应显示已发现服务的初始列表
有效瞬时 - 即通常为0.1秒，而不是10秒
秒。
2.发现的服务列表不应该过时
从它显示的那一刻起就过时了。清单应该是
'live'并且应该继续更新，因为新的服务
发现。由于延迟，数据包丢失，和
网络中固有的重传，可以预料到
有时，显示初始列表后显示
大多数被发现的服务，一些剩余的散兵游勇者可能
在接下来的几秒钟内继续涓涓细流。甚至
在建立并显示此稳定列表之后，它应该
保持“现场”并应继续更新。在将来的任何时候，
无论是几分钟，几小时，甚至几天后，如果是新服务的话
发现所需的类型，它应该显示在列表中
自动，无需用户点击“刷新”
按钮或采取任何其他显式操作来更新显示。
3.用户养成了离开服务发现的习惯
窗户打开，并期望它们显示连续的“实时”视图
当前的网络现实，这给了我们一个额外的
要求：删除过时的服务。当一个服务
发现列表在某个时刻仅显示静态快照，
情况很简单：要么发现了服务，要么发现了
出现在列表中，或者它不是也不是。但是，什么时候
我们的列表是实时的，并随着发现的不断更新
新服务，那么这意味着推论：当一个服务
消失了，它需要*从服务发现中消失*
名单。否则，服务发现列表将会增长
随着时间的推移，单调地收集过时的数据，并且需要
定期“刷新”（或完全解雇和娱乐）
恢复正确显示。
4.用户离开服务发现窗口的另一个后果
这些窗户应该长时间打开
更新不仅是为了响应来来往往的服务，而且
也是为了响应配置和连接的变化
客户端机器本身。例如，如果用户打开了
客户端计算机没有网络时的服务发现窗口
连接，那么窗口通常会显示为空
没有发现的服务。当用户连接以太网电缆时
或加入802.11 [IEEEW]无线网络窗口应该
然后自动填充已发现的服务，而不是
需要任何明确的用户操作。如果用户断开连接
以太网电缆或关闭802.11无线然后所有服务
通过该网络接口发现应该是自动的
消失。如果用户从一个802.11无线接入切换
指向另一个，服务发现窗口应该
自动更新以删除通过发现的所有服务
旧的无线接入点，并添加所有服务
通过新的发现。
附录G.部署历史
1997年7月，发送电子邮件至net-thinkers@thumper.vmeng.com
邮件列表中，Stuart Cheshire首先提出了运行的想法
基于IP的AppleTalk名称绑定协议[RFC6760]。后果
这个以及相关的IETF讨论，IETF Zeroconf工作组
1999年9月特许。经过各种工作组的审议
讨论和其他非正式的IETF讨论，几个互联网 -
撰写的草案与一般主题松散相关
DNS和多播，但没有解决服务发现
NBP的方面。
2000年4月，Stuart Cheshire注册了IPv4多播地址
224.0.0.251与IANA一起开始编写代码来测试和开发
使用多播DNS执行类似NBP的服务发现的想法，
这是在一组三个互联网草案中记录的：
o“替换AppleTalk名称绑定的协议要求
协议（NBP）“[RFC6760]是解释AppleTalk的概述
名称绑定协议，因为许多IETF社区都有
使用AppleTalk的第一手经验很少，而且混淆了
关于AppleTalk NBP所做的事情的IETF社区引起了混乱
关于基于IP的替代品需要什么。
o“使用DNS发现抽象服务的命名实例”
后来成为这份文件的[NIAS]提出了一种方法
使用与DNS兼容的名称执行类似NBP的服务发现
记录类型。
o“Multicast DNS”[RFC6762]指定了一种传输这些DNS的方法 -
使用IP多播的兼容查询和响应，为零
没有传统单播DNS的配置环境
服务器可用。
2001年，对Mac OS 9的更新增加了解析器库支持
使用多播DNS进行主机名查找。如果用户键入了这样的名称
作为“MyPrinter.local”。进入任何使用过的网络软件
标准的Mac OS 9名称查找API，然后是那些名称查找API
将该名称识别为点本地名称并按其查询
将简单的一次性多播DNS查询发送到224.0.0.251:5353。
这使用户能够输入名称
“MyPrinter.local。” 进入他们的网络浏览器以便查看
打印机的状态和配置网页，或输入名称
“MyPrinter.local。” 进入打印机设置实用程序以创建打印
用于在该打印机上打印文档的队列。
首先是具有完整服务发现的多播DNS响应软件
随着Mac OS X的推出，它开始向终端用户发货
10.2“Jaguar”于2002年8月和网络打印机制造商（曾经有过
历史上支持AppleTalk在他们的网络打印机和
接受基于IP的技术，可以提供类似的技术
不久之后，很容易开始采用多播DNS。
2002年9月，Apple发布了该代码的源代码
mDNSResponder守护程序作为Apple标准Apple下的开源
公共源许可证（APSL）。
多播DNS响应软件可供Microsoft使用
Windows用户于2004年6月推出Apple的“Rendezvous for
Windows“（现在是”Bonjour for Windows“），都是可执行的形式（a
最终用户可下载的安装程序）和开源（其中一个
支持Apple平台内部跨平台代码的平台
可公开访问的mDNSResponder CVS源代码库）[BJ]。
2006年8月，Apple重新授权跨平台mDNSResponder
Apache License，Version 2.0下的源代码。
除了运行Mac OS X和Linux的台式机和笔记本电脑之外
Microsoft Windows，多播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的服务
发现是针对没有配置的零配置环境
传统的单播DNS服务器，基于DNS的服务发现也
使用DNS更新[RFC2136] [RFC3007]使用单播DNS服务器
创建服务发现记录和标准DNS查询以进行查询
对他们来说 使用Mac OS X推出的Apple的Back to My Mac服务
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]。
1197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
