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




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.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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 .....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 .....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
1. Introduction
1. 介绍

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.


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.


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.


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].


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


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.


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.


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".


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.


2. Conventions and Terminology Used in This Document
2. 本文件中使用的约定和术语

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].


3. Design Goals
3. 设计目标

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).


(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.


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.


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.


4. Service Instance Enumeration (Browsing)
4. 服务实例枚举(浏览)

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 "" would allow a client to discover servers implementing the "_http._tcp" service (i.e., web servers) for the "" 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].

例如,具有(假设)名称“”的SRV记录将允许客户端发现为“”域实现“_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 "" 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”以查找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.


4.1. Structured Service Instance Names
4.1. 结构化服务实例名称

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 "", 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”的“SRV”类型的记录。[RFC1035]。

In effect, if one thinks of the domain name "" 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 "" were expressed as a file system path name, it would be "/com/example/_tcp/_ipp".)

实际上,如果你认为域名“”类似于文件系统中某个目录的绝对路径,那么DNS-SD的PTR查找类似于执行该目录的列表以查找其包含的所有条目。(请记住,域名的表达顺序与路径名相反——绝对路径名从左边的根开始,从左到右读取,而完全限定的域名从右边的根开始,从右到左读取。如果完全限定的域名“\u ipp.\u。”表示为文件系统路径名,它将是“/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 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".


4.1.1. Instance Names
4.1.1. 实例名称

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".


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


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.


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.


4.1.2. Service Names
4.1.2. 服务名称

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".


4.1.3. Domain Names
4.1.3. 域名

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 "", "", or "" 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域名,如“”、“”或“”。因为服务实例名称不是主机名,所以它们不受主机名的常规规则[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 .


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标签,并且查询仍然失败,则放弃。

4.2. User Interface Presentation
4.2. 用户界面演示

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).


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.


For further discussion of Service Instance Enumeration (browsing) user-interface considerations, see Appendix F, "'Continuous Live Update' Browsing Model".


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.


4.3. Internal Handling of Names
4.3. 姓名的内部处理

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.


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 "\\").


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(),后者将按预期解释反斜杠转义字符串。

5. Service Instance Resolution
5. 服务实例解析

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.


6. Data Syntax for DNS-SD TXT Records
6. DNS-SD TXT记录的数据语法

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.


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记录。

6.1. General Format Rules for DNS TXT Records
6.1. DNS 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.


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:


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或无错误无应答响应。)

6.2. DNS-SD TXT Record Size
6.2. DNS-SD TXT记录大小

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].


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.


Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time.


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


(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.


6.3. DNS TXT Record Format Rules for Use in DNS-SD
6.3. DNS-SD中使用的DNS TXT记录格式规则

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.


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.


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


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.


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.


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.


6.4. Rules for Keys in DNS-SD Key/Value Pairs
6.4. DNS-SD密钥/值对中密钥的规则

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


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.


The characters of a key MUST be printable US-ASCII values (0x20-0x7E) [RFC20], excluding '=' (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.


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.


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:


* 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:


* 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].


6.5. Rules for Values in DNS-SD Key/Value Pairs
6.5. DNS-SD键/值对中值的规则

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.


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.


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.


6.6. Example TXT Record
6.6. 示例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.)


        | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
        | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
6.7. Version Tag
6.7. 版本标签

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.


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".


6.8. Service Instances with Multiple TXT Records
6.8. 具有多个TXT记录的服务实例

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.


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打印协议的这一不足之处,从而效仿这个坏例子。

7. Service Names
7. 服务名称

The <Service> portion of a 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.


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


"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.


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.


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>的可见结构应该反映协议实现方式的私有内部结构。这是不对的。所需的只是通过一些唯一的不透明服务名称来标识服务。使服务名称成为英文文本,至少在一定程度上描述服务的功能可能是方便的,但这绝不是必需的。

7.1. Selective Instance Enumeration (Subtypes)
7.1. 选择性实例枚举(子类型)

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", 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”的服务的标准浏览查询仍然可以发现播发的网页。注册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:


; 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.


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.


7.2. Service Name Length Limits
7.2. 服务名称长度限制

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).


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:


<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").


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.


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.


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.


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.


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.


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.


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.


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.


