Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6763 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6763 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
DNS-Based Service Discovery
基于DNS的服务发现
Abstract
摘要
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
本文档指定DNS资源记录的命名和结构，以便于服务发现。给定客户端正在查找的服务类型以及客户端正在查找该服务的域，此机制允许客户端使用标准DNS查询发现所需服务的命名实例列表。此机制称为基于DNS的服务发现或DNS-SD。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6763.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6763.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............5
3. Design Goals ....................................................5
4. Service Instance Enumeration (Browsing) .........................6
4.1. Structured Service Instance Names ..........................6
4.2. User Interface Presentation ................................9
4.3. Internal Handling of Names .................................9
5. Service Instance Resolution ....................................10
6. Data Syntax for DNS-SD TXT Records .............................11
6.1. General Format Rules for DNS TXT Records ..................11
6.2. DNS-SD TXT Record Size ....................................12
6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13
6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14
6.5. Rules for Values in DNS-SD Key/Value Pairs ................16
6.6. Example TXT Record ........................................17
6.7. Version Tag ...............................................17
6.8. Service Instances with Multiple TXT Records ...............18
7. Service Names ..................................................19
7.1. Selective Instance Enumeration (Subtypes) .................21
7.2. Service Name Length Limits ................................23
8. Flagship Naming ................................................25
9. Service Type Enumeration .......................................27
10. Populating the DNS with Information ...........................27
11. Discovery of Browsing and Registration Domains (Domain
Enumeration) ..................................................28
12. DNS Additional Record Generation ..............................30
12.1. PTR Records ..............................................30
12.2. SRV Records ..............................................30
12.3. TXT Records ..............................................31
12.4. Other Record Types .......................................31
13. Working Examples ..............................................31
13.1. What web pages are being advertised from dns-sd.org? .....31
13.2. What printer-configuration web pages are there? ..........31
13.3. How do I access the web page called "Service
Discovery"? ..............................................32
14. IPv6 Considerations ...........................................32
15. Security Considerations .......................................32
16. IANA Considerations ...........................................32
17. Acknowledgments ...............................................33
18. References ....................................................33
18.1. Normative References .....................................33
18.2. Informative References ...................................34
Appendix A. Rationale for Using DNS as a Basis for Service
Discovery .............................................37
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............5
3. Design Goals ....................................................5
4. Service Instance Enumeration (Browsing) .........................6
4.1. Structured Service Instance Names ..........................6
4.2. User Interface Presentation ................................9
4.3. Internal Handling of Names .................................9
5. Service Instance Resolution ....................................10
6. Data Syntax for DNS-SD TXT Records .............................11
6.1. General Format Rules for DNS TXT Records ..................11
6.2. DNS-SD TXT Record Size ....................................12
6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13
6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14
6.5. Rules for Values in DNS-SD Key/Value Pairs ................16
6.6. Example TXT Record ........................................17
6.7. Version Tag ...............................................17
6.8. Service Instances with Multiple TXT Records ...............18
7. Service Names ..................................................19
7.1. Selective Instance Enumeration (Subtypes) .................21
7.2. Service Name Length Limits ................................23
8. Flagship Naming ................................................25
9. Service Type Enumeration .......................................27
10. Populating the DNS with Information ...........................27
11. Discovery of Browsing and Registration Domains (Domain
Enumeration) ..................................................28
12. DNS Additional Record Generation ..............................30
12.1. PTR Records ..............................................30
12.2. SRV Records ..............................................30
12.3. TXT Records ..............................................31
12.4. Other Record Types .......................................31
13. Working Examples ..............................................31
13.1. What web pages are being advertised from dns-sd.org? .....31
13.2. What printer-configuration web pages are there? ..........31
13.3. How do I access the web page called "Service
Discovery"? ..............................................32
14. IPv6 Considerations ...........................................32
15. Security Considerations .......................................32
16. IANA Considerations ...........................................32
17. Acknowledgments ...............................................33
18. References ....................................................33
18.1. Normative References .....................................33
18.2. Informative References ...................................34
Appendix A. Rationale for Using DNS as a Basis for Service
Discovery .............................................37
Appendix B. Ordering of Service Instance Name Components ..........38
B.1. Semantic Structure ........................................38
B.2. Network Efficiency ........................................39
B.3. Operational Flexibility ...................................39
Appendix C. What You See Is What You Get ..........................40
Appendix D. Choice of Factory-Default Names .......................42
Appendix E. Name Encodings in the Domain Name System ..............44
Appendix F. "Continuous Live Update" Browsing Model ...............45
Appendix G. Deployment History ....................................47
Appendix B. Ordering of Service Instance Name Components ..........38
B.1. Semantic Structure ........................................38
B.2. Network Efficiency ........................................39
B.3. Operational Flexibility ...................................39
Appendix C. What You See Is What You Get ..........................40
Appendix D. Choice of Factory-Default Names .......................42
Appendix E. Name Encodings in the Domain Name System ..............44
Appendix F. "Continuous Live Update" Browsing Model ...............45
Appendix G. Deployment History ....................................47
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
本文档指定DNS资源记录的命名和结构，以便于服务发现。给定客户端正在查找的服务类型以及客户端正在查找该服务的域，此机制允许客户端使用标准DNS查询发现所需服务的命名实例列表。此机制称为基于DNS的服务发现或DNS-SD。
This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values.
本文档不建议更改DNS消息的结构，也不建议更改新的操作代码、响应代码、资源记录类型或任何其他新的DNS协议值。
This document specifies that a particular service instance can be described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. The SRV record has a name of the form "<Instance>.<Service>.<Domain>" and gives the target host and port where the service instance can be reached. The DNS TXT record of the same name gives additional information about this instance, in a structured form using key/value pairs, described in Section 6. A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "<Service>.<Domain>", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs.
本文档指定可以使用DNS SRV[RFC2782]和DNS TXT[RFC1035]记录来描述特定的服务实例。SRV记录的名称形式为“<Instance><Service><Domain>”，并提供可以访问服务实例的目标主机和端口。相同名称的DNS TXT记录以使用键/值对的结构化形式提供有关此实例的附加信息，如第6节所述。客户端使用对DNS PTR[RFC1035]记录的查询来发现给定服务类型的可用实例列表，该记录的名称为“<service><Domain>”，返回一组零个或多个名称，这些名称是上述DNS SRV/TXT记录对的名称。
This specification is compatible with both Multicast DNS [RFC6762] and with today's existing Unicast DNS server and client software.
此规范与多播DNS[RFC6762]以及当前现有的单播DNS服务器和客户端软件兼容。
When used with Multicast DNS, DNS-SD can provide zero-configuration operation -- just connect a DNS-SD/mDNS device, and its services are advertised on the local link with no further user interaction [ZC].
当与多播DNS一起使用时，DNS-SD可以提供零配置操作——只需连接一个DNS-SD/mDNS设备，其服务在本地链路上公布，无需进一步的用户交互[ZC]。
When used with conventional Unicast DNS, some configuration will usually be required -- such as configuring the device with the DNS domain(s) in which it should advertise its services, and configuring it with the DNS Update [RFC2136] [RFC3007] keys to give it permission to do so. In rare cases, such as a secure corporate network behind a
当与传统的单播DNS一起使用时，通常需要进行一些配置——例如，使用DNS域配置设备，设备应在其中公布其服务，并使用DNS更新[RFC2136][RFC3007]密钥配置设备，以授予其这样做的权限。在极少数情况下，例如在
firewall where no DNS Update keys are required, zero-configuration operation may be achieved by simply having the device register its services in a default registration domain learned from the network (see Section 11, "Discovery of Browsing and Registration Domains"), but this is the exception and usually security credentials will be required to perform DNS updates.
在不需要DNS更新密钥的防火墙中，只需让设备在从网络获知的默认注册域中注册其服务，即可实现零配置操作（参见第11节“浏览和注册域的发现”），但这是例外，通常需要安全凭据才能执行DNS更新。
Note that when using DNS-SD with Unicast DNS, the Unicast DNS-SD service does NOT have to be provided by the same DNS server hardware that is currently providing an organization's conventional host name lookup service. While many people think of "DNS" exclusively in the context of mapping host names to IP addresses, in fact, "the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose" [RFC2181]. By delegating the "_tcp" and "_udp" subdomains, all the workload related to DNS-SD can be offloaded to a different machine. This flexibility, to handle DNS-SD on the main DNS server or not, at the network administrator's discretion, is one of the benefits of using DNS.
请注意，当将DNS-SD与单播DNS一起使用时，单播DNS-SD服务不必由当前提供组织的常规主机名查找服务的同一DNS服务器硬件提供。虽然许多人认为“DNS”只是在将主机名映射到IP地址的上下文中出现的，但事实上，“DNS是一个通用（如果有一定限制的话）分层数据库，可以存储几乎任何类型的数据，用于几乎任何目的”[RFC2181]。通过委派“_tcp”和“_udp”子域，所有与DNS-SD相关的工作负载都可以卸载到不同的机器上。这种灵活性，由网络管理员决定是否在主DNS服务器上处理DNS-SD，是使用DNS的好处之一。
Even when the DNS-SD functions are delegated to a different machine, the benefits of using DNS remain: it is mature technology, well understood, with multiple independent implementations from different vendors, a wide selection of books published on the subject, and an established workforce experienced in its operation. In contrast, adopting some other service discovery technology would require every site in the world to install, learn, configure, operate, and maintain some entirely new and unfamiliar server software. Faced with these obstacles, it seems unlikely that any other service discovery technology could hope to compete with the ubiquitous deployment that DNS already enjoys. For further discussion, see Appendix A, "Rationale for Using DNS as a Basis for Service Discovery".
即使将DNS-SD功能委托给不同的机器，使用DNS的好处仍然存在：它是一种成熟的技术，被广泛理解，有来自不同供应商的多个独立实现，出版了大量关于该主题的书籍，并且拥有一支经验丰富的工作队伍。相反，采用其他一些服务发现技术需要世界上的每个站点安装、学习、配置、操作和维护一些全新的、不熟悉的服务器软件。面对这些障碍，任何其他服务发现技术似乎都不可能与DNS已经享有的无处不在的部署竞争。有关进一步的讨论，请参见附录A，“使用DNS作为服务发现基础的基本原理”。
This document is written for two audiences: for developers creating application software that offers or accesses services on the network, and for developers creating DNS-SD libraries to implement the advertising and discovery mechanisms. For both audiences, understanding the entire document is helpful. For developers creating application software, this document provides guidance on choosing instance names, service names, and other aspects that play a role in creating a good overall user experience. However, also understanding the underlying DNS mechanisms used to provide the service discovery facilities helps application developers understand the capabilities and limitations of those underlying mechanisms (e.g., name length limits). For library developers writing software to construct the DNS records (to advertise a service) and generate the DNS queries (to discover and use a service), understanding the ultimate user-experience goals helps them provide APIs that can meet those goals.
本文档面向两个受众：一个是为创建在网络上提供或访问服务的应用软件的开发人员，另一个是为创建DNS-SD库以实现广告和发现机制的开发人员。对于这两位读者来说，理解整个文档是很有帮助的。对于创建应用程序软件的开发人员，本文档提供了有关选择实例名称、服务名称以及在创建良好的总体用户体验中起作用的其他方面的指导。但是，了解用于提供服务发现设施的底层DNS机制也有助于应用程序开发人员了解这些底层机制的功能和限制（例如，名称长度限制）。对于编写软件来构建DNS记录（发布服务）和生成DNS查询（发现和使用服务）的库开发人员来说，了解最终用户体验目标有助于他们提供能够满足这些目标的API。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
Of the many properties a good service discovery protocol needs to have, three of particular importance are:
在一个好的服务发现协议需要具备的许多属性中，有三个特别重要：
(i) The ability to query for services of a certain type in a certain logical domain, and receive in response a list of named instances (network browsing or "Service Instance Enumeration").
(i) 能够在特定逻辑域中查询特定类型的服务，并作为响应接收命名实例列表（网络浏览或“服务实例枚举”）。
(ii) Given a particular named instance, the ability to efficiently resolve that instance name to the required information a client needs to actually use the service, i.e., IP address and port number, at the very least (Service Instance Resolution).
（ii）给定一个特定的命名实例，能够有效地将该实例名称解析为客户端实际使用该服务所需的信息，即IP地址和端口号，至少（服务实例解析）。
(iii) Instance names should be relatively persistent. If a user selects their default printer from a list of available choices today, then tomorrow they should still be able to print on that printer -- even if the IP address and/or port number where the service resides have changed -- without the user (or their software) having to repeat the step (i) (the initial network browsing) a second time.
（iii）实例名称应相对持久。如果用户今天从可用选项列表中选择了默认打印机，那么明天他们仍然可以在该打印机上打印，即使服务所在的IP地址和/或端口号已更改，而用户（或其软件）无需再次重复步骤（i）（初始网络浏览）。
In addition, if it is to become successful, a service discovery protocol should be so simple to implement that virtually any device capable of implementing IP should not have any trouble implementing the service discovery software as well.
此外，如果要获得成功，服务发现协议的实现应该非常简单，几乎任何能够实现IP的设备在实现服务发现软件时都不会遇到任何问题。
These goals are discussed in more detail in the remainder of this document. A more thorough treatment of service discovery requirements may be found in "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760]. That document draws upon examples from two decades of operational experience with AppleTalk to develop a list of universal requirements that are broadly applicable to any potential service discovery protocol.
这些目标将在本文档的其余部分进行更详细的讨论。对服务发现要求的更彻底的处理可以在“替代AppleTalk名称绑定协议（NBP）的协议要求”[RFC6760]中找到。该文档利用了AppleTalk二十年运营经验中的示例，开发了广泛适用于任何潜在服务发现协议的通用需求列表。
Traditional DNS SRV records [RFC2782] are useful for locating instances of a particular type of service when all the instances are effectively indistinguishable and provide the same service to the client.
传统的DNS SRV记录[RFC2782]对于定位特定类型服务的实例非常有用，因为所有实例实际上都不可区分，并向客户端提供相同的服务。
For example, SRV records with the (hypothetical) name "_http._tcp.example.com." would allow a client to discover servers implementing the "_http._tcp" service (i.e., web servers) for the "example.com." domain. The unstated assumption is that all these servers offer an identical set of web pages, and it doesn't matter to the client which of the servers it uses, as long as it selects one at random according to the weight and priority rules laid out in the DNS SRV specification [RFC2782].
例如，具有（假设）名称“_http._tcp.example.com.”的SRV记录将允许客户端发现为“example.com.”域实现“_http._tcp”服务的服务器（即web服务器）。未声明的假设是，所有这些服务器都提供一组相同的网页，只要客户机根据DNS SRV规范[RFC2782]中规定的权重和优先级规则随机选择一个，那么客户机使用哪一个服务器并不重要。
Instances of other kinds of service are less easily interchangeable. If a word processing application were to look up the (hypothetical) SRV record "_ipp._tcp.example.com." to find the list of Internet Printing Protocol (IPP) [RFC2910] printers at Example Co., then picking one at random and printing on it would probably not be what the user wanted.
其他类型服务的实例不太容易互换。如果文字处理应用程序要查找（假设的）SRV记录“\u ipp.\u tcp.example.com.”以查找example Co.的Internet打印协议（ipp）[RFC2910]打印机列表，则随机选择一个并在其上打印可能不是用户想要的。
The remainder of this section describes how SRV records may be used in a slightly different way, to allow a user to discover the names of all available instances of a given type of service, and then select, from that list, the particular instance they desire.
本节的其余部分描述了如何以稍微不同的方式使用SRV记录，以允许用户发现给定服务类型的所有可用实例的名称，然后从该列表中选择他们想要的特定实例。
This document borrows the logical service-naming syntax and semantics from DNS SRV records, but adds one level of indirection. Instead of requesting records of type "SRV" with name "_ipp._tcp.example.com.", the client requests records of type "PTR" (pointer from one name to another in the DNS namespace) [RFC1035].
本文档借用了DNS SRV记录中的逻辑服务命名语法和语义，但添加了一级间接寻址。客户端请求类型为“PTR”（DNS命名空间中从一个名称指向另一个名称的指针）的记录，而不是请求名称为“\u ipp.\u tcp.example.com.”的“SRV”类型的记录。[RFC1035]。
In effect, if one thinks of the domain name "_ipp._tcp.example.com." as being analogous to an absolute path to a directory in a file system, then DNS-SD's PTR lookup is akin to performing a listing of that directory to find all the entries it contains. (Remember that domain names are expressed in reverse order compared to path names -- an absolute path name starts with the root on the left and is read from left to right, whereas a fully qualified domain name starts with the root on the right and is read from right to left. If the fully qualified domain name "_ipp._tcp.example.com." were expressed as a file system path name, it would be "/com/example/_tcp/_ipp".)
实际上，如果你认为域名“_ipp._tcp.example.com.”类似于文件系统中某个目录的绝对路径，那么DNS-SD的PTR查找类似于执行该目录的列表以查找其包含的所有条目。（请记住，域名的表达顺序与路径名相反——绝对路径名从左边的根开始，从左到右读取，而完全限定的域名从右边的根开始，从右到左读取。如果完全限定的域名“\u ipp.\u tcp.example.com。”表示为文件系统路径名，它将是“/com/example/\u tcp/\u ipp”。）
The result of this PTR lookup for the name "<Service>.<Domain>" is a set of zero or more PTR records giving Service Instance Names of the form:
名称“<Service><Domain>”的PTR查找结果是一组零或多个PTR记录，给出以下形式的服务实例名称：
Service Instance Name = <Instance> . <Service> . <Domain>
Service Instance Name = <Instance> . <Service> . <Domain>
For explanation of why the components are in this order, see Appendix B, "Ordering of Service Instance Name Components".
有关组件为何按此顺序排列的说明，请参见附录B“服务实例名称组件的排序”。
The <Instance> portion of the Service Instance Name is a user-friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It MUST NOT contain ASCII control characters (byte values 0x00-0x1F and 0x7F) [RFC20] but otherwise is allowed to contain any characters, without restriction, including spaces, uppercase, lowercase, punctuation -- including dots -- accented characters, non-Roman text, and anything else that may be represented using Net-Unicode. For discussion of why the <Instance> name should be a user-visible, user-friendly name rather than an invisible machine-generated opaque identifier, see Appendix C, "What You See Is What You Get".
服务实例名称的<Instance>部分是一个用户友好的名称，由任意网络Unicode文本[RFC5198]组成。它不能包含ASCII控制字符（字节值0x00-0x1F和0x7F）[RFC20]，但允许包含任何字符，不受限制，包括空格、大写、小写、标点符号（包括点）、重音字符、非罗马文本，以及可能使用Net Unicode表示的任何其他字符。有关为什么<Instance>名称应该是用户可见的、用户友好的名称而不是不可见的机器生成的不透明标识符的讨论，请参见附录C，“所见即所得”。
The <Instance> portion of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can in many cases allow the device or service to be accessed without any manual configuration at all. The default name should be short and descriptive, and SHOULD NOT include the device's Media Access Control (MAC) address, serial number, or any similar incomprehensible hexadecimal string in an attempt to make the name globally unique. For discussion of why <Instance> names don't need to be (and SHOULD NOT be) made unique at the factory, see Appendix D, "Choice of Factory-Default Names".
网络上提供的服务名称的<Instance>部分应由设置该服务的用户进行配置，以便他或她可以为其提供信息性名称。但是，设备或服务在使用前不应要求用户配置名称。在许多情况下，明智地选择默认名称可以允许访问设备或服务，而无需任何手动配置。默认名称应简短且具有描述性，并且不应包括设备的媒体访问控制（MAC）地址、序列号或任何类似的不可理解的十六进制字符串，以尝试使名称全局唯一。有关为什么<Instance>名称不需要（也不应该）在工厂唯一化的讨论，请参见附录D“工厂默认名称的选择”。
This <Instance> portion of the Service Instance Name is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. For further discussion of text encodings, see Appendix E, "Name Encodings in the Domain Name System".
服务实例名称的<Instance>部分作为规范化预合成UTF-8[RFC3629]“Net Unicode”（Unicode规范化格式C）[RFC5198]文本的单个DNS标签直接存储在DNS中。有关文本编码的进一步讨论，请参见附录E“域名系统中的名称编码”。
DNS labels are currently limited to 63 octets in length. UTF-8 encoding can require up to four octets per Unicode character, which means that in the worst case, the <Instance> portion of a name could be limited to fifteen Unicode characters. However, the Unicode
DNS标签目前的长度限制为63个八位字节。UTF-8编码可能需要每个Unicode字符最多四个八位字节，这意味着在最坏的情况下，名称的<Instance>部分可以限制为十五个Unicode字符。但是，Unicode
characters with longer octet lengths under UTF-8 encoding tend to be the more rarely used ones, and tend to be the ones that convey greater meaning per character.
在UTF-8编码下，八位字节长度较长的字符往往是更很少使用的字符，并且往往是每个字符传达更大含义的字符。
Note that any character in the commonly used 16-bit Unicode Basic Multilingual Plane [Unicode6] can be encoded with no more than three octets of UTF-8 encoding. This means that an instance name can contain up to 21 Kanji characters, which is a sufficiently expressive name for most purposes.
请注意，常用的16位Unicode基本多语言平面[Unicode6]中的任何字符都可以使用不超过三个八位字节的UTF-8编码进行编码。这意味着一个实例名称最多可以包含21个汉字字符，对于大多数目的来说，这是一个足够表达的名称。
The <Service> portion of the Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782]. The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it. The second label is either "_tcp" (for application protocols that run over TCP) or "_udp" (for all others). For more details, see Section 7, "Service Names".
服务实例名称的<Service>部分由一对DNS标签组成，遵循已经为SRV记录建立的约定[RFC2782]。该对的第一个标签是下划线字符，后跟服务名称[RFC6335]。服务名称标识服务所做的事情及其使用的应用程序协议。第二个标签是“_tcp”（用于在tcp上运行的应用程序协议）或“_udp”（用于所有其他协议）。有关更多详细信息，请参阅第7节“服务名称”。
The <Domain> portion of the Service Instance Name specifies the DNS subdomain within which those names are registered. It may be "local.", meaning "link-local Multicast DNS" [RFC6762], or it may be a conventional Unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." Because Service Instance Names are not host names, they are not constrained by the usual rules for host names [RFC1033] [RFC1034] [RFC1035], and rich-text service subdomains are allowed and encouraged, for example:
服务实例名称的<Domain>部分指定在其中注册这些名称的DNS子域。它可以是“local.”，意思是“link local Multicast 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 .
2号楼，一楼。实例通用域名格式。2号楼，二楼。实例通用域名格式。2号楼，三楼。实例通用域名格式。2号楼，4楼。实例通用域名格式。
In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using the "Punycode" algorithm [RFC3492] to convert the UTF-8 name to an IDNA "A-label" [RFC5890], beginning with the top-level label, then issuing the query
此外，由于服务实例名称不受主机名限制，因此本文档建议将它们存储在DNS中，并通过线路进行通信，编码为简单规范的预合成UTF-8[RFC3629]“Net Unicode”（Unicode规范化格式C）[RFC5198]文本。在DNS服务器返回有关名称的否定响应的情况下，客户端软件可以选择使用“Punycode”算法[RFC3492]重试查询，以将UTF-8名称转换为IDNA“a-label”[RFC5890]，从顶级标签开始，然后发出查询
repeatedly, with successively more labels translated to IDNA A-labels each time, and giving up if it has converted all labels to IDNA A-labels and the query still fails.
重复地，每次都会有更多的标签被转换为IDNA A标签，如果已经将所有标签转换为IDNA A标签，并且查询仍然失败，则放弃。
The names resulting from the Service Instance Enumeration PTR lookup are presented to the user in a list for the user to select one (or more). Typically, only the first label is shown (the user-friendly <Instance> portion of the name).
服务实例枚举PTR查找产生的名称将显示在列表中，供用户选择一个（或多个）。通常，只显示第一个标签（名称中用户友好的<Instance>部分）。
In the common case the <Service> and <Domain> are already known to the client software, these having been provided implicitly by the user in the first place, by the act of indicating the service being sought, and the domain in which to look for it. Note that the software handling the response should be careful not to make invalid assumptions though, since it *is* possible, though rare, for a service enumeration in one domain to return the names of services in a different domain. Similarly, when using subtypes (see Section 7.1, "Selective Instance Enumeration") the <Service> of the discovered instance may not be exactly the same as the <Service> that was requested.
在常见情况下，<Service>和<Domain>对于客户端软件来说已经是已知的，它们首先由用户通过指示正在寻求的服务以及在其中寻找服务的域的行为隐式地提供。请注意，处理响应的软件应小心，不要做出无效的假设，因为一个域中的服务枚举返回不同域中的服务名称是可能的，尽管很少见。类似地，当使用子类型（参见第7.1节“选择性实例枚举”）时，发现实例的<Service>可能与请求的<Service>不完全相同。
For further discussion of Service Instance Enumeration (browsing) user-interface considerations, see Appendix F, "'Continuous Live Update' Browsing Model".
有关服务实例枚举（浏览）用户界面注意事项的进一步讨论，请参阅附录F“持续实时更新”浏览模型。
Once the user has selected the desired named instance, the Service Instance Name may then be used immediately, or saved away in some persistent user-preference data structure for future use, depending on what is appropriate for the application in question.
一旦用户选择了所需的命名实例，服务实例名称就可以立即使用，或者保存在某个持久的用户首选项数据结构中以备将来使用，这取决于适用于所讨论的应用程序的内容。
If client software takes the <Instance>, <Service>, and <Domain> portions of a Service Instance Name and internally concatenates them together into a single string, then because the <Instance> portion is allowed to contain any characters, including dots, appropriate precautions MUST be taken to ensure that DNS label boundaries are properly preserved. Client software can do this in a variety of ways, such as character escaping.
如果客户端软件采用服务实例名称的<Instance>、<Service>和<Domain>部分，并在内部将它们连接成单个字符串，那么由于<Instance>部分允许包含任何字符，包括点，必须采取适当的预防措施，以确保正确保留DNS标签边界。客户端软件可以通过多种方式实现这一点，例如字符转义。
This document RECOMMENDS that if concatenating the three portions of a Service Instance Name, any dots in the <Instance> portion be escaped following the customary DNS convention for text files: by preceding literal dots with a backslash (so "." becomes "\."). Likewise, any backslashes in the <Instance> portion should also be escaped by preceding them with a backslash (so "\" becomes "\\").
本文档建议，如果连接服务实例名称的三个部分，<Instance>部分中的任何点都应按照文本文件的习惯DNS约定进行转义：在文字点之前加上反斜杠（因此“.”变为“\”）。同样，<Instance>部分中的任何反斜杠也应该通过在它们前面加一个反斜杠来转义（因此“\”变为“\”）。
Having done this, the three components of the name may be safely concatenated. The backslash-escaping allows literal dots in the name (escaped) to be distinguished from label-separator dots (not escaped), and the resulting concatenated string may be safely passed to standard DNS APIs like res_query(), which will interpret the backslash-escaped string as intended.
完成此操作后，名称的三个组件可以安全地连接起来。反斜杠转义允许将名称（转义）中的文字点与标签分隔符点（非转义）区分开来，并且生成的连接字符串可以安全地传递给标准DNS API，如res_query（），后者将按预期解释反斜杠转义字符串。
When a client needs to contact a particular service, identified by a Service Instance Name, previously discovered via Service Instance Enumeration (browsing), it queries for the SRV and TXT records of that name. The SRV record for a service gives the port number and target host name where the service may be found. The TXT record gives additional information about the service, as described in Section 6, "Data Syntax for DNS-SD TXT Records".
当客户机需要联系一个特定的服务时（由服务实例名称标识），该名称以前是通过服务实例枚举（浏览）发现的，它会查询该名称的SRV和TXT记录。服务的SRV记录提供了可以找到服务的端口号和目标主机名。TXT记录提供有关服务的附加信息，如第6节“DNS-SD TXT记录的数据语法”所述。
SRV records are extremely useful because they remove the need for preassigned port numbers. There are only 65535 TCP port numbers available. These port numbers are traditionally allocated one per application protocol [RFC6335]. Some protocols like the X Window System have a block of 64 TCP ports allocated (6000-6063). Using a different TCP port for each different instance of a given service on a given machine is entirely sensible, but allocating each application its own large static range, as was done for the X Window System, is not a practical way to do that. On any given host, most TCP ports are reserved for services that will never run on that particular host in its lifetime. This is very poor utilization of the limited port space. Using SRV records allows each host to allocate its available port numbers dynamically to those services actually running on that host that need them, and then advertise the allocated port numbers via SRV records. Allocating the available listening port numbers locally on a per-host basis as needed allows much better utilization of the available port space than today's centralized global allocation.
SRV记录非常有用，因为它们不再需要预先指定的端口号。只有65535个TCP端口号可用。这些端口号传统上按应用程序协议分配一个[RFC6335]。某些协议（如X Window系统）分配了64个TCP端口（6000-6063）。在给定的机器上为给定服务的每个不同实例使用不同的TCP端口是完全明智的，但像在X Window系统中那样，为每个应用程序分配自己的大静态范围并不是一种切实可行的方法。在任何给定的主机上，大多数TCP端口都是为在其生命周期内永远不会在该主机上运行的服务保留的。这是对有限的港口空间的极低利用率。使用SRV记录允许每个主机将其可用端口号动态分配给该主机上实际运行的需要这些端口号的服务，然后通过SRV记录公布分配的端口号。根据需要在每个主机上本地分配可用的侦听端口号，可以比现在的集中式全局分配更好地利用可用的端口空间。
In the event that more than one SRV is returned, clients MUST correctly interpret the priority and weight fields -- i.e., lower-numbered priority servers should be used in preference to higher-numbered priority servers, and servers with equal priority should be selected randomly in proportion to their relative weights. However, in the overwhelmingly common case, a single advertised DNS-SD service instance is described by exactly one SRV record, and in this common case the priority and weight fields of the SRV record SHOULD both be set to zero.
在返回多个SRV的情况下，客户端必须正确解释优先级和权重字段——即，应优先使用编号较低的优先级服务器，而不是编号较高的优先级服务器，并且应根据其相对权重按比例随机选择具有相同优先级的服务器。然而，在极为常见的情况下，单个公布的DNS-SD服务实例仅由一个SRV记录描述，在这种常见情况下，SRV记录的优先级和权重字段都应设置为零。
Some services discovered via Service Instance Enumeration may need more than just an IP address and port number to completely identify the service instance. For example, printing via the old Unix LPR (port 515) protocol [RFC1179] often specifies a queue name [BJP]. This queue name is typically short and cryptic, and need not be shown to the user. It should be regarded the same way as the IP address and port number: it is another component of the addressing information required to identify a specific instance of a service being offered by some piece of hardware. Similarly, a file server may have multiple volumes, each identified by its own volume name. A web server typically has multiple pages, each identified by its own URL. In these cases, the necessary additional data is stored in a TXT record with the same name as the SRV record. The specific nature of that additional data, and how it is to be used, is service-dependent, but the overall syntax of the data in the TXT record is standardized, as described below.
通过服务实例枚举发现的某些服务可能需要不止一个IP地址和端口号来完全标识服务实例。例如，通过旧的Unix LPR（端口515）协议[RFC1179]打印通常会指定队列名称[BJP]。此队列名称通常较短且神秘，不需要向用户显示。它应该被视为与IP地址和端口号相同的方式：它是地址信息的另一个组成部分，用于识别某个硬件提供的服务的特定实例。类似地，文件服务器可能有多个卷，每个卷由其自己的卷名标识。web服务器通常有多个页面，每个页面由自己的URL标识。在这些情况下，必要的附加数据存储在与SRV记录同名的TXT记录中。附加数据的具体性质以及使用方式取决于服务，但TXT记录中数据的总体语法是标准化的，如下所述。
Every DNS-SD service MUST have a TXT record in addition to its SRV record, with the same name, even if the service has no additional data to store and the TXT record contains no more than a single zero byte. This allows a service to have explicit control over the Time to Live (TTL) of its (empty) TXT record, rather than using the default negative caching TTL, which would otherwise be used for a "no error no answer" DNS response.
每个DNS-SD服务除了其SRV记录外，还必须有一个同名的TXT记录，即使该服务没有要存储的额外数据，并且TXT记录包含的字节数不超过一个零。这允许服务对其（空）TXT记录的生存时间（TTL）进行显式控制，而不是使用默认的负缓存TTL，否则将用于“无错误无应答”DNS响应。
Note that this requirement for a mandatory TXT record applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. The DNS SRV record datatype [RFC2782] may still be used in other contexts without any requirement for accompanying PTR and TXT records.
注意，强制TXT记录的要求仅适用于DNS-SD服务广告，即使用本文件中规定的PTR+SRV+TXT约定进行广告的服务。一般来说，这不是SRV记录的要求。DNS SRV记录数据类型[RFC2782]仍可在其他上下文中使用，而无需附带PTR和TXT记录。
A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total length is indicated by the length given in the resource record header in the DNS message. There is no way to tell directly from the data alone how long it is (e.g., there is no length count at the start, or terminating NULL byte at the end).
DNS TXT记录的长度最多可达65535（0xFFFF）字节。总长度由DNS消息中资源记录头中给定的长度表示。无法仅从数据直接判断它的长度（例如，在开始时没有长度计数，或在结束时终止空字节）。
Note that when using Multicast DNS [RFC6762] the maximum packet size is 9000 bytes, including the IP header, UDP header, and DNS message header, which imposes an upper limit on the size of TXT records of about 8900 bytes. In practice the maximum sensible size of a DNS-SD TXT record is smaller even than this, typically at most a few hundred bytes, as described below in Section 6.2.
请注意，当使用多播DNS[RFC6762]时，最大数据包大小为9000字节，包括IP头、UDP头和DNS消息头，这对TXT记录的大小施加了约8900字节的上限。实际上，DNS-SD TXT记录的最大合理大小甚至小于此值，通常最多为几百字节，如下文第6.2节所述。
The format of the data within a DNS TXT record is one or more strings, packed together in memory without any intervening gaps or padding bytes for word alignment.
DNS TXT记录中的数据格式是一个或多个字符串，在内存中打包在一起，没有任何间隙或填充字节用于字对齐。
The format of each constituent string within the DNS TXT record is a single length byte, followed by 0-255 bytes of text data.
DNS TXT记录中每个组成字符串的格式都是一个单长度字节，后跟0-255字节的文本数据。
These format rules for TXT records are defined in Section 3.3.14 of the DNS specification [RFC1035] and are not specific to DNS-SD. DNS-SD specifies additional rules for what data should be stored in those constituent strings when used for DNS-SD service advertising, i.e., when used to describe services advertised using the PTR+SRV+TXT convention specified in this document.
这些TXT记录的格式规则在DNS规范[RFC1035]的第3.3.14节中定义，并不特定于DNS-SD。DNS-SD规定了当用于DNS-SD服务广告时，即当用于描述使用本文档中指定的PTR+SRV+TXT约定广告的服务时，应在这些组成字符串中存储哪些数据的附加规则。
An empty TXT record containing zero strings is not allowed [RFC1035]. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD clients MUST treat the following as equivalent:
不允许包含零字符串的空TXT记录[RFC1035]。DNS-SD实现不得发出空TXT记录。DNS-SD客户端必须将以下各项视为等效项：
o A TXT record containing a single zero byte. (i.e., a single empty string.)
o 包含单个零字节的TXT记录。（即，单个空字符串。）
o An empty (zero-length) TXT record. (This is not strictly legal, but should one be received, it should be interpreted as the same as a single empty string.)
o 空（零长度）TXT记录。（这并不严格合法，但如果收到一个，则应将其解释为与单个空字符串相同。）
o No TXT record. (i.e., an NXDOMAIN or no-error-no-answer response.)
o 没有TXT记录。（即，NXDOMAIN或无错误无应答响应。）
The total size of a typical DNS-SD TXT record is intended to be small -- 200 bytes or less.
一个典型的DNS-SD TXT记录的总大小应该很小——不超过200字节。
In cases where more data is justified (e.g., LPR printing [BJP]), keeping the total size under 400 bytes should allow it to fit in a single 512-byte DNS message [RFC1035].
在需要更多数据的情况下（例如，LPR打印[BJP]），将总大小保持在400字节以下应允许其适合单个512字节DNS消息[RFC1035]。
In extreme cases where even this is not enough, keeping the size of the TXT record under 1300 bytes should allow it to fit in a single 1500-byte Ethernet packet.
在极端情况下，即使这还不够，将TXT记录的大小保持在1300字节以下应该允许它容纳在一个1500字节的以太网数据包中。
Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time.
此时不建议使用大于1300字节的TXT记录。
Note that some Ethernet hardware vendors offer chipsets with Multicast DNS [RFC6762] offload, so that computers can sleep and still be discoverable on the network. Early versions of such chipsets were sometimes quite limited: for example, some were
请注意，一些以太网硬件供应商提供具有多播DNS[RFC6762]卸载的芯片组，这样计算机就可以睡眠，并且仍然可以在网络上发现。这种芯片组的早期版本有时相当有限：例如，有些是
(unwisely) limited to handling TXT records no larger than 256 bytes (which meant that LPR printer services with larger TXT records did not work). Developers should be aware of this real-world limitation, and should understand that even hardware which is otherwise perfectly capable may have low-power and sleep modes that are more limited.
（不明智地）仅限于处理不超过256字节的TXT记录（这意味着具有较大TXT记录的LPR打印机服务无法工作）。开发人员应该意识到这一现实世界的局限性，并且应该理解，即使是功能完美的硬件，其低功耗和睡眠模式也可能受到更大的限制。
DNS-SD uses DNS TXT records to store arbitrary key/value pairs conveying additional information about the named service. Each key/value pair is encoded as its own constituent string within the DNS TXT record, in the form "key=value" (without the quotation marks). Everything up to the first '=' character is the key (Section 6.4). Everything after the first '=' character to the end of the string (including subsequent '=' characters, if any) is the value (Section 6.5). No quotation marks are required around the value, even if it contains spaces, '=' characters, or other punctuation marks. Each author defining a DNS-SD profile for discovering instances of a particular type of service should define the base set of key/value attributes that are valid for that type of service.
DNS-SD使用DNS TXT记录存储任意键/值对，以传递有关命名服务的附加信息。每个键/值对在DNS TXT记录中以“key=value”（不带引号）的形式编码为自己的组成字符串。第一个“=”字符之前的所有内容都是关键（第6.4节）。从第一个“=”字符到字符串末尾的所有字符（包括后续的“=”字符，如果有）都是值（第6.5节）。值周围不需要引号，即使它包含空格、“=”字符或其他标点符号。定义用于发现特定类型服务实例的DNS-SD配置文件的每个作者都应定义对该类型服务有效的键/值属性的基本集。
Using this standardized key/value syntax within the TXT record makes it easier for these base definitions to be expanded later by defining additional named attributes. If an implementation sees unknown keys in a service TXT record, it MUST silently ignore them.
在TXT记录中使用这种标准化的键/值语法，可以更容易地在以后通过定义其他命名属性来扩展这些基本定义。如果实现在服务TXT记录中看到未知键，它必须默默地忽略它们。
The target host name and TCP (or UDP) port number of the service are given in the SRV record. This information -- target host name and port number -- MUST NOT be duplicated using key/value attributes in the TXT record.
SRV记录中给出了服务的目标主机名和TCP（或UDP）端口号。不能使用TXT记录中的键/值属性复制此信息（目标主机名和端口号）。
The intention of DNS-SD TXT records is to convey a small amount of useful additional information about a service. Ideally, it should not be necessary for a client to retrieve this additional information before it can usefully establish a connection to the service. For a well-designed application protocol, even if there is no information at all in the TXT record, it should be possible, knowing only the host name, port number, and protocol being used, to communicate with that listening process and then perform version- or feature-negotiation to determine any further options or capabilities of the service instance. For example, when connecting to an AFP (Apple Filing Protocol) server [AFP] over TCP, the client enters into a protocol exchange with the server to determine which version of AFP the server implements and which optional features or capabilities (if any) are available.
DNS-SD TXT记录的目的是传递少量有关服务的有用附加信息。理想情况下，客户端在能够有效地建立到服务的连接之前，不必检索这些附加信息。对于设计良好的应用程序协议，即使TXT记录中没有任何信息，也应该可以只知道主机名、端口号和正在使用的协议，与该侦听过程通信，然后执行版本或功能协商，以确定服务实例的任何其他选项或功能。例如，当通过TCP连接到AFP（苹果归档协议）服务器[AFP]时，客户端与服务器进行协议交换，以确定服务器实现的AFP版本以及可用的可选功能或功能（如果有）。
For protocols designed with adequate in-band version- and feature-negotiation, any information in the TXT record should be viewed as a
对于设计有足够带内版本和功能协商的协议，TXT记录中的任何信息都应视为
performance optimization -- when a client discovers many instances of a service, the TXT record allows the client to know some rudimentary information about each instance without having to open a TCP connection to each one and interrogate every service instance separately. Care should be taken when doing this to ensure that the information in the TXT record is in agreement with the information that would be retrieved by a client connecting over TCP.
性能优化——当客户机发现一个服务的多个实例时，TXT记录允许客户机知道关于每个实例的一些基本信息，而无需打开到每个实例的TCP连接并分别询问每个服务实例。执行此操作时应小心，以确保TXT记录中的信息与通过TCP连接的客户端检索到的信息一致。
There are legacy protocols that provide no feature negotiation capability, and in these cases it may be useful to convey necessary information in the TXT record. For example, when printing using LPR [RFC1179], the LPR protocol provides no way for the client to determine whether a particular printer accepts PostScript, what version of PostScript, etc. In this case it is appropriate to embed this information in the TXT record [BJP], because the alternative would be worse -- passing around written instructions to the users, arcane manual configuration of "/etc/printcap" files, etc.
有一些遗留协议不提供功能协商功能，在这些情况下，在TXT记录中传递必要的信息可能很有用。例如，当使用LPR[RFC1179]打印时，LPR协议无法让客户端确定特定打印机是否接受PostScript、PostScript的版本等。在这种情况下，将此信息嵌入TXT记录[BJP]是合适的，因为替代方案会更糟糕——将书面指令传递给用户，神秘的“/etc/printcap”文件手动配置，等等。
The engineering decision about what keys to define for the TXT record needs to be decided on a case-by-case basis for each service type. For some service types it is appropriate to communicate information via the TXT record as well as (or instead of) via in-band communication in the application protocol.
关于为TXT记录定义哪些键的工程决策需要根据每个服务类型的具体情况来确定。对于某些服务类型，通过TXT记录以及（或代替）应用协议中的带内通信来传输信息是合适的。
The key MUST be at least one character. DNS-SD TXT record strings beginning with an '=' character (i.e., the key is missing) MUST be silently ignored.
密钥必须至少包含一个字符。必须以“=”字符开头的DNS-SD TXT记录字符串（即缺少密钥）被静默忽略。
The key SHOULD be no more than nine characters long. This is because it is beneficial to keep packet sizes small for the sake of network efficiency. When using DNS-SD in conjunction with Multicast DNS [RFC6762] this is important because multicast traffic is especially expensive on 802.11 wireless networks [IEEEW], but even when using conventional Unicast DNS, keeping the TXT records small helps improve the chance that responses will fit within the original DNS 512-byte size limit [RFC1035]. Also, each constituent string of a DNS TXT record is limited to 255 bytes, so excessively long keys reduce the space available for that key's values.
密钥长度不应超过9个字符。这是因为为了提高网络效率，保持数据包的小尺寸是有益的。当将DNS-SD与多播DNS[RFC6762]结合使用时，这一点很重要，因为在802.11无线网络[IEEW]上多播流量特别昂贵，但即使使用传统的单播DNS，保持TXT记录较小也有助于提高响应符合原始DNS 512字节大小限制[RFC1035]的可能性。此外，DNS TXT记录的每个组成字符串限制为255字节，因此过长的键会减少该键值的可用空间。
The keys in key/value pairs can be as short as a single character. A key name needs only to be unique and unambiguous within the context of the service type for which it is defined. A key name is intended solely to be a machine-readable identifier, not a human-readable essay giving detailed discussion of the purpose of a parameter, with a URL for a web page giving yet more details of the specification. For ease of development and debugging, it can be valuable to use key
键/值对中的键可以短至单个字符。密钥名只需在为其定义的服务类型的上下文中是唯一和明确的。密钥名仅用于机器可读的标识符，而不是提供参数用途详细讨论的人类可读文章，以及提供规范更多细节的网页URL。为了便于开发和调试，可以使用key
names that are mnemonic textual names, but excessively verbose keys are wasteful and inefficient, hence the recommendation to keep them to nine characters or fewer.
名称是助记文字名称，但过于冗长的键是浪费和低效的，因此建议将其保留为9个字符或更少。
The characters of a key MUST be printable US-ASCII values (0x20-0x7E) [RFC20], excluding '=' (0x3D).
键的字符必须是可打印的US-ASCII值（0x20-0x7E）[RFC20]，不包括“=”（0x3D）。
Spaces in the key are significant, whether leading, trailing, or in the middle -- so don't include any spaces unless you really intend that.
键中的空格是重要的，不管是引导的、尾随的还是中间的，所以除非你真的打算这样做，否则不要包含任何空格。
Case is ignored when interpreting a key, so "papersize=A4", "PAPERSIZE=A4", and "Papersize=A4" are all identical.
解释键时忽略大小写，因此“papersize=A4”、“papersize=A4”和“papersize=A4”都是相同的。
If there is no '=' in a DNS-SD TXT record string, then it is a boolean attribute, simply identified as being present, with no value.
如果DNS-SD TXT记录字符串中没有“=”，则它是一个布尔属性，仅标识为存在，没有值。
A given key SHOULD NOT appear more than once in a TXT record. The reason for this simplifying rule is to facilitate the creation of client libraries that parse the TXT record into an internal data structure (such as a hash table or dictionary object that maps from keys to values) and then make that abstraction available to client code. The rule that a given key may not appear more than once simplifies these abstractions because they aren't required to support the case of returning more than one value for a given key.
给定的键在TXT记录中不应出现多次。这种简化规则的原因是为了方便创建客户端库，这些库将TXT记录解析为内部数据结构（例如从键映射到值的哈希表或字典对象），然后将该抽象提供给客户端代码。给定键不能出现多次的规则简化了这些抽象，因为它们不需要支持为给定键返回多个值的情况。
If a client receives a TXT record containing the same key more than once, then the client MUST silently ignore all but the first occurrence of that attribute. For client implementations that process a DNS-SD TXT record from start to end, placing key/value pairs into a hash table using the key as the hash table key, this means that if the implementation attempts to add a new key/value pair into the table and finds an entry with the same key already present, then the new entry being added should be silently discarded instead. Client implementations that retrieve key/value pairs by searching the TXT record for the requested key should search the TXT record from the start and simply return the first matching key they find.
如果客户机多次收到包含相同密钥的TXT记录，则客户机必须以静默方式忽略该属性的第一次出现以外的所有内容。对于从头到尾处理DNS-SD TXT记录的客户端实现，将密钥/值对放置到哈希表中，使用该密钥作为哈希表密钥，这意味着如果实现尝试将新的密钥/值对添加到该表中，并发现已存在具有相同密钥的条目，然后添加的新条目应该被静默地丢弃。通过在TXT记录中搜索请求的键来检索键/值对的客户端实现应该从一开始就搜索TXT记录，并只返回找到的第一个匹配键。
When examining a TXT record for a given key, there are therefore four categories of results that may be returned:
因此，在检查给定密钥的TXT记录时，可能会返回四类结果：
* Attribute not present (Absent)
* 属性不存在（不存在）
* Attribute present, with no value (e.g., "passreq" -- password required for this service)
* 属性存在，没有值（例如，“passreq”--此服务所需的密码）
* Attribute present, with empty value (e.g., "PlugIns=" -- the server supports plugins, but none are presently installed)
* 属性present，值为空（例如，“PlugIns=“--服务器支持插件，但当前未安装任何插件）
* Attribute present, with non-empty value (e.g., "PlugIns=JPEG,MPEG2,MPEG4")
* 属性存在，具有非空值（例如，“PlugIns=JPEG、MPEG2、MPEG4”）
Each author defining a DNS-SD profile for discovering instances of a particular type of service should define the interpretation of these different kinds of result. For example, for some keys, there may be a natural true/false boolean interpretation:
每个定义DNS-SD配置文件以发现特定类型服务实例的作者都应该定义这些不同类型结果的解释。例如，对于某些键，可能存在自然的真/假布尔解释：
* Absent implies 'false' * Present implies 'true'
* 缺席意味着“假”*现在意味着“真”
For other keys it may be sensible to define other semantics, such as value/no-value/unknown:
对于其他键，可以定义其他语义，例如值/无值/未知：
* Present with value implies that value. (e.g., "Color=4" for a four-color ink-jet printer or "Color=6" for a six-color ink-jet printer)
* 以价值呈现意味着价值。（例如，四色喷墨打印机的颜色为“4”，六色喷墨打印机的颜色为“6”）
* Present with empty value implies 'false'. (e.g., not a color printer)
* 带空值的Present表示“false”。（例如，不是彩色打印机）
* Absent implies 'Unknown'. (e.g., a print server connected to some unknown printer where the print server doesn't actually know if the printer does color or not -- which gives a very bad user experience and should be avoided wherever possible)
* 缺席意味着“未知”。（例如，连接到某台未知打印机的打印服务器，打印服务器实际上不知道打印机是否有颜色，这会给用户带来非常糟糕的体验，应尽可能避免）
Note that this is a hypothetical example, not an example of actual key/value keys used by DNS-SD network printers, which are documented in the "Bonjour Printing Specification" [BJP].
请注意，这是一个假设的示例，而不是DNS-SD网络打印机使用的实际键/值键的示例，其记录在“Bonjour打印规范”[BJP]中。
If there is an '=' in a DNS-SD TXT record string, then everything after the first '=' to the end of the string is the value. The value can contain any eight-bit values including '='. The value MUST NOT
如果DNS-SD TXT记录字符串中有一个“=”，则字符串末尾第一个“=”之后的所有内容都是该值。该值可以包含任意八位值，包括“=”。该值不能为空
be enclosed in additional quotation marks or any similar punctuation; any quotation marks, or leading or trailing spaces, are part of the value.
用附加引号或任何类似标点符号括起来；任何引号、前导空格或尾随空格都是该值的一部分。
The value is opaque binary data. Often the value for a particular attribute will be US-ASCII [RFC20] or UTF-8 [RFC3629] text, but it is legal for a value to be any binary data.
该值是不透明的二进制数据。通常，特定属性的值将是US-ASCII[RFC20]或UTF-8[RFC3629]文本，但值为任何二进制数据是合法的。
Generic debugging tools should generally display all attribute values as a hex dump, with accompanying text alongside displaying the UTF-8 interpretation of those bytes, except for attributes where the debugging tool has embedded knowledge that the value is some other kind of data.
一般调试工具通常应将所有属性值显示为十六进制转储，并随附文本显示这些字节的UTF-8解释，但调试工具嵌入的值是其他类型数据的属性除外。
Authors defining DNS-SD profiles SHOULD NOT generically convert binary attribute data types into printable text using hexadecimal representation, Base-64 [RFC4648], or Unix-to-Unix (UU) encoding, merely for the sake of making the data appear to be printable text when seen in a generic debugging tool. Doing this simply bloats the size of the TXT record, without actually making the data any more understandable to someone looking at it in a generic debugging tool.
定义DNS-SD配置文件的作者不应使用十六进制表示法、Base-64[RFC4648]或Unix到Unix（UU）编码将二进制属性数据类型转换为可打印文本，仅仅是为了使数据在通用调试工具中显示为可打印文本。这样做只会增大TXT记录的大小，而不会使在通用调试工具中查看数据的人更容易理解数据。
The TXT record below contains three syntactically valid key/value strings. (The meaning of these key/value pairs, if any, would depend on the definitions pertaining to the service in question that is using them.)
下面的TXT记录包含三个语法有效的键/值字符串。（这些键/值对（如果有）的含义将取决于使用它们的相关服务的定义。）
-------------------------------------------------------
| 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
-------------------------------------------------------
-------------------------------------------------------
| 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
-------------------------------------------------------
It is recommended that authors defining DNS-SD profiles include an attribute of the form "txtvers=x", where "x" is a decimal version number in US-ASCII [RFC20] text (e.g., "txtvers=1" or "txtvers=8"), in their definition, and require it to be the first key/value pair in the TXT record. This information in the TXT record can be useful to help clients maintain backwards compatibility with older implementations if it becomes necessary to change or update the specification over time. Even if the profile author doesn't anticipate the need for any future incompatible changes, having a version number in the TXT record provides useful insurance should incompatible changes become unavoidable [RFC6709]. Clients SHOULD ignore TXT records with a txtvers number higher (or lower) than the version(s) they know how to interpret.
建议定义DNS-SD配置文件的作者在其定义中包括形式为“txtvers=x”的属性，其中“x”是US-ASCII[RFC20]文本中的十进制版本号（例如，“txtvers=1”或“txtvers=8”），并要求它是TXT记录中的第一个键/值对。如果需要随时间更改或更新规范，TXT记录中的这些信息有助于客户机保持与旧实现的向后兼容性。即使概要文件作者预计不需要将来进行任何不兼容的更改，如果不兼容的更改不可避免，在TXT记录中提供版本号也可以提供有用的保险[RFC6709]。客户机应该忽略txtvers编号高于（或低于）他们知道如何解释的版本的TXT记录。
Note that the version number in the txtvers tag describes the version of the specification governing the defined keys and the meaning of those keys for that particular TXT record, not the version of the application protocol that will be used if the client subsequently decides to contact that service. Ideally, every DNS-SD TXT record specification starts at txtvers=1 and stays that way forever. Improvements can be made by defining new keys that older clients silently ignore. The only reason to increment the version number is if the old specification is subsequently found to be so horribly broken that there's no way to do a compatible forward revision, so the txtvers number has to be incremented to tell all the old clients they should just not even try to understand this new TXT record.
请注意，txtvers标记中的版本号描述了管理已定义密钥的规范版本以及特定TXT记录中这些密钥的含义，而不是客户端随后决定联系该服务时将使用的应用程序协议版本。理想情况下，每个DNS-SD TXT记录规范从txtvers=1开始，并永远保持这种状态。可以通过定义旧客户端默默忽略的新密钥来进行改进。增加版本号的唯一原因是，如果随后发现旧规范严重破坏，无法进行兼容的正向修订，则必须增加txtvers号，以告知所有旧客户端，他们甚至不应该尝试理解此新TXT记录。
If there is a need to indicate which version number(s) of the application protocol the service implements, the recommended key for this is "protovers".
如果需要指示服务实现的应用程序协议的版本号，建议使用“protovers”键。
Generally speaking, every DNS-SD service instance has exactly one TXT record. However, it is possible for a particular protocol's DNS-SD advertising specification to state that it allows multiple TXT records. In this case, each TXT record describes a different variant of the same logical service, offered using the same underlying protocol on the same port, described by the same SRV record.
一般来说，每个DNS-SD服务实例都有一条TXT记录。但是，特定协议的DNS-SD广告规范可能会声明它允许多个TXT记录。在这种情况下，每个TXT记录描述同一逻辑服务的不同变体，在同一端口上使用相同的底层协议提供，由相同的SRV记录描述。
Having multiple TXT records to describe a single service instance is very rare, and to date, of the many hundreds of registered DNS-SD service types [SN], only one makes use of this capability, namely LPR printing [BJP]. This capability is used when a printer conceptually supports multiple logical queue names, where each different logical queue name implements a different page description language, such as 80-column monospaced plain text, seven-bit Adobe PostScript, eight-bit ("binary") PostScript, or some proprietary page description language. When multiple TXT records are used to describe multiple logical LPR queue names for the same underlying service, printers include two additional keys in each TXT record: 'qtotal', which specifies the total number of TXT records associated with this SRV record, and 'priority', which gives the printer's relative preference for this particular TXT record. Clients then select the most preferred TXT record that meets the client's needs [BJP]. The only reason multiple TXT records are used is because the LPR protocol lacks in-band feature-negotiation capabilities for the client and server to agree on a data representation for the print job, so this information has to be communicated out-of-band instead using the DNS-SD TXT records. Future protocol designs should not follow this bad example by mimicking this inadequacy of the LPR printing protocol.
拥有多个TXT记录来描述单个服务实例是非常罕见的，到目前为止，在数百种注册的DNS-SD服务类型[SN]中，只有一种使用了此功能，即LPR打印[BJP]。当打印机概念上支持多个逻辑队列名称时，使用此功能，其中每个不同的逻辑队列名称实现不同的页面描述语言，例如80列单间隔纯文本、7位Adobe PostScript、8位（“二进制”）PostScript或某些专有页面描述语言。当多个TXT记录用于描述同一基础服务的多个逻辑LPR队列名称时，打印机在每个TXT记录中包括两个附加键：“qtotal”，用于指定与此SRV记录关联的TXT记录总数，以及“优先级”，这将为打印机提供此特定TXT记录的相对首选项。然后，客户选择满足客户需求的最首选TXT记录[BJP]。使用多个TXT记录的唯一原因是，LPR协议缺少带内功能协商功能，客户端和服务器无法就打印作业的数据表示达成一致，因此必须使用DNS-SD TXT记录在带外传递此信息。未来的协议设计不应该模仿LPR打印协议的这一不足之处，从而效仿这个坏例子。
The <Service> portion of a Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782].
服务实例名称的<Service>部分由一对DNS标签组成，遵循已经为SRV记录建立的约定[RFC2782]。
The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it.
该对的第一个标签是下划线字符，后跟服务名称[RFC6335]。服务名称标识服务所做的事情及其使用的应用程序协议。
For applications using TCP, the second label is "_tcp".
对于使用TCP的应用程序，第二个标签是“\u TCP”。
For applications using any transport protocol other than TCP, the second label is "_udp". This applies to all other transport protocols, including User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control Protocol (DCCP) [RFC4340], Adobe's Real Time Media Flow Protocol (RTMFP), etc. In retrospect, perhaps the SRV specification should not have used the "_tcp" and "_udp" labels at all, and instead should have used a single label "_srv" to carve off a subdomain of DNS namespace for this use, but that specification is already published and deployed. At this point there is no benefit in changing established practice. While "_srv" might be aesthetically nicer than "_udp", it is not a user-visible string, and all that is required protocol-wise is (i) that it be a label that can form a DNS delegation point, and (ii) that it be short so that it does not take up too much space in the packet, and in this respect either "_udp" or "_srv" is equally good. Thus, it makes sense to use "_tcp" for TCP-based services and "_udp" for all other transport protocols -- which are in fact, in today's world, often encapsulated over UDP -- rather than defining a new subdomain for every new transport protocol.
对于使用TCP以外的任何传输协议的应用程序，第二个标签是“_udp”。这适用于所有其他传输协议，包括用户数据报协议（UDP）、流控制传输协议（SCTP）[RFC4960]、数据报拥塞控制协议（DCCP）[RFC4340]、Adobe的实时媒体流协议（RTMFP）等。回顾过去，SRV规范可能不应该使用“tcp”和“UDP”标签，而是应该使用单个标签“\u srv”来分割DNS命名空间的子域以用于此用途，但该规范已经发布和部署。在这一点上，改变既定做法毫无益处。虽然“_srv”在美学上可能比“_udp”更好，但它不是用户可见的字符串，协议方面所需的只是（i）它是一个可以形成DNS委托点的标签，并且（ii）它要短，以便不会在数据包中占用太多空间，在这方面“_udp”或“_srv”都同样好。因此，对基于tcp的服务使用“_tcp”和对所有其他传输协议使用“_udp”是有意义的，而不是为每个新的传输协议定义一个新的子域。事实上，在当今世界，这些协议通常是通过udp封装的。
Note that this usage of the "_udp" label for all protocols other than TCP applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. Other specifications that are independent of DNS-SD and not intended to interoperate with DNS-SD records are not in any way constrained by how DNS-SD works just because they also use the DNS SRV record datatype [RFC2782]; they are free to specify their own naming conventions as appropriate.
请注意，对于TCP以外的所有协议使用的“_udp”标签仅适用于DNS-SD服务广告，即使用本文档中指定的PTR+SRV+TXT约定广告的服务。一般来说，这不是SRV记录的要求。独立于DNS-SD且不打算与DNS-SD记录互操作的其他规范不受DNS-SD工作方式的任何限制，因为它们也使用DNS SRV记录数据类型[RFC2782]；他们可以根据需要自由指定自己的命名约定。
The rules for Service Names [RFC6335] state that they may be no more than fifteen characters long (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, must not contain consecutive hyphens, and must contain at least one letter. The requirement to contain at least one letter is to disallow Service Names such as "80" or
服务名称规则[RFC6335]规定，它们的长度不得超过15个字符（不包括强制下划线），仅由字母、数字和连字符组成，必须以字母或数字开头和结尾，不得包含连续连字符，并且必须至少包含一个字母。至少包含一个字母的要求是不允许服务名称，如“80”或
"6000-6063", which could be misinterpreted as port numbers or port number ranges. While both uppercase and lowercase letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings "HTTP" and "http" refer to the same service.
“6000-6063”，可能被误解为端口号或端口号范围。虽然大写和小写字母都可以用于助记，但出于比较目的，大小写被忽略，因此字符串“HTTP”和“HTTP”引用相同的服务。
Wise selection of a Service Name is important, and the choice is not always as obvious as it may appear.
明智地选择服务名称很重要，而且选择并不总是像看上去那么明显。
In many cases, the Service Name merely names and refers to the on-the-wire message format and semantics being used. FTP is "ftp", IPP printing is "ipp", and so on.
在许多情况下，服务名称只是命名和引用正在使用的在线消息格式和语义。FTP是“FTP”，IPP打印是“IPP”，依此类推。
However, it is common to "borrow" an existing protocol and repurpose it for a new task. This is entirely sensible and sound engineering practice, but that doesn't mean that the new protocol is providing the same semantic service as the old one, even if it borrows the same message formats. For example, the network music sharing protocol implemented by iTunes on Macintosh and Windows is built upon "HTTP GET" commands. However, that does *not* mean that it is sensible or useful to try to access one of these music servers by connecting to it with a standard web browser. Consequently, the DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" (Digital Audio Access Protocol), not "_http._tcp".
然而，“借用”现有协议并将其重新用于新任务是很常见的。这是完全合理的工程实践，但这并不意味着新协议提供与旧协议相同的语义服务，即使它借用了相同的消息格式。例如，iTunes在Macintosh和Windows上实现的网络音乐共享协议是基于“HTTP GET”命令构建的。然而，这并不意味着通过标准的网络浏览器连接音乐服务器来访问其中一个音乐服务器是明智的或有用的。因此，iTunes发布（和浏览）的DNS-SD服务是“数字音频访问协议”，而不是“http.\U tcp”。
If iTunes were to advertise that it offered "_http._tcp" service, that would cause iTunes servers to appear in conventional web browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox, Chrome, etc.), which is of little use since an iTunes music library offers no HTML pages containing human-readable content that a web browser could display.
如果iTunes发布广告说它提供了“http.\u tcp”服务，这将导致iTunes服务器出现在传统的web浏览器（Safari、Camino、OmniWeb、Internet Explorer、Firefox、Chrome等）中，这几乎没有什么用处，因为iTunes音乐库不提供包含web浏览器可以显示的人类可读内容的HTML页面。
Equally, if iTunes were to browse for "_http._tcp" service, that would cause it to discover generic web servers, such as the embedded web servers in devices like printers, which is of little use since printers generally don't have much music to offer.
同样，如果iTunes要浏览“\u http.\u tcp”服务，这将导致它发现通用的web服务器，例如打印机等设备中的嵌入式web服务器，这一点用处不大，因为打印机通常没有多少音乐可供提供。
Analogously, Sun Microsystems's Network File System (NFS) is built on top of Sun Microsystems's Remote Procedure Call (Sun RPC) mechanism, but that doesn't mean it makes sense for an NFS server to advertise that it provides "Sun RPC" service. Likewise, Microsoft's Server Message Block (SMB) file service is built on top of Netbios running over IP, but that doesn't mean it makes sense for an SMB file server to advertise that it provides "Netbios-over-IP" service. The DNS-SD name of a service needs to encapsulate both the "what" (semantics) and the "how" (protocol implementation) of the service, since knowledge of both is necessary for a client to use the service meaningfully. Merely advertising that a service was built on top of Sun RPC is no use if the client has no idea what the service does.
类似地，Sun Microsystems的网络文件系统（NFS）构建在Sun Microsystems的远程过程调用（Sun RPC）机制之上，但这并不意味着NFS服务器宣传它提供“Sun RPC”服务是有意义的。同样，Microsoft的服务器消息块（SMB）文件服务构建在通过IP运行的Netbios之上，但这并不意味着SMB文件服务器宣传其提供“通过IP运行的Netbios”服务是有意义的。服务的DNS-SD名称需要封装服务的“what”（语义）和“how”（协议实现），因为客户机要有意义地使用服务，必须了解这两者。如果客户机不知道服务是做什么的，那么仅仅宣传服务是建立在Sun RPC之上是没有用的。
Another common question is whether the service type advertised by iTunes should be "_daap._http._tcp." This would also be incorrect. Similarly, a protocol designer implementing a network service that happens to use the Simple Object Access Protocol [SOAP] should not feel compelled to have "_soap" appear somewhere in the Service Name. Part of the confusion here is that the presence of "_tcp" or "_udp" in the <Service> portion of a Service Instance Name has led people to assume that the visible structure of the <Service> should reflect the private internal structure of how the protocol was implemented. This is not correct. All that is required is that the service be identified by some unique opaque Service Name. Making the Service Name be English text that is at least marginally descriptive of what the service does may be convenient, but it is by no means essential.
另一个常见的问题是iTunes发布的服务类型是否应该是“\u daap.\u http.\u tcp”。这也是不正确的。类似地，实现碰巧使用简单对象访问协议[SOAP]的网络服务的协议设计器不应该被迫在服务名称中的某个位置显示“\uSOAP”。这里的混乱部分在于，服务实例名称的<Service>部分中存在“_tcp”或“_udp”，这导致人们认为<Service>的可见结构应该反映协议实现方式的私有内部结构。这是不对的。所需的只是通过一些唯一的不透明服务名称来标识服务。使服务名称成为英文文本，至少在一定程度上描述服务的功能可能是方便的，但这绝不是必需的。
This document does not attempt to define a sophisticated (e.g., Turing complete, or even regular expression) query language for service discovery, nor do we believe one is necessary.
本文档并不试图为服务发现定义一种复杂的查询语言（例如图灵完全，甚至正则表达式），我们也不认为有必要这样做。
However, there are some limited circumstances where narrowing the set of results may be useful. For example, many network printers offer a web-based user interface, for management and administration, using HTML/HTTP. A web browser wanting to discover all advertised web pages issues a query for "_http._tcp.<Domain>". On the other hand, there are cases where users wish to manage printers specifically, not to discover web pages in general, and it is good accommodate this. In this case, we define the "_printer" subtype of "_http._tcp", and to discover only the subset of pages advertised as having that subtype property, the web browser issues a query for "_printer._sub._http._tcp.<Domain>".
然而，在某些有限的情况下，缩小结果集可能是有用的。例如，许多网络打印机使用HTML/HTTP提供基于web的用户界面，用于管理和管理。希望发现所有播发网页的web浏览器会对“\u http.\u tcp.<Domain>”发出查询。另一方面，在某些情况下，用户希望专门管理打印机，而不是一般地发现网页，这是很好的解决方案。在本例中，我们定义了“\u http.\u tcp”的“\u printer”子类型，为了只发现广告中具有该子类型属性的页面子集，web浏览器会发出一个查询“\u printer.\u sub.\u http.\u tcp.<Domain>”。
The Safari web browser on Mac OS X 10.5 "Leopard" and later uses subtypes in this way. If an "_http._tcp" service is discovered both via "_printer._sub._http._tcp" browsing and via "_http._tcp" browsing then it is displayed in the "Printers" section of Safari's UI. If a service is discovered only via "_http._tcp" browsing then it is displayed in the "Webpages" section of Safari's UI. This can be seen by using the commands below on Mac OS X to advertise two "fake" services. The service instance "A web page" is displayed in the "Webpages" section of Safari's Bonjour list, while the instance "A printer's web page" is displayed in the "Printers" section.
Mac OS X 10.5“Leopard”及更高版本上的Safari web浏览器以这种方式使用子类型。如果通过“\u printer.\u sub.\u http.\u tcp”浏览和“\u http.\u tcp”浏览发现了“\u http.\u tcp”服务，则该服务将显示在Safari用户界面的“打印机”部分。如果仅通过“\u http.\u tcp”浏览发现服务，则该服务将显示在Safari用户界面的“网页”部分。这可以通过在MacOSX上使用下面的命令来宣传两个“假”服务。服务实例“A网页”显示在Safari的“你好”列表的“网页”部分，而实例“A打印机的网页”显示在“打印机”部分。
dns-sd -R "A web page" _http._tcp local 100 dns-sd -R "A printer's web page" _http._tcp,_printer local 101
dns sd-R“一个网页”\u http.\u tcp本地100 dns sd-R“一个打印机的网页”\u http.\u tcp，\u打印机本地101
Note that the advertised web page's Service Instance Name is unchanged by the use of subtypes -- it is still something of the form
请注意，广告网页的服务实例名称因子类型的使用而保持不变——它仍然是某种形式
"The Server._http._tcp.example.com.", and the advertised web page is still discoverable using a standard browsing query for services of type "_http._tcp". The subdomain in which HTTP server SRV records are registered defines the namespace within which HTTP server names are unique. Additional subtypes (e.g., "_printer") of the basic service type (e.g., "_http._tcp") serve to allow clients to query for a narrower set of results, not to create more namespace.
“服务器._http._tcp.example.com.”，并且使用类型为“_http._tcp”的服务的标准浏览查询仍然可以发现播发的网页。注册HTTP服务器SRV记录的子域定义了HTTP服务器名称唯一的命名空间。基本服务类型（例如“\u http.\u tcp”）的附加子类型（例如“\u printer”）用于允许客户端查询更窄的结果集，而不是创建更多的命名空间。
Using DNS zone file syntax, the service instance "A web page" is advertised using one PTR record, while the instance "A printer's web page" is advertised using two: the primary service type and the additional subtype. Even though the "A printer's web page" service is advertised two different ways, both PTR records refer to the name of the same SRV+TXT record pair:
使用DNS区域文件语法，服务实例“A网页”使用一条PTR记录进行播发，而实例“A打印机的网页”使用两条记录进行播发：主服务类型和附加子类型。尽管“打印机网页”服务以两种不同的方式发布，但两条PTR记录都引用同一SRV+TXT记录对的名称：
; One PTR record advertises "A web page" _http._tcp.local. PTR A\032web\032page._http._tcp.local.
; 一条PTR记录宣传“一个网页”\u http.\u tcp.local。PTR A\032web\032页面。\u http.\u tcp.local。
; Two different PTR records advertise "A printer's web page" _http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local. _printer._sub._http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local.
; 两个不同的PTR记录宣传“打印机的网页”\u http.\u tcp.local。PTR A\032打印机的\032web\032页面。\u http.\u tcp.local_打印机。\u sub.\u http.\u tcp.local。PTR A\032打印机的\032web\032页面。\u http.\u tcp.local。
Subtypes are appropriate when it is desirable for different kinds of client to be able to browse for services at two levels of granularity. In the example above, we describe two classes of HTTP clients: general web browsing clients that are interested in all web pages, and specific printer management tools that would like to discover only web UI pages advertised by printers. The set of HTTP servers on the network is the same in both cases; the difference is that some clients want to discover all of them, whereas other clients only want to find the subset of HTTP servers whose purpose is printer administration.
当不同类型的客户端需要能够在两个粒度级别上浏览服务时，子类型是合适的。在上面的示例中，我们描述了两类HTTP客户机：对所有web页面感兴趣的通用web浏览客户机，以及只希望发现打印机广告的web UI页面的特定打印机管理工具。在这两种情况下，网络上的HTTP服务器集是相同的；不同之处在于，一些客户端希望发现所有这些服务器，而其他客户端只希望找到用于打印机管理的HTTP服务器的子集。
Subtypes are only appropriate in two-level scenarios such as this one, where some clients want to find the full set of services of a given type, and at the same time other clients only want to find some subset. Generally speaking, if there is no client that wants to find the entire set, then it's neither necessary nor desirable to use the subtype mechanism. If all clients are browsing for some particular subtype, and no client exists that browses for the parent type, then a new Service Name representing the logical service should be defined, and software should simply advertise and browse for that particular service type directly. In particular, just because a particular network service happens to be implemented in terms of some other underlying protocol, like HTTP, Sun RPC, or SOAP, doesn't mean that it's sensible for that service to be defined as a subtype of "_http", "_sunrpc", or "_soap". That would only be useful if there
子类型仅适用于两级场景，如本场景，其中一些客户端希望查找给定类型的完整服务集，而其他客户端只希望查找某些子集。一般来说，如果没有客户机希望找到整个集合，那么使用子类型机制既不必要也不可取。如果所有客户端都在浏览某个特定的子类型，并且不存在浏览父类型的客户端，那么应该定义一个表示逻辑服务的新服务名称，并且软件应该直接播发和浏览该特定服务类型。特别是，仅仅因为某个特定的网络服务碰巧是根据其他一些底层协议（如HTTP、Sun RPC或SOAP）实现的，并不意味着将该服务定义为“_HTTP”、“_Sun RPC”或“_SOAP”的子类型是明智的。只有在有必要的情况下，这才是有用的
were some class of client for which it is sensible to say, "I want to discover a service on the network, and I don't care what it does, as long as it does it using the SOAP XML RPC mechanism."
对于某类客户机，可以说：“我想在网络上发现服务，我不在乎它做什么，只要它使用SOAP XML RPC机制就行。”
Subtype strings are not required to begin with an underscore, though they often do. As with the TXT record key/value pairs, the list of possible subtypes, if any (including whether some or all begin with an underscore) are defined and specified separately for each basic service type.
子类型字符串不需要以下划线开头，尽管它们通常以下划线开头。与TXT记录键/值对一样，为每个基本服务类型分别定义和指定可能的子类型列表（如果有）（包括部分或全部是否以下划线开头）。
Subtype strings (e.g., "_printer" in the example above) may be constructed using arbitrary 8-bit data values. In many cases these data values may be UTF-8 [RFC3629] representations of text, or even (as in the example above) plain ASCII [RFC20], but they do not have to be. Note, however, that even when using arbitrary 8-bit data for subtype strings, DNS name comparisons are still case-insensitive, so (for example) the byte values 0x41 and 0x61 will be considered equivalent for subtype comparison purposes.
子类型字符串（例如，上面示例中的“_printer”）可以使用任意8位数据值构造。在许多情况下，这些数据值可能是文本的UTF-8[RFC3629]表示，甚至（如上例所示）纯ASCII[RFC20]，但它们不必是。但是，请注意，即使对子类型字符串使用任意8位数据，DNS名称比较仍然不区分大小写，因此（例如）出于子类型比较的目的，字节值0x41和0x61将被视为等效。
As specified above, Service Names are allowed to be no more than fifteen characters long. The reason for this limit is to conserve bytes in the domain name for use both by the network administrator (choosing service domain names) and by the end user (choosing instance names).
如上所述，服务名称的长度不允许超过15个字符。此限制的原因是保留域名中的字节，以供网络管理员（选择服务域名）和最终用户（选择实例名称）使用。
A fully qualified domain name may be up to 255 bytes long, plus one byte for the final terminating root label at the end. Domain names used by DNS-SD take the following forms:
一个完全限定的域名可能最多有255个字节长，加上最后一个终止根标签的一个字节。DNS-SD使用的域名采用以下形式：
<sn>._tcp . <servicedomain> . <parentdomain>. <Instance> . <sn>._tcp . <servicedomain> . <parentdomain>. <sub>._sub . <sn>._tcp . <servicedomain> . <parentdomain>.
<sn>\u tcp<servicedomain><父域><实例><sn>\u tcp<servicedomain><父域><sub>\u sub<sn>\u tcp<servicedomain><父域>。
The first example shows the name used for PTR queries. The second shows a Service Instance Name, i.e., the name of the service's SRV and TXT records. The third shows a subtype browsing name, i.e., the name of a PTR record pointing to a Service Instance Name (see Section 7.1, "Selective Instance Enumeration").
第一个示例显示用于PTR查询的名称。第二个显示服务实例名称，即服务的SRV和TXT记录的名称。第三个显示子类型浏览名称，即指向服务实例名称的PTR记录的名称（参见第7.1节“选择性实例枚举”）。
The Service Name <sn> may be up to 15 bytes, plus the underscore and length byte, making a total of 17. Including the "_udp" or "_tcp" and its length byte, this makes 22 bytes.
服务名称<sn>最多可以是15个字节，加上下划线和长度字节，总共是17个字节。包括“_udp”或“_tcp”及其长度字节，这将产生22个字节。
The instance name <Instance> may be up to 63 bytes. Including the length byte used by the DNS format when the name is stored in a packet, that makes 64 bytes.
实例名<instance>最多可包含63个字节。包括名称存储在数据包中时DNS格式使用的长度字节，即64个字节。
When using subtypes, the subtype identifier is allowed to be up to 63 bytes, plus the length byte, making 64. Including the "_sub" and its length byte, this makes 69 bytes.
使用子类型时，子类型标识符最多允许为63字节，加上长度字节，即64字节。包括“_sub”及其长度字节，这将产生69个字节。
Typically, DNS-SD service records are placed into subdomains of their own beneath a company's existing domain name. Since these subdomains are intended to be accessed through graphical user interfaces, not typed on a command line, they are frequently long and descriptive. Including the length byte, the user-visible service domain may be up to 64 bytes.
通常，DNS-SD服务记录放置在公司现有域名下的子域中。由于这些子域旨在通过图形用户界面访问，而不是在命令行上键入，因此它们通常很长且具有描述性。包括长度字节，用户可见服务域可能最多为64字节。
Of our available 255 bytes, we have now accounted for 69+22+64 = 155 bytes. This leaves 100 bytes to accommodate the organization's existing domain name <parentdomain>. When used with Multicast DNS, <parentdomain> is "local.", which easily fits. When used with parent domains of 100 bytes or less, the full functionality of DNS-SD is available without restriction. When used with parent domains longer than 100 bytes, the protocol risks exceeding the maximum possible length of domain names, causing failures. In this case, careful choice of short <servicedomain> names can help avoid overflows. If the <servicedomain> and <parentdomain> are too long, then service instances with long instance names will not be discoverable or resolvable, and applications making use of long subtype names may fail.
在可用的255个字节中，我们现在占69+22+64=155个字节。这将留下100个字节来容纳组织的现有域名<parentdomain>。当与多播DNS一起使用时，<parentdomain>是“本地的”，这很容易适应。当与100字节或更少的父域一起使用时，DNS-SD的完整功能不受限制。当与长度超过100字节的父域一起使用时，协议可能会超过域名的最大可能长度，从而导致失败。在这种情况下，仔细选择短<servicedomain>名称有助于避免溢出。如果<servicedomain>和<parentdomain>太长，则具有长实例名称的服务实例将无法发现或解析，并且使用长子类型名称的应用程序可能会失败。
Because of this constraint, we choose to limit Service Names to 15 characters or less. Allowing more characters would not increase the expressive power of the protocol and would needlessly reduce the maximum <parentdomain> length that may be safely used.
由于这个限制，我们选择将服务名称限制为15个字符或更少。允许更多字符不会增加协议的表达能力，并且会不必要地减少可安全使用的最大<parentdomain>长度。
Note that <Instance> name lengths affect the maximum number of services of a given type that can be discovered in a given <servicedomain>. The largest Unicast DNS response than can be sent (typically using TCP, not UDP) is 64 kB. Using DNS name compression, a Service Instance Enumeration PTR record requires 2 bytes for the (compressed) name, plus 10 bytes for type, class, ttl, and rdata length. The rdata of the PTR record requires up to 64 bytes for the <Instance> part of the name, plus 2 bytes for a name compression pointer to the common suffix, making a maximum of 78 bytes total. This means that using maximum-sized <Instance> names, up to 839 instances of a given service type can be discovered in a given <servicedomain>.
请注意，<Instance>名称长度会影响在给定的<servicedomain>中可以发现的给定类型的最大服务数。可以发送的最大单播DNS响应（通常使用TCP，而不是UDP）为64 kB。使用DNS名称压缩，服务实例枚举PTR记录需要2个字节的（压缩）名称，加上10个字节的类型、类、ttl和rdata长度。PTR记录的rdata要求名称的<Instance>部分最多64个字节，加上指向公共后缀的名称压缩指针2个字节，总共最多78个字节。这意味着使用最大大小的<Instance>名称，在给定的<servicedomain>中最多可以发现839个给定服务类型的实例。
Multicast DNS aggregates response packets, so it does not have the same hard limit, but in practice it is also useful for up to a few hundred instances of a given service type, but probably not thousands.
多播DNS聚合响应数据包，因此它没有相同的硬限制，但在实践中，它对于给定服务类型的数百个实例（可能不是数千个）也很有用。
However, displaying even 100 instances in a flat list is probably too many to be helpful to a typical user. If a network has more than 100 instances of a given service type, it's probably appropriate to divide those services into logical subdomains by building, by floor, by department, etc.
但是，在一个平面列表中显示100个实例可能太多，对典型用户来说没有帮助。如果一个网络有100多个给定服务类型的实例，那么按建筑物、楼层、部门等将这些服务划分为逻辑子域可能是合适的。
In some cases, there may be several network protocols available that all perform roughly the same logical function. For example, the printing world has the lineprinter (LPR) protocol [RFC1179] and the Internet Printing Protocol (IPP) [RFC2910], both of which cause printed sheets to be emitted from printers in much the same way. In addition, many printer vendors send their own proprietary page description language (PDL) data over a TCP connection to TCP port 9100, herein referred to generically as the "pdl-datastream" protocol. In an ideal world, we would have only one network printing protocol, and it would be sufficiently good that no one felt a compelling need to invent a different one. However, in practice, multiple legacy protocols do exist, and a service discovery protocol has to accommodate that.
在某些情况下，可能有几种可用的网络协议，它们都执行大致相同的逻辑功能。例如，打印世界有lineprinter（LPR）协议[RFC1179]和Internet打印协议（IPP）[RFC2910]，这两种协议都导致打印纸张以几乎相同的方式从打印机发出。此外，许多打印机供应商通过TCP连接将他们自己的专有页面描述语言（PDL）数据发送到TCP端口9100，这里通常称为“PDL数据流”协议。在一个理想的世界里，我们只有一个网络打印协议，这就足够好了，没有人觉得迫切需要发明一个不同的协议。然而，在实践中，确实存在多个遗留协议，服务发现协议必须适应这一点。
Many printers implement all three printing protocols: LPR, IPP, and pdl-datastream. For the benefit of clients that may speak only one of those protocols, all three are advertised.
许多打印机实现所有三种打印协议：LPR、IPP和pdl数据流。为了使可能只使用其中一种协议的客户机受益，所有三种协议都会被公布。
However, some clients may implement two, or all three of those printing protocols. When a client looks for all three service types on the network, it will find three distinct services -- an LPR service, an IPP service, and a pdl-datastream service -- all of which cause printed sheets to be emitted from the same physical printer.
但是，一些客户端可能实现两个或全部三个打印协议。当客户端在网络上查找所有三种服务类型时，它将发现三种不同的服务—LPR服务、IPP服务和pdl数据流服务—所有这些服务都会导致打印的纸张从同一台物理打印机发出。
In a case like this, where multiple protocols all perform effectively the same function, a client may browse for all the service types it supports and display all the discovered instance names in a single aggregated list. Where the same instance name is discovered more than once because that entity supports more than one service type (e.g. a single printer which implements multiple printing protocols) the duplicates should be suppressed and the name should appear only once in the list. When the user indicates their desire to print on a given named printer, the printing client is responsible for choosing which of the available protocols will best achieve the desired effect, without, for example, requiring the user to make a manual choice between LPR and IPP.
在这种情况下，当多个协议都有效地执行相同的功能时，客户端可以浏览它支持的所有服务类型，并在单个聚合列表中显示所有发现的实例名称。如果由于实体支持多种服务类型（例如，实现多种打印协议的单个打印机）而多次发现同一实例名称，则应抑制重复项，并且名称应仅在列表中出现一次。当用户表示希望在指定的打印机上打印时，打印客户端负责选择哪种可用协议最能达到预期效果，而无需用户在LPR和IPP之间进行手动选择。
As described so far, this all works very well. However, consider the case of: some future printer that only supports IPP printing, and some other future printer that only supports pdl-datastream printing.
正如到目前为止所描述的，这一切都非常有效。但是，考虑以下情况：一些未来的打印机只支持IPP打印，以及一些其他未来的打印机，只支持PDL数据流打印。
The namespaces for different service types are intentionally disjoint (it is acceptable and desirable to be able to have both a file server called "Sales Department" and a printer called "Sales Department"). However, it is not desirable, in the common case, to allow two different printers both to be called "Sales Department" merely because those two printers implement different printing protocols.
不同服务类型的名称空间故意不相交（可以接受并希望同时拥有名为“Sales Department”的文件服务器和名为“Sales Department”的打印机）。然而，在常见情况下，不希望仅仅因为两台不同的打印机实现不同的打印协议，就允许两台不同的打印机都被称为“销售部门”。
To help guard against this, when there are two or more network protocols that perform roughly the same logical function, one of the protocols is declared the "flagship" of the fleet of related protocols. Typically the flagship protocol is the oldest and/or best-known protocol of the set.
为了帮助防范这种情况，当有两个或多个网络协议执行大致相同的逻辑功能时，其中一个协议被宣布为相关协议组的“旗舰”。通常，旗舰协议是集合中最古老和/或最知名的协议。
If a device does not implement the flagship protocol, then it instead creates a placeholder SRV record (priority=0, weight=0, port=0, target host = host name of device) with that name. If, when it attempts to create this SRV record, it finds that a record with the same name already exists, then it knows that this name is already taken by some other entity implementing at least one of the protocols from the fleet, and it must choose another. If no SRV record already exists, then the act of creating it stakes a claim to that name so that future devices in the same protocol fleet will detect a conflict when they try to use it.
如果设备未实现旗舰协议，则它将使用该名称创建占位符SRV记录（优先级=0，权重=0，端口=0，目标主机=设备的主机名）。如果在尝试创建此SRV记录时，它发现已存在同名记录，则它知道此名称已被实施车队中至少一个协议的其他实体使用，并且它必须选择另一个。如果SRV记录不存在，那么创建该记录的行为就意味着对该名称的声明，以便同一协议组中的未来设备在尝试使用该记录时能够检测到冲突。
Note: When used with Multicast DNS [RFC6762], the target host field of the placeholder SRV record MUST NOT be the empty root label. The SRV record needs to contain a real target host name in order for the Multicast DNS conflict detection rules to operate. If two different devices were to create placeholder SRV records both using a null target host name (just the root label), then the two SRV records would be seen to be in agreement, and no conflict would be detected.
注意：当与多播DNS[RFC6762]一起使用时，占位符SRV记录的目标主机字段不能是空的根标签。SRV记录需要包含真实的目标主机名，以便多播DNS冲突检测规则能够运行。如果两个不同的设备使用空目标主机名（仅根标签）创建占位符SRV记录，则两个SRV记录将被视为一致，并且不会检测到冲突。
By defining a common well-known flagship protocol for the class, future devices that may not even know about each other's protocols establish a common ground where they can coordinate to verify uniqueness of names.
通过为该类定义一个通用的、众所周知的旗舰协议，未来的设备甚至可能不知道彼此的协议，从而建立了一个共同点，在这里它们可以协调以验证名称的唯一性。
No PTR record is created advertising the presence of empty flagship SRV records, since they do not represent a real service being advertised, and hence are not (and should not be) discoverable via Service Instance Enumeration (browsing).
没有创建任何PTR记录来显示空旗舰SRV记录的存在，因为它们不代表正在发布的真实服务，因此不能（也不应该）通过服务实例枚举（浏览）发现。
In general, a normal client is not interested in finding *every* service on the network, just the services that the client knows how to use.
一般来说，普通客户机对查找网络上的*每个*服务不感兴趣，只对客户机知道如何使用的服务感兴趣。
However, for problem diagnosis and network management tools, it may be useful for network administrators to find the list of advertised service types on the network, even if those Service Names are just opaque identifiers and not particularly informative in isolation.
但是，对于问题诊断和网络管理工具，网络管理员可以查找网络上公布的服务类型列表，即使这些服务名称只是不透明的标识符，并且单独提供的信息不多。
For this purpose, a special meta-query is defined. A DNS query for PTR records with the name "_services._dns-sd._udp.<Domain>" yields a set of PTR records, where the rdata of each PTR record is the two-label <Service> name, plus the same domain, e.g., "_http._tcp.<Domain>". Including the domain in the PTR rdata allows for slightly better name compression in Unicast DNS responses, but only the first two labels are relevant for the purposes of service type enumeration. These two-label service types can then be used to construct subsequent Service Instance Enumeration PTR queries, in this <Domain> or others, to discover instances of that service type.
为此，定义了一个特殊的元查询。对名为“\u services.\u DNS-sd.\u udp.<Domain>”的PTR记录的DNS查询将生成一组PTR记录，其中每个PTR记录的rdata是两个标签<Service>名称加上相同的域，例如“\u http.\u tcp.<Domain>”。在PTR rdata中包含域允许在单播DNS响应中稍微更好地压缩名称，但只有前两个标签与服务类型枚举相关。然后，可以使用这两种标签服务类型在此<Domain>或其他位置构建后续服务实例枚举PTR查询，以发现该服务类型的实例。
How a service's PTR, SRV, and TXT records make their way into the DNS is outside the scope of this document, but, for illustrative purposes, some examples are given here.
服务的PTR、SRV和TXT记录如何进入DNS不在本文档的范围内，但为了说明目的，这里给出了一些示例。
On some networks, the administrator might manually enter the records into the name server's configuration file.
在某些网络上，管理员可能会手动将记录输入到名称服务器的配置文件中。
A network monitoring tool could output a standard zone file to be read into a conventional DNS server. For example, a tool that can find networked PostScript laser printers using AppleTalk NBP could find the list of printers, communicate with each one to find its IP address, PostScript version, installed options, etc., and then write out a DNS zone file describing those printers and their capabilities using DNS resource records. That information would then be available to IP-only clients that implement DNS-SD but not AppleTalk NBP.
网络监控工具可以输出一个标准区域文件，以便读取到传统DNS服务器中。例如，可以使用AppleTalk NBP查找联网PostScript激光打印机的工具可以找到打印机列表，与每个打印机通信以查找其IP地址、PostScript版本、安装选项等，然后使用DNS资源记录写出DNS区域文件，描述这些打印机及其功能。然后，该信息将可用于实现DNS-SD而非AppleTalk NBP的仅限IP的客户端。
A printer manager device that has knowledge of printers on the network through some other management protocol could also output a zone file or use DNS Update [RFC2136] [RFC3007].
通过某些其他管理协议了解网络上打印机的打印机管理器设备也可以输出区域文件或使用DNS更新[RFC2136][RFC3007]。
Alternatively, a printer manager device could implement enough of the DNS protocol that it is able to answer DNS queries directly, and Example Co.'s main DNS server could delegate the "_ipp._tcp.example.com." subdomain to the printer manager device.
或者，打印机管理器设备可以实现足够多的DNS协议，从而能够直接回答DNS查询，Example Co.的主DNS服务器可以将“\u ipp.\u tcp.Example.com.”子域委托给打印机管理器设备。
IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] to automatically register their own PTR, SRV, and TXT records with the DNS server.
IP打印机可以使用动态DNS更新[RFC2136][RFC3007]在DNS服务器上自动注册自己的PTR、SRV和TXT记录。
Zeroconf printers answer Multicast DNS queries on the local link for their own PTR, SRV, and TXT names ending with ".local." [RFC6762].
Zeroconf打印机在本地链接上为其自己的PTR、SRV和以“.local.”[RFC6762]结尾的TXT名称回答多播DNS查询。
One of the motivations for DNS-based Service Discovery is to enable a visiting client (e.g., a Wi-Fi-equipped [IEEEW] laptop computer, tablet, or mobile telephone) arriving on a new network to discover what services are available on that network, without any manual configuration. The logic that discovering services without manual configuration is a good idea also dictates that discovering recommended registration and browsing domains without manual configuration is a similarly good idea.
基于DNS的服务发现的动机之一是使到达新网络的访问客户端（例如，配备Wi-Fi的笔记本电脑、平板电脑或移动电话）能够发现该网络上的可用服务，而无需任何手动配置。发现没有手动配置的服务是一个好主意的逻辑也表明，发现推荐的注册和浏览域而没有手动配置也是一个类似的好主意。
This discovery is performed using DNS queries, using Unicast or Multicast DNS. Five special RR names are reserved for this purpose:
此发现使用DNS查询、单播或多播DNS执行。为此，保留了五个特殊的RR名称：
b._dns-sd._udp.<domain>. db._dns-sd._udp.<domain>. r._dns-sd._udp.<domain>. dr._dns-sd._udp.<domain>. lb._dns-sd._udp.<domain>.
b、 _dns-sd._udp.<domain>。db.\U dns-sd.\U udp.<domain>。r、 _dns-sd._udp.<domain>。dr._dns-sd._udp.<domain>。lb._dns-sd._udp.<domain>。
By performing PTR queries for these names, a client can learn, respectively:
通过对这些名称执行PTR查询，客户机可以分别了解：
o A list of domains recommended for browsing.
o 建议浏览的域列表。
o A single recommended default domain for browsing.
o 建议浏览的单个默认域。
o A list of domains recommended for registering services using Dynamic Update.
o 建议使用动态更新注册服务的域列表。
o A single recommended default domain for registering services.
o 注册服务的单个推荐默认域。
o The "legacy browsing" or "automatic browsing" domain(s). Sophisticated client applications that care to present choices of domain to the user use the answers learned from the previous four queries to discover the domains to present. In contrast, many current applications browse without specifying an explicit domain, allowing the operating system to automatically select an appropriate domain on their behalf. It is for this class of application that the "automatic browsing" query is provided, to
o “传统浏览”或“自动浏览”域。关心向用户呈现域选择的复杂客户端应用程序使用从前面四个查询中获得的答案来发现要呈现的域。相比之下，许多当前的应用程序在浏览时不指定显式域，从而允许操作系统代表它们自动选择适当的域。为此类应用程序提供“自动浏览”查询，以
allow the network administrator to communicate to the client operating systems which domain(s) should be used automatically for these applications.
允许网络管理员与客户端操作系统通信哪些域应自动用于这些应用程序。
These domains are purely advisory. The client or user is free to register services and/or browse in any domains. The purpose of these special queries is to allow software to create a user interface that displays a useful list of suggested choices to the user, from which the user may make an informed selection, or ignore the offered suggestions and manually enter their own choice.
这些领域纯粹是咨询性的。客户端或用户可以在任何域中自由注册服务和/或浏览。这些特殊查询的目的是允许软件创建一个用户界面，向用户显示一个有用的建议选择列表，用户可以从中进行知情选择，或者忽略提供的建议并手动输入自己的选择。
The <domain> part of the Domain Enumeration query name may be "local." (meaning "perform the query using link-local multicast") or it may be learned through some other mechanism, such as the DHCP "Domain" option (option code 15) [RFC2132], the DHCP "Domain Search" option (option code 119) [RFC3397], or IPv6 Router Advertisement Options [RFC6106].
域枚举查询名称的<domain>部分可以是“本地的”（意思是“使用链路本地多播执行查询”），或者可以通过一些其他机制来学习，例如DHCP“domain”选项（选项代码15）[RFC2132]、DHCP“domain Search”选项（选项代码119）[RFC3397]或IPv6路由器广告选项[RFC6106]。
The <domain> part of the query name may also be derived a different way, from the host's IP address. The host takes its IP address and calculates the logical AND of that address and its subnet mask, to derive the 'base' address of the subnet (the 'network address' of that subnet, or, equivalently, the IP address of the 'all-zero' host address on that subnet). It then constructs the conventional DNS "reverse mapping" name corresponding to that base address, and uses that as the <domain> part of the name for the queries described above. For example, if a host has the address 192.168.12.34, with the subnet mask 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, and to discover the recommended automatic browsing domain(s) for devices on this subnet, the host issues a DNS PTR query for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
查询名称的<domain>部分也可能以不同的方式从主机的IP地址派生。主机获取其IP地址并计算该地址及其子网掩码的逻辑and，以导出子网的“基本”地址（该子网的“网络地址”，或等效地，该子网上“全零”主机地址的IP地址）。然后，它构造与该基址对应的常规DNS“反向映射”名称，并将其用作上述查询的名称的<domain>部分。例如，如果主机的地址为192.168.12.34，子网掩码为255.255.0.0，则子网的“基”地址为192.168.0.0，并且为了发现此子网上设备的推荐自动浏览域，主机会在addr.arpa中对名称“lb.\u DNS-sd.\u udp.0.0.168.192.发出DNS PTR查询
Equivalent address-derived Domain Enumeration queries should also be done for the host's IPv6 address(es).
还应针对主机的IPv6地址执行等效地址派生的域枚举查询。
Address-derived Domain Enumeration queries SHOULD NOT be done for IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses [RFC4862].
不应对IPv4链路本地地址[RFC3927]或IPv6链路本地地址[RFC4862]执行地址派生的域枚举查询。
Sophisticated clients may perform Domain Enumeration queries both in "local." and in one or more unicast domains, using both name-derived and address-derived queries, and then present the user with an combined result, aggregating the information received from all sources.
复杂的客户端可以在“本地”和一个或多个单播域中执行域枚举查询，同时使用名称派生查询和地址派生查询，然后向用户提供一个组合结果，聚合从所有来源接收的信息。
DNS has an efficiency feature whereby a DNS server may place additional records in the additional section of the DNS message. These additional records are records that the client did not explicitly request, but the server has reasonable grounds to expect that the client might request them shortly, so including them can save the client from having to issue additional queries.
DNS具有效率特性，DNS服务器可以在DNS消息的附加部分中放置附加记录。这些附加记录是客户端没有明确请求的记录，但是服务器有合理的理由期望客户端可能很快请求它们，因此包含它们可以避免客户端不得不发出附加查询。
This section recommends which additional records SHOULD be generated to improve network efficiency, for both Unicast and Multicast DNS-SD responses.
本节建议应为单播和多播DNS-SD响应生成哪些附加记录以提高网络效率。
Note that while servers SHOULD add these additional records for efficiency purposes, as with all DNS additional records, it is the client's responsibility to determine whether or not to trust them.
请注意，虽然服务器应添加这些附加记录以提高效率，但与所有DNS附加记录一样，客户端有责任确定是否信任这些记录。
Generally speaking, stub resolvers that talk to a single recursive name server for all their queries will trust all records they receive from that recursive name server (whom else would they ask?). Recursive name servers that talk to multiple authoritative name servers should verify that any records they receive from a given authoritative name server are "in bailiwick" for that server, and ignore them if not.
一般来说，针对所有查询与单个递归名称服务器进行对话的存根解析器将信任从该递归名称服务器接收的所有记录（他们还会问谁？）。与多个权威名称服务器通信的递归名称服务器应验证它们从给定权威名称服务器接收的任何记录是否在该服务器的“辖区内”，如果不在，则忽略它们。
Clients MUST be capable of functioning correctly with DNS servers (and Multicast DNS Responders) that fail to generate these additional records automatically, by issuing subsequent queries for any further record(s) they require. The additional-record generation rules in this section are RECOMMENDED for improving network efficiency, but are not required for correctness.
客户端必须能够与无法自动生成这些附加记录的DNS服务器（和多播DNS响应程序）正常运行，方法是对其所需的任何其他记录发出后续查询。建议使用本节中的附加记录生成规则来提高网络效率，但正确性不需要这些规则。
When including a DNS-SD Service Instance Enumeration or Selective Instance Enumeration (subtype) PTR record in a response packet, the server/responder SHOULD include the following additional records:
在响应数据包中包括DNS-SD服务实例枚举或选择性实例枚举（子类型）PTR记录时，服务器/响应程序应包括以下附加记录：
o The SRV record(s) named in the PTR rdata. o The TXT record(s) named in the PTR rdata. o All address records (type "A" and "AAAA") named in the SRV rdata.
o PTR rdata中命名的SRV记录。o PTR rdata中命名的TXT记录。o SRV rdata中命名的所有地址记录（键入“A”和“AAAA”）。
When including an SRV record in a response packet, the server/responder SHOULD include the following additional records:
在响应数据包中包括SRV记录时，服务器/响应程序应包括以下附加记录：
o All address records (type "A" and "AAAA") named in the SRV rdata.
o SRV rdata中命名的所有地址记录（类型“A”和“AAAA”）。
When including a TXT record in a response packet, no additional records are required.
在响应数据包中包含TXT记录时，不需要其他记录。
In response to address queries, or other record types, no new additional records are recommended by this document.
为响应地址查询或其他记录类型，本文档不推荐新的附加记录。
The following examples were prepared using standard unmodified nslookup and standard unmodified BIND running on GNU/Linux.
以下示例是使用在GNU/Linux上运行的标准未修改nslookup和标准未修改绑定编写的。
Note: In real products, this information is obtained and presented to the user using graphical network browser software, not command-line tools. However, if you wish, you can try these examples for yourself as you read along, using the nslookup command already available on most Unix machines.
注意：在实际产品中，这些信息是使用图形网络浏览器软件而不是命令行工具获取并呈现给用户的。但是，如果您愿意，您可以在阅读过程中使用大多数Unix机器上已有的nslookup命令亲自尝试这些示例。
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's\032Printer._http._tcp.dns-sd.org
nslookup-q=ptr\u http.\u tcp.dns-sd.org_http.\u tcp.dns-sd.org name=Zeroconf.\u http.\u tcp.dns-sd.org\u http.\u tcp.dns-sd.org name=Multicast\032DNS.\u http.\u tcp.dns-sd.org name=Service\032Discovery.\u http.\u tcp.dns-sd.org\u http.\u tcp.dns-sd.org name=Stuart\032Printer.\u http.\u tcp.dns-sd.org
Answer: There are four, called "Zeroconf", "Multicast DNS", "Service Discovery", and "Stuart's Printer".
答：有四种，分别称为“Zeroconf”、“多播DNS”、“服务发现”和“Stuart的打印机”。
Note that nslookup escapes spaces as "\032" for display purposes, but a graphical DNS-SD browser should not.
请注意，出于显示目的，nslookup将空格转义为“\032”，但图形DNS-SD浏览器不应转义空格。
nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org. _printer._sub._http._tcp.dns-sd.org name = Stuart's\032Printer._http._tcp.dns-sd.org
nslookup-q=ptr\u printer.\u sub.\u http.\u tcp.dns-sd.org_打印机。_sub._http._tcp.dns-sd.org name=Stuart的\032打印机。_http._tcp.dns-sd.org
Answer: "Stuart's Printer" is the web configuration UI of a network printer.
答：“Stuart’s Printer”是网络打印机的web配置UI。
nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org."
Service\032Discovery._http._tcp.dns-sd.org
priority = 0, weight = 0, port = 80, host = dns-sd.org
Service\032Discovery._http._tcp.dns-sd.org
text = "txtvers=1" "path=/"
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org internet address = 64.142.82.154
ns1.dns-sd.org internet address = 64.142.82.152
nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org."
Service\032Discovery._http._tcp.dns-sd.org
priority = 0, weight = 0, port = 80, host = dns-sd.org
Service\032Discovery._http._tcp.dns-sd.org
text = "txtvers=1" "path=/"
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org internet address = 64.142.82.154
ns1.dns-sd.org internet address = 64.142.82.152
Answer: You need to connect to dns-sd.org port 80, path "/". The address for dns-sd.org is also given (64.142.82.154).
答：您需要连接到dns-sd.org端口80，路径“/”。还提供了dns-sd.org的地址（64.142.82.154）。
IPv6 has only minor differences from IPv4.
IPv6与IPv4只有细微的区别。
The address of the SRV record's target host is given by the appropriate IPv6 "AAAA" address records instead of (or in addition to) IPv4 "A" records.
SRV记录的目标主机的地址由相应的IPv6“AAAA”地址记录而不是（或附加）IPv4“A”记录给出。
Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree, which is different from the IPv4 reverse-mapping tree and has longer names in it.
基于地址的域枚举查询是使用IPv6反向映射树下的名称执行的，该树不同于IPv4反向映射树，其中的名称较长。
Since DNS-SD is just a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates.
由于DNS-SD只是现有DNS系统中如何命名和使用记录的规范，因此除了已经应用于DNS查询和DNS更新的安全要求外，它没有其他特定的安全要求。
For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important.
对于DNS查询，如果信息的真实性很重要，则应使用DNS安全扩展（DNSSEC）[RFC4033]。
For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.
对于DNS更新，通常应使用安全更新[RFC2136][RFC3007]来控制哪些客户端有权更新DNS记录。
IANA manages the namespace of unique Service Names [RFC6335].
IANA管理唯一服务名称的命名空间[RFC6335]。
When a protocol service advertising specification includes subtypes, these should be documented in the protocol specification in question and/or in the "notes" field of the registration request sent to IANA. In the event that a new subtype becomes relevant after a protocol
当协议服务广告规范包含子类型时，这些子类型应记录在相关协议规范和/或发送给IANA的注册请求的“备注”字段中。如果协议之后新的子类型变得相关
specification has been published, this can be recorded by requesting that IANA add it to the "notes" field. For example, vendors of network printers advertise their embedded web servers using the subtype _printer. This allows printer management clients to browse for only printer-related web servers by browsing for the _printer subtype. While the existence of the _printer subtype of _http._tcp is not directly relevant to the HTTP protocol specification, it is useful to record this usage in the IANA registry to help avoid another community of developers inadvertently using the same subtype string for a different purpose. The namespace of possible subtypes is separate for each different service type. For example, the existence of the _printer subtype of _http._tcp does not imply that the _printer subtype is defined or has any meaning for any other service type.
规范已经发布，可以通过请求IANA将其添加到“注释”字段来记录。例如，网络打印机供应商使用子类型_printer宣传其嵌入式web服务器。这允许打印机管理客户端通过浏览_打印机子类型，仅浏览与打印机相关的web服务器。虽然http.\U tcp的_printer子类型的存在与http协议规范没有直接关系，但在IANA注册表中记录此用法非常有用，以帮助避免另一个开发人员社区无意中将同一子类型字符串用于不同的目的。对于每个不同的服务类型，可能的子类型的名称空间是独立的。例如，_http._tcp的_printer子类型的存在并不意味着_printer子类型已定义或对任何其他服务类型有任何意义。
When IANA records a Service Name registration, if the new application protocol is one that conceptually duplicates existing functionality of an older protocol, and the implementers desire the Flagship Naming behavior described in Section 8, then the registrant should request that IANA record the name of the flagship protocol in the "notes" field of the new registration. For example, the registrations for "ipp" and "pdl-datastream" both reference "printer" as the flagship name for this family of printing-related protocols.
当IANA记录服务名称注册时，如果新的应用协议在概念上与旧协议的现有功能重复，且实施者希望实现第8节中描述的旗舰命名行为，则注册者应要求IANA在“备注”中记录旗舰协议的名称新注册的字段。例如，“ipp”和“pdl数据流”的注册都引用“打印机”作为这一系列打印相关协议的旗舰名称。
The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions.
在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的重要贡献。
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987.
[RFC1033]洛托，M.，“域管理员操作指南”，RFC1033，1987年11月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[AFP] Mac OS X Developer Library, "Apple Filing Protocol Programming Guide", <http://developer.apple.com/ documentation/Networking/Conceptual/AFP/>.
[法新社]Mac OS X开发者库，“苹果归档协议编程指南”<http://developer.apple.com/ 文件/网络/概念/AFP/>。
[BJ] Apple Bonjour Open Source Software, <http://developer.apple.com/bonjour/>.
[BJ]苹果早安开源软件<http://developer.apple.com/bonjour/>.
[BJP] Bonjour Printing Specification, <https://developer.apple.com/bonjour/ printing-specification/bonjourprinting-1.0.2.pdf>.
[BJP]你好，印刷规范<https://developer.apple.com/bonjour/ 打印规范/bonjourprinting-1.0.2.pdf>。
[IEEEW] IEEE 802 LAN/MAN Standards Committee, <http://standards.ieee.org/wireless/>.
IEEE 802局域网/城域网标准委员会<http://standards.ieee.org/wireless/>.
[NIAS] Cheshire, S., "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001.
[NIAS]Cheshire，S.，“使用DNS发现抽象服务的命名实例”，正在进行的工作，2001年7月。
[NSD] "NsdManager | Android Developer", June 2012, <http://developer.android.com/reference/android/ net/nsd/NsdManager.html>.
[NSD]“NsdManager | Android开发者”，2012年6月<http://developer.android.com/reference/android/ net/nsd/NsdManager.html>。
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990.
[RFC1179]McLaughlin，L.，“线路打印机守护程序协议”，RFC1179，1990年8月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910]Herriot，R.，Ed.，Butler，S.，Moore，P.，Turner，R.，和J.Wenn，“互联网打印协议/1.1：编码和传输”，RFC 29102000年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397]Aboba，B.和S.Cheshire，“动态主机配置协议（DHCP）域搜索选项”，RFC 3397，2002年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 47952007年1月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281]Cheshire，S.，Zhu，Z.，Wakikawa，R.，和L.Zhang，“理解苹果的回到我的Mac（BTMM）服务”，RFC 62812011年6月。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.
[RFC6709]Carpenter，B.，Aboba，B.，Ed.，和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，2012年9月。
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, February 2013.
[RFC6760]Cheshire，S.和M.Krocmal，“替代AppleTalk名称绑定协议（NBP）的协议要求”，RFC 67602013年2月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月。
[SN] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers/>.
[SN]IANA，“服务名称和传输协议端口号注册表”<http://www.iana.org/assignments/ 服务名称端口号/>。
[SOAP] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C Proposed Recommendation 24 June 2003, <http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.
[SOAP]Mitra，N.，“SOAP版本1.2第0部分：入门”，W3C建议建议，2003年6月24日<http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.
[Unicode6] The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6) <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode 6]Unicode联盟。Unicode标准，版本6.0.0，（加利福尼亚州山景城：Unicode联盟，2011年。ISBN 978-1-936213-01-6）<http://www.unicode.org/versions/Unicode6.0.0/>.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
[ZC]Cheshire，S.和D.Steinberg，“零配置网络：最终指南”，O'Reilly Media，Inc.，ISBN 0-596-10100-7，2005年12月。
Over the years, there have been many proposed ways to do network service discovery with IP, but none achieved ubiquity in the marketplace. Certainly none has achieved anything close to the ubiquity of today's deployment of DNS servers, clients, and other infrastructure.
多年来，已经有很多人提出了使用IP进行网络服务发现的方法，但没有一种方法能够在市场上普及。毫无疑问，没有一家公司的DNS服务器、客户端和其他基础设施的部署能达到今天的普及程度。
The advantage of using DNS as the basis for service discovery is that it makes use of those existing servers, clients, protocols, infrastructure, and expertise. Existing network analyzer tools already know how to decode and display DNS packets for network debugging.
使用DNS作为服务发现基础的优势在于，它利用了现有的服务器、客户端、协议、基础设施和专业知识。现有的网络分析器工具已经知道如何解码和显示用于网络调试的DNS数据包。
For ad hoc networks such as Zeroconf environments, peer-to-peer multicast protocols are appropriate. Using DNS-SD running over Multicast DNS [RFC6762] provides zero-configuration ad hoc service discovery, while maintaining the DNS-SD semantics and record types described here.
对于像Zeroconf环境这样的adhoc网络，对等多播协议是合适的。使用在多播DNS上运行的DNS-SD[RFC6762]可以提供零配置自组织服务发现，同时维护此处描述的DNS-SD语义和记录类型。
In larger networks, a high volume of enterprise-wide IP multicast traffic may not be desirable, so any credible service discovery protocol intended for larger networks has to provide some facility to aggregate registrations and lookups at a central server (or servers) instead of working exclusively using multicast. This requires some service discovery aggregation server software to be written, debugged, deployed, and maintained. This also requires some service discovery registration protocol to be implemented and deployed for clients to register with the central aggregation server. Virtually every company with an IP network already runs a DNS server, and DNS already has a dynamic registration protocol [RFC2136] [RFC3007]. Given that virtually every company already has to operate and maintain a DNS server anyway, it makes sense to take advantage of this expertise instead of also having to learn, operate, and maintain a different service registration server. It should be stressed again that using the same software and protocols doesn't necessarily mean using the same physical piece of hardware. The DNS-SD service discovery functions do not have to be provided by the same piece of hardware that is currently providing the company's DNS name service. The "_tcp.<Domain>" and "_udp.<Domain>" subdomains may be delegated to a different piece of hardware. However, even when the DNS-SD service is being provided by a different piece of hardware, it is still the same familiar DNS server software, with the same configuration file syntax, the same log file format, and so forth.
在更大的网络中，可能不需要大量企业范围的IP多播通信，因此任何用于更大网络的可信服务发现协议都必须提供一些设施，以便在中央服务器（或多个服务器）上聚合注册和查找，而不是专门使用多播。这需要编写、调试、部署和维护一些服务发现聚合服务器软件。这还需要实现和部署一些服务发现注册协议，以便客户端向中央聚合服务器注册。几乎所有拥有IP网络的公司都已经运行了DNS服务器，DNS已经有了动态注册协议[RFC2136][RFC3007]。考虑到几乎所有公司都必须操作和维护DNS服务器，因此利用这些专业知识而不是学习、操作和维护不同的服务注册服务器是有意义的。需要再次强调的是，使用相同的软件和协议并不一定意味着使用相同的物理硬件。DNS-SD服务发现功能不必由当前提供公司DNS名称服务的同一硬件提供。“_tcp.<Domain>”和“_udp.<Domain>”子域可以委托给不同的硬件。然而，即使DNS-SD服务由不同的硬件提供，它仍然是相同的熟悉DNS服务器软件，具有相同的配置文件语法、相同的日志文件格式，等等。
Service discovery needs to be able to provide appropriate security. DNS already has existing mechanisms for security [RFC4033].
服务发现需要能够提供适当的安全性。DNS已经有了现有的安全机制[RFC4033]。
In summary:
总之：
Service discovery requires a central aggregation server. DNS already has one: a DNS server.
服务发现需要一个中央聚合服务器。DNS已经有一个：DNS服务器。
Service discovery requires a service registration protocol. DNS already has one: DNS Dynamic Update.
服务发现需要服务注册协议。DNS已经有一个：DNS动态更新。
Service discovery requires a query protocol. DNS already has one: DNS queries.
服务发现需要查询协议。DNS已经有一个：DNS查询。
Service discovery requires security mechanisms. DNS already has security mechanisms: DNSSEC.
服务发现需要安全机制。DNS已经有了安全机制：DNSSEC。
Service discovery requires a multicast mode for ad hoc networks. Using DNS-SD in conjunction with Multicast DNS provides this, using peer-to-peer multicast instead of a DNS server.
服务发现要求adhoc网络采用多播模式。将DNS-SD与多播DNS结合使用提供了这一点，即使用对等多播而不是DNS服务器。
It makes more sense to use the existing software that every network needs already, instead of deploying an entire parallel system just for service discovery.
使用每个网络已经需要的现有软件，而不是仅仅为了服务发现而部署整个并行系统，这样做更有意义。
There have been questions about why services are named using DNS Service Instance Names of the form:
关于为什么使用以下形式的DNS服务实例名称命名服务，存在一些问题：
Service Instance Name = <Instance> . <Service> . <Domain>
Service Instance Name = <Instance> . <Service> . <Domain>
instead of:
而不是：
Service Instance Name = <Service> . <Instance> . <Domain>
Service Instance Name = <Service> . <Instance> . <Domain>
There are three reasons why it is beneficial to name service instances with the parent domain as the most-significant (rightmost) part of the name, then the abstract service type as the next-most significant, and then the specific instance name as the least-significant (leftmost) part of the name. These reasons are discussed below in Sections B.1, B.2, and B.3.
将父域作为名称的最重要（最右边）部分，然后将抽象服务类型作为下一个最重要的部分，然后将特定实例名称作为名称的最不重要（最左边）部分，这样命名服务实例有三个好处。下文第B.1、B.2和B.3节讨论了这些原因。
The facility being provided by browsing ("Service Instance Enumeration") is effectively enumerating the leaves of a tree structure. A given domain offers zero or more services. For each of those service types, there may be zero or more instances of that service.
通过浏览（“服务实例枚举”）提供的功能可以有效地枚举树结构的叶子。给定域提供零个或多个服务。对于这些服务类型中的每一种，都可能有零个或多个该服务的实例。
The user knows what type of service they are seeking. (If they are running an FTP client, they are looking for FTP servers. If they have a document to print, they are looking for entities that speak some known printing protocol.) The user knows in which organizational or geographical domain they wish to search. (The user does not want a single flat list of every single printer on the planet, even if such a thing were possible.) What the user does not know in advance is whether the service they seek is offered in the given domain, or if so, the number of instances that are offered and the names of those instances.
用户知道他们正在寻求什么类型的服务。（如果他们正在运行FTP客户端，则他们正在查找FTP服务器。如果他们有文档要打印，则他们正在查找使用某种已知打印协议的实体。）用户知道他们希望搜索的组织域或地理域。（用户不希望看到地球上每一台打印机的单一平面列表，即使这样的事情是可能的。）用户事先不知道的是他们所寻求的服务是否在给定的域中提供，或者如果是，提供的实例数和这些实例的名称。
Hence, having the instance names be the leaves of the tree is consistent with this semantic model.
因此，将实例名称作为树的叶子与此语义模型是一致的。
Having the service types be the terminal leaves of the tree would imply that the user knows the domain name and the name of the service instance, but doesn't have any idea what the service does. We would argue that this is a less useful model.
将服务类型设置为树的终端叶子将意味着用户知道域名和服务实例的名称，但不知道该服务做什么。我们认为这是一个不太有用的模型。
When a DNS response contains multiple answers, name compression works more effectively if all the names contain a common suffix. If many answers in the packet have the same <Service> and <Domain>, then each occurrence of a Service Instance Name can be expressed using only the <Instance> part followed by a two-byte compression pointer referencing a previous appearance of "<Service>.<Domain>". This efficiency would not be possible if the <Service> component appeared first in each name.
当DNS响应包含多个答案时，如果所有名称都包含一个公共后缀，则名称压缩会更有效。如果数据包中的多个答案具有相同的<Service>和<Domain>，则服务实例名称的每次出现都可以仅使用<Instance>部分，后跟引用先前出现的“<Service><Domain>”的两字节压缩指针来表示。如果<Service>组件首先出现在每个名称中，则不可能实现这种效率。
This name structure allows subdomains to be delegated along logical service boundaries. For example, the network administrator at Example Co. could choose to delegate the "_tcp.example.com." subdomain to a different machine, so that the machine handling service discovery doesn't have to be the machine that handles other day-to-day DNS operations. (It *can* be the same machine if the administrator so chooses, but the administrator is free to make that choice.) Furthermore, if the network administrator wishes to delegate all information related to IPP printers to a machine dedicated to that specific task, this is easily done by delegating the "_ipp._tcp.example.com." subdomain to the desired machine. It is also convenient to set security policies on a per-zone/per-subdomain basis. For example, the administrator may choose to enable DNS Dynamic Update [RFC2136] [RFC3007] for printers registering in the
此名称结构允许沿逻辑服务边界委派子域。例如，example Co.的网络管理员可以选择将“_tcp.example.com.”子域委托给另一台机器，以便处理服务发现的机器不必是处理其他日常DNS操作的机器。（如果管理员选择，它*可以*是同一台机器，但管理员可以自由选择。）此外，如果网络管理员希望将与IPP打印机相关的所有信息委派给专用于该特定任务的机器，则可以通过委派“_IPP._tcp.example.com”轻松完成所需计算机的子域。在每个区域/每个子域的基础上设置安全策略也很方便。例如，管理员可以选择为在中注册的打印机启用DNS动态更新[RFC2136][RFC3007]
"_ipp._tcp.example.com." subdomain, but not for other zones/subdomains. This easy flexibility would not exist if the <Service> component appeared first in each name.
“_ipp._tcp.example.com.”子域，但不适用于其他区域/子域。如果<Service>组件首先出现在每个名称中，那么这种简单的灵活性就不存在了。
Some service discovery protocols decouple the true service identifier from the name presented to the user. The true service identifier used by the protocol is an opaque unique identifier, often represented using a long string of hexadecimal digits, which should never be seen by the typical user. The name presented to the user is merely one of the decorative ephemeral attributes attached to this opaque identifier.
一些服务发现协议将真正的服务标识符与提供给用户的名称分离。协议使用的真正的服务标识符是一个不透明的唯一标识符，通常使用一个十六进制数字的长字符串来表示，这是典型用户永远不会看到的。呈现给用户的名称只是附加在该不透明标识符上的装饰性短暂属性之一。
The problem with this approach is that it decouples user perception from network reality:
这种方法的问题在于，它将用户感知与网络现实脱钩：
* What happens if there are two service instances, with different unique ids, but they have inadvertently been given the same user-visible name? If two instances appear in an on-screen list with the same name, how does the user know which is which?
* 如果有两个具有不同唯一ID的服务实例，但无意中为它们指定了相同的用户可见名称，会发生什么情况？如果两个实例以相同的名称出现在屏幕列表中，用户如何知道哪个是哪个？
* Suppose a printer breaks down, and the user replaces it with another printer of the same make and model, and configures the new printer with the exact same name as the one being replaced: "Stuart's Printer". Now, when the user tries to print, the on-screen print dialog tells them that their selected default printer is "Stuart's Printer". When they browse the network to see what is there, they see a printer called "Stuart's Printer", yet when the user tries to print, they are told that the printer "Stuart's Printer" can't be found. The hidden internal unique identifier that the software is trying to find on the network doesn't match the hidden internal unique identifier of the new printer, even though its apparent "name" and its logical purpose for being there are the same. To remedy this, the user typically has to delete the print queue they have created, and then create a new (apparently identical) queue for the new printer, so that the new queue will contain the right hidden internal unique identifier. Having all this hidden information that the user can't see makes for a confusing and frustrating user experience, and exposing long, ugly hexadecimal strings to the user and forcing them to understand what they mean is even worse.
* 假设一台打印机出现故障，用户将其替换为另一台相同品牌和型号的打印机，并使用与被替换打印机完全相同的名称配置新打印机：“Stuart’s printer”。现在，当用户尝试打印时，屏幕上的打印对话框会告诉他们所选的默认打印机是“Stuart’s printer”。当他们浏览网络查看内容时，他们会看到一台名为“斯图尔特打印机”的打印机，但当用户尝试打印时，他们会被告知无法找到打印机“斯图尔特打印机”。软件试图在网络上查找的隐藏内部唯一标识符与新打印机的隐藏内部唯一标识符不匹配，即使其外观“名称”及其存在的逻辑目的相同。要解决此问题，用户通常必须删除他们创建的打印队列，然后为新打印机创建一个新的（显然相同的）队列，以便新队列将包含正确隐藏的内部唯一标识符。拥有所有这些用户看不到的隐藏信息会带来混乱和令人沮丧的用户体验，而向用户暴露长而难看的十六进制字符串并迫使他们理解它们的含义更糟糕。
* Suppose an existing printer is moved to a new department, and given a new name and a new function. Changing the user-visible name of that piece of hardware doesn't change its hidden internal unique identifier. Users who had previously created a print queue
* 假设将现有打印机移动到新部门，并赋予新名称和新功能。更改该硬件的用户可见名称不会更改其隐藏的内部唯一标识符。以前创建过打印队列的用户
for that printer will still be accessing the same hardware by its unique identifier, even though the logical service that used to be offered by that hardware has ceased to exist.
因为该打印机仍将通过其唯一标识符访问同一硬件，即使该硬件以前提供的逻辑服务已不存在。
Solving these problems requires the user or administrator to be aware of the supposedly hidden unique identifier, and to set its value correctly as hardware is moved around, repurposed, or replaced, thereby contradicting the notion that it is a hidden identifier that human users never need to deal with. Requiring the user to understand this expert behind-the-scenes knowledge of what is *really* going on is just one more burden placed on the user when they are trying to diagnose why their computers and network devices are not working as expected.
解决这些问题需要用户或管理员知道所谓的隐藏唯一标识符，并在硬件移动、重新调整用途或更换时正确设置其值，从而与人类用户永远不需要处理的隐藏标识符的概念相矛盾。当用户试图诊断为什么他们的计算机和网络设备不能按预期工作时，要求用户理解这个专家对“真正”发生的事情的幕后知识只是又一个负担。
These anomalies and counterintuitive behaviors can be eliminated by maintaining a tight bidirectional one-to-one mapping between what the user sees on the screen and what is really happening "behind the curtain". If something is configured incorrectly, then that is apparent in the familiar day-to-day user interface that everyone understands, not in some little-known, rarely used "expert" interface.
这些异常和违反直觉的行为可以通过在用户在屏幕上看到的内容和“幕后”真正发生的事情之间保持紧密的双向一对一映射来消除。如果某些配置不正确，那么在大家都能理解的熟悉的日常用户界面中，而不是在一些鲜为人知、很少使用的“专家”界面中，这一点是显而易见的。
In summary: in DNS-SD the user-visible name is also the primary identifier for a service. If the user-visible name is changed, then conceptually the service being offered is a different logical service -- even though the hardware offering the service may have stayed the same. If the user-visible name doesn't change, then conceptually the service being offered is the same logical service -- even if the hardware offering the service is new hardware brought in to replace some old equipment.
总之：在DNS-SD中，用户可见名称也是服务的主要标识符。如果更改了用户可见名称，则从概念上讲，提供的服务是不同的逻辑服务——即使提供该服务的硬件可能保持不变。如果用户可见名称没有改变，那么从概念上讲，提供的服务是相同的逻辑服务——即使提供服务的硬件是为了替换一些旧设备而引入的新硬件。
There are certainly arguments on both sides of this debate. Nonetheless, the designers of any service discovery protocol have to make a choice between having the primary identifiers be hidden, or having them be visible, and these are the reasons that we chose to make them visible. We're not claiming that there are no disadvantages of having primary identifiers be visible. We considered both alternatives, and we believe that the few disadvantages of visible identifiers are far outweighed by the many problems caused by use of hidden identifiers.
这场辩论的双方当然都有争论。尽管如此，任何服务发现协议的设计者都必须在隐藏或可见主标识符之间做出选择，这就是我们选择使它们可见的原因。我们并不是说让主标识符可见没有缺点。我们考虑了这两种选择，并且我们相信可见标识符的少数缺点远远超过了使用隐藏标识符所引起的许多问题。
When a DNS-SD service is advertised using Multicast DNS [RFC6762], if there is already another service of the same type advertising with the same name then automatic name conflict resolution will occur. As described in the Multicast DNS specification [RFC6762], upon detecting a conflict, the service should:
当使用多播DNS[RFC6762]播发DNS-SD服务时，如果已经存在具有相同名称的相同类型播发的另一个服务，则将发生自动名称冲突解决。如多播DNS规范[RFC6762]所述，在检测到冲突时，服务应：
1. Automatically select a new name (typically by appending or incrementing a digit at the end of the name), 2. Try advertising with the new name, and 3. Upon success, record the new name in persistent storage.
1. 自动选择新名称（通常通过在名称末尾追加或递增数字），2。试着用新名字做广告，3。成功后，在持久存储中记录新名称。
This renaming behavior is very important, because it is key to providing user-friendly instance names in the out-of-the-box factory-default configuration. Some product developers apparently have not realized this, because there are some products today where the factory-default name is distinctly unfriendly, containing random-looking strings of characters, such as the device's Ethernet address in hexadecimal. This is unnecessary and undesirable, because the point of the user-visible name is that it should be friendly and meaningful to human users. If the name is not unique on the local network then the protocol will remedy this as necessary. It is ironic that many of the devices with this design mistake are network printers, given that these same printers also simultaneously support AppleTalk-over-Ethernet, with nice user-friendly default names (and automatic conflict detection and renaming). Some examples of good factory-default names are:
这种重命名行为非常重要，因为它是在现成的工厂默认配置中提供用户友好的实例名称的关键。一些产品开发人员显然没有意识到这一点，因为现在有些产品的出厂默认名称明显不友好，包含随机的字符串，例如设备的十六进制以太网地址。这是不必要的，也是不可取的，因为用户可见名称的意义在于它应该对人类用户友好且有意义。如果名称在本地网络上不是唯一的，则协议将根据需要对此进行补救。具有讽刺意味的是，许多存在这种设计错误的设备都是网络打印机，因为这些打印机还同时支持以太网上的AppleTalk，具有良好的用户友好默认名称（以及自动冲突检测和重命名）。以下是一些良好的出厂默认名称示例：
Brother 5070N Canon W2200 HP LaserJet 4600 Lexmark W840 Okidata C5300 Ricoh Aficio CL7100 Xerox Phaser 6200DX
Brother 5070N佳能W2200 HP激光喷射4600利盟W840 Okidata C5300理光Aficio CL7100施乐移相器6200DX
To make the case for why adding long, ugly factory-unique serial numbers to the end of names is neither necessary nor desirable, consider the cases where the user has (a) only one network printer, (b) two network printers, and (c) many network printers.
为了说明为什么在名称的末尾添加长的、丑陋的工厂特有的序列号既不必要也不可取，考虑用户只有（a）一个网络打印机、（b）两个网络打印机和（c）许多网络打印机的情况。
(a) In the case where the user has only one network printer, a simple name like (to use a vendor-neutral example) "Printer" is more user-friendly than an ugly name like "Printer_0001E68C74FB". Appending ugly hexadecimal goop to the end of the name to make sure the name is unique is irrelevant to a user who only has one printer anyway.
(a) 在用户只有一台网络打印机的情况下，像“打印机”这样的简单名称（使用与供应商无关的示例）比像“打印机_0001E68C74FB”这样的难看名称更容易使用。在名称末尾添加难看的十六进制goop以确保名称是唯一的，这与仅拥有一台打印机的用户无关。
(b) In the case where the user gets a second network printer, having the new printer detect that the name "Printer" is already in use and automatically name itself "Printer (2)" instead, provides a good user experience. For most users, remembering that the old printer is "Printer" and the new one is "Printer (2)" is easy and intuitive. Seeing a printer called "Printer_0001E68C74FB" and another called "Printer_00306EC3FD1C" is a lot less helpful.
(b) 在用户获得第二台网络打印机的情况下，让新打印机检测到名称“打印机”已经在使用中，并自动将其命名为“打印机（2）”，可以提供良好的用户体验。对于大多数用户来说，记住旧打印机是“打印机”，而新打印机是“打印机（2）”是简单直观的。看到一台名为“printer_0001; e68c74fb”的打印机和另一台名为“printer_00306EC3FD1C”的打印机就没什么帮助了。
(c) In the case of a network with ten network printers, seeing a list of ten names all of the form "Printer_xxxxxxxxxxxx" has effectively taken what was supposed to be a list of user-friendly rich-text names (supporting mixed case, spaces, punctuation, non-Roman characters, and other symbols) and turned it into just about the worst user interface imaginable: a list of incomprehensible random-looking strings of letters and digits. In a network with a lot of printers, it would be advisable for the people setting up the printers to take a moment to give each one a descriptive name, but in the event they don't, presenting the users with a list of sequentially numbered printers is a much more desirable default user experience than showing a list of raw Ethernet addresses.
(c) 在一个有十台网络打印机的网络中，看到十个名称的列表时，所有形式的“Printer_uxxxxxxxxxxxx”实际上是一个用户友好的富文本名称列表（支持混合大小写、空格、标点符号、非罗马字符和其他符号）并且把它变成了最糟糕的用户界面：一系列令人费解的随机字母和数字串。在一个有很多打印机的网络中，设置打印机的人最好花点时间为每个打印机指定一个描述性名称，但如果他们不这样做，则向用户提供一个按顺序编号的打印机列表是比显示原始以太网地址列表更理想的默认用户体验。
Although the original DNS specifications [RFC1033] [RFC1034] [RFC1035] recommend that host names contain only letters, digits, and hyphens (because of the limitations of the typing-based user interfaces of that era), Service Instance Names are not host names. Users generally access a service by selecting it from a list presented by a user interface, not by typing in its Service Instance Name. "Clarifications to the DNS Specification" [RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that the traditional letters-digits-hyphens rule applies only to conventional host names:
尽管原始DNS规范[RFC1033][RFC1034][RFC1035]建议主机名仅包含字母、数字和连字符（由于该时代基于键入的用户界面的限制），但服务实例名称不是主机名。用户通常通过从用户界面显示的列表中选择服务来访问服务，而不是通过键入服务实例名称。“DNS规范澄清”[RFC2181]直接讨论了第11节（“名称语法”）中允许的字符集主题，并明确指出传统字母数字连字符规则仅适用于传统主机名：
Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose.
有时，假定域名系统仅用于将Internet主机名映射到数据，并将Internet地址映射到主机名。这是不正确的，DNS是一个通用的（如果有一定限制的话）分层数据库，可以存储几乎任何类型的数据，用于几乎任何目的。
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.
DNS本身仅对可用于标识资源记录的特定标签设置一个限制。这一限制与标签的长度和全名有关。任何一个标签的长度限制在1到63个八位字节之间。完整域名限制为255个八位字节（包括分隔符）。长度为零的全名定义为表示DNS树的根，通常写入并显示为“”。撇开这些限制不谈，任何二进制字符串都可以用作任何资源记录的标签。类似地，任何二进制字符串都可以用作任何记录的值，该记录将域名作为其部分或全部值（SOA、NS、MX、PTR、CNAME以及可能添加的任何其他值）。DNS协议的实施不得对可使用的标签施加任何限制。特别是，DNS服务器不能拒绝为区域提供服务，因为它包含一些DNS客户端程序可能无法接受的标签。
Note that just because DNS-based Service Discovery supports arbitrary UTF-8-encoded names doesn't mean that any particular user or administrator is obliged to make use of that capability. Any user is free, if they wish, to continue naming their services using only letters, digits, and hyphens, with no spaces, capital letters, or other punctuation.
请注意，仅仅因为基于DNS的服务发现支持任意UTF-8编码的名称，并不意味着任何特定用户或管理员都必须使用该功能。如果用户愿意，他们可以继续免费使用字母、数字和连字符命名服务，而不使用空格、大写字母或其他标点符号。
Appendix F. "Continuous Live Update" Browsing Model
附录F“持续实时更新”浏览模式
Of particular concern in the design of DNS-SD, especially when used in conjunction with ad hoc Multicast DNS, is the dynamic nature of service discovery in a changing network environment. Other service discovery protocols seem to have been designed with an implicit unstated assumption that the usage model is:
在DNS-SD的设计中，特别是当与自组织多播DNS结合使用时，需要特别关注的是在不断变化的网络环境中服务发现的动态特性。其他服务发现协议的设计似乎隐含了一个未声明的假设，即使用模型为：
(a) client software calls the service discovery API, (b) service discovery code spends a few seconds getting a list of instances available at a particular moment in time, and then (c) client software displays the list for the user to select from.
(a) 客户端软件调用服务发现API，（b）服务发现代码花费几秒钟获取特定时刻可用实例的列表，然后（c）客户端软件显示列表供用户选择。
Superficially this usage model seems reasonable, but the problem is that it's too optimistic. It only considers the success case, where the software immediately finds the service instance the user is looking for.
从表面上看，这种使用模式似乎合理，但问题是它过于乐观。它只考虑成功案例，即软件立即找到用户正在寻找的服务实例。
In the case where the user is looking for (say) a particular printer, and that printer is not turned on or not connected, the user first has to attempt to remedy the problem, and then has to click a "refresh" button to retry the service discovery to find out whether they were successful. Because nothing happens instantaneously in networking, and packets can be lost, necessitating some number of retransmissions, a service discovery search is not instantaneous and typically takes a few seconds. As a result, a fairly typical user experience is:
如果用户正在查找（例如）某台特定打印机，并且该打印机未打开或未连接，则用户首先必须尝试解决该问题，然后必须单击“刷新”按钮重试服务发现，以确定它们是否成功。因为在网络中没有任何事情是瞬间发生的，并且数据包可能会丢失，因此需要一定数量的重新传输，所以服务发现搜索不是瞬间的，通常需要几秒钟。因此，一个相当典型的用户体验是：
(a) display an empty window, (b) display some animation like a searchlight sweeping back and forth for ten seconds, and then (c) at the end of the ten-second search, display a static list showing what was discovered.
(a) 显示一个空窗口，（b）显示一些动画，如探照灯来回扫视10秒钟，然后（c）在10秒钟搜索结束时，显示一个静态列表，显示发现的内容。
Every time the user clicks the "refresh" button they have to endure another ten-second wait, and every time the discovered list is finally shown at the end of the ten-second wait, it's already beginning to get stale and out-of-date the moment it's displayed on the screen.
每次用户点击“刷新”按钮时，他们必须再等待10秒，每次发现的列表在10秒等待结束时最终显示时，它在屏幕上显示的那一刻就已经开始过时。
The service discovery user experience that the DNS-SD designers had in mind has some rather different properties:
DNS-SD设计者心目中的服务发现用户体验具有一些截然不同的特性：
1. Displaying the initial list of discovered services should be effectively instantaneous -- i.e., typically 0.1 seconds, not 10 seconds.
1. 显示发现的服务的初始列表应该是即时的，即通常为0.1秒，而不是10秒。
2. The list of discovered services should not be getting stale and out-of-date from the moment it's displayed. The list should be 'live' and should continue to update as new services are discovered. Because of the delays, packet losses, and retransmissions inherent in networking, it is to be expected that sometimes, after the initial list is displayed showing the majority of discovered services, a few remaining stragglers may continue to trickle in during the subsequent few seconds. Even after this stable list has been built and displayed, it should remain 'live' and should continue to update. At any future time, be it minutes, hours, or even days later, if a new service of the desired type is discovered, it should be displayed in the list automatically, without the user having to click a "refresh" button or take any other explicit action to update the display.
2. 发现的服务列表从显示时起不应过时。该列表应为“实时”列表，并应在发现新服务时继续更新。由于网络固有的延迟、数据包丢失和重传，可以预期，有时在显示大多数已发现服务的初始列表后，一些剩余的掉队者可能会在随后的几秒钟内继续掉队。即使在这个稳定的列表已经建立和显示之后，它也应该保持“活动”状态并继续更新。在未来的任何时间，无论是几分钟、几小时甚至几天之后，如果发现了所需类型的新服务，则该服务应自动显示在列表中，而用户无需单击“刷新”按钮或采取任何其他显式操作来更新显示。
3. With users getting in the habit of leaving service discovery windows open, and expecting them to show a continuous 'live' view of current network reality, this gives us an additional requirement: deletion of stale services. When a service discovery list shows just a static snapshot at a moment in time, then the situation is simple: either a service was discovered and appears in the list, or it was not and does not. However, when our list is live and updates continuously with the discovery of new services, then this implies the corollary: when a service goes away, it needs to *disappear* from the service discovery list. Otherwise, the service discovery list would simply grow monotonically over time, accreting stale data, and would require a periodic "refresh" (or complete dismissal and recreation) to restore correct display.
3. 随着用户习惯于打开服务发现窗口，并期望他们显示当前网络现实的连续“实时”视图，这给了我们额外的要求：删除过时的服务。当服务发现列表在某一时刻仅显示一个静态快照时，情况很简单：服务被发现并出现在列表中，或者它没有也没有。然而，当我们的列表处于活动状态并且随着新服务的发现而不断更新时，这就意味着必然结果：当服务消失时，它需要从服务发现列表中“消失”。否则，服务发现列表将随着时间单调增长，积累陈旧数据，并需要定期“刷新”（或完全撤销和重新创建）以恢复正确的显示。
4. Another consequence of users leaving service discovery windows open for extended periods of time is that these windows should update not only in response to services coming and going, but also in response to changes in configuration and connectivity of the client machine itself. For example, if a user opens a service discovery window when the client machine has no network connectivity, then the window will typically appear empty, with no discovered services. When the user connects an Ethernet cable or joins an 802.11 [IEEEW] wireless network the window should then automatically populate with discovered services, without requiring any explicit user action. If the user disconnects the Ethernet cable or turns off 802.11 wireless then all the services discovered via that network interface should automatically disappear. If the user switches from one 802.11 wireless access point to another, the service discovery window should automatically update to remove all the services discovered via the old wireless access point, and add all the services discovered via the new one.
4. 用户将服务发现窗口长时间打开的另一个后果是，这些窗口不仅应更新以响应服务的进出，还应更新以响应客户端计算机本身的配置和连接更改。例如，如果用户在客户端计算机没有网络连接时打开服务发现窗口，则该窗口通常会显示为空，没有发现的服务。当用户连接以太网电缆或加入802.11[IEEEW]无线网络时，窗口应自动填充发现的服务，而无需任何明确的用户操作。如果用户断开以太网电缆或关闭802.11无线，则通过该网络接口发现的所有服务应自动消失。如果用户从一个802.11无线接入点切换到另一个，则服务发现窗口应自动更新，以删除通过旧无线接入点发现的所有服务，并添加通过新无线接入点发现的所有服务。
Appendix G. Deployment History
附录G.部署历史
In July 1997, in an email to the net-thinkers@thumper.vmeng.com mailing list, Stuart Cheshire first proposed the idea of running the AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of this and related IETF discussions, the IETF Zeroconf working group was chartered September 1999. After various working group discussions and other informal IETF discussions, several Internet-Drafts were written that were loosely related to the general themes of DNS and multicast, but did not address the service discovery aspect of NBP.
1997年7月，在一封电子邮件中-thinkers@thumper.vmeng.comStuart Cheshire首先提出了在IP上运行AppleTalk名称绑定协议[RFC6760]的想法。由于这次和相关的IETF讨论，IETF Zeroconf工作组于1999年9月成立。在各种工作组讨论和其他非正式IETF讨论之后，编写了几份与DNS和多播的一般主题松散相关的互联网草案，但没有涉及NBP的服务发现方面。
In April 2000, Stuart Cheshire registered IPv4 multicast address 224.0.0.251 with IANA and began writing code to test and develop the idea of performing NBP-like service discovery using Multicast DNS, which was documented in a group of three Internet-Drafts:
2000年4月，Stuart Cheshire向IANA注册了IPv4多播地址224.0.0.251，并开始编写代码来测试和开发使用多播DNS执行类似NBP的服务发现的想法，该想法记录在一组三个Internet草稿中：
o "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk Name Binding Protocol, because many in the IETF community had little first-hand experience using AppleTalk, and confusion in the IETF community about what AppleTalk NBP did was causing confusion about what would be required in an IP-based replacement.
o “替代AppleTalk名称绑定协议（NBP）的协议要求”[RFC6760]是解释AppleTalk名称绑定协议的概述，因为IETF社区中的许多人几乎没有使用AppleTalk的第一手经验，IETF社区对AppleTalk NBP所做的工作的困惑导致了对基于IP的替换所需内容的困惑。
o "Discovering Named Instances of Abstract Services using DNS" [NIAS], which later became this document, proposed a way to perform NBP-like service discovery using DNS-compatible names and record types.
o “使用DNS发现抽象服务的命名实例”[NIAS]，后来成为本文档，提出了一种使用DNS兼容名称和记录类型执行类似NBP的服务发现的方法。
o "Multicast DNS" [RFC6762] specifies a way to transport those DNS-compatible queries and responses using IP multicast, for zero-configuration environments where no conventional Unicast DNS server was available.
o “多播DNS”[RFC6762]指定了一种使用IP多播传输那些DNS兼容的查询和响应的方法，适用于没有传统单播DNS服务器的零配置环境。
In 2001, an update to Mac OS 9 added resolver library support for host name lookup using Multicast DNS. If the user typed a name such as "MyPrinter.local." into any piece of networking software that used the standard Mac OS 9 name lookup APIs, then those name lookup APIs would recognize the name as a dot-local name and query for it by sending simple one-shot Multicast DNS queries to 224.0.0.251:5353. This enabled the user to, for example, enter the name "MyPrinter.local." into their web browser in order to view a printer's status and configuration web page, or enter the name "MyPrinter.local." into the printer setup utility to create a print queue for printing documents on that printer.
2001年，Mac OS 9的更新增加了解析器库对使用多播DNS查找主机名的支持。如果用户在使用标准Mac OS 9名称查找API的任何网络软件中键入“MyPrinter.local.”等名称，则这些名称查找API将识别该名称为点本地名称，并通过向224.0.0.251:5353发送简单的一次性多播DNS查询来查询该名称。例如，这允许用户在其web浏览器中输入名称“MyPrinter.local.”以查看打印机的状态和配置网页，或在打印机设置实用程序中输入名称“MyPrinter.local.”以创建打印队列，以便在该打印机上打印文档。
Multicast DNS responder software, with full service discovery, first began shipping to end users in volume with the launch of Mac OS X 10.2 "Jaguar" in August 2002, and network printer makers (who had historically supported AppleTalk in their network printers and were receptive to IP-based technologies that could offer them similar ease-of-use) started adopting Multicast DNS shortly thereafter.
随着2002年8月Mac OS X 10.2“Jaguar”的推出，多播DNS响应程序软件（具有全服务发现功能）首先开始批量向最终用户提供，网络打印机制造商（他们在网络打印机中一直支持AppleTalk，并接受基于IP的技术，这些技术可以为他们提供类似的易用性）此后不久开始采用多播DNS。
In September 2002, Apple released the source code for the mDNSResponder daemon as Open Source under Apple's standard Apple Public Source License (APSL).
2002年9月，苹果根据苹果的标准苹果公共源代码许可证（APSL）发布了mDNSResponder守护程序的源代码，该守护程序是开源的。
Multicast DNS responder software became available for Microsoft Windows users in June 2004 with the launch of Apple's "Rendezvous for Windows" (now "Bonjour for Windows"), both in executable form (a downloadable installer for end users) and as Open Source (one of the supported platforms within Apple's body of cross-platform code in the publicly accessible mDNSResponder CVS source code repository) [BJ].
2004年6月，随着苹果公司推出的“Windows集合”（现为“Windows你好”）的推出，微软Windows用户可以使用多播DNS响应程序软件，该软件以可执行形式（最终用户可下载的安装程序）和开源形式提供（可公开访问的MDnsrresponder CVS源代码库中苹果跨平台代码库中受支持的平台之一）[BJ]。
In August 2006, Apple re-licensed the cross-platform mDNSResponder source code under the Apache License, Version 2.0.
2006年8月，苹果根据Apache许可证2.0版重新许可了跨平台mDNSResponder源代码。
In addition to desktop and laptop computers running Mac OS X and Microsoft Windows, Multicast DNS is now implemented in a wide range of hardware devices, such as Apple's "AirPort" wireless base stations, iPhone and iPad, and in home gateways from other vendors, network printers, network cameras, TiVo DVRs, etc.
除了运行Mac OS X和Microsoft Windows的台式机和笔记本电脑外，多播DNS现在还应用于各种硬件设备中，如苹果的“机场”无线基站、iPhone和iPad，以及其他供应商的家庭网关、网络打印机、网络摄像头、TiVo DVR等。
The Open Source community has produced many independent implementations of Multicast DNS, some in C like Apple's mDNSResponder daemon, and others in a variety of different languages including Java, Python, Perl, and C#/Mono.
开源社区已经产生了许多独立的多播DNS实现，一些采用C语言，如Apple的mDNSResponder守护程序，另一些采用各种不同的语言，包括Java、Python、Perl和C#/Mono。
In January 2007, the IETF published the Informational RFC "Link-Local Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially similar to Multicast DNS, but incompatible in some small but important ways. In particular, the LLMNR design explicitly excluded support for service discovery, which made it an unsuitable candidate for a protocol to replace AppleTalk NBP [RFC6760].
2007年1月，IETF发布了信息RFC“链路本地多播名称解析（LLMNR）”[RFC4795]，它与多播DNS基本相似，但在一些小但重要的方面不兼容。特别是，LLMNR设计明确排除了对服务发现的支持，这使得它不适合替代AppleTalk NBP的协议[RFC6760]。
While the original focus of Multicast DNS and DNS-Based Service Discovery was for zero-configuration environments without a conventional Unicast DNS server, DNS-Based Service Discovery also works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over Unicast DNS [RFC6281].
虽然多播DNS和基于DNS的服务发现的最初重点是针对没有传统单播DNS服务器的零配置环境，但基于DNS的服务发现也可以使用单播DNS服务器工作，使用DNS更新[RFC2136][RFC3007]创建服务发现记录，并使用标准DNS查询对其进行查询。2007年10月，苹果推出了Mac OS X 10.5“Leopard”版的“回到我的Mac”服务，该服务在单播DNS上使用基于DNS的服务发现[RFC6281]。
In June 2012, Google's Android operating system added native support for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
2012年6月，谷歌的Android操作系统在Android 4.1“Jelly Bean”（API级别16）[nsd]中添加了对DNS-SD和多播DNS的本机支持，其中包含Android.net.nsd.NsdManager类。
Authors' Addresses
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 4368
EMail: marc@apple.com
Phone: +1 408 974 4368
EMail: marc@apple.com