DNSSD官方文档翻译

目录

 

   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记录的意图是传达少量的

   有关服务的有用的其他信息。理想情况下，它应该

   客户端无需检索此附加信息