8. Flagship Naming
8. 旗舰命名

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.


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.


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.


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.


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.


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.


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.


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).


9. Service Type Enumeration
9. 服务类型枚举

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查询,以发现该服务类型的实例。

10. Populating the DNS with Information
10. 用信息填充DNS

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.


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].


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 "" subdomain to the printer manager device.

或者,打印机管理器设备可以实现足够多的DNS协议,从而能够直接回答DNS查询,Example Co.的主DNS服务器可以将“\u ipp.\u”子域委托给打印机管理器设备。

IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] to automatically register their own PTR, SRV, and TXT records with the DNS server.


Zeroconf printers answer Multicast DNS queries on the local link for their own PTR, SRV, and TXT names ending with ".local." [RFC6762].


11. Discovery of Browsing and Registration Domains (Domain Enumeration)
11. 发现浏览和注册域(域枚举)

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.


This discovery is performed using DNS queries, using Unicast or Multicast DNS. Five special RR names are reserved for this purpose:


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:


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, with the subnet mask, then the 'base' address of the subnet is, and to discover the recommended automatic browsing domain(s) for devices on this subnet, the host issues a DNS PTR query for the name ""

查询名称的<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.发出DNS PTR查询

Equivalent address-derived Domain Enumeration queries should also be done for the host's IPv6 address(es).


Address-derived Domain Enumeration queries SHOULD NOT be done for IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses [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.


12. DNS Additional Record Generation
12. DNS附加记录生成

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.


This section recommends which additional records SHOULD be generated to improve network efficiency, for both Unicast and Multicast DNS-SD responses.


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.


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.


12.1. PTR Records
12.1. PTR记录

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:


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”)。

12.2. SRV Records
12.2. SRV记录

When including an SRV record in a response packet, the server/responder SHOULD include the following additional records:


o All address records (type "A" and "AAAA") named in the SRV rdata.

o SRV rdata中命名的所有地址记录(类型“A”和“AAAA”)。

12.3. TXT Records
12.3. TXT记录

When including a TXT record in a response packet, no additional records are required.


12.4. Other Record Types
12.4. 其他记录类型

In response to address queries, or other record types, no new additional records are recommended by this document.


13. Working Examples
13. 工作实例

The following examples were prepared using standard unmodified nslookup and standard unmodified BIND running on GNU/Linux.


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.


13.1. What web pages are being advertised from
13.1. 从dns-sd.org广告哪些网页?

nslookup -q=ptr name = name = Multicast\ name = Service\ name = Stuart's\

nslookup-q=ptr\u http.\u tcp.dns-sd.org_http.\u name=Zeroconf.\u http.\u\u http.\u name=Multicast\032DNS.\u http.\u name=Service\032Discovery.\u http.\u\u http.\u name=Stuart\032Printer.\u http.\u

Answer: There are four, called "Zeroconf", "Multicast DNS", "Service Discovery", and "Stuart's Printer".


Note that nslookup escapes spaces as "\032" for display purposes, but a graphical DNS-SD browser should not.


13.2. What printer-configuration web pages are there?
13.2. 有哪些打印机配置网页?

nslookup -q=ptr name = Stuart's\

nslookup-q=ptr\u printer.\u sub.\u http.\u tcp.dns-sd.org_打印机。 name=Stuart的\032打印机。

Answer: "Stuart's Printer" is the web configuration UI of a network printer.

答:“Stuart’s Printer”是网络打印机的web配置UI。

13.3. How do I access the web page called "Service Discovery"?
13.3. 如何访问名为“服务发现”的网页?
   nslookup -q=any "Service\"
                  priority = 0, weight = 0, port = 80, host =
                  text = "txtvers=1" "path=/"     nameserver =     internet address = internet address =
   nslookup -q=any "Service\"
                  priority = 0, weight = 0, port = 80, host =
                  text = "txtvers=1" "path=/"     nameserver =     internet address = internet address =

Answer: You need to connect to port 80, path "/". The address for is also given (


14. IPv6 Considerations
14. IPv6注意事项

IPv6 has only minor differences from 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.


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.


15. Security Considerations
15. 安全考虑

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.


For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important.


For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.


16. IANA Considerations
16. IANA考虑

IANA manages the namespace of unique Service Names [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


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.


17. Acknowledgments
17. 致谢

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的重要贡献。

18. References
18. 工具书类
18.1. Normative References
18.1. 规范性引用文件

[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.


[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987.


[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月。

18.2. Informative References
18.2. 资料性引用

[AFP] Mac OS X Developer Library, "Apple Filing Protocol Programming Guide", < documentation/Networking/Conceptual/AFP/>.

[法新社]Mac OS X开发者库,“苹果归档协议编程指南”< 文件/网络/概念/AFP/>。

[BJ] Apple Bonjour Open Source Software, <>.


[BJP] Bonjour Printing Specification, < printing-specification/bonjourprinting-1.0.2.pdf>.

[BJP]你好,印刷规范< 打印规范/bonjourprinting-1.0.2.pdf>。

[IEEEW] IEEE 802 LAN/MAN Standards Committee, <>.

IEEE 802局域网/城域网标准委员会<>.

[NIAS] Cheshire, S., "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001.


[NSD] "NsdManager | Android Developer", June 2012, < net/nsd/NsdManager.html>.

[NSD]“NsdManager | Android开发者”,2012年6月< net/nsd/NsdManager.html>。

[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990.


[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.


[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", < service-names-port-numbers/>.

[SN]IANA,“服务名称和传输协议端口号注册表”< 服务名称端口号/>。

[SOAP] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C Proposed Recommendation 24 June 2003, <>.


[Unicode6] The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6) <>.

[Unicode 6]Unicode联盟。Unicode标准,版本6.0.0,(加利福尼亚州山景城:Unicode联盟,2011年。ISBN 978-1-936213-01-6)<>.

[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月。

Appendix A. Rationale for Using DNS as a Basis for Service Discovery

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.


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.


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.


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.


Service discovery needs to be able to provide appropriate security. DNS already has existing mechanisms for security [RFC4033].


In summary:


Service discovery requires a central aggregation server. DNS already has one: a DNS server.


Service discovery requires a service registration protocol. DNS already has one: DNS Dynamic Update.


Service discovery requires a query protocol. DNS already has one: DNS queries.


Service discovery requires security mechanisms. DNS already has security mechanisms: 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.


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.


Appendix B. Ordering of Service Instance Name Components

There have been questions about why services are named using DNS Service Instance Names of the form:


      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. Semantic Structure
B.1. 语义结构

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.


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.


B.2. Network Efficiency
B.2. 网络效率

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.


B.3. Operational Flexibility
B.3. 操作灵活性

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 "" 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 "" 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.的网络管理员可以选择将“”子域委托给另一台机器,以便处理服务发现的机器不必是处理其他日常DNS操作的机器。(如果管理员选择,它*可以*是同一台机器,但管理员可以自由选择。)此外,如果网络管理员希望将与IPP打印机相关的所有信息委派给专用于该特定任务的机器,则可以通过委派“”轻松完成所需计算机的子域。在每个区域/每个子域的基础上设置安全策略也很方便。例如,管理员可以选择为在中注册的打印机启用DNS动态更新[RFC2136][RFC3007]

"" subdomain, but not for other zones/subdomains. This easy flexibility would not exist if the <Service> component appeared first in each name.


Appendix C. What You See Is What You Get

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.


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.


Appendix D. Choice of Factory-Default Names

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:


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:


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) 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”实际上是一个用户友好的富文本名称列表(支持混合大小写、空格、标点符号、非罗马字符和其他符号)并且把它变成了最糟糕的用户界面:一系列令人费解的随机字母和数字串。在一个有很多打印机的网络中,设置打印机的人最好花点时间为每个打印机指定一个描述性名称,但如果他们不这样做,则向用户提供一个按顺序编号的打印机列表是比显示原始以太网地址列表更理想的默认用户体验。

Appendix E. Name Encodings in the Domain Name System

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:


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.


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.


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.


Appendix F. "Continuous Live Update" Browsing Model


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:


(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.


The service discovery user experience that the DNS-SD designers had in mind has some rather different properties:


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


In July 1997, in an email to the 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 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 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).


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.


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.


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 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的本机支持,其中包含类。

Authors' Addresses


Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA


   Phone: +1 408 974 3207
   Phone: +1 408 974 3207

Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA

Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号,邮编95014

   Phone: +1 408 974 4368
   Phone: +1 408 974 4368