Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6762 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6762 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
Multicast DNS
多播DNS
Abstract
摘要
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
随着网络设备变得更小、更便携、更普遍，使用配置更少的基础设施进行操作的能力变得越来越重要。特别是，在没有传统托管DNS服务器的情况下查找DNS资源记录数据类型（包括但不限于主机名）的能力非常有用。
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
多播DNS（mDNS）提供在没有任何传统单播DNS服务器的情况下在本地链路上执行类似DNS的操作的能力。此外，多播DNS指定DNS命名空间的一部分免费供本地使用，无需支付任何年费，也无需设置委派或以其他方式配置传统DNS服务器来回答这些名称。
The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.
多播DNS名称的主要好处是：（i）它们只需要很少或不需要管理或配置即可设置；（ii）在不存在基础设施时工作；（iii）在基础设施故障时工作。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6762.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6762.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions and Terminology Used in This Document ...............4
3. Multicast DNS Names .............................................5
4. Reverse Address Mapping .........................................7
5. Querying ........................................................8
6. Responding .....................................................13
7. Traffic Reduction ..............................................22
8. Probing and Announcing on Startup ..............................25
9. Conflict Resolution ............................................31
10. Resource Record TTL Values and Cache Coherency ................33
11. Source Address Check ..........................................38
12. Special Characteristics of Multicast DNS Domains ..............40
13. Enabling and Disabling Multicast DNS ..........................41
14. Considerations for Multiple Interfaces ........................42
15. Considerations for Multiple Responders on the Same Machine ....43
16. Multicast DNS Character Set ...................................45
17. Multicast DNS Message Size ....................................46
18. Multicast DNS Message Format ..................................47
19. Summary of Differences between Multicast DNS and Unicast DNS ..51
20. IPv6 Considerations ...........................................52
21. Security Considerations .......................................52
22. IANA Considerations ...........................................53
23. Acknowledgments ...............................................56
24. References ....................................................56
Appendix A. Design Rationale for Choice of UDP Port Number ........60
Appendix B. Design Rationale for Not Using Hashed Multicast
Addresses .............................................61
Appendix C. Design Rationale for Maximum Multicast DNS Name
Length ................................................62
Appendix D. Benefits of Multicast Responses .......................64
Appendix E. Design Rationale for Encoding Negative Responses ......65
Appendix F. Use of UTF-8 ..........................................66
Appendix G. Private DNS Namespaces ................................67
Appendix H. Deployment History ....................................67
1. Introduction ....................................................4
2. Conventions and Terminology Used in This Document ...............4
3. Multicast DNS Names .............................................5
4. Reverse Address Mapping .........................................7
5. Querying ........................................................8
6. Responding .....................................................13
7. Traffic Reduction ..............................................22
8. Probing and Announcing on Startup ..............................25
9. Conflict Resolution ............................................31
10. Resource Record TTL Values and Cache Coherency ................33
11. Source Address Check ..........................................38
12. Special Characteristics of Multicast DNS Domains ..............40
13. Enabling and Disabling Multicast DNS ..........................41
14. Considerations for Multiple Interfaces ........................42
15. Considerations for Multiple Responders on the Same Machine ....43
16. Multicast DNS Character Set ...................................45
17. Multicast DNS Message Size ....................................46
18. Multicast DNS Message Format ..................................47
19. Summary of Differences between Multicast DNS and Unicast DNS ..51
20. IPv6 Considerations ...........................................52
21. Security Considerations .......................................52
22. IANA Considerations ...........................................53
23. Acknowledgments ...............................................56
24. References ....................................................56
Appendix A. Design Rationale for Choice of UDP Port Number ........60
Appendix B. Design Rationale for Not Using Hashed Multicast
Addresses .............................................61
Appendix C. Design Rationale for Maximum Multicast DNS Name
Length ................................................62
Appendix D. Benefits of Multicast Responses .......................64
Appendix E. Design Rationale for Encoding Negative Responses ......65
Appendix F. Use of UTF-8 ..........................................66
Appendix G. Private DNS Namespaces ................................67
Appendix H. Deployment History ....................................67
Multicast DNS and its companion technology DNS-Based Service Discovery [RFC6763] were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well-known [RFC6760]. When reading this document, familiarity with the concepts of Zero Configuration Networking [Zeroconf] and automatic link-local addressing [RFC3927] [RFC4862] is helpful.
创建多播DNS及其配套技术基于DNS的服务发现[RFC6763]是为了提供易于使用和自动配置的IP网络，AppleTalk对此非常熟悉[RFC6760]。阅读本文档时，熟悉零配置网络[Zeroconf]和自动链接本地寻址[RFC3927][RFC4862]的概念会有所帮助。
Multicast DNS borrows heavily from the existing DNS protocol [RFC1034] [RFC1035] [RFC6195], using the existing DNS message structure, name syntax, and resource record types. This document specifies no new operation codes or response codes. This document describes how clients send DNS-like queries via IP multicast, and how a collection of hosts cooperate to collectively answer those queries in a useful manner.
多播DNS大量借用现有DNS协议[RFC1034][RFC1035][RFC6195]，使用现有DNS消息结构、名称语法和资源记录类型。本文件未规定新的操作代码或响应代码。本文档描述了客户端如何通过IP多播发送类似DNS的查询，以及主机集合如何协作以有用的方式集体回答这些查询。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
When this document uses the term "Multicast DNS", it should be taken to mean: "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response messages over IP Multicast to UDP port 5353". The design rationale for selecting UDP port 5353 is discussed in Appendix A.
当本文档使用术语“多播DNS”时，应理解为“通过IP多播向UDP端口5353发送类似DNS的UDP查询和响应消息，对类似DNS的资源记录执行类似DNS查询的客户端”。附录A讨论了选择UDP端口5353的设计原理。
This document uses the term "host name" in the strict sense to mean a fully qualified domain name that has an IPv4 or IPv6 address record. It does not use the term "host name" in the commonly used but incorrect sense to mean just the first DNS label of a host's fully qualified domain name.
本文档使用严格意义上的术语“主机名”表示具有IPv4或IPv6地址记录的完全限定域名。它没有使用常用但不正确的术语“主机名”来表示主机完全限定域名的第一个DNS标签。
A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP header, which is effectively a hop-count limit for the packet, to guard against routing loops. Each resource record also contains a TTL, which is the number of seconds for which the resource record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the resource record TTL (cache lifetime).
DNS（或mDNS）数据包在IP报头中包含IP生存时间（TTL），这实际上是数据包的跳数限制，以防止路由循环。每个资源记录还包含一个TTL，TTL是可以缓存资源记录的秒数。本文档使用术语“IP TTL”表示IP头TTL（跃点限制），术语“RR TTL”或仅“TTL”表示资源记录TTL（缓存生存期）。
DNS-format messages contain a header, a Question Section, then Answer, Authority, and Additional Record Sections. The Answer, Authority, and Additional Record Sections all hold resource records
DNS格式消息包含标题、问题部分、答案、权限和其他记录部分。答案、权限和附加记录部分都保存资源记录
in the same format. Where this document describes issues that apply equally to all three sections, it uses the term "Resource Record Sections" to refer collectively to these three sections.
同样的格式。如果本文件描述的问题同样适用于所有三个章节，则使用术语“资源记录章节”统称这三个章节。
This document uses the terms "shared" and "unique" when referring to resource record sets [RFC1034]:
本文档在引用资源记录集[RFC1034]时使用术语“共享”和“唯一”：
A "shared" resource record set is one where several Multicast DNS responders may have records with the same name, rrtype, and rrclass, and several responders may respond to a particular query.
“共享”资源记录集是多播DNS响应程序可能具有相同名称、rrtype和rrclass的记录，并且多个响应程序可能响应特定查询的记录集。
A "unique" resource record set is one where all the records with that name, rrtype, and rrclass are conceptually under the control or ownership of a single responder, and it is expected that at most one responder should respond to a query for that name, rrtype, and rrclass. Before claiming ownership of a unique resource record set, a responder MUST probe to verify that no other responder already claims ownership of that set, as described in Section 8.1, "Probing". (For fault-tolerance and other reasons, sometimes it is permissible to have more than one responder answering for a particular "unique" resource record set, but such cooperating responders MUST give answers containing identical rdata for these records. If they do not give answers containing identical rdata, then the probing step will reject the data as being inconsistent with what is already being advertised on the network for those names.)
“唯一”资源记录集是指具有该名称、rrtype和rrclass的所有记录在概念上都由单个响应者控制或拥有的记录集，预计最多有一个响应者应对该名称、rrtype和rrclass的查询作出响应。在声明唯一资源记录集的所有权之前，响应者必须进行探测，以验证没有其他响应者已声明该集的所有权，如第8.1节“探测”所述。（出于容错和其他原因，有时允许一个以上的响应者为特定的“唯一”应答）资源记录集，但此类合作响应者必须为这些记录提供包含相同rdata的答案。如果他们不提供包含相同rdata的答案，则探测步骤将拒绝这些数据，因为这些数据与网络上已公布的名称不一致。）
Strictly speaking, the terms "shared" and "unique" apply to resource record sets, not to individual resource records. However, it is sometimes convenient to talk of "shared resource records" and "unique resource records". When used this way, the terms should be understood to mean a record that is a member of a "shared" or "unique" resource record set, respectively.
严格来说，“共享”和“唯一”这两个术语适用于资源记录集，而不是单个资源记录。然而，有时谈论“共享资源记录”和“唯一资源记录”是很方便的。当以这种方式使用时，术语应理解为分别是“共享”或“唯一”资源记录集的成员的记录。
A host that belongs to an organization or individual who has control over some portion of the DNS namespace can be assigned a globally unique name within that portion of the DNS namespace, such as, "cheshire.example.com.". For those of us who have this luxury, this works very well. However, the majority of home computer users do not have easy access to any portion of the global DNS namespace within which they have the authority to create names. This leaves the majority of home computers effectively anonymous for practical purposes.
可以在DNS命名空间的某一部分中为属于控制DNS命名空间某一部分的组织或个人的主机分配一个全局唯一名称，例如“cheshire.example.com”。对于我们这些拥有这种奢侈品的人来说，这非常有效。但是，大多数家庭计算机用户无法轻松访问全局DNS命名空间的任何部分，他们有权在其中创建名称。这使得大多数家庭电脑实际上是匿名的。
To remedy this problem, this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local.". For example, a laptop computer may answer to the name "MyComputer.local.". Any computer user is granted the authority to name their computer this way, provided that the chosen host name is not already in use on that link. Having named their computer this way, the user has the authority to continue utilizing that name until such time as a name conflict occurs on the link that is not resolved in the user's favor. If this happens, the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link. These conflicts are expected to be relatively rare for people who choose reasonably imaginative names, but it is still important to have a mechanism in place to handle them when they happen.
为了解决此问题，此文档允许任何计算机用户选择以“single DNS label.local.”的形式为其计算机提供链接本地多播DNS主机名。例如，膝上型计算机的名称可能是“MyComputer.local”。任何计算机用户都有权以这种方式命名其计算机，前提是所选主机名尚未在该链接上使用。以这种方式命名他们的计算机后，用户有权继续使用该名称，直到链接上出现名称冲突，而该冲突没有得到有利于用户的解决。如果发生这种情况，计算机（或其人类用户）必须停止使用该名称，并应尝试分配一个新的唯一名称以在该链接上使用。这些冲突对于那些选择合理的富有想象力的名字的人来说是相对罕见的，但是当冲突发生时，有一个适当的机制来处理它们仍然很重要。
This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.
本文档规定DNS顶级域“.local.”是一个具有特殊语义的特殊域，即任何以“.local.”结尾的完全限定名称都是本地链接，并且此域中的名称仅在其来源的链接上有意义。这类似于169.254/16前缀中的IPv4地址或FE80:：/10前缀中的IPv6地址，它们是链路本地地址，仅在它们发起的链路上才有意义。
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). The design rationale for using a fixed multicast address instead of selecting from a range of multicast addresses using a hash function is discussed in Appendix B. Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster).
任何以“.local.”结尾的名称的DNS查询都必须发送到mDNS IPv4链路本地多播地址224.0.0.251（或其IPv6等效项FF02:：FB）。附录B讨论了使用固定多播地址而不是使用哈希函数从一系列多播地址中进行选择的设计原理。实施者可以选择通过其他机制（例如，单播DNS）同时查找此类名称，并以某种方式合并结果。选择这样做的实现者应该意识到，当给定的名称可能根据外部网络条件（例如，但不限于，哪个名称查找机制响应更快）产生不同的结果时，用户可能会感到困惑。
It is unimportant whether a name ending with ".local." occurred because the user explicitly typed in a fully qualified domain name ending in ".local.", or because the user entered an unqualified domain name and the host software appended the suffix ".local." because that suffix appears in the user's search list. The ".local." suffix could appear in the search list because the user manually configured it, or because it was received via DHCP [RFC2132] or via any other mechanism for configuring the DNS search list. In this respect the ".local." suffix is treated no differently from any other search domain that might appear in the DNS search list.
出现以“.local.”结尾的名称并不重要，因为用户显式键入了以“.local.”结尾的完全限定域名，或者因为用户输入了非限定域名，主机软件附加了后缀“.local.”，因为该后缀出现在用户的搜索列表中。“.local.”后缀可能出现在搜索列表中，因为用户手动配置了它，或者因为它是通过DHCP[RFC2132]或任何其他用于配置DNS搜索列表的机制接收的。在这方面，“.local.”后缀与DNS搜索列表中可能出现的任何其他搜索域没有区别。
DNS queries for names that do not end with ".local." MAY be sent to the mDNS multicast address, if no other conventional DNS server is available. This can allow hosts on the same link to continue communicating using each other's globally unique DNS names during network outages that disrupt communication with the greater Internet. When resolving global names via local multicast, it is even more important to use DNS Security Extensions (DNSSEC) [RFC4033] or other security mechanisms to ensure that the response is trustworthy. Resolving global names via local multicast is a contentious issue, and this document does not discuss it further, instead concentrating on the issue of resolving local names using DNS messages sent to a multicast address.
如果没有其他常规DNS服务器可用，则可以将对不以“.local.”结尾的名称的DNS查询发送到mDNS多播地址。这可以允许同一链路上的主机在网络中断期间继续使用彼此的全局唯一DNS名称进行通信，从而中断与更大Internet的通信。当通过本地多播解析全局名称时，更重要的是使用DNS安全扩展（DNSSEC）[RFC4033]或其他安全机制来确保响应是可信的。通过本地多播解析全局名称是一个有争议的问题，本文档不再进一步讨论，而是集中讨论使用发送到多播地址的DNS消息解析本地名称的问题。
This document recommends a single flat namespace for dot-local host names, (i.e., the names of DNS "A" and "AAAA" records, which map names to IPv4 and IPv6 addresses), but other DNS record types (such as those used by DNS-Based Service Discovery [RFC6763]) may contain as many labels as appropriate for the desired usage, up to a maximum of 255 bytes, plus a terminating zero byte at the end. Name length issues are discussed further in Appendix C.
本文档建议为dot本地主机名（即DNS“a”和“AAAA”记录的名称，它们将名称映射到IPv4和IPv6地址）使用单一的平面名称空间，但其他DNS记录类型（如基于DNS的服务发现[RFC6763]所使用的记录）可能包含适合所需用途的尽可能多的标签，最多255个字节，最后加一个终止的零字节。附录C进一步讨论了名称长度问题。
Enforcing uniqueness of host names is probably desirable in the common case, but this document does not mandate that. It is permissible for a collection of coordinated hosts to agree to maintain multiple DNS address records with the same name, possibly for load-balancing or fault-tolerance reasons. This document does not take a position on whether that is sensible. It is important that both modes of operation be supported. The Multicast DNS protocol allows hosts to verify and maintain unique names for resource records where that behavior is desired, and it also allows hosts to maintain multiple resource records with a single shared name where that behavior is desired. This consideration applies to all resource records, not just address records (host names). In summary: It is required that the protocol have the ability to detect and handle name conflicts, but it is not required that this ability be used for every record.
在常见情况下，强制实现主机名的唯一性可能是可取的，但本文档并不要求这样做。允许协调主机的集合同意维护具有相同名称的多个DNS地址记录，可能是出于负载平衡或容错原因。这份文件没有就这是否合理采取立场。重要的是两种操作模式都应得到支持。多播DNS协议允许主机验证和维护所需行为的资源记录的唯一名称，还允许主机使用单个共享名称维护所需行为的多个资源记录。这一考虑适用于所有资源记录，而不仅仅是地址记录（主机名）。总之：协议必须具有检测和处理名称冲突的能力，但不要求对每个记录都使用这种能力。
Like ".local.", the IPv4 and IPv6 reverse mapping domains are also defined to be link-local:
与“.local”类似，IPv4和IPv6反向映射域也定义为链路本地：
Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 multicast address FF02::FB. Since names under this domain correspond to IPv4 link-local addresses, it is logical that the local link is the best place to find information pertaining to those names.
任何以“254.169.in addr.arpa.”结尾的名称的DNS查询都必须发送到mDNS IPv4链路本地多播地址224.0.0.251或mDNS IPv6多播地址FF02:：FB。由于此域下的名称对应于IPv4链路本地地址，因此本地链路是查找这些名称相关信息的最佳位置是合乎逻辑的。
Likewise, any DNS query for a name within the reverse mapping domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST be sent to the mDNS IPv6 link-local multicast address FF02::FB or the mDNS IPv4 link-local multicast address 224.0.0.251.
同样，在IPv6链路本地地址的反向映射域中对名称的任何DNS查询（“8.e.f.ip6.arpa.”、“9.e.f.ip6.arpa.”、“a.e.f.ip6.arpa.”和“b.e.f.ip6.arpa.”必须发送到mDNS IPv6链路本地多播地址FF02:：FB或mDNS IPv4链路本地多播地址224.0.0.251。
There are two kinds of Multicast DNS queries: one-shot queries of the kind made by legacy DNS resolvers, and continuous, ongoing Multicast DNS queries made by fully compliant Multicast DNS queriers, which support asynchronous operations including DNS-Based Service Discovery [RFC6763].
有两种多播DNS查询：一种是由传统DNS解析程序进行的一次性查询，另一种是由完全兼容的多播DNS查询程序进行的持续多播DNS查询，支持异步操作，包括基于DNS的服务发现[RFC6763]。
Except in the rare case of a Multicast DNS responder that is advertising only shared resource records and no unique records, a Multicast DNS responder MUST also implement a Multicast DNS querier so that it can first verify the uniqueness of those records before it begins answering queries for them.
除了少数情况下，多播DNS响应程序仅公布共享资源记录而没有唯一记录外，多播DNS响应程序还必须实现多播DNS查询器，以便在开始回答这些记录的查询之前，能够首先验证这些记录的唯一性。
The most basic kind of Multicast DNS client may simply send standard DNS queries blindly to 224.0.0.251:5353, without necessarily even being aware of what a multicast address is. This change can typically be implemented with just a few lines of code in an existing DNS resolver library. If a name being queried falls within one of the reserved Multicast DNS domains (see Sections 3 and 4), then, rather than using the configured Unicast DNS server address, the query is instead sent to 224.0.0.251:5353 (or its IPv6 equivalent [FF02::FB]:5353). Typically, the timeout would also be shortened to two or three seconds. It's possible to make a minimal Multicast DNS resolver with only these simple changes. These queries are typically done using a high-numbered ephemeral UDP source port, but regardless of whether they are sent from a dynamic port or from a fixed port, these queries MUST NOT be sent using UDP source port 5353, since using UDP source port 5353 signals the presence of a fully compliant Multicast DNS querier, as described below.
最基本的多播DNS客户端可能只是盲目地将标准DNS查询发送到224.0.0.251:5353，而不一定知道多播地址是什么。此更改通常只需在现有DNS解析器库中使用几行代码即可实现。如果查询的名称属于保留的多播DNS域之一（请参见第3节和第4节），则查询将被发送到224.0.0.251:5353（或其IPv6等效项[FF02:：FB]：5353），而不是使用配置的单播DNS服务器地址。通常，超时时间也会缩短到2秒或3秒。仅通过这些简单的更改就可以创建一个最小的多播DNS解析器。这些查询通常使用编号较高的临时UDP源端口完成，但无论它们是从动态端口还是从固定端口发送，都不能使用UDP源端口5353发送这些查询，因为使用UDP源端口5353表示存在完全兼容的多播DNS查询器，如下所述。
A simple DNS resolver like this will typically just take the first response it receives. It will not listen for additional UDP responses, but in many instances this may not be a serious problem. If a user types "http://MyPrinter.local." into their web browser, and their simple DNS resolver just takes the first response it receives, and the user gets to see the status and configuration web page for their printer, then the protocol has met the user's needs in this case.
这样一个简单的DNS解析器通常只接受它收到的第一个响应。它不会侦听其他UDP响应，但在许多情况下，这可能不是一个严重的问题。如果用户键入“http://MyPrinter.local.“进入他们的web浏览器，他们的简单DNS解析器只需接收到它接收到的第一个响应，用户就可以看到他们打印机的状态和配置网页，在这种情况下，协议满足了用户的需要。
While a basic DNS resolver like this may be adequate for simple host name lookup, it may not get ideal behavior in other cases. Additional refinements to create a fully compliant Multicast DNS querier are described below.
虽然像这样的基本DNS解析器可能足以进行简单的主机名查找，但在其他情况下可能无法获得理想的行为。下面描述了创建完全兼容的多播DNS查询器的其他改进。
In one-shot queries, the underlying assumption is that the transaction begins when the application issues a query, and ends when the first response is received. There is another type of query operation that is more asynchronous, in which having received one response is not necessarily an indication that there will be no more relevant responses, and the querying operation continues until no further responses are required. Determining when no further responses are required depends on the type of operation being performed. If the operation is looking up the IPv4 and IPv6 addresses of another host, then no further responses are required once a successful connection has been made to one of those IPv4 or IPv6 addresses. If the operation is browsing to present the user with a list of DNS-SD services found on the network [RFC6763], then no further responses are required once the user indicates this to the user-interface software, e.g., by closing the network browsing window that was displaying the list of discovered services.
在一次性查询中，基本假设是事务在应用程序发出查询时开始，在收到第一个响应时结束。还有另一种类型的查询操作更为异步，在这种情况下，接收到一个响应并不一定表示将没有更多相关响应，并且查询操作将继续，直到不需要进一步的响应。确定何时不需要进一步响应取决于正在执行的操作类型。如果操作正在查找其他主机的IPv4和IPv6地址，则在成功连接到其中一个IPv4或IPv6地址后，无需进一步响应。如果操作正在浏览以向用户提供在网络[RFC6763]上找到的DNS-SD服务列表，则一旦用户向用户界面软件表明这一点（例如，关闭显示发现的服务列表的网络浏览窗口），则无需进一步响应。
Imagine some hypothetical software that allows users to discover network printers. The user wishes to discover all printers on the local network, not only the printer that is quickest to respond. When the user is actively looking for a network printer to use, they open a network browsing window that displays the list of discovered printers. It would be convenient for the user if they could rely on this list of network printers to stay up to date as network printers come and go, rather than displaying out-of-date stale information, and requiring the user explicitly to click a "refresh" button any time they want to see accurate information (which, from the moment it is displayed, is itself already beginning to become out-of-date and stale). If we are to display a continuously updated live list like this, we need to be able to do it efficiently, without naive constant polling, which would be an unreasonable burden on the network. It is not expected that all users will be browsing to discover new printers all the time, but when a user is browsing to discover service instances for an extended period, we want to be able to support that operation efficiently.
想象一下，一些假设的软件允许用户发现网络打印机。用户希望发现本地网络上的所有打印机，而不仅仅是响应最快的打印机。当用户正在积极寻找要使用的网络打印机时，他们会打开一个网络浏览窗口，其中显示发现的打印机列表。如果用户可以依靠此网络打印机列表在网络打印机出现和消失时保持最新状态，而不是显示过时的陈旧信息，并要求用户在任何时候想要查看准确信息时显式单击“刷新”按钮，这将非常方便（从显示的那一刻起，它本身就已经开始过时和过时）。如果我们要像这样显示一个不断更新的实时列表，我们需要能够高效地执行此操作，而不必进行简单的持续轮询，这将对网络造成不合理的负担。并非所有用户都会一直浏览以发现新的打印机，而是当用户浏览以发现某个打印机的服务实例时延长期限后，我们希望能够有效地支持该操作。
Therefore, when retransmitting Multicast DNS queries to implement this kind of continuous monitoring, the interval between the first two queries MUST be at least one second, the intervals between successive queries MUST increase by at least a factor of two, and the querier MUST implement Known-Answer Suppression, as described below
因此，当重新传输多播DNS查询以实现这种连续监视时，前两个查询之间的间隔必须至少为1秒，连续查询之间的间隔必须至少增加两倍，并且查询者必须实现已知答案抑制，如下所述
in Section 7.1. The Known-Answer Suppression mechanism tells responders which answers are already known to the querier, thereby allowing responders to avoid wasting network capacity with pointless repeated transmission of those answers. A querier retransmits its question because it wishes to receive answers it may have missed the first time, not because it wants additional duplicate copies of answers it already received. Failure to implement Known-Answer Suppression can result in unacceptable levels of network traffic. When the interval between queries reaches or exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 minutes, and perform subsequent queries at a steady-state rate of one query per hour. To avoid accidental synchronization when, for some reason, multiple clients begin querying at exactly the same moment (e.g., because of some common external trigger event), a Multicast DNS querier SHOULD also delay the first query of the series by a randomly chosen amount in the range 20-120 ms.
在第7.1节中。已知答案抑制机制告诉响应者查询者已经知道哪些答案，从而允许响应者避免无意义地重复传输这些答案而浪费网络容量。提问者重发问题是因为希望收到第一次错过的答案，而不是因为希望收到已收到答案的额外副本。未能实施已知答案抑制可能会导致不可接受的网络流量水平。当两次查询之间的间隔达到或超过60分钟时，查询者可以将间隔限制为最多60分钟，并以每小时一次查询的稳态速率执行后续查询。为了避免由于某些原因，当多个客户端在完全相同的时刻开始查询时（例如，由于某些常见的外部触发事件）发生意外同步，多播DNS查询器还应将该系列的第一次查询延迟20-120 ms范围内的随机选择量。
When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid. After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache. Before the record expiry time is reached, a Multicast DNS querier that has local clients with an active interest in the state of that record (e.g., a network browsing window displaying a list of discovered services to the user) SHOULD reissue its query to determine whether the record is still valid.
当多播DNS查询器接收到应答时，应答包含一个TTL值，该值指示此应答有效的秒数。超过此时间间隔后，答案将不再有效，应从缓存中删除。在达到记录到期时间之前，具有对该记录的状态有积极兴趣的本地客户端（例如，向用户显示已发现服务列表的网络浏览窗口）的多播DNS查询器应重新发出其查询，以确定该记录是否仍然有效。
To perform this cache maintenance, a Multicast DNS querier should plan to retransmit its query after at least 50% of the record lifetime has elapsed. This document recommends the following specific strategy.
要执行此缓存维护，多播DNS查询器应计划在至少50%的记录生存期结束后重新传输其查询。本文件建议采用以下具体策略。
The querier should plan to issue a query at 80% of the record lifetime, and then if no answer is received, at 85%, 90%, and 95%. If an answer is received, then the remaining TTL is reset to the value given in the answer, and this process repeats for as long as the Multicast DNS querier has an ongoing interest in the record. If no answer is received after four queries, the record is deleted when it reaches 100% of its lifetime. A Multicast DNS querier MUST NOT perform this cache maintenance for records for which it has no local clients with an active interest. If the expiry of a particular record from the cache would result in no net effect to any client software running on the querier device, and no visible effect to the human user, then there is no reason for the Multicast DNS querier to waste network capacity checking whether the record remains valid.
查询者应该计划在记录生存期的80%发出查询，如果没有收到答案，则在85%、90%和95%发出查询。如果接收到应答，则剩余的TTL被重置为应答中给定的值，并且只要多播DNS查询器对该记录有持续兴趣，该过程就会重复。如果在四次查询后没有收到任何答案，则当记录达到其生存期的100%时，将删除该记录。多播DNS查询器不得对其没有具有活动兴趣的本地客户端的记录执行此缓存维护。如果缓存中的特定记录过期不会对查询器设备上运行的任何客户端软件产生任何净影响，也不会对人类用户产生任何可见影响，则多播DNS查询器没有理由浪费网络容量来检查记录是否仍然有效。
To avoid the case where multiple Multicast DNS queriers on a network all issue their queries simultaneously, a random variation of 2% of the record TTL should be added, so that queries are scheduled to be performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.
为了避免网络上的多播DNS查询器同时发出查询的情况，应添加记录TTL的2%的随机变化，以便计划在TTL的80-82%、85-87%、90-92%和95-97%执行查询。
An additional efficiency optimization SHOULD be performed when a Multicast DNS response is received containing a unique answer (as indicated by the cache-flush bit being set, described in Section 10.2, "Announcements to Flush Outdated Cache Entries"). In this case, there is no need for the querier to continue issuing a stream of queries with exponentially increasing intervals, since the receipt of a unique answer is a good indication that no other answers will be forthcoming. In this case, the Multicast DNS querier SHOULD plan to issue its next query for this record at 80-82% of the record's TTL, as described above.
当接收到包含唯一答案的多播DNS响应时（如第10.2节“刷新过期缓存条目的通知”中所述，设置的缓存刷新位所示），应执行额外的效率优化。在这种情况下，查询者不需要继续以指数级递增的间隔发出查询流，因为收到唯一的答案很好地表明不会有其他答案。在这种情况下，多播DNS查询器应该计划以记录的TTL的80-82%对此记录进行下一次查询，如上所述。
A compliant Multicast DNS querier, which implements the rules specified in this document, MUST send its Multicast DNS queries from UDP source port 5353 (the well-known port assigned to mDNS), and MUST listen for Multicast DNS replies sent to UDP destination port 5353 at the mDNS link-local multicast address (224.0.0.251 and/or its IPv6 equivalent FF02::FB).
实现本文档中指定规则的兼容多播DNS查询器必须从UDP源端口5353（分配给mDNS的已知端口）发送其多播DNS查询，并且必须侦听发送到mDNS链路本地多播地址的UDP目标端口5353的多播DNS回复（224.0.0.251和/或其IPv6等效物FF02:：FB）。
Multicast DNS allows a querier to place multiple questions in the Question Section of a single Multicast DNS query message.
多播DNS允许查询者在单个多播DNS查询消息的问题部分放置多个问题。
The semantics of a Multicast DNS query message containing multiple questions is identical to a series of individual DNS query messages containing one question each. Combining multiple questions into a single message is purely an efficiency optimization and has no other semantic significance.
包含多个问题的多播DNS查询消息的语义与包含每个问题的一系列单独DNS查询消息的语义相同。将多个问题组合成一条消息纯粹是一种效率优化，没有其他语义意义。
Sending Multicast DNS responses via multicast has the benefit that all the other hosts on the network get to see those responses, enabling them to keep their caches up to date and detect conflicting responses.
通过多播发送多播DNS响应的好处是，网络上的所有其他主机都可以看到这些响应，使它们能够保持缓存最新并检测冲突响应。
However, there are situations where all the other hosts on the network don't need to see every response. Some examples are a laptop computer waking from sleep, the Ethernet cable being connected to a running machine, or a previously inactive interface being activated through a configuration change. At the instant of wake-up or link activation, the machine is a brand new participant on a new network. Its Multicast DNS cache for that interface is empty, and it has no
但是，在某些情况下，网络上的所有其他主机不需要看到每个响应。例如，笔记本电脑从睡眠中醒来，以太网电缆连接到正在运行的机器，或者通过配置更改激活以前不活动的接口。在唤醒或链接激活的瞬间，机器是新网络上的全新参与者。该接口的多播DNS缓存为空，并且没有
knowledge of its peers on that link. It may have a significant number of questions that it wants answered right away, to discover information about its new surroundings and present that information to the user. As a new participant on the network, it has no idea whether the exact same questions may have been asked and answered just seconds ago. In this case, triggering a large sudden flood of multicast responses may impose an unreasonable burden on the network.
对该链接的同行的了解。它可能有大量的问题需要立即回答，以发现有关其新环境的信息并将该信息呈现给用户。作为网络上的一名新参与者，它不知道是否在几秒钟前就提出并回答了完全相同的问题。在这种情况下，触发大量突发的多播响应可能会给网络带来不合理的负担。
To avoid large floods of potentially unnecessary responses in these cases, Multicast DNS defines the top bit in the class field of a DNS question as the unicast-response bit. When this bit is set in a question, it indicates that the querier is willing to accept unicast replies in response to this specific query, as well as the usual multicast responses. These questions requesting unicast responses are referred to as "QU" questions, to distinguish them from the more usual questions requesting multicast responses ("QM" questions). A Multicast DNS querier sending its initial batch of questions immediately on wake from sleep or interface activation SHOULD set the unicast-response bit in those questions.
为了避免在这些情况下出现大量可能不必要的响应，多播DNS将DNS问题的类字段中的顶部位定义为单播响应位。当在问题中设置此位时，它表示查询者愿意接受单播回复以响应此特定查询，以及通常的多播回复。这些请求单播响应的问题称为“QU”问题，以区别于请求多播响应的更常见问题（“QM”问题）。多播DNS查询器在从睡眠或接口激活唤醒时立即发送其初始批问题时，应在这些问题中设置单播响应位。
When a question is retransmitted (as described in Section 5.2), the unicast-response bit SHOULD NOT be set in subsequent retransmissions of that question. Subsequent retransmissions SHOULD be usual "QM" questions. After the first question has received its responses, the querier should have a large Known-Answer list (Section 7.1) so that subsequent queries should elicit few, if any, further responses. Reverting to multicast responses as soon as possible is important because of the benefits that multicast responses provide (see Appendix D). In addition, the unicast-response bit SHOULD be set only for questions that are active and ready to be sent the moment of wake from sleep or interface activation. New questions created by local clients afterwards should be treated as normal "QM" questions and SHOULD NOT have the unicast-response bit set on the first question of the series.
当问题被重新传输时（如第5.2节所述），单播响应位不应在该问题的后续重新传输中设置。随后的重新传输应该是常见的“QM”问题。在第一个问题收到答复后，询问者应该有一个大的已知答案列表（第7.1节），以便后续的查询应该很少（如果有的话）得到进一步的答复。尽快恢复多播响应非常重要，因为多播响应提供了好处（参见附录D）。此外，应仅为处于活动状态且准备在从睡眠中醒来或接口激活时发送的问题设置单播响应位。本地客户随后创建的新问题应被视为正常的“QM”问题，并且不应在系列的第一个问题上设置单播响应位。
When receiving a question with the unicast-response bit set, a responder SHOULD usually respond with a unicast packet directed back to the querier. However, if the responder has not multicast that record recently (within one quarter of its TTL), then the responder SHOULD instead multicast the response so as to keep all the peer caches up to date, and to permit passive conflict detection. In the case of answering a probe question (Section 8.1) with the unicast-response bit set, the responder should always generate the requested unicast response, but it may also send a multicast announcement if the time since the last multicast announcement of that record is more than a quarter of its TTL.
当接收到设置了单播响应位的问题时，响应者通常应使用定向回查询者的单播数据包进行响应。但是，如果响应者最近没有多播该记录（在其TTL的四分之一之内），则响应者应改为多播该响应，以使所有对等缓存保持最新，并允许被动冲突检测。在使用设置的单播响应位回答探测问题（第8.1节）的情况下，响应者应始终生成请求的单播响应，但如果自该记录的最后一次多播公告起的时间超过其TTL的四分之一，则响应者也可发送多播公告。
Unicast replies are subject to all the same packet generation rules as multicast replies, including the cache-flush bit (Section 10.2) and (except when defending a unique name against a probe from another host) randomized delays to reduce network collisions (Section 6).
单播回复遵循与多播回复相同的所有数据包生成规则，包括缓存刷新位（第10.2节）和（针对另一主机的探测保护唯一名称时除外）随机延迟，以减少网络冲突（第6节）。
In specialized applications there may be rare situations where it makes sense for a Multicast DNS querier to send its query via unicast to a specific machine. When a Multicast DNS responder receives a query via direct unicast, it SHOULD respond as it would for "QU" questions, as described above in Section 5.4. Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not.
在专门的应用程序中，可能很少有多播DNS查询器通过单播将其查询发送到特定机器的情况。当多播DNS响应程序通过直接单播接收到查询时，它应该像对“QU”问题一样进行响应，如上文第5.4节所述。由于可以从本地链路之外的机器接收单播查询，响应者应检查查询数据包中的源地址是否与该链路的本地子网匹配（或者，在IPv6的情况下，源地址具有链路前缀），如果不匹配，则静默忽略该数据包。
There may be specialized situations, outside the scope of this document, where it is intended and desirable to create a responder that does answer queries originating outside the local link. Such a responder would need to ensure that these non-local queries are always answered via unicast back to the querier, since an answer sent via link-local multicast would not reach a querier outside the local link.
在本文件范围之外的一些特殊情况下，可能需要创建一个响应者来回答来自本地链接之外的查询。这样的响应者需要确保这些非本地查询总是通过单播返回到查询者，因为通过链路本地多播发送的应答不会到达本地链路之外的查询者。
When a Multicast DNS responder constructs and sends a Multicast DNS response message, the Resource Record Sections of that message must contain only records for which that responder is explicitly authoritative. These answers may be generated because the record answers a question received in a Multicast DNS query message, or at certain other times that the responder determines than an unsolicited announcement is warranted. A Multicast DNS responder MUST NOT place records from its cache, which have been learned from other responders on the network, in the Resource Record Sections of outgoing response messages. Only an authoritative source for a given record is allowed to issue responses containing that record.
当多播DNS响应程序构造并发送多播DNS响应消息时，该消息的资源记录部分必须仅包含该响应程序明确授权的记录。这些答案的生成可能是因为记录回答了在多播DNS查询消息中接收到的问题，或者在响应者确定的某些其他时间，而不是未经请求的公告是有保证的。多播DNS响应程序不得将其缓存中的记录（已从网络上的其他响应程序学习）放在传出响应消息的资源记录部分。只允许给定记录的权威源发出包含该记录的响应。
The determination of whether a given record answers a given question is made using the standard DNS rules: the record name must match the question name, the record rrtype must match the question qtype unless the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record rrclass must match the question qclass unless the qclass is "ANY" (255). As with Unicast DNS, generally only DNS class 1 ("Internet") is used, but should client software use classes other than 1, the matching rules described above MUST be used.
使用标准DNS规则确定给定记录是否回答给定问题：记录名称必须与问题名称匹配，记录rrtype必须与问题qtype匹配，除非qtype为“ANY”（255）或rrtype为“CNAME”（5），记录rrclass必须与问题qclass匹配，除非qclass为“ANY”（255）. 与单播DNS一样，通常仅使用DNS类1（“Internet”），但如果客户端软件使用的类不是1，则必须使用上述匹配规则。
A Multicast DNS responder MUST only respond when it has a positive, non-null response to send, or it authoritatively knows that a particular record does not exist. For unique records, where the host has already established sole ownership of the name, it MUST return negative answers to queries for records that it knows not to exist. For example, a host with no IPv6 address, that has claimed sole ownership of the name "host.local." for all rrtypes, MUST respond to AAAA queries for "host.local." by sending a negative answer indicating that no AAAA records exist for that name. See Section 6.1, "Negative Responses". For shared records, which are owned by no single host, the nonexistence of a given record is ascertained by the failure of any machine to respond to the Multicast DNS query, not by any explicit negative response. For shared records, NXDOMAIN and other error responses MUST NOT be sent.
多播DNS响应程序必须仅在其要发送的响应为正、非空或权威性地知道某个特定记录不存在时进行响应。对于唯一记录，如果主机已建立名称的唯一所有权，则必须对其知道不存在的记录的查询返回否定答案。例如，对于所有RRTYPE，没有IPv6地址且已声明名称“host.local.”的唯一所有权的主机，必须通过发送表示该名称不存在AAAA记录的否定回答来响应“host.local.”的AAAA查询。见第6.1节“负面反应”。对于不由单个主机拥有的共享记录，给定记录的不存在是通过任何计算机无法响应多播DNS查询而不是通过任何明确的否定响应来确定的。对于共享记录，不得发送NXDOMAIN和其他错误响应。
Multicast DNS responses MUST NOT contain any questions in the Question Section. Any questions in the Question Section of a received Multicast DNS response MUST be silently ignored. Multicast DNS queriers receiving Multicast DNS responses do not care what question elicited the response; they care only that the information in the response is true and accurate.
多播DNS响应不得在问题部分包含任何问题。接收到的多播DNS响应的问题部分中的任何问题都必须以静默方式忽略。接收多播DNS响应的多播DNS查询者不关心引发响应的问题；他们只关心回复中的信息是真实和准确的。
A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared multiple access networks SHOULD have the capability of delaying its responses by up to 500 ms, as described below.
以太网[IEEE.802.3]和类似共享多址网络上的多播DNS响应程序应具有将其响应延迟500 ms的能力，如下所述。
If a large number of Multicast DNS responders were all to respond immediately to a particular query, a collision would be virtually guaranteed. By imposing a small random delay, the number of collisions is dramatically reduced. On a full-sized Ethernet using the maximum cable lengths allowed and the maximum number of repeaters allowed, an Ethernet frame is vulnerable to collisions during the transmission of its first 256 bits. On 10 Mb/s Ethernet, this equates to a vulnerable time window of 25.6 microseconds. On higher-speed variants of Ethernet, the vulnerable time window is shorter.
如果大量的多播DNS响应程序都要立即响应特定的查询，那么冲突实际上是有保证的。通过施加一个小的随机延迟，碰撞的数量大大减少。在使用允许的最大电缆长度和允许的最大中继器数量的全尺寸以太网上，以太网帧在其前256位传输期间容易发生冲突。在10 Mb/s以太网上，这相当于25.6微秒的脆弱时间窗口。在高速以太网变体上，易受攻击的时间窗口较短。
In the case where a Multicast DNS responder has good reason to believe that it will be the only responder on the link that will send a response (i.e., because it is able to answer every question in the query message, and for all of those answer records it has previously verified that the name, rrtype, and rrclass are unique on the link), it SHOULD NOT impose any random delay before responding, and SHOULD normally generate its response within at most 10 ms. In particular, this applies to responding to probe queries with the unicast-response bit set. Since receiving a probe query gives a clear indication that some other responder is planning to start using this name in the very near future, answering such probe queries to defend a unique record is a high priority and needs to be done without delay. A probe query
如果多播DNS响应程序有充分的理由相信它将是链路上唯一发送响应的响应程序（即，因为它能够回答查询消息中的每个问题，并且对于所有这些应答记录，它之前已验证名称、rrtype和rrclass在链路上是唯一的），在响应之前，它不应施加任何随机延迟，并且通常应在最多10 ms内生成响应。特别是，这适用于使用单播响应比特集响应探测查询。由于收到探测查询清楚地表明其他响应者计划在不久的将来开始使用此名称，因此回答此类探测查询以保护唯一记录是一项高度优先事项，需要毫不延迟地完成。探测查询
can be distinguished from a normal query by the fact that a probe query contains a proposed record in the Authority Section that answers the question in the Question Section (for more details, see Section 8.2, "Simultaneous Probe Tiebreaking").
与普通查询不同的是，探测查询在权限部分中包含一条建议记录，该记录回答了问题部分中的问题（有关更多详细信息，请参阅第8.2节“同步探测断开”）。
Responding without delay is appropriate for records like the address record for a particular host name, when the host name has been previously verified unique. Responding without delay is *not* appropriate for things like looking up PTR records used for DNS-Based Service Discovery [RFC6763], where a large number of responses may be anticipated.
当主机名之前已被验证为唯一时，无延迟响应适用于特定主机名的地址记录等记录。无延迟响应对于查找用于基于DNS的服务发现[RFC6763]的PTR记录这样的事情是不合适的，因为在这种情况下，可能会出现大量响应。
In any case where there may be multiple responses, such as queries where the answer is a member of a shared resource record set, each responder SHOULD delay its response by a random amount of time selected with uniform random distribution in the range 20-120 ms. The reason for requiring that the delay be at least 20 ms is to accommodate the situation where two or more query packets are sent back-to-back, because in that case we want a responder with answers to more than one of those queries to have the opportunity to aggregate all of its answers into a single response message.
在可能有多个响应的任何情况下，例如答案是共享资源记录集成员的查询，每个响应者应将其响应延迟20-120 ms范围内均匀随机分布选择的随机时间量。要求延迟至少为20 ms的原因是为了适应两个或多个查询数据包背靠背发送的情况，因为在这种情况下，我们希望一个对不止一个查询有答案的响应者有机会将其所有答案聚合到一个响应消息中。
In the case where the query has the TC (truncated) bit set, indicating that subsequent Known-Answer packets will follow, responders SHOULD delay their responses by a random amount of time selected with uniform random distribution in the range 400-500 ms, to allow enough time for all the Known-Answer packets to arrive, as described in Section 7.2, "Multipacket Known-Answer Suppression".
在查询设置了TC（截断）位的情况下，表示随后将出现已知应答包，响应者应将其响应延迟400-500 ms范围内均匀随机分布选择的随机时间量，以允许所有已知应答包有足够的时间到达，如第7.2节所述，“多包已知答案抑制”。
The source UDP port in all Multicast DNS responses MUST be 5353 (the well-known port assigned to mDNS). Multicast DNS implementations MUST silently ignore any Multicast DNS responses they receive where the source UDP port is not 5353.
所有多播DNS响应中的源UDP端口必须是5353（分配给MDN的已知端口）。在源UDP端口不是5353的情况下，多播DNS实现必须以静默方式忽略它们接收到的任何多播DNS响应。
The destination UDP port in all Multicast DNS responses MUST be 5353, and the destination address MUST be the mDNS IPv4 link-local multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except when generating a reply to a query that explicitly requested a unicast response:
所有多播DNS响应中的目标UDP端口必须为5353，目标地址必须为mDNS IPv4链路本地多播地址224.0.0.251或其IPv6等效FF02:：FB，除非生成对明确请求单播响应的查询的答复：
* via the unicast-response bit, * by virtue of being a legacy query (Section 6.7), or * by virtue of being a direct unicast query.
* 通过单播响应位，*由于是传统查询（第6.7节），或*由于是直接单播查询。
Except for these three specific cases, responses MUST NOT be sent via unicast, because then the "Passive Observation of Failures" mechanisms described in Section 10.5 would not work correctly. Other
除这三种特定情况外，不得通过单播发送响应，因为第10.5节中描述的“故障被动观察”机制将无法正常工作。另外
benefits of sending responses via multicast are discussed in Appendix D. A Multicast DNS querier MUST only accept unicast responses if they answer a recently sent query (e.g., sent within the last two seconds) that explicitly requested unicast responses. A Multicast DNS querier MUST silently ignore all other unicast responses.
附录D中讨论了通过多播发送响应的好处。如果多播DNS查询者回答最近发送的明确请求单播响应的查询（例如，在最后两秒钟内发送），则他们必须只接受单播响应。多播DNS查询器必须以静默方式忽略所有其他单播响应。
To protect the network against excessive packet flooding due to software bugs or malicious attack, a Multicast DNS responder MUST NOT (except in the one special case of answering probe queries) multicast a record on a given interface until at least one second has elapsed since the last time that record was multicast on that particular interface. A legitimate querier on the network should have seen the previous transmission and cached it. A querier that did not receive and cache the previous transmission will retry its request and receive a subsequent response. In the special case of answering probe queries, because of the limited time before the probing host will make its decision about whether or not to use the name, a Multicast DNS responder MUST respond quickly. In this special case only, when responding via multicast to a probe, a Multicast DNS responder is only required to delay its transmission as necessary to ensure an interval of at least 250 ms since the last time the record was multicast on that interface.
为了保护网络免受由于软件错误或恶意攻击而导致的过度数据包泛滥，多播DNS响应程序不得（在回答探测查询的一种特殊情况下除外）在给定接口上多播记录，直到自该记录上次在该特定接口上多播起至少一秒钟。网络上的合法查询者应该已经看到了上一次传输并缓存了它。未接收并缓存上一次传输的查询器将重试其请求并接收后续响应。在回答探测查询的特殊情况下，由于探测主机决定是否使用该名称之前的时间有限，多播DNS响应程序必须快速响应。仅在这种特殊情况下，当通过多播对探测进行响应时，多播DNS响应者仅需要根据需要延迟其传输，以确保自上次在该接口上对记录进行多播以来至少有250 ms的间隔。
In the early design of Multicast DNS it was assumed that explicit negative responses would never be needed. A host can assert the existence of the set of records that it claims to exist, and the union of all such sets on a link is the set of Multicast DNS records that exist on that link. Asserting the nonexistence of every record in the complement of that set -- i.e., all possible Multicast DNS records that could exist on this link but do not at this moment -- was felt to be impractical and unnecessary. The nonexistence of a record would be ascertained by a querier querying for it and failing to receive a response from any of the hosts currently attached to the link.
在多播DNS的早期设计中，假设永远不需要显式的否定响应。主机可以断言其声称存在的记录集的存在，并且链路上所有这些记录集的并集就是该链路上存在的多播DNS记录集。断言该集合的补集中的每个记录都不存在——即，所有可能存在于该链路上但目前不存在的多播DNS记录——被认为是不切实际和不必要的。查询者查询记录并未能从当前连接到链接的任何主机接收到响应，就可以确定记录是否不存在。
However, operational experience showed that explicit negative responses can sometimes be valuable. One such example is when a querier is querying for a AAAA record, and the host name in question has no associated IPv6 addresses. In this case, the responding host knows it currently has exclusive ownership of that name, and it knows that it currently does not have any IPv6 addresses, so an explicit negative response is preferable to the querier having to retransmit its query multiple times, and eventually give up with a timeout, before it can conclude that a given AAAA record does not exist.
然而，运营经验表明，明确的负面反应有时是有价值的。一个这样的示例是当查询者查询AAAA记录时，所涉及的主机名没有关联的IPv6地址。在这种情况下，响应主机知道它当前拥有该名称的独占所有权，并且它知道它当前没有任何IPv6地址，因此显式的否定响应比查询者必须多次重新传输其查询并最终以超时放弃更好，在此之前，它可以得出结论，一个给定的AAAA记录不存在。
Any time a responder receives a query for a name for which it has verified exclusive ownership, for a type for which that name has no records, the responder MUST (except as allowed in (a) below) respond asserting the nonexistence of that record using a DNS NSEC record [RFC4034]. In the case of Multicast DNS the NSEC record is not being used for its usual DNSSEC [RFC4033] security properties, but simply as a way of expressing which records do or do not exist with a given name.
任何时候，响应程序收到一个查询，查询的名称已被验证为独占所有权，且该名称没有记录的类型，响应程序必须（除非下文（a）中允许）使用DNS NSEC记录[RFC4034]响应断言该记录不存在。在多播DNS的情况下，NSEC记录不用于其通常的DNSSEC[RFC4033]安全属性，而只是作为一种表示给定名称下哪些记录存在或不存在的方式。
On receipt of a question for a particular name, rrtype, and rrclass, for which a responder does have one or more unique answers, the responder MAY also include an NSEC record in the Additional Record Section indicating the nonexistence of other rrtypes for that name and rrclass.
在收到特定名称、rrtype和rrclass的问题时，响应者确实有一个或多个唯一答案，响应者还可以在附加记录部分包括NSEC记录，指示该名称和rrclass不存在其他rrtype。
Implementers working with devices with sufficient memory and CPU resources MAY choose to implement code to handle the full generality of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits long. To facilitate use by devices with limited memory and CPU resources, Multicast DNS queriers are only REQUIRED to be able to parse a restricted form of the DNS NSEC record. All compliant Multicast DNS implementations MUST at least correctly generate and parse the restricted DNS NSEC record format described below:
使用具有足够内存和CPU资源的设备的实现者可以选择实现代码，以处理DNS NSEC记录[RFC4034]的全部通用性，包括高达65536位的位图。为了便于内存和CPU资源有限的设备使用，多播DNS查询器只需要能够解析受限形式的DNS NSEC记录。所有符合要求的多播DNS实施必须至少正确生成和解析以下所述的受限DNS NSEC记录格式：
o The 'Next Domain Name' field contains the record's own name. When used with name compression, this means that the 'Next Domain Name' field always takes exactly two bytes in the message.
o “下一个域名”字段包含记录自己的名称。当与名称压缩一起使用时，这意味着“下一个域名”字段在消息中始终正好占用两个字节。
o The Type Bit Map block number is 0.
o 类型位图块编号为0。
o The Type Bit Map block length byte is a value in the range 1-32.
o 类型位图块长度字节是1-32范围内的值。
o The Type Bit Map data is 1-32 bytes, as indicated by length byte.
o 类型位图数据为1-32字节，如长度字节所示。
Because this restricted form of the DNS NSEC record is limited to Type Bit Map block number zero, it cannot express the existence of rrtypes above 255. Consequently, if a Multicast DNS responder were to have records with rrtypes above 255, it MUST NOT generate these restricted-form NSEC records for those names, since to do so would imply that the name has no records with rrtypes above 255, which would be false. In such cases a Multicast DNS responder MUST either (a) emit no NSEC record for that name, or (b) emit a full NSEC record containing the appropriate Type Bit Map block(s) with the correct bits set for all the record types that exist. In practice this is not a significant limitation, since rrtypes above 255 are not currently in widespread use.
由于DNS NSEC记录的这种受限形式仅限于类型位图块编号0，因此它无法表示255以上的RRTYPE的存在。因此，如果多播DNS响应程序具有rrtypes高于255的记录，则它不得为这些名称生成这些受限形式的NSEC记录，因为这样做将意味着该名称没有rrtypes高于255的记录，这将是错误的。在这种情况下，多播DNS响应程序必须（a）不发出该名称的NSEC记录，或（b）发出包含适当类型位图块的完整NSEC记录，并为所有存在的记录类型设置正确的位。实际上，这并不是一个显著的限制，因为255以上的RRTYPE目前还没有被广泛使用。
If a Multicast DNS implementation receives an NSEC record where the 'Next Domain Name' field is not the record's own name, then the implementation SHOULD ignore the 'Next Domain Name' field and process the remainder of the NSEC record as usual. In Multicast DNS the 'Next Domain Name' field is not currently used, but it could be used in a future version of this protocol, which is why a Multicast DNS implementation MUST NOT reject or ignore an NSEC record it receives just because it finds an unexpected value in the 'Next Domain Name' field.
如果多播DNS实现接收到一个NSEC记录，其中“下一个域名”字段不是该记录自己的名称，则该实现应忽略“下一个域名”字段，并像往常一样处理剩余的NSEC记录。在多播DNS中，当前未使用“下一个域名”字段，但该字段可用于此协议的未来版本，这就是为什么多播DNS实现不能仅仅因为在“下一个域名”字段中发现意外值而拒绝或忽略其接收的NSEC记录的原因。
If a Multicast DNS implementation receives an NSEC record containing more than one Type Bit Map, or where the Type Bit Map block number is not zero, or where the block length is not in the range 1-32, then the Multicast DNS implementation MAY silently ignore the entire NSEC record. A Multicast DNS implementation MUST NOT ignore an entire message just because that message contains one or more NSEC record(s) that the Multicast DNS implementation cannot parse. This provision is to allow future enhancements to the protocol to be introduced in a backwards-compatible way that does not break compatibility with older Multicast DNS implementations.
如果多播DNS实现接收到包含多个类型位图的NSEC记录，或者类型位图块号不为零，或者块长度不在1-32范围内，则多播DNS实现可以静默地忽略整个NSEC记录。多播DNS实现不能因为整个消息包含多播DNS实现无法解析的一个或多个NSEC记录而忽略该消息。这项规定允许将来以向后兼容的方式引入协议的增强功能，而不会破坏与旧的多播DNS实现的兼容性。
To help differentiate these synthesized NSEC records (generated programmatically on-the-fly) from conventional Unicast DNS NSEC records (which actually exist in a signed DNS zone), the synthesized Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do have the NSEC bit set.
为了帮助区分这些合成的NSEC记录（动态编程生成）与传统的单播DNS NSEC记录（实际存在于签名DNS区域中），合成的多播DNS NSEC记录不得在类型位映射中设置NSEC位，而传统的单播DNS NSEC记录确实设置了NSEC位。
The TTL of the NSEC record indicates the intended lifetime of the negative cache entry. In general, the TTL given for an NSEC record SHOULD be the same as the TTL that the record would have had, had it existed. For example, the TTL for address records in Multicast DNS is typically 120 seconds (see Section 10), so the negative cache lifetime for an address record that does not exist should also be 120 seconds.
NSEC记录的TTL表示负缓存项的预期生存期。一般来说，为NSEC记录提供的TTL应该与该记录存在时的TTL相同。例如，多播DNS中地址记录的TTL通常为120秒（参见第10节），因此不存在的地址记录的负缓存生存期也应为120秒。
A responder MUST only generate negative responses to queries for which it has legitimate ownership of the name, rrtype, and rrclass in question, and can legitimately assert that no record with that name, rrtype, and rrclass exists. A responder can assert that a specified rrtype does not exist for one of its names if it knows a priori that it has exclusive ownership of that name (e.g., names of reverse address mapping PTR records, which are derived from IP addresses, which should be unique on the local link) or if it previously claimed unique ownership of that name using probe queries for rrtype "ANY". (If it were to use probe queries for a specific rrtype, then it would only own the name for that rrtype, and could not assert that other rrtypes do not exist.)
响应者只能对其拥有相关名称、rrtype和rrclass合法所有权的查询生成否定响应，并且可以合法地断言不存在具有该名称、rrtype和rrclass的记录。如果响应者事先知道某个指定的rrtype对该名称具有独占所有权（例如，反向地址映射PTR记录的名称，该记录是从IP地址派生的，在本地链路上应该是唯一的），则响应者可以断言其某个名称不存在指定的rrtype或者，如果它以前使用rrtype“ANY”的探测查询声明该名称的唯一所有权。（如果它对特定的rrtype使用探测查询，那么它将只拥有该rrtype的名称，并且不能断言其他rrtype不存在。）
The design rationale for this mechanism for encoding negative responses is discussed further in Appendix E.
附录E进一步讨论了这种编码负面响应机制的设计原理。
When a Multicast DNS responder sends a Multicast DNS response message containing its own address records, it MUST include all addresses that are valid on the interface on which it is sending the message, and MUST NOT include addresses that are not valid on that interface (such as addresses that may be configured on the host's other interfaces). For example, if an interface has both an IPv6 link-local and an IPv6 routable address, both should be included in the response message so that queriers receive both and can make their own choice about which to use. This allows a querier that only has an IPv6 link-local address to connect to the link-local address, and a different querier that has an IPv6 routable address to connect to the IPv6 routable address instead.
当多播DNS响应程序发送包含其自身地址记录的多播DNS响应消息时，它必须包括在其发送消息的接口上有效的所有地址，并且不得包括在该接口上无效的地址（例如，可以在主机的其他接口上配置的地址）。例如，如果接口同时具有IPv6本地链路和IPv6可路由地址，则响应消息中应包含这两个地址，以便查询者接收这两个地址，并可以自行选择使用哪一个。这允许仅具有IPv6链路本地地址的查询器连接到链路本地地址，并允许具有IPv6路由地址的其他查询器连接到IPv6路由地址。
When a Multicast DNS responder places an IPv4 or IPv6 address record (rrtype "A" or "AAAA") into a response message, it SHOULD also place any records of the other address type with the same name into the additional section, if there is space in the message. This is to provide fate sharing, so that all a device's addresses are delivered atomically in a single message, to reduce the risk that packet loss could cause a querier to receive only the IPv4 addresses and not the IPv6 addresses, or vice versa.
当多播DNS响应程序将IPv4或IPv6地址记录（rrtype“a”或“AAAA”）放入响应消息时，如果消息中有空格，它还应将具有相同名称的其他地址类型的任何记录放入附加部分。这是为了提供命运共享，以便在单个消息中以原子方式传递设备的所有地址，以降低数据包丢失可能导致查询者只接收IPv4地址而不接收IPv6地址的风险，反之亦然。
In the event that a device has only IPv4 addresses but no IPv6 addresses, or vice versa, then the appropriate NSEC record SHOULD be placed into the additional section, so that queriers can know with certainty that the device has no addresses of that kind.
如果设备只有IPv4地址但没有IPv6地址，或者反之亦然，则应将适当的NSEC记录放入附加部分，以便查询者可以确定该设备没有此类地址。
Some Multicast DNS responders treat a physical interface with both IPv4 and IPv6 address as a single interface with two addresses. Other Multicast DNS responders may treat this case as logically two interfaces (one with one or more IPv4 addresses, and the other with one or more IPv6 addresses), but responders that operate this way MUST NOT put the corresponding automatic NSEC records in replies they send (i.e., a negative IPv4 assertion in their IPv6 responses, and a negative IPv6 assertion in their IPv4 responses) because this would cause incorrect operation in responders on the network that work the former way.
一些多播DNS响应程序将同时具有IPv4和IPv6地址的物理接口视为具有两个地址的单个接口。其他多播DNS响应程序可能将这种情况视为逻辑上的两个接口（一个具有一个或多个IPv4地址，另一个具有一个或多个IPv6地址），但以这种方式运行的响应程序不得将相应的自动NSEC记录放入其发送的响应中（即，他们的IPv6响应中的负IPv4断言，以及他们的IPv4响应中的负IPv6断言），因为这将导致网络上以前一种方式工作的响应程序的错误操作。
Multicast DNS responders MUST correctly handle DNS query messages containing more than one question, by answering any or all of the questions to which they have answers. Unlike single-question
多播DNS响应者必须正确处理包含多个问题的DNS查询消息，方法是回答他们所回答的任何或所有问题。不同于单一问题
queries, where responding without delay is allowed in appropriate cases, for query messages containing more than one question, all (non-defensive) answers SHOULD be randomly delayed in the range 20-120 ms, or 400-500 ms if the TC (truncated) bit is set. This is because when a query message contains more than one question, a Multicast DNS responder cannot generally be certain that other responders will not also be simultaneously generating answers to other questions in that query message. (Answers defending a name, in response to a probe for that name, are not subject to this delay rule and are still sent immediately.)
在适当情况下允许不延迟响应的查询，对于包含多个问题的查询消息，所有（非防御性）答案应在20-120毫秒范围内随机延迟，如果设置了TC（截断）位，则应在400-500毫秒范围内随机延迟。这是因为当查询消息包含多个问题时，多播DNS响应程序通常无法确定其他响应程序也不会同时生成该查询消息中其他问题的答案。（针对某个名称的调查，为该名称辩护的回答不受此延迟规则的约束，仍然会立即发送。）
When possible, a responder SHOULD, for the sake of network efficiency, aggregate as many responses as possible into a single Multicast DNS response message. For example, when a responder has several responses it plans to send, each delayed by a different interval, then earlier responses SHOULD be delayed by up to an additional 500 ms if that will permit them to be aggregated with other responses scheduled to go out a little later.
在可能的情况下，为了提高网络效率，响应者应将尽可能多的响应聚合到单个多播DNS响应消息中。例如，当响应者计划发送多个响应，每个响应延迟不同的时间间隔时，如果允许将较早的响应与计划稍后发出的其他响应聚合，则应将较早的响应延迟最多500 ms。
When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its records that match the query. This is subtly different from how qtype "ANY" and qclass "ANY" work in Unicast DNS.
当使用qtype“ANY”（255）和/或qclass“ANY”（255）响应查询时，多播DNS响应程序必须使用与查询匹配的*所有*记录进行响应。这与单播DNS中qtype“ANY”和qclass“ANY”的工作方式略有不同。
A common misconception is that a Unicast DNS query for qtype "ANY" will elicit a response containing all matching records. This is incorrect. If there are any records that match the query, the response is required only to contain at least one of them, not necessarily all of them.
一个常见的误解是，对qtype“ANY”的单播DNS查询将引发包含所有匹配记录的响应。这是不正确的。如果存在与查询匹配的任何记录，则响应只需要包含其中至少一个记录，而不一定包含所有记录。
This somewhat surprising behavior is commonly seen with caching (i.e., "recursive") name servers. If a caching server receives a qtype "ANY" query for which it has at least one valid answer, it is allowed to return only those matching answers it happens to have already in its cache, and it is not required to reconsult the authoritative name server to check if there are any more records that also match the qtype "ANY" query.
这种有点令人惊讶的行为常见于缓存（即“递归”）名称服务器。如果缓存服务器接收到至少有一个有效答案的qtype“ANY”查询，则允许它仅返回其缓存中碰巧已存在的匹配答案，并且不需要重新查询权威名称服务器以检查是否还有与qtype“ANY”查询匹配的记录。
For example, one might imagine that a query for qtype "ANY" for name "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA) address records for that host. In reality, what happens is that it depends on the history of what queries have been previously received by intervening caching servers. If a caching server has no records for "host.example.com", then it will consult another server (usually
例如，您可能会想象，查询名称“host.example.com”的qtype“ANY”将返回该主机的IPv4（a）和IPv6（AAAA）地址记录。实际上，所发生的情况取决于中间缓存服务器以前接收到的查询的历史记录。如果缓存服务器没有“host.example.com”的记录，那么它将咨询另一个服务器（通常是
the authoritative name server for the name in question), and, in that case, it will typically return all IPv4 and IPv6 address records. However, if some other host has recently done a query for qtype "A" for name "host.example.com", so that the caching server already has IPv4 address records for "host.example.com" in its cache but no IPv6 address records, then it will return only the IPv4 address records it already has cached, and no IPv6 address records.
权威名称服务器（用于相关名称），在这种情况下，它通常会返回所有IPv4和IPv6地址记录。但是，如果其他主机最近查询了名称“host.example.com”的qtype“a”，因此缓存服务器在其缓存中已具有“host.example.com”的IPv4地址记录，但没有IPv6地址记录，则它将只返回已缓存的IPv4地址记录，而不返回IPv6地址记录。
Multicast DNS does not share this property that qtype "ANY" and qclass "ANY" queries return some undefined subset of the matching records. When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its records that match the query.
多播DNS不共享此属性，即qtype“ANY”和qclass“ANY”查询返回一些未定义的匹配记录子集。当使用qtype“ANY”（255）和/或qclass“ANY”（255）响应查询时，多播DNS响应程序必须使用与查询匹配的*所有*记录进行响应。
If a Multicast DNS responder ("A") observes some other Multicast DNS responder ("B") send a Multicast DNS response message containing a resource record with the same name, rrtype, and rrclass as one of A's resource records, but *different* rdata, then:
如果多播DNS响应程序（“a”）观察到其他多播DNS响应程序（“B”）发送多播DNS响应消息，其中包含与a的一个资源记录具有相同名称、rrtype和rrclass，但*不同*rdata的资源记录，则：
o If A's resource record is intended to be a shared resource record, then this is no conflict, and no action is required.
o 如果一个用户的资源记录是一个共享资源记录，那么这就没有冲突，也不需要执行任何操作。
o If A's resource record is intended to be a member of a unique resource record set owned solely by that responder, then this is a conflict and MUST be handled as described in Section 9, "Conflict Resolution".
o 如果某个响应者的资源记录是该响应者单独拥有的唯一资源记录集的成员，则这是一个冲突，必须按照第9节“冲突解决”中的说明进行处理。
If a Multicast DNS responder ("A") observes some other Multicast DNS responder ("B") send a Multicast DNS response message containing a resource record with the same name, rrtype, and rrclass as one of A's resource records, and *identical* rdata, then:
如果多播DNS响应程序（“a”）观察到其他多播DNS响应程序（“B”）发送多播DNS响应消息，其中包含与a的一个资源记录具有相同名称、rrtype和rrclass以及*相同*rdata的资源记录，则：
o If the TTL of B's resource record given in the message is at least half the true TTL from A's point of view, then no action is required.
o 如果消息中给出的B的资源记录的TTL从A的角度来看至少是真实TTL的一半，则无需执行任何操作。
o If the TTL of B's resource record given in the message is less than half the true TTL from A's point of view, then A MUST mark its record to be announced via multicast. Queriers receiving the record from B would use the TTL given by B and, hence, may delete the record sooner than A expects. By sending its own multicast response correcting the TTL, A ensures that the record will be retained for the desired time.
o 如果消息中给出的B的资源记录的TTL从A的角度来看小于真实TTL的一半，则A必须将其记录标记为通过多播宣布。从B接收记录的查询者将使用B给出的TTL，因此，可能会比A预期的更早删除记录。通过发送自己的多播响应来纠正TTL，A确保记录将保留所需的时间。
These rules allow multiple Multicast DNS responders to offer the same data on the network (perhaps for fault-tolerance reasons) without conflicting with each other.
这些规则允许多个多播DNS响应程序在网络上提供相同的数据（可能是出于容错原因），而不会相互冲突。
If the source UDP port in a received Multicast DNS query is not port 5353, this indicates that the querier originating the query is a simple resolver such as described in Section 5.1, "One-Shot Multicast DNS Queries", which does not fully implement all of Multicast DNS. In this case, the Multicast DNS responder MUST send a UDP response directly back to the querier, via unicast, to the query packet's source IP address and port. This unicast response MUST be a conventional unicast response as would be generated by a conventional Unicast DNS server; for example, it MUST repeat the query ID and the question given in the query message. In addition, the cache-flush bit described in Section 10.2, "Announcements to Flush Outdated Cache Entries", MUST NOT be set in legacy unicast responses.
如果接收到的多播DNS查询中的源UDP端口不是端口5353，这表明发起查询的查询者是一个简单的解析器，如第5.1节“一次性多播DNS查询”中所述，它没有完全实现所有多播DNS。在这种情况下，多播DNS响应程序必须通过单播将UDP响应直接发送回查询器，发送到查询数据包的源IP地址和端口。该单播响应必须是常规单播响应，如将由常规单播DNS服务器生成的；例如，它必须重复查询ID和查询消息中给出的问题。此外，不得在传统单播响应中设置第10.2节“刷新过期缓存项的公告”中所述的缓存刷新位。
The resource record TTL given in a legacy unicast response SHOULD NOT be greater than ten seconds, even if the true TTL of the Multicast DNS resource record is higher. This is because Multicast DNS responders that fully participate in the protocol use the cache coherency mechanisms described in Section 10, "Resource Record TTL Values and Cache Coherency", to update and invalidate stale data. Were unicast responses sent to legacy resolvers to use the same high TTLs, these legacy resolvers, which do not implement these cache coherency mechanisms, could retain stale cached resource record data long after it is no longer valid.
传统单播响应中给出的资源记录TTL不应大于10秒，即使多播DNS资源记录的真实TTL更高。这是因为完全参与协议的多播DNS响应程序使用第10节“资源记录TTL值和缓存一致性”中描述的缓存一致性机制来更新和使陈旧数据无效。如果将单播响应发送到旧版解析程序以使用相同的高TTL，这些旧版解析程序（不实现这些缓存一致性机制）可能会在过时的缓存资源记录数据不再有效后保留很长时间。
A variety of techniques are used to reduce the amount of traffic on the network.
使用多种技术来减少网络上的通信量。
When a Multicast DNS querier sends a query to which it already knows some answers, it populates the Answer Section of the DNS query message with those answers.
当多播DNS查询器发送其已经知道某些答案的查询时，它会用这些答案填充DNS查询消息的答案部分。
Generally, this applies only to Shared records, not Unique records, since if a Multicast DNS querier already has at least one Unique record in its cache then it should not be expecting further different answers to this question, since the Unique record(s) it already has comprise the complete answer, so it has no reason to be sending the query at all. In contrast, having some Shared records in its cache does not necessarily imply that a Multicast DNS querier will not
通常，这仅适用于共享记录，而非唯一记录，因为如果多播DNS查询器在其缓存中已经至少有一条唯一记录，则不应期望对该问题有更多不同的答案，因为它已经拥有的唯一记录包含完整答案，因此，它根本没有理由发送查询。相比之下，在其缓存中有一些共享记录并不一定意味着多播DNS查询器不会这样做
receive further answers to this query, and it is in this case that it is beneficial to use the Known-Answer list to suppress repeated sending of redundant answers that the querier already knows.
接收此查询的进一步答案，在这种情况下，使用已知答案列表抑制重复发送查询者已经知道的冗余答案是有益的。
A Multicast DNS responder MUST NOT answer a Multicast DNS query if the answer it would give is already included in the Answer Section with an RR TTL at least half the correct value. If the RR TTL of the answer as given in the Answer Section is less than half of the true RR TTL as known by the Multicast DNS responder, the responder MUST send an answer so as to update the querier's cache before the record becomes in danger of expiration.
如果多播DNS响应程序将给出的答案已包含在应答部分，且RR TTL值至少为正确值的一半，则多播DNS响应程序不得应答多播DNS查询。如果应答部分给出的应答的RR TTL小于多播DNS应答器已知的真实RR TTL的一半，则应答器必须发送应答，以便在记录有过期危险之前更新查询器的缓存。
Because a Multicast DNS responder will respond if the remaining TTL given in the Known-Answer list is less than half the true TTL, it is superfluous for the querier to include such records in the Known-Answer list. Therefore, a Multicast DNS querier SHOULD NOT include records in the Known-Answer list whose remaining TTL is less than half of their original TTL. Doing so would simply consume space in the message without achieving the goal of suppressing responses and would, therefore, be a pointless waste of network capacity.
由于如果已知答案列表中给出的剩余TTL小于真实TTL的一半，则多播DNS响应程序将进行响应，因此查询者将此类记录包括在已知答案列表中是多余的。因此，多播DNS查询器不应包括已知答案列表中剩余TTL小于其原始TTL一半的记录。这样做只会消耗消息中的空间，而不会达到抑制响应的目的，因此，这是对网络容量的无意义浪费。
A Multicast DNS querier MUST NOT cache resource records observed in the Known-Answer Section of other Multicast DNS queries. The Answer Section of Multicast DNS queries is not authoritative. By placing information in the Answer Section of a Multicast DNS query, the querier is stating that it *believes* the information to be true. It is not asserting that the information *is* true. Some of those records may have come from other hosts that are no longer on the network. Propagating that stale information to other Multicast DNS queriers on the network would not be helpful.
多播DNS查询器不得缓存在其他多播DNS查询的“已知答案”部分中观察到的资源记录。多播DNS查询的答案部分不具有权威性。通过将信息放置在多播DNS查询的应答部分，查询者表示它*相信*该信息是真实的。这并不是说信息是真实的。其中一些记录可能来自不再在网络上的其他主机。将陈旧信息传播到网络上的其他多播DNS查询器将没有帮助。
Sometimes a Multicast DNS querier will already have too many answers to fit in the Known-Answer Section of its query packets. In this case, it should issue a Multicast DNS query containing a question and as many Known-Answer records as will fit. It MUST then set the TC (Truncated) bit in the header before sending the query. It MUST immediately follow the packet with another query packet containing no questions and as many more Known-Answer records as will fit. If there are still too many records remaining to fit in the packet, it again sets the TC bit and continues until all the Known-Answer records have been sent.
有时，多播DNS查询器已经有太多的答案，无法放入其查询数据包的已知答案部分。在这种情况下，它应该发出一个多播DNS查询，其中包含一个问题和尽可能多的已知答案记录。然后，它必须在发送查询之前在报头中设置TC（截断）位。它必须立即在数据包后面添加另一个查询数据包，该数据包不包含任何问题，并包含尽可能多的已知答案记录。如果仍然有太多的记录无法放入数据包，它将再次设置TC位并继续，直到发送所有已知应答记录。
A Multicast DNS responder seeing a Multicast DNS query with the TC bit set defers its response for a time period randomly selected in the interval 400-500 ms. This gives the Multicast DNS querier time to send additional Known-Answer packets before the responder
多播DNS响应程序看到具有TC位集的多播DNS查询时，会将其响应延迟400-500毫秒的随机时间段。这使多播DNS查询程序有时间在响应程序之前发送额外的已知应答数据包
responds. If the responder sees any of its answers listed in the Known-Answer lists of subsequent packets from the querying host, it MUST delete that answer from the list of answers it is planning to give (provided that no other host on the network has also issued a query for that record and is waiting to receive an answer).
他回答道。如果响应者看到来自查询主机的后续数据包的已知答案列表中列出了其任何答案，则必须从其计划给出的答案列表中删除该答案（前提是网络上没有其他主机也对该记录发出了查询，并且正在等待接收答案）。
If the responder receives additional Known-Answer packets with the TC bit set, it SHOULD extend the delay as necessary to ensure a pause of 400-500 ms after the last such packet before it sends its answer. This opens the potential risk that a continuous stream of Known-Answer packets could, theoretically, prevent a responder from answering indefinitely. In practice, answers are never actually delayed significantly, and should a situation arise where significant delays did happen, that would be a scenario where the network is so overloaded that it would be desirable to err on the side of caution. The consequence of delaying an answer may be that it takes a user longer than usual to discover all the services on the local network; in contrast, the consequence of incorrectly answering before all the Known-Answer packets have been received would be wasted capacity sending unnecessary answers on an already overloaded network. In this (rare) situation, sacrificing speed to preserve reliable network operation is the right trade-off.
如果应答器接收到设置了TC位的其他已知应答数据包，则应根据需要延长延迟，以确保在发送应答之前，在最后一个此类数据包之后暂停400-500 ms。这就带来了潜在的风险，即已知应答包的连续流理论上可能会阻止应答者无限期地应答。在实践中，答案实际上从来没有明显延迟过，如果出现确实发生了明显延迟的情况，那将是一种网络超负荷的情况，需要谨慎行事。延迟回答的结果可能是，用户需要比平常更长的时间才能发现本地网络上的所有服务；相反，在接收到所有已知应答数据包之前错误应答的结果将是在已经过载的网络上发送不必要应答的容量浪费。在这种（罕见的）情况下，牺牲速度以保持可靠的网络运行是正确的权衡。
If a host is planning to transmit (or retransmit) a query, and it sees another host on the network send a query containing the same "QM" question, and the Known-Answer Section of that query does not contain any records that this host would not also put in its own Known-Answer Section, then this host SHOULD treat its own query as having been sent. When multiple queriers on the network are querying for the same resource records, there is no need for them to all be repeatedly asking the same question.
如果主机计划传输（或重新传输）查询，并且它看到网络上的另一台主机发送包含相同“QM”问题的查询，并且该查询的已知答案部分不包含该主机不会放在其自己的已知答案部分的任何记录，则该主机应将其自己的查询视为已发送。当网络上的多个查询者查询相同的资源记录时，它们不需要重复地问相同的问题。
If a host is planning to send an answer, and it sees another host on the network send a response message containing the same answer record, and the TTL in that record is not less than the TTL this host would have given, then this host SHOULD treat its own answer as having been sent, and not also send an identical answer itself. When multiple responders on the network have the same data, there is no need for all of them to respond.
如果一台主机计划发送应答，并且它看到网络上的另一台主机发送包含相同应答记录的响应消息，并且该记录中的TTL不小于该主机将给出的TTL，则该主机应将其自己的应答视为已发送，而不是发送相同的应答。当网络上的多个响应者具有相同的数据时，不需要所有响应者都响应。
The opportunity for duplicate answer suppression occurs when a host has received a query, and is delaying its response for some pseudo-random interval up to 500 ms, as described elsewhere in this document, and then, before the host sends its response, it sees some other host on the network send a response message containing the same answer record.
当主机接收到查询并将其响应延迟一段伪随机间隔达500 ms（如本文档其他部分所述），然后在主机发送响应之前，它看到网络上的其他主机发送包含相同应答记录的响应消息时，就会出现重复应答抑制的机会。
This feature is particularly useful when Multicast DNS Proxy Servers are in use, where there could be more than one proxy on the network giving Multicast DNS answers on behalf of some other host (e.g., because that other host is currently asleep and is not itself responding to queries).
当使用多播DNS代理服务器时，此功能特别有用，其中网络上可能有多个代理代表其他主机提供多播DNS应答（例如，因为其他主机当前处于休眠状态，并且自身不响应查询）。
Typically a Multicast DNS responder should have, at the very least, address records for all of its active interfaces. Creating and advertising an HINFO record on each interface as well can be useful to network administrators.
通常，多播DNS响应程序至少应具有其所有活动接口的地址记录。在每个界面上创建和公布HINFO记录对网络管理员也很有用。
Whenever a Multicast DNS responder starts up, wakes up from sleep, receives an indication of a network interface "Link Change" event, or has any other reason to believe that its network connectivity may have changed in some relevant way, it MUST perform the two startup steps below: Probing (Section 8.1) and Announcing (Section 8.3).
每当多播DNS响应程序启动、从睡眠中唤醒、接收到网络接口“链路更改”事件的指示，或有任何其他理由认为其网络连接可能以某种相关方式发生了更改时，它必须执行以下两个启动步骤：探测（第8.1节）和宣布（第8.3节）。
The first startup step is that, for all those resource records that a Multicast DNS responder desires to be unique on the local link, it MUST send a Multicast DNS query asking for those resource records, to see if any of them are already in use. The primary example of this is a host's address records, which map its unique host name to its unique IPv4 and/or IPv6 addresses. All probe queries SHOULD be done using the desired resource record name and class (usually class 1, "Internet"), and query type "ANY" (255), to elicit answers for all types of records with that name. This allows a single question to be used in place of several questions, which is more efficient on the network. It also allows a host to verify exclusive ownership of a name for all rrtypes, which is desirable in most cases. It would be confusing, for example, if one host owned the "A" record for "myhost.local.", but a different host owned the "AAAA" record for that name.
第一个启动步骤是，对于多播DNS响应程序希望在本地链路上唯一的所有资源记录，它必须发送多播DNS查询，询问这些资源记录，以查看是否有任何资源记录已在使用中。这方面的主要示例是主机的地址记录，它将其唯一的主机名映射到其唯一的IPv4和/或IPv6地址。所有探测查询都应使用所需的资源记录名称和类（通常为类1，“Internet”）以及查询类型“ANY”（255）来完成，以获取具有该名称的所有类型记录的答案。这样就可以用一个问题代替几个问题，这在网络上更有效。它还允许主机验证所有RRTYPE的名称的独占所有权，这在大多数情况下是可取的。例如，如果一个主机拥有“myhost.local.”的“A”记录，而另一个主机拥有该名称的“AAAA”记录，这将令人困惑。
The ability to place more than one question in a Multicast DNS query is useful here, because it can allow a host to use a single message to probe for all of its resource records instead of needing a separate message for each. For example, a host can simultaneously probe for uniqueness of its "A" record and all its SRV records [RFC6763] in the same query message.
在多播DNS查询中放置多个问题的功能在这里很有用，因为它允许主机使用单个消息来探测其所有资源记录，而不需要为每个资源记录单独发送消息。例如，主机可以在同一查询消息中同时探测其“a”记录和所有SRV记录[RFC6763]的唯一性。
When ready to send its Multicast DNS probe packet(s) the host should first wait for a short random delay time, uniformly distributed in the range 0-250 ms. This random delay is to guard against the case where several devices are powered on simultaneously, or several devices are connected to an Ethernet hub, which is then powered on, or some other external event happens that might cause a group of hosts to all send synchronized probes.
当准备好发送其多播DNS探测数据包时，主机应首先等待一段短的随机延迟时间，均匀分布在0-250 ms范围内。此随机延迟是为了防止多个设备同时通电，或多个设备连接到以太网集线器，然后再通电，或者发生其他一些外部事件，可能导致一组主机发送所有同步探测。
250 ms after the first query, the host should send a second; then, 250 ms after that, a third. If, by 250 ms after the third probe, no conflicting Multicast DNS responses have been received, the host may move to the next step, announcing. (Note that probing is the one exception from the normal rule that there should be at least one second between repetitions of the same question, and the interval between subsequent repetitions should at least double.)
第一次查询250毫秒后，主机应发送第二次查询；然后，250毫秒之后，第三个。如果在第三次探测后250毫秒，没有收到冲突的多播DNS响应，则主机可以移动到下一步，即宣布。（请注意，探究是正常规则的一个例外，即同一问题的重复之间至少应有1秒的间隔，后续重复之间的间隔至少应加倍。）
When sending probe queries, a host MUST NOT consult its cache for potential answers. Only conflicting Multicast DNS responses received "live" from the network are considered valid for the purposes of determining whether probing has succeeded or failed.
发送探测查询时，主机不得查阅其缓存以获取可能的答案。只有从网络“实时”接收到的冲突多播DNS响应才被认为是有效的，以确定探测是否成功或失败。
In order to allow services to announce their presence without unreasonable delay, the time window for probing is intentionally set quite short. As a result of this, from the time the first probe packet is sent, another device on the network using that name has just 750 ms to respond to defend its name. On networks that are slow, or busy, or both, it is possible for round-trip latency to account for a few hundred milliseconds, and software delays in slow devices can add additional delay. Hence, it is important that when a device receives a probe query for a name that it is currently using, it SHOULD generate its response to defend that name immediately and send it as quickly as possible. The usual rules about random delays before responding, to avoid sudden bursts of simultaneous answers from different hosts, do not apply here since normally at most one host should ever respond to a given probe question. Even when a single DNS query message contains multiple probe questions, it would be unusual for that message to elicit a defensive response from more than one other host. Because of the mDNS multicast rate-limiting
为了使服务能够在没有不合理延迟的情况下宣布其存在，故意将探测的时间窗口设置得很短。因此，从发送第一个探测数据包开始，网络上使用该名称的另一个设备只有750 ms的响应时间来保护其名称。在慢速、繁忙或两者兼有的网络上，往返延迟可能达到几百毫秒，而慢速设备中的软件延迟可能会增加额外的延迟。因此，重要的是，当设备收到针对其当前使用的名称的探测查询时，它应该立即生成响应以保护该名称，并尽快发送该名称。通常关于响应前随机延迟的规则，以避免来自不同主机的同时回答突然爆发，在这里不适用，因为通常最多一个主机应该响应给定的探测问题。即使单个DNS查询消息包含多个探测问题，该消息也会引发来自多个其他主机的防御响应。由于mDNS多播速率限制
rules, the probes SHOULD be sent as "QU" questions with the unicast-response bit set, to allow a defending host to respond immediately via unicast, instead of potentially having to wait before replying via multicast.
根据规则，探测应以“QU”问题的形式发送，并设置单播响应位，以允许防御主机通过单播立即响应，而不必在通过多播响应之前等待。
During probing, from the time the first probe packet is sent until 250 ms after the third probe, if any conflicting Multicast DNS response is received, then the probing host MUST defer to the existing host, and SHOULD choose new names for some or all of its resource records as appropriate. Apparently conflicting Multicast DNS responses received *before* the first probe packet is sent MUST be silently ignored (see discussion of stale probe packets in Section 8.2, "Simultaneous Probe Tiebreaking", below). In the case of a host probing using query type "ANY" as recommended above, any answer containing a record with that name, of any type, MUST be considered a conflicting response and handled accordingly.
在探测期间，从发送第一个探测数据包到第三个探测后250毫秒，如果接收到任何冲突的多播DNS响应，则探测主机必须遵从现有主机，并应根据需要为其部分或全部资源记录选择新名称。在*发送第一个探测数据包之前*收到的明显冲突的多播DNS响应必须被静默忽略（请参阅下面第8.2节“同步探测分接”中对过时探测数据包的讨论）。在使用上述建议的查询类型“ANY”进行主机探测的情况下，包含具有该名称的记录的任何类型的任何答案都必须视为冲突响应，并相应地进行处理。
If fifteen conflicts occur within any ten-second period, then the host MUST wait at least five seconds before each successive additional probe attempt. This is to help ensure that, in the event of software bugs or other unanticipated problems, errant hosts do not flood the network with a continuous stream of multicast traffic. For very simple devices, a valid way to comply with this requirement is to always wait five seconds after any failed probe attempt before trying again.
如果在任何10秒钟内发生15次冲突，则主机必须在每次连续的额外探测尝试之前至少等待5秒钟。这有助于确保在出现软件错误或其他意外问题时，错误的主机不会使网络充满连续的多播通信流。对于非常简单的设备，遵守此要求的有效方法是在任何失败的探测尝试后始终等待五秒钟，然后重试。
If a responder knows by other means that its unique resource record set name, rrtype, and rrclass cannot already be in use by any other responder on the network, then it SHOULD skip the probing step for that resource record set. For example, when creating the reverse address mapping PTR records, the host can reasonably assume that no other host will be trying to create those same PTR records, since that would imply that the two hosts were trying to use the same IP address, and if that were the case, the two hosts would be suffering communication problems beyond the scope of what Multicast DNS is designed to solve. Similarly, if a responder is acting as a proxy, taking over from another Multicast DNS responder that has already verified the uniqueness of the record, then the proxy SHOULD NOT repeat the probing step for those records.
如果响应者通过其他方式知道其唯一的资源记录集名称、rrtype和rrclass不能被网络上的任何其他响应者使用，则应跳过该资源记录集的探测步骤。例如，当创建反向地址映射PTR记录时，主机可以合理地假设没有其他主机尝试创建这些相同的PTR记录，因为这意味着两台主机尝试使用相同的IP地址，如果是这样，这两台主机的通信问题超出了多播DNS的设计范围。类似地，如果响应程序充当代理，从已验证记录唯一性的另一个多播DNS响应程序接管，则代理程序不应对这些记录重复探测步骤。
The astute reader will observe that there is a race condition inherent in the previous description. If two hosts are probing for the same name simultaneously, neither will receive any response to the probe, and the hosts could incorrectly conclude that they may both proceed to use the name. To break this symmetry, each host populates the query message's Authority Section with the record or
精明的读者会注意到在前面的描述中有一个固有的竞争条件。如果两台主机同时探测相同的名称，则两台主机都不会收到对探测的任何响应，并且主机可能会错误地认为它们都可能继续使用该名称。为了打破这种对称性，每个主机都用记录或数据填充查询消息的权限部分
records with the rdata that it would be proposing to use, should its probing be successful. The Authority Section is being used here in a way analogous to the way it is used as the "Update Section" in a DNS Update message [RFC2136] [RFC3007].
若探测成功，则记录其将建议使用的rdata。此处使用授权部分的方式类似于在DNS更新消息[RFC2136][RFC3007]中将其用作“更新部分”的方式。
When a host is probing for a group of related records with the same name (e.g., the SRV and TXT record describing a DNS-SD service), only a single question need be placed in the Question Section, since query type "ANY" (255) is used, which will elicit answers for all records with that name. However, for tiebreaking to work correctly in all cases, the Authority Section must contain *all* the records and proposed rdata being probed for uniqueness.
当主机探测具有相同名称的一组相关记录（例如，描述DNS-SD服务的SRV和TXT记录）时，只需在问题部分放置一个问题，因为使用了查询类型“ANY”（255），这将获取具有该名称的所有记录的答案。但是，为了在所有情况下都能正常工作，权限部分必须包含*所有*正在调查的记录和建议的rdata，以确保其唯一性。
When a host that is probing for a record sees another host issue a query for the same record, it consults the Authority Section of that query. If it finds any resource record(s) there which answers the query, then it compares the data of that (those) resource record(s) with its own tentative data. We consider first the simple case of a host probing for a single record, receiving a simultaneous probe from another host also probing for a single record. The two records are compared and the lexicographically later data wins. This means that if the host finds that its own data is lexicographically later, it simply ignores the other host's probe. If the host finds that its own data is lexicographically earlier, then it defers to the winning host by waiting one second, and then begins probing for this record again. The logic for waiting one second and then trying again is to guard against stale probe packets on the network (possibly even stale probe packets sent moments ago by this host itself, before some configuration change, which may be echoed back after a short delay by some Ethernet switches and some 802.11 base stations). If the winning simultaneous probe was from a real other host on the network, then after one second it will have completed its probing, and will answer subsequent probes. If the apparently winning simultaneous probe was in fact just an old stale packet on the network (maybe from the host itself), then when it retries its probing in one second, its probes will go unanswered, and it will successfully claim the name.
当探测记录的主机看到另一台主机对同一记录发出查询时，它会咨询该查询的权限部分。如果它在那里找到了回答查询的任何资源记录，那么它会将该资源记录的数据与其自己的暂定数据进行比较。我们首先考虑主机探测单个记录的简单情况，接收来自另一主机的同时探测也探测单个记录。这两个记录将被比较，随后按词典编纂的数据将获胜。这意味着，如果主机发现其自己的数据在以后按词典编纂，它只会忽略另一个主机的探测。如果主机发现它自己的数据在词典编纂上更早，那么它将等待一秒钟，以等待获胜主机，然后再次开始探测该记录。等待一秒钟然后重试的逻辑是防止网络上的过时探测数据包（甚至可能是在某些配置更改之前不久由该主机本身发送的过时探测数据包，在一些以太网交换机和一些802.11基站短暂延迟后可能会回显）。如果获胜的同时探测来自网络上的真实其他主机，则在一秒钟后，它将完成探测，并将应答后续探测。如果表面上获胜的同步探测实际上只是网络上的一个陈旧数据包（可能来自主机本身），那么当它在一秒钟内重试探测时，它的探测将无法应答，并且它将成功地声明名称。
The determination of "lexicographically later" is performed by first comparing the record class (excluding the cache-flush bit described in Section 10.2), then the record type, then raw comparison of the binary content of the rdata without regard for meaning or structure. If the record classes differ, then the numerically greater class is considered "lexicographically later". Otherwise, if the record types differ, then the numerically greater type is considered "lexicographically later". If the rrtype and rrclass both match, then the rdata is compared.
通过首先比较记录类（不包括第10.2节中描述的缓存刷新位），然后比较记录类型，然后比较rdata的二进制内容，而不考虑其含义或结构，来确定“以后的词典”。如果记录类别不同，则数字较大的类别被视为“词典编纂较晚”。否则，如果记录类型不同，则数字较大的类型被视为“词典编纂较晚”。如果rrtype和rrclass都匹配，则比较rdata。
In the case of resource records containing rdata that is subject to name compression [RFC1035], the names MUST be uncompressed before comparison. (The details of how a particular name is compressed is an artifact of how and where the record is written into the DNS message; it is not an intrinsic property of the resource record itself.)
对于包含受名称压缩[RFC1035]约束的rdata的资源记录，在比较之前必须先解压缩名称。（特定名称如何压缩的详细信息是记录写入DNS消息的方式和位置的产物；它不是资源记录本身的固有属性。）
The bytes of the raw uncompressed rdata are compared in turn, interpreting the bytes as eight-bit UNSIGNED values, until a byte is found whose value is greater than that of its counterpart (in which case, the rdata whose byte has the greater value is deemed lexicographically later) or one of the resource records runs out of rdata (in which case, the resource record which still has remaining data first is deemed lexicographically later). The following is an example of a conflict:
依次比较原始未压缩rdata的字节，将字节解释为8位无符号值，直到找到一个值大于其对应值的字节（在这种情况下，其字节具有更大值的rdata在以后的词典中被视为）或一个资源记录耗尽rdata（在这种情况下，先保留剩余数据的资源记录将在以后按字典顺序被视为）。以下是冲突示例：
MyPrinter.local. A 169.254.99.200 MyPrinter.local. A 169.254.200.50
我的打印机是本地的。A 169.254.99.200 MyPrinter.local。A 169.254.200.50
In this case, 169.254.200.50 is lexicographically later (the third byte, with value 200, is greater than its counterpart with value 99), so it is deemed the winner.
在本例中，169.254.200.50按字典顺序排列较晚（第三个字节的值为200，大于其对应的值99），因此它被视为赢家。
Note that it is vital that the bytes are interpreted as UNSIGNED values in the range 0-255, or the wrong outcome may result. In the example above, if the byte with value 200 had been incorrectly interpreted as a signed eight-bit value, then it would be interpreted as value -56, and the wrong address record would be deemed the winner.
请注意，必须将字节解释为0-255范围内的无符号值，否则可能导致错误的结果。在上面的示例中，如果值为200的字节被错误地解释为有符号的8位值，那么它将被解释为值-56，错误的地址记录将被视为胜利者。
When a host is probing for a set of records with the same name, or a message is received containing multiple tiebreaker records answering a given probe question in the Question Section, the host's records and the tiebreaker records from the message are each sorted into order, and then compared pairwise, using the same comparison technique described above, until a difference is found.
当主机探测具有相同名称的一组记录时，或收到一条消息，其中包含回答问题部分中给定探测问题的多条断开连接的记录，主机的记录和消息中的断开连接的记录将分别按顺序排序，然后成对比较，使用上述相同的比较技术，直到发现差异。
The records are sorted using the same lexicographical order as described above, that is, if the record classes differ, the record with the lower class number comes first. If the classes are the same but the rrtypes differ, the record with the lower rrtype number comes first. If the class and rrtype match, then the rdata is compared bytewise until a difference is found. For example, in the common case of advertising DNS-SD services with a TXT record and an SRV record, the TXT record comes first (the rrtype value for TXT is 16) and the SRV record comes second (the rrtype value for SRV is 33).
使用与上述相同的词典顺序对记录进行排序，也就是说，如果记录类别不同，则具有较低类别编号的记录优先。如果类别相同，但rrtype不同，则先出现rrtype编号较低的记录。如果类和rrtype匹配，则按字节比较rdata，直到发现差异。例如，在使用TXT记录和SRV记录发布DNS-SD服务的常见情况下，TXT记录位于第一位（TXT的rrtype值为16），SRV记录位于第二位（SRV的rrtype值为33）。
When comparing the records, if the first records match perfectly, then the second records are compared, and so on. If either list of records runs out of records before any difference is found, then the list with records remaining is deemed to have won the tiebreak. If both lists run out of records at the same time without any difference being found, then this indicates that two devices are advertising identical sets of records, as is sometimes done for fault tolerance, and there is, in fact, no conflict.
比较记录时，如果第一个记录完全匹配，则比较第二个记录，依此类推。如果任一记录列表在发现任何差异之前用完记录，则剩余记录的列表被视为赢得了决胜局。如果两个列表同时用完记录而未发现任何差异，则这表明两个设备正在宣传相同的记录集，有时是为了容错，事实上没有冲突。
The second startup step is that the Multicast DNS responder MUST send an unsolicited Multicast DNS response containing, in the Answer Section, all of its newly registered resource records (both shared records, and unique records that have completed the probing step). If there are too many resource records to fit in a single packet, multiple packets should be used.
第二个启动步骤是，多播DNS响应程序必须发送一个未经请求的多播DNS响应，该响应在应答部分包含其所有新注册的资源记录（共享记录和完成探测步骤的唯一记录）。如果有太多的资源记录无法放入单个数据包中，则应使用多个数据包。
In the case of shared records (e.g., the PTR records used by DNS-Based Service Discovery [RFC6763]), the records are simply placed as is into the Answer Section of the DNS response.
在共享记录的情况下（例如，基于DNS的服务发现[RFC6763]使用的PTR记录），这些记录只是按原样放入DNS响应的应答部分。
In the case of records that have been verified to be unique in the previous step, they are placed into the Answer Section of the DNS response with the most significant bit of the rrclass set to one. The most significant bit of the rrclass for a record in the Answer Section of a response message is the Multicast DNS cache-flush bit and is discussed in more detail below in Section 10.2, "Announcements to Flush Outdated Cache Entries".
对于在上一步中已验证为唯一的记录，它们将被放入DNS响应的应答部分，rrclass的最高有效位设置为1。响应消息应答部分中记录的rrclass最重要的位是多播DNS缓存刷新位，下面将在第10.2节“刷新过期缓存项的公告”中进行更详细的讨论。
The Multicast DNS responder MUST send at least two unsolicited responses, one second apart. To provide increased robustness against packet loss, a responder MAY send up to eight unsolicited responses, provided that the interval between unsolicited responses increases by at least a factor of two with every response sent.
多播DNS响应程序必须至少发送两个未经请求的响应，间隔1秒。为了提供对分组丢失的增强鲁棒性，响应者可以发送多达八个未经请求的响应，前提是每发送一个响应，未经请求的响应之间的间隔至少增加两倍。
A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course.
多播DNS响应程序不得在缺少其网络连接可能以某种相关方式发生更改的信息的情况下发送通知。特别是，多播DNS响应程序当然不能定期发送通知。
Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described in Section 9, "Conflict Resolution".
每当多播DNS响应程序收到包含冲突资源记录的任何多播DNS响应（请求或其他），必须按照第9节“冲突解决”中的说明解决冲突。
At any time, if the rdata of any of a host's Multicast DNS records changes, the host MUST repeat the Announcing step described above to update neighboring caches. For example, if any of a host's IP addresses change, it MUST re-announce those address records. The host does not need to repeat the Probing step because it has already established unique ownership of that name.
在任何时候，如果主机的任何多播DNS记录的rdata发生更改，则主机必须重复上述宣布步骤以更新相邻缓存。例如，如果主机的任何IP地址发生更改，它必须重新宣布这些地址记录。主机不需要重复探测步骤，因为它已经建立了该名称的唯一所有权。
In the case of shared records, a host MUST send a "goodbye" announcement with RR TTL zero (see Section 10.1, "Goodbye Packets") for the old rdata, to cause it to be deleted from peer caches, before announcing the new rdata. In the case of unique records, a host SHOULD omit the "goodbye" announcement, since the cache-flush bit on the newly announced records will cause old rdata to be flushed from peer caches anyway.
在共享记录的情况下，主机必须为旧rdata发送RR TTL为零的“再见”通知（参见第10.1节“再见数据包”），以便在宣布新rdata之前将其从对等缓存中删除。对于唯一记录，主机应该忽略“再见”通知，因为新通知的记录上的缓存刷新位将导致旧rdata从对等缓存中刷新。
A host may update the contents of any of its records at any time, though a host SHOULD NOT update records more frequently than ten times per minute. Frequent rapid updates impose a burden on the network. If a host has information to disseminate which changes more frequently than ten times per minute, then it may be more appropriate to design a protocol for that specific purpose.
主机可以随时更新其任何记录的内容，但主机更新记录的频率不应超过每分钟十次。频繁的快速更新给网络带来了负担。如果主机要传播的信息每分钟变化超过十次，那么为特定目的设计协议可能更合适。
A conflict occurs when a Multicast DNS responder has a unique record for which it is currently authoritative, and it receives a Multicast DNS response message containing a record with the same name, rrtype and rrclass, but inconsistent rdata. What may be considered inconsistent is context sensitive, except that resource records with identical rdata are never considered inconsistent, even if they originate from different hosts. This is to permit use of proxies and other fault-tolerance mechanisms that may cause more than one responder to be capable of issuing identical answers on the network.
当多播DNS响应程序具有其当前授权的唯一记录，并且接收到多播DNS响应消息，其中包含具有相同名称、rrtype和rrclass但rdata不一致的记录时，会发生冲突。可以认为不一致的内容是上下文相关的，除非具有相同rdata的资源记录永远不会被认为不一致，即使它们来自不同的主机。这是为了允许使用代理和其他容错机制，这些机制可能导致多个响应者能够在网络上发布相同的答案。
A common example of a resource record type that is intended to be unique, not shared between hosts, is the address record that maps a host's name to its IP address. Should a host witness another host announce an address record with the same name but a different IP address, then that is considered inconsistent, and that address record is considered to be in conflict.
用于唯一而不是在主机之间共享的资源记录类型的一个常见示例是将主机名映射到其IP地址的地址记录。如果一个主机看到另一个主机宣布一个具有相同名称但不同IP地址的地址记录，则认为该地址记录不一致，并且认为该地址记录存在冲突。
Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record in any of the Resource Record Sections, the Multicast DNS responder MUST immediately reset its conflicted unique record to probing state, and go through the startup steps described above in
每当多播DNS响应程序收到任何多播DNS响应（请求或其他）时，在任何资源记录部分中包含冲突的资源记录，多播DNS响应程序必须立即将其冲突的唯一记录重置为探测状态，并执行上述中所述的启动步骤
Section 8, "Probing and Announcing on Startup". The protocol used in the Probing phase will determine a winner and a loser, and the loser MUST cease using the name, and reconfigure.
第8节，“启动时的探测和宣布”。探测阶段使用的协议将确定赢家和输家，输家必须停止使用该名称，并重新配置。
It is very important that any host receiving a resource record that conflicts with one of its own MUST take action as described above. In the case of two hosts using the same host name, where one has been configured to require a unique host name and the other has not, the one that has not been configured to require a unique host name will not perceive any conflict, and will not take any action. By reverting to Probing state, the host that desires a unique host name will go through the necessary steps to ensure that a unique host name is obtained.
非常重要的是，任何接收到与其自身资源记录冲突的资源记录的主机都必须采取上述操作。如果两台主机使用相同的主机名，其中一台已配置为需要唯一的主机名，而另一台未配置为需要唯一的主机名，则未配置为需要唯一主机名的主机将不会发现任何冲突，也不会采取任何行动。通过恢复到探测状态，需要唯一主机名的主机将执行必要的步骤，以确保获得唯一主机名。
The recommended course of action after probing and failing is as follows:
探测失败后，建议采取以下措施：
1. Programmatically change the resource record name in an attempt to find a new name that is unique. This could be done by adding some further identifying information (e.g., the model name of the hardware) if it is not already present in the name, or appending the digit "2" to the name, or incrementing a number at the end of the name if one is already present.
1. 以编程方式更改资源记录名称，以尝试找到唯一的新名称。如果名称中不存在其他标识信息（例如，硬件的型号名称），可以通过添加这些信息来实现，或者在名称后面添加数字“2”，或者在名称末尾增加一个数字（如果已经存在）。
2. Probe again, and repeat as necessary until a unique name is found.
2. 再次探测，并根据需要重复，直到找到唯一的名称。
3. Once an available unique name has been determined, by probing without receiving any conflicting response, record this newly chosen name in persistent storage so that the device will use the same name the next time it is power-cycled.
3. 一旦确定了可用的唯一名称，在不接收任何冲突响应的情况下进行探测，将新选择的名称记录在永久存储器中，以便设备下次通电时使用相同的名称。
4. Display a message to the user or operator informing them of the name change. For example:
4. 向用户或操作员显示一条消息，通知他们名称更改。例如：
The name "Bob's Music" is in use by another music server on the network. Your music collection has been renamed to "Bob's Music (2)". If you want to change this name, use [describe appropriate menu item or preference dialog here].
网络上的另一个音乐服务器正在使用名称“Bob's Music”。您的音乐收藏已重命名为“Bob的音乐（2）”。如果要更改此名称，请使用[此处描述相应的菜单项或首选项对话框]。
The details of how the user or operator is informed of the new name depends on context. A desktop computer with a screen might put up a dialog box. A headless server in the closet may write a message to a log file, or use whatever mechanism (email, SNMP trap, etc.) it uses to inform the administrator of error conditions. On the other hand, a headless server in the closet may not inform the user at all -- if the user cares,
有关如何通知用户或操作员新名称的详细信息取决于上下文。带有屏幕的台式计算机可能会显示一个对话框。壁橱中的无头服务器可能会将消息写入日志文件，或者使用它用来通知管理员错误情况的任何机制（电子邮件、SNMP陷阱等）。另一方面，壁橱中的无头服务器可能根本不会通知用户——如果用户关心，
they will notice the name has changed, and connect to the server in the usual way (e.g., via web browser) to configure a new name.
他们会注意到名称已更改，并以常规方式（例如，通过web浏览器）连接到服务器以配置新名称。
5. After one minute of probing, if the Multicast DNS responder has been unable to find any unused name, it should log an error message to inform the user or operator of this fact. This situation should never occur in normal operation. The only situations that would cause this to happen would be either a deliberate denial-of-service attack, or some kind of very obscure hardware or software bug that acts like a deliberate denial-of-service attack.
5. 探测一分钟后，如果多播DNS响应程序无法找到任何未使用的名称，则应记录一条错误消息，通知用户或操作员这一事实。这种情况在正常操作中不应发生。导致这种情况发生的唯一情况可能是故意的拒绝服务攻击，或者某种非常模糊的硬件或软件缺陷，其行为类似于故意的拒绝服务攻击。
These considerations apply to address records (i.e., host names) and to all resource records where uniqueness (or maintenance of some other defined constraint) is desired.
这些注意事项适用于地址记录（即主机名）和需要唯一性（或维护某些其他定义约束）的所有资源记录。
As a general rule, the recommended TTL value for Multicast DNS resource records with a host name as the resource record's name (e.g., A, AAAA, HINFO) or a host name contained within the resource record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120 seconds.
作为一般规则，使用主机名作为资源记录名称（例如，a、AAAA、HINFO）或包含在资源记录rdata中的主机名（例如，SRV、反向映射PTR记录）的多播DNS资源记录的建议TTL值应为120秒。
The recommended TTL value for other Multicast DNS resource records is 75 minutes.
其他多播DNS资源记录的建议TTL值为75分钟。
A querier with an active outstanding query will issue a query message when one or more of the resource records in its cache are 80% of the way to expiry. If the TTL on those records is 75 minutes, this ongoing cache maintenance process yields a steady-state query rate of one query every 60 minutes.
具有活动未完成查询的查询器将在其缓存中的一个或多个资源记录即将过期80%时发出查询消息。如果这些记录上的TTL为75分钟，则此正在进行的缓存维护过程将产生稳定的查询速率，即每60分钟查询一次。
Any distributed cache needs a cache coherency protocol. If Multicast DNS resource records follow the recommendation and have a TTL of 75 minutes, that means that stale data could persist in the system for a little over an hour. Making the default RR TTL significantly lower would reduce the lifetime of stale data, but would produce too much extra traffic on the network. Various techniques are available to minimize the impact of such stale data, outlined in the five subsections below.
任何分布式缓存都需要缓存一致性协议。如果多播DNS资源记录遵循建议并具有75分钟的TTL，则意味着陈旧数据可能会在系统中持续一个多小时。使默认RR TTL显著降低会缩短过时数据的生存期，但会在网络上产生太多额外流量。可以使用各种技术来最小化这些过时数据的影响，如下五小节所述。
In the case where a host knows that certain resource record data is about to become invalid (for example, when the host is undergoing a clean shutdown), the host SHOULD send an unsolicited Multicast DNS
如果主机知道某些资源记录数据即将变得无效（例如，当主机处于完全关闭状态时），则主机应发送未经请求的多播DNS
response packet, giving the same resource record name, rrtype, rrclass, and rdata, but an RR TTL of zero. This has the effect of updating the TTL stored in neighboring hosts' cache entries to zero, causing that cache entry to be promptly deleted.
响应数据包，提供相同的资源记录名称、rrtype、rrclass和rdata，但RR TTL为零。这会将存储在相邻主机缓存项中的TTL更新为零，从而使该缓存项立即被删除。
Queriers receiving a Multicast DNS response with a TTL of zero SHOULD NOT immediately delete the record from the cache, but instead record a TTL of 1 and then delete the record one second later. In the case of multiple Multicast DNS responders on the network described in Section 6.6 above, if one of the responders shuts down and incorrectly sends goodbye packets for its records, it gives the other cooperating responders one second to send out their own response to "rescue" the records before they expire and are deleted.
收到TTL为零的多播DNS响应的查询者不应立即从缓存中删除该记录，而应记录TTL为1，然后在1秒后删除该记录。在上文第6.6节所述的网络上有多个多播DNS响应程序的情况下，如果其中一个响应程序关闭并错误地发送其记录的再见数据包，则会给其他合作响应程序一秒钟的时间，以便在记录过期并被删除之前发送其自己的响应以“拯救”记录。
Whenever a host has a resource record with new data, or with what might potentially be new data (e.g., after rebooting, waking from sleep, connecting to a new network link, or changing IP address), the host needs to inform peers of that new data. In cases where the host has not been continuously connected and participating on the network link, it MUST first probe to re-verify uniqueness of its unique records, as described above in Section 8.1, "Probing".
每当主机具有包含新数据或可能包含新数据的资源记录时（例如，在重新启动、从睡眠中醒来、连接到新网络链路或更改IP地址后），主机都需要通知对等方该新数据。如果主机未连续连接并参与网络链路，则必须首先探测以重新验证其唯一记录的唯一性，如上文第8.1节“探测”所述。
Having completed the Probing step, if necessary, the host MUST then send a series of unsolicited announcements to update cache entries in its neighbor hosts. In these unsolicited announcements, if the record is one that has been verified unique, the host sets the most significant bit of the rrclass field of the resource record. This bit, the cache-flush bit, tells neighboring hosts that this is not a shared record type. Instead of merging this new record additively into the cache in addition to any previous records with the same name, rrtype, and rrclass, all old records with that name, rrtype, and rrclass that were received more than one second ago are declared invalid, and marked to expire from the cache in one second.
完成探测步骤后，如有必要，主机必须发送一系列未经请求的通知，以更新其邻居主机中的缓存项。在这些未经请求的公告中，如果记录是已验证唯一的记录，则主机将设置资源记录的rrclass字段的最高有效位。该位（缓存刷新位）告诉相邻主机这不是共享记录类型。除了具有相同名称、rrtype和rrclass的任何以前的记录之外，不再将此新记录添加到缓存中，而是将在一秒钟以上收到的所有具有该名称、rrtype和rrclass的旧记录声明为无效，并标记为在一秒钟内从缓存中过期。
The semantics of the cache-flush bit are as follows: normally when a resource record appears in a Resource Record Section of the DNS response it means, "This is an assertion that this information is true". When a resource record appears in a Resource Record Section of the DNS response with the cache-flush bit set, it means, "This is an assertion that this information is the truth and the whole truth, and anything you may have heard more than a second ago regarding records of this name/rrtype/rrclass is no longer true".
缓存刷新位的语义如下：通常，当资源记录出现在DNS响应的资源记录部分时，它意味着“这是该信息为真的断言”。当资源记录出现在设置了缓存刷新位的DNS响应的资源记录部分时，这意味着“这是一个断言，该信息是真实的，并且是全部真实的，并且您可能在一秒钟前听到的关于此名称/rrtype/rrclass的记录的任何内容都不再真实”。
To accommodate the case where the set of records from one host constituting a single unique RRSet is too large to fit in a single packet, only cache records that are more than one second old are
为了适应构成单个唯一RRSet的来自一台主机的记录集太大而无法容纳在单个数据包中的情况，只允许使用超过1秒的缓存记录
flushed. This allows the announcing host to generate a quick burst of packets back-to-back on the wire containing all the members of the RRSet. When receiving records with the cache-flush bit set, all records older than one second are marked to be deleted one second in the future. One second after the end of the little packet burst, any records not represented within that packet burst will then be expired from all peer caches.
脸红了。这允许广播主机在包含RRSet所有成员的线路上背靠背地生成快速数据包突发。当接收设置了缓存刷新位的记录时，所有早于1秒的记录都将标记为在未来1秒内删除。在小数据包突发结束后一秒钟，该数据包突发中未表示的任何记录将从所有对等缓存中过期。
Any time a host sends a response packet containing some members of a unique RRSet, it MUST send the entire RRSet, preferably in a single packet, or if the entire RRSet will not fit in a single packet, in a quick burst of packets sent as close together as possible. The host MUST set the cache-flush bit on all members of the unique RRSet.
每当主机发送包含唯一RRSet的一些成员的响应数据包时，它必须发送整个RRSet，最好是在单个数据包中，或者如果整个RRSet不能容纳在单个数据包中，则以尽可能接近的方式发送快速数据包突发。主机必须在唯一RRSet的所有成员上设置缓存刷新位。
Another reason for waiting one second before deleting stale records from the cache is to accommodate bridged networks. For example, a host's address record announcement on a wireless interface may be bridged onto a wired Ethernet and may cause that same host's Ethernet address records to be flushed from peer caches. The one-second delay gives the host the chance to see its own announcement arrive on the wired Ethernet, and immediately re-announce its Ethernet interface's address records so that both sets remain valid and live in peer caches.
在从缓存中删除过时记录之前等待一秒钟的另一个原因是为了适应桥接网络。例如，无线接口上的主机地址记录公告可以桥接到有线以太网上，并且可能导致从对等缓存刷新同一主机的以太网地址记录。一秒钟的延迟使主机有机会看到其自己的通知到达有线以太网，并立即重新通知其以太网接口的地址记录，以便两个集保持有效并在对等缓存中生存。
These rules, about when to set the cache-flush bit and about sending the entire rrset, apply regardless of *why* the response message is being generated. They apply to startup announcements as described in Section 8.3, "Announcing", and to responses generated as a result of receiving query messages.
无论生成响应消息的*原因*如何，这些规则（关于何时设置缓存刷新位以及关于发送整个rrset）都适用。它们适用于第8.3节“公告”中所述的启动公告，以及接收查询消息后生成的响应。
The cache-flush bit is only set in records in the Resource Record Sections of Multicast DNS responses sent to UDP port 5353.
缓存刷新位仅在发送到UDP端口5353的多播DNS响应的资源记录部分的记录中设置。
The cache-flush bit MUST NOT be set in any resource records in a response message sent in legacy unicast responses to UDP ports other than 5353.
在以传统单播响应发送到UDP端口（5353除外）的响应消息中，不得在任何资源记录中设置缓存刷新位。
The cache-flush bit MUST NOT be set in any resource records in the Known-Answer list of any query message.
不得在任何查询消息的已知应答列表中的任何资源记录中设置缓存刷新位。
The cache-flush bit MUST NOT ever be set in any shared resource record. To do so would cause all the other shared versions of this resource record with different rdata from different responders to be immediately deleted from all the caches on the network.
不得在任何共享资源记录中设置缓存刷新位。这样做将导致此资源记录的所有其他共享版本（具有来自不同响应者的不同rdata）立即从网络上的所有缓存中删除。
The cache-flush bit does *not* apply to questions listed in the Question Section of a Multicast DNS message. The top bit of the rrclass field in questions is used for an entirely different purpose (see Section 5.4, "Questions Requesting Unicast Responses").
缓存刷新位*不*适用于多播DNS消息的问题部分中列出的问题。问题中rrclass字段的顶部用于完全不同的目的（参见第5.4节“请求单播响应的问题”）。
Note that the cache-flush bit is NOT part of the resource record class. The cache-flush bit is the most significant bit of the second 16-bit word of a resource record in a Resource Record Section of a Multicast DNS message (the field conventionally referred to as the rrclass field), and the actual resource record class is the least significant fifteen bits of this field. There is no Multicast DNS resource record class 0x8001. The value 0x8001 in the rrclass field of a resource record in a Multicast DNS response message indicates a resource record with class 1, with the cache-flush bit set. When receiving a resource record with the cache-flush bit set, implementations should take care to mask off that bit before storing the resource record in memory, or otherwise ensure that it is given the correct semantic interpretation.
请注意，缓存刷新位不是资源记录类的一部分。缓存刷新位是多播DNS消息的资源记录部分中资源记录的第二个16位字的最高有效位（该字段通常称为rrclass字段），而实际资源记录类别是该字段的最低有效15位。没有多播DNS资源记录类0x8001。多播DNS响应消息中资源记录的rrclass字段中的值0x8001表示设置了缓存刷新位的类别为1的资源记录。当接收设置了缓存刷新位的资源记录时，实现应注意在将资源记录存储在内存中之前屏蔽该位，或者确保为其提供正确的语义解释。
The reuse of the top bit of the rrclass field only applies to conventional resource record types that are subject to caching, not to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930], SIG0 [RFC2931], etc., that pertain only to a particular transport level message and not to any actual DNS data. Since pseudo-RRs should never go into the Multicast DNS cache, the concept of a cache-flush bit for these types is not applicable. In particular, the rrclass field of an OPT record encodes the sender's UDP payload size, and should be interpreted as a sixteen-bit length value in the range 0-65535, not a one-bit flag and a fifteen-bit length.
rrclass字段顶部位的重用仅适用于受缓存约束的常规资源记录类型，而不适用于伪RRs，如OPT[RFC2671]、TSIG[RFC2845]、TKEY[RFC2930]、SIG0[RFC2931]等，这些伪RRs仅适用于特定传输级别消息，而不适用于任何实际DNS数据。由于伪RRs不应进入多播DNS缓存，因此这些类型的缓存刷新位的概念不适用。特别是，OPT记录的rrclass字段对发送方的UDP有效负载大小进行编码，并应解释为0-65535范围内的16位长度值，而不是1位标志和15位长度。
If the hardware on a given host is able to indicate physical changes of connectivity, then when the hardware indicates such a change, the host should take this information into account in its Multicast DNS cache management strategy. For example, a host may choose to immediately flush all cache records received on a particular interface when that cable is disconnected. Alternatively, a host may choose to adjust the remaining TTL on all those records to a few seconds so that if the cable is not reconnected quickly, those records will expire from the cache.
如果给定主机上的硬件能够指示连接的物理更改，则当硬件指示此类更改时，主机应在其多播DNS缓存管理策略中考虑此信息。例如，当电缆断开时，主机可以选择立即刷新在特定接口上接收的所有缓存记录。或者，主机可以选择将所有这些记录上的剩余TTL调整为几秒钟，以便如果电缆未快速重新连接，这些记录将从缓存中过期。
Likewise, when a host reboots, wakes from sleep, or undergoes some other similar discontinuous state change, the cache management strategy should take that information into account.
同样，当主机重新启动、从睡眠中唤醒或经历其他类似的不连续状态更改时，缓存管理策略应该考虑这些信息。
Sometimes a cache record can be determined to be stale when a client attempts to use the rdata it contains, and the client finds that rdata to be incorrect.
有时，当客户端试图使用缓存记录包含的rdata，并且客户端发现该rdata不正确时，可以确定缓存记录已过时。
For example, the rdata in an address record can be determined to be incorrect if attempts to contact that host fail, either because (for an IPv4 address on a local subnet) ARP requests for that address go unanswered, because (for an IPv6 address with an on-link prefix) ND requests for that address go unanswered, or because (for an address on a remote network) a router returns an ICMP "Host Unreachable" error.
例如，如果联系该主机的尝试失败，则地址记录中的rdata可能会被确定为不正确，原因可能是（对于本地子网上的IPv4地址）该地址的ARP请求未得到响应，或者（对于具有on-link前缀的IPv6地址）该地址的ND请求未得到响应，或者（对于远程网络上的地址）路由器返回ICMP“主机不可访问”错误。
The rdata in an SRV record can be determined to be incorrect if attempts to communicate with the indicated service at the host and port number indicated are not successful.
如果尝试与主机上指示的服务和指示的端口号通信失败，则可以确定SRV记录中的rdata不正确。
The rdata in a DNS-SD PTR record can be determined to be incorrect if attempts to look up the SRV record it references are not successful.
如果尝试查找其引用的SRV记录未成功，则可以确定DNS-SD PTR记录中的rdata不正确。
The software implementing the Multicast DNS resource record cache should provide a mechanism so that clients detecting stale rdata can inform the cache.
实现多播DNS资源记录缓存的软件应提供一种机制，以便检测过时rdata的客户端可以通知缓存。
When the cache receives this hint that it should reconfirm some record, it MUST issue two or more queries for the resource record in dispute. If no response is received within ten seconds, then, even though its TTL may indicate that it is not yet due to expire, that record SHOULD be promptly flushed from the cache.
当缓存接收到应该重新确认某个记录的提示时，它必须对有争议的资源记录发出两个或多个查询。如果在十秒钟内没有收到响应，则即使其TTL可能指示其尚未到期，也应立即从缓存中刷新该记录。
The end result of this is that if a printer suffers a sudden power failure or other abrupt disconnection from the network, its name may continue to appear in DNS-SD browser lists displayed on users' screens. Eventually, that entry will expire from the cache naturally, but if a user tries to access the printer before that happens, the failure to successfully contact the printer will trigger the more hasty demise of its cache entries. This is a sensible trade-off between good user experience and good network efficiency. If we were to insist that printers should disappear from the printer list within 30 seconds of becoming unavailable, for all failure modes, the only way to achieve this would be for the client to poll the printer at least every 30 seconds, or for the printer to announce its presence at least every 30 seconds, both of which would be an unreasonable burden on most networks.
这样做的最终结果是，如果打印机突然断电或与网络的其他突然断开连接，其名称可能会继续出现在用户屏幕上显示的DNS-SD浏览器列表中。最终，该条目将从缓存中自然过期，但如果用户在此之前尝试访问打印机，则未能成功联系打印机将触发其缓存条目的更快终止。这是良好的用户体验和良好的网络效率之间明智的权衡。如果我们坚持打印机应在不可用的30秒内从打印机列表中消失，对于所有故障模式，实现这一点的唯一方法是客户端至少每30秒轮询一次打印机，或打印机至少每30秒宣布其存在，这两种情况对大多数网络来说都是不合理的负担。
A host observes the multicast queries issued by the other hosts on the network. One of the major benefits of also sending responses using multicast is that it allows all hosts to see the responses (or lack thereof) to those queries.
主机观察网络上其他主机发出的多播查询。使用多播发送响应的一个主要好处是，它允许所有主机看到这些查询的响应（或没有响应）。
If a host sees queries, for which a record in its cache would be expected to be given as an answer in a multicast response, but no such answer is seen, then the host may take this as an indication that the record may no longer be valid.
如果主机看到查询，其缓存中的记录将作为多播响应中的答案给出，但没有看到这样的答案，则主机可以将此视为该记录可能不再有效的指示。
After seeing two or more of these queries, and seeing no multicast response containing the expected answer within ten seconds, then even though its TTL may indicate that it is not yet due to expire, that record SHOULD be flushed from the cache. The host SHOULD NOT perform its own queries to reconfirm that the record is truly gone. If every host on a large network were to do this, it would cause a lot of unnecessary multicast traffic. If host A sends multicast queries that remain unanswered, then there is no reason to suppose that host B or any other host is likely to be any more successful.
在看到其中两个或多个查询，并且在10秒内没有看到包含预期答案的多播响应后，即使其TTL可能指示其尚未到期，也应该从缓存中刷新该记录。主机不应该执行自己的查询来再次确认记录是否真的消失了。如果大型网络上的每台主机都这样做，将导致大量不必要的多播流量。如果主机A发送的多播查询仍然没有应答，那么就没有理由认为主机B或任何其他主机可能会更成功。
The previous section, "Cache Flush on Failure Indication", describes a situation where a user trying to print discovers that the printer is no longer available. By implementing the passive observation described here, when one user fails to contact the printer, all hosts on the network observe that failure and update their caches accordingly.
上一节“故障指示时缓存刷新”描述了一种情况，即试图打印的用户发现打印机不再可用。通过实现此处描述的被动观察，当一个用户未能联系打印机时，网络上的所有主机都会观察到该故障并相应地更新其缓存。
All Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255. This is recommended to provide backwards-compatibility with older Multicast DNS queriers (implementing a draft version of this document, posted in February 2004) that check the IP TTL on reception to determine whether the packet originated on the local link. These older queriers discard all packets with TTLs other than 255.
所有多播DNS响应（包括通过单播发送的响应）应在IP TTL设置为255的情况下发送。建议提供与旧的多播DNS查询器（实现本文档的草案版本，发布于2004年2月）的向后兼容性，这些查询器在接收时检查IP TTL，以确定数据包是否源自本地链路。这些较旧的查询器丢弃所有TTL不是255的数据包。
A host sending Multicast DNS queries to a link-local destination address (including the 224.0.0.251 and FF02::FB link-local multicast addresses) MUST only accept responses to that query that originate from the local link, and silently discard any other response packets. Without this check, it could be possible for remote rogue hosts to send spoof answer packets (perhaps unicast to the victim host), which the receiving machine could misinterpret as having originated on the local link.
向链路本地目标地址（包括224.0.0.251和FF02:：FB链路本地多播地址）发送多播DNS查询的主机必须仅接受来自本地链路的对该查询的响应，并以静默方式丢弃任何其他响应数据包。如果没有此检查，远程恶意主机可能会发送欺骗应答数据包（可能是单播到受害主机），接收机器可能会错误地将其解释为源自本地链路。
The test for whether a response originated on the local link is done in two ways:
测试是否在本地链路上发起响应的方法有两种：
* All responses received with a destination address in the IP header that is the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 link-local multicast address FF02::FB are necessarily deemed to have originated on the local link, regardless of source IP address. This is essential to allow devices to work correctly and reliably in unusual configurations, such as multiple logical IP subnets overlayed on a single link, or in cases of severe misconfiguration, where devices are physically connected to the same link, but are currently misconfigured with completely unrelated IP addresses and subnet masks.
* 无论源IP地址如何，IP报头中目标地址为mDNS IPv4链路本地多播地址224.0.0.251或mDNS IPv6链路本地多播地址FF02:：FB的所有响应都必须视为源自本地链路。这对于允许设备在异常配置中正确可靠地工作是至关重要的，例如在单个链路上覆盖多个逻辑IP子网，或者在严重错误配置的情况下，设备物理连接到同一链路，但当前使用完全不相关的IP地址和子网掩码进行错误配置。
* For responses received with a unicast destination address in the IP header, the source IP address in the packet is checked to see if it is an address on a local subnet. An IPv4 source address is determined to be on a local subnet if, for (one of) the address(es) configured on the interface receiving the packet, (I & M) == (P & M), where I and M are the interface address and subnet mask respectively, P is the source IP address from the packet, '&' represents the bitwise logical 'and' operation, and '==' represents a bitwise equality test. An IPv6 source address is determined to be on the local link if, for any of the on-link IPv6 prefixes on the interface receiving the packet (learned via IPv6 router advertisements or otherwise configured on the host), the first 'n' bits of the IPv6 source address match the first 'n' bits of the prefix address, where 'n' is the length of the prefix being considered.
* 对于使用IP报头中的单播目标地址接收的响应，将检查数据包中的源IP地址，以查看它是否是本地子网上的地址。如果对于在接收分组的接口上配置的（一个）地址，（I&M）=（P&M），其中I和M分别是接口地址和子网掩码，P是来自分组的源IP地址，&“表示按位逻辑”和“操作”，则IPv4源地址被确定在本地子网上，和“==”表示按位相等测试。如果对于接收数据包的接口上的任何链路上IPv6前缀（通过IPv6路由器播发或在主机上以其他方式配置），IPv6源地址的前“n”位与前缀地址的前“n”位匹配，则IPv6源地址被确定为位于本地链路上，其中'n'是所考虑前缀的长度。
Since queriers will ignore responses apparently originating outside the local subnet, a responder SHOULD avoid generating responses that it can reasonably predict will be ignored. This applies particularly in the case of overlayed subnets. If a responder receives a query addressed to the mDNS IPv4 link-local multicast address 224.0.0.251, from a source address not apparently on the same subnet as the responder (or, in the case of IPv6, from a source IPv6 address for which the responder does not have any address with the same prefix on that interface), then even if the query indicates that a unicast response is preferred (see Section 5.4, "Questions Requesting Unicast Responses"), the responder SHOULD elect to respond by multicast anyway, since it can reasonably predict that a unicast response with an apparently non-local source address will probably be ignored.
由于查询者将忽略显然源自本地子网之外的响应，因此响应者应避免生成其可以合理预测将被忽略的响应。这尤其适用于重叠子网的情况。如果响应程序从与响应程序显然不在同一子网的源地址（或者，在IPv6情况下，从响应程序在该接口上没有任何具有相同前缀的地址的源IPv6地址）接收到地址为mDNS IPv4链路本地多播地址224.0.0.251的查询，然后，即使查询表明首选单播响应（参见第5.4节“请求单播响应的问题”），响应者仍应选择通过多播进行响应，因为它可以合理地预测具有明显非本地源地址的单播响应可能会被忽略。
Unlike conventional DNS names, names that end in ".local." have only local significance. The same is true of names within the IPv4 link-local reverse mapping domain "254.169.in-addr.arpa." and the IPv6 link-local reverse mapping domains "8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
与传统DNS名称不同，以“.local.”结尾的名称仅具有本地意义。IPv4链路本地反向映射域“254.169.in addr.arpa.”和IPv6链路本地反向映射域“8.e.f.ip6.arpa.”、“9.e.f.ip6.arpa.”、“a.e.f.ip6.arpa.”和“b.e.f.ip6.arpa.”中的名称也是如此。
These names function primarily as protocol identifiers, rather than as user-visible identifiers. Even though they may occasionally be visible to end users, that is not their primary purpose. As such, these names should be treated as opaque identifiers. In particular, the string "local" should not be translated or localized into different languages, much as the name "localhost" is not translated or localized into different languages.
这些名称主要用作协议标识符，而不是用户可见的标识符。即使最终用户偶尔可以看到它们，但这并不是它们的主要目的。因此，这些名称应被视为不透明标识符。特别是，字符串“local”不应翻译或本地化为不同的语言，就像名称“localhost”不应翻译或本地化为不同的语言一样。
Conventional Unicast DNS seeks to provide a single unified namespace, where a given DNS query yields the same answer no matter where on the planet it is performed or to which recursive DNS server the query is sent. In contrast, each IP link has its own private ".local.", "254.169.in-addr.arpa." and IPv6 link-local reverse mapping namespaces, and the answer to any query for a name within those domains depends on where that query is asked. (This characteristic is not unique to Multicast DNS. Although the original concept of DNS was a single global namespace, in recent years, split views, firewalls, intranets, DNS geolocation, and the like have increasingly meant that the answer to a given DNS query has become dependent on the location of the querier.)
传统的单播DNS寻求提供一个统一的名称空间，在该名称空间中，给定的DNS查询产生相同的答案，无论查询在地球上的何处执行，或将查询发送到哪个递归DNS服务器。相反，每个IP链路都有自己的专用“.local.”、“254.169.In addr.arpa.”和IPv6链路本地反向映射名称空间，这些域中的名称查询的答案取决于查询的位置。（此特征并非多播DNS所独有。虽然DNS的最初概念是一个单一的全局命名空间，但近年来，拆分视图、防火墙、内部网、DNS地理位置等越来越多地意味着给定DNS查询的答案取决于查询者的位置。）
The IPv4 name server address for a Multicast DNS domain is 224.0.0.251. The IPv6 name server address for a Multicast DNS domain is FF02::FB. These are multicast addresses; therefore, they identify not a single host but a collection of hosts, working in cooperation to maintain some reasonable facsimile of a competently managed DNS zone. Conceptually, a Multicast DNS domain is a single DNS zone; however, its server is implemented as a distributed process running on a cluster of loosely cooperating CPUs rather than as a single process running on a single CPU.
多播DNS域的IPv4名称服务器地址为224.0.0.251。多播DNS域的IPv6名称服务器地址为FF02:：FB。这些是多播地址；因此，它们识别的不是单个主机，而是一组主机，它们协同工作，以维护一个适当管理的DNS区域的合理传真。从概念上讲，多播DNS域是单个DNS区域；但是，它的服务器实现为一个分布式进程，运行在松散协作的CPU集群上，而不是一个运行在单个CPU上的单个进程。
Multicast DNS domains are not delegated from their parent domain via use of NS (Name Server) records, and there is also no concept of delegation of subdomains within a Multicast DNS domain. Just because a particular host on the network may answer queries for a particular record type with the name "example.local." does not imply anything about whether that host will answer for the name "child.example.local.", or indeed for other record types with the name "example.local.".
多播DNS域不是通过使用NS（名称服务器）记录从其父域委派的，并且在多播DNS域中也没有委派子域的概念。仅仅因为网络上的某个特定主机可能会回答名为“example.local.”的特定记录类型的查询，并不意味着该主机是否会回答名为“child.example.local.”的查询，或者确实会回答名为“example.local.”的其他记录类型的查询。
There are no NS records anywhere in Multicast DNS domains. Instead, the Multicast DNS domains are reserved by IANA, and there is effectively an implicit delegation of all Multicast DNS domains to the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue of client software implementing the protocol rules specified in this document.
在多播DNS域中的任何位置都没有NS记录。相反，多播DNS域由IANA保留，并且借助于实现本文档中指定的协议规则的客户端软件，所有多播DNS域有效地隐式委托给224.0.0.251:5353和[FF02:：FB]：5353多播组。
Multicast DNS zones have no SOA (Start of Authority) record. A conventional DNS zone's SOA record contains information such as the email address of the zone administrator and the monotonically increasing serial number of the last zone modification. There is no single human administrator for any given Multicast DNS zone, so there is no email address. Because the hosts managing any given Multicast DNS zone are only loosely coordinated, there is no readily available monotonically increasing serial number to determine whether or not the zone contents have changed. A host holding part of the shared zone could crash or be disconnected from the network at any time without informing the other hosts. There is no reliable way to provide a zone serial number that would, whenever such a crash or disconnection occurred, immediately change to indicate that the contents of the shared zone had changed.
多播DNS区域没有SOA（授权开始）记录。传统DNS区域的SOA记录包含区域管理员的电子邮件地址和上次区域修改的单调递增的序列号等信息。任何给定的多播DNS区域都没有单一的管理员，因此没有电子邮件地址。由于管理任何给定多播DNS区域的主机只是松散协调的，因此没有现成的单调递增序列号来确定区域内容是否已更改。持有部分共享区域的主机可能随时崩溃或断开与网络的连接，而不通知其他主机。没有可靠的方法提供区域序列号，该序列号在发生此类崩溃或断开连接时会立即更改，以表明共享区域的内容已更改。
Zone transfers are not possible for any Multicast DNS zone.
任何多播DNS区域都不可能进行区域传输。
The option to fail-over to Multicast DNS for names not ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. Enabling Multicast DNS for names not ending in ".local." may be appropriate on a secure isolated network, or on some future network were machines exclusively use DNSSEC for all DNS queries, and have Multicast DNS responders capable of generating the appropriate cryptographic DNSSEC signatures, thereby guarding against spoofing.
对于不以“.local.”结尾的名称，故障切换到多播DNS的选项应为用户配置的选项，并且默认情况下应禁用该选项，因为可能存在与非预期的全局名称本地解析相关的安全问题。为不以“.local.”结尾的名称启用多播DNS可能适用于安全隔离网络，或者在某些未来网络上，计算机专门使用DNSSEC进行所有DNS查询，并且多播DNS响应程序能够生成适当的加密DNSSEC签名，从而防止欺骗。
The option to look up unqualified (relative) names by appending ".local." (or not) is controlled by whether ".local." appears (or not) in the client's DNS search list.
通过附加“.local.”（或否）查找非限定（相对）名称的选项由“.local.”是否出现在客户端的DNS搜索列表中控制。
No special control is needed for enabling and disabling Multicast DNS for names explicitly ending with ".local." as entered by the user. The user doesn't need a way to disable Multicast DNS for names ending with ".local.", because if the user doesn't want to use Multicast DNS, they can achieve this by simply not using those names. If a user *does* enter a name ending in ".local.", then we can safely assume the user's intention was probably that it should work. Having user configuration options that can be (intentionally or
对于用户输入的显式以“.local.”结尾的名称，启用和禁用多播DNS不需要特殊控制。用户不需要为以“.local.”结尾的名称禁用多播DNS，因为如果用户不想使用多播DNS，他们可以通过不使用这些名称来实现这一点。如果用户*确实*输入了一个以“.local.”结尾的名称，那么我们可以放心地假设用户的意图可能是它应该工作。具有用户配置选项，可以（故意或
unintentionally) set so that local names don't work is just one more way of frustrating the user's ability to perform the tasks they want, perpetuating the view that, "IP networking is too complicated to configure and too hard to use".
无意中）设置使本地名称不起作用只是又一种挫败用户执行他们想要的任务的能力的方式，使“IP网络太复杂，无法配置，太难使用”的观点永久化。
A host SHOULD defend its dot-local host name on all active interfaces on which it is answering Multicast DNS queries.
主机应在其应答多播DNS查询的所有活动接口上保护其点本地主机名。
In the event of a name conflict on *any* interface, a host should configure a new host name, if it wishes to maintain uniqueness of its host name.
如果*any*接口上出现名称冲突，主机应配置新的主机名（如果希望保持其主机名的唯一性）。
A host may choose to use the same name (or set of names) for all of its address records on all interfaces, or it may choose to manage its Multicast DNS interfaces independently, potentially answering to a different name (or set of names) on different interfaces.
主机可以选择对其所有接口上的所有地址记录使用相同的名称（或名称集），也可以选择独立管理其多播DNS接口，可能对不同接口上的不同名称（或名称集）进行应答。
Except in the case of proxying and other similar specialized uses, addresses in IPv4 or IPv6 address records in Multicast DNS responses MUST be valid for use on the interface on which the response is being sent.
除代理和其他类似专门用途外，多播DNS响应中IPv4或IPv6地址记录中的地址必须有效，才能在发送响应的接口上使用。
Just as the same link-local IP address may validly be in use simultaneously on different links by different hosts, the same link-local host name may validly be in use simultaneously on different links, and this is not an error. A multihomed host with connections to two different links may be able to communicate with two different hosts that are validly using the same name. While this kind of name duplication should be rare, it means that a host that wants to fully support this case needs network programming APIs that allow applications to specify on what interface to perform a link-local Multicast DNS query, and to discover on what interface a Multicast DNS response was received.
正如不同主机可以在不同链路上同时有效地使用同一链路本地IP地址一样，同一链路本地主机名也可以在不同链路上同时有效地使用，这不是错误。连接到两个不同链路的多宿主机可能能够与有效使用相同名称的两个不同主机通信。虽然这种名称重复应该很少，但这意味着想要完全支持这种情况的主机需要网络编程API，允许应用程序指定在哪个接口上执行链路本地多播DNS查询，并发现在哪个接口上接收到多播DNS响应。
There is one other special precaution that multihomed hosts need to take. It's common with today's laptop computers to have an Ethernet connection and an 802.11 [IEEE.802.11] wireless connection active at the same time. What the software on the laptop computer can't easily tell is whether the wireless connection is in fact bridged onto the same network segment as its Ethernet connection. If the two networks are bridged together, then packets the host sends on one interface will arrive on the other interface a few milliseconds later, and care must be taken to ensure that this bridging does not cause problems:
多宿主主机还需要采取另一种特殊的预防措施。在今天的笔记本电脑中，以太网连接和802.11[IEEE.802.11]无线连接同时处于活动状态是很常见的。笔记本电脑上的软件不容易分辨的是，无线连接实际上是否与以太网连接桥接到同一网段上。如果将两个网络桥接在一起，那么主机在一个接口上发送的数据包将在几毫秒后到达另一个接口，必须小心确保此桥接不会导致问题：
When the host announces its host name (i.e., its address records) on its wireless interface, those announcement records are sent with the cache-flush bit set, so when they arrive on the Ethernet segment, they will cause all the peers on the Ethernet to flush the host's Ethernet address records from their caches. The Multicast DNS protocol has a safeguard to protect against this situation: when records are received with the cache-flush bit set, other records are not deleted from peer caches immediately, but are marked for deletion in one second. When the host sees its own wireless address records arrive on its Ethernet interface, with the cache-flush bit set, this one-second grace period gives the host time to respond and re-announce its Ethernet address records, to reinstate those records in peer caches before they are deleted.
当主机在其无线接口上宣布其主机名（即其地址记录）时，这些宣布记录将与缓存刷新位一起发送，因此当它们到达以太网段时，它们将导致以太网上的所有对等方从其缓存中刷新主机的以太网地址记录。多播DNS协议有一个保护措施来防止这种情况：当接收到带有缓存刷新位设置的记录时，其他记录不会立即从对等缓存中删除，而是在一秒钟内标记为删除。当主机看到自己的无线地址记录到达其以太网接口时，设置了缓存刷新位，这一秒的宽限期使主机有时间响应并重新宣布其以太网地址记录，以便在删除这些记录之前在对等缓存中恢复这些记录。
As described, this solves one problem, but creates another, because when those Ethernet announcement records arrive back on the wireless interface, the host would again respond defensively to reinstate its wireless records, and this process would continue forever, continuously flooding the network with traffic. The Multicast DNS protocol has a second safeguard, to solve this problem: the cache-flush bit does not apply to records received very recently, within the last second. This means that when the host sees its own Ethernet address records arrive on its wireless interface, with the cache-flush bit set, it knows there's no need to re-announce its wireless address records again because it already sent them less than a second ago, and this makes them immune from deletion from peer caches. (See Section 10.2.)
如上所述，这解决了一个问题，但又造成了另一个问题，因为当这些以太网公告记录返回到无线接口时，主机将再次做出防御响应以恢复其无线记录，并且此过程将永远持续，不断地向网络发送大量流量。多播DNS协议还有第二个保护措施来解决这个问题：缓存刷新位不适用于最近在最后一秒钟内收到的记录。这意味着，当主机看到自己的以太网地址记录到达其无线接口时（设置了缓存刷新位），它知道无需再次宣布其无线地址记录，因为它在不到一秒钟之前就已经发送了这些记录，这使它们免于从对等缓存中删除。（见第10.2节。）
It is possible to have more than one Multicast DNS responder and/or querier implementation coexist on the same machine, but there are some known issues.
在同一台机器上可能存在多个多播DNS响应程序和/或查询器实现，但存在一些已知问题。
In most operating systems, incoming *multicast* packets can be delivered to *all* open sockets bound to the right port number, provided that the clients take the appropriate steps to allow this. For this reason, all Multicast DNS implementations SHOULD use the SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as appropriate for the operating system in question) so they will all be able to bind to UDP port 5353 and receive incoming multicast packets addressed to that port. However, unlike multicast packets, incoming unicast UDP packets are typically delivered only to the first socket to bind to that port. This means that "QU" responses and other packets sent via unicast will be received only by the first Multicast DNS responder and/or querier on a system. This limitation can be
在大多数操作系统中，传入的*多播*数据包可以传送到绑定到正确端口号的*所有*开放套接字，前提是客户机采取适当的步骤允许这样做。因此，所有多播DNS实现都应使用SO_REUSEPORT和/或SO_ReuseAdr选项（或适用于相关操作系统的等效选项），以便它们都能够绑定到UDP端口5353并接收发往该端口的传入多播数据包。但是，与多播数据包不同，传入的单播UDP数据包通常只传送到第一个绑定到该端口的套接字。这意味着通过单播发送的“QU”响应和其他数据包将仅由系统上的第一个多播DNS响应器和/或查询器接收。这种限制可以是
partially mitigated if Multicast DNS implementations detect when they are not the first to bind to port 5353, and in that case they do not request "QU" responses. One way to detect if there is another Multicast DNS implementation already running is to attempt binding to port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that fails it indicates that some other socket is already bound to this port.
如果多播DNS实现检测到它们不是第一个绑定到端口5353的，并且在这种情况下它们不请求“QU”响应，则部分缓解。检测是否有另一个多播DNS实现已在运行的一种方法是尝试绑定到端口5353，而不使用SO_REUSEPORT和/或SO_ReuseAdr，如果失败，则表示其他某个套接字已绑定到此端口。
When a Multicast DNS querier issues a query with too many Known Answers to fit into a single packet, it divides the Known-Answer list into two or more packets. Multicast DNS responders associate the initial truncated query with its continuation packets by examining the source IP address in each packet. Since two independent Multicast DNS queriers running on the same machine will be sending packets with the same source IP address, from an outside perspective they appear to be a single entity. If both queriers happened to send the same multipacket query at the same time, with different Known-Answer lists, then they could each end up suppressing answers that the other needs.
当多播DNS查询器发出一个包含太多已知答案的查询而无法放入单个数据包时，它会将已知答案列表分成两个或多个数据包。多播DNS响应程序通过检查每个数据包中的源IP地址，将初始截断查询与其继续数据包相关联。由于在同一台机器上运行的两个独立的多播DNS查询器将发送具有相同源IP地址的数据包，因此从外部角度看，它们似乎是一个实体。如果两个查询器碰巧同时发送相同的多数据包查询，并且具有不同的已知答案列表，那么它们可能最终都会抑制对方需要的答案。
If different clients on a machine were each to have their own independent Multicast DNS implementation, they would lose certain efficiency benefits. Apart from the unnecessary code duplication, memory usage, and CPU load, the clients wouldn't get the benefit of a shared system-wide cache, and they would not be able to aggregate separate queries into single packets to reduce network traffic.
如果一台机器上的不同客户端都有各自独立的多播DNS实现，它们将失去某些效率优势。除了不必要的代码复制、内存使用和CPU负载之外，客户机无法获得共享的系统范围缓存的好处，并且无法将单独的查询聚合到单个数据包中以减少网络流量。
Because of these issues, this document encourages implementers to design systems with a single Multicast DNS implementation that provides Multicast DNS services shared by all clients on that machine, much as most operating systems today have a single TCP implementation, which is shared between all clients on that machine. Due to engineering constraints, there may be situations where embedding a "user-level" Multicast DNS implementation in the client application software is the most expedient solution, and while this will usually work in practice, implementers should be aware of the issues outlined in this section.
由于这些问题，本文档鼓励实施者设计具有单个多播DNS实现的系统，该实现提供该机器上所有客户端共享的多播DNS服务，就像当今大多数操作系统具有单个TCP实现一样，该实现在该机器上的所有客户端之间共享。由于工程限制，可能存在这样的情况，即在客户端应用软件中嵌入“用户级”多播DNS实现是最方便的解决方案，虽然这通常在实践中可行，但实现者应该了解本节中概述的问题。
Historically, Unicast DNS has been used with a very restricted set of characters. Indeed, conventional DNS is usually limited to just twenty-six letters, ten digits and the hyphen character, not even allowing spaces or other punctuation. Attempts to remedy this for Unicast DNS have been badly constrained by the perceived need to accommodate old buggy legacy DNS implementations. In reality, the DNS specification itself actually imposes no limits on what characters may be used in names, and good DNS implementations handle any arbitrary eight-bit data without trouble. "Clarifications to the DNS Specification" [RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that DNS names may contain arbitrary eight-bit data. However, the old rules for ARPANET host names back in the 1980s required host names to be just letters, digits, and hyphens [RFC1034], and since the predominant use of DNS is to store host address records, many have assumed that the DNS protocol itself suffers from the same limitation. It might be accurate to say that there could be hypothetical bad implementations that do not handle eight-bit data correctly, but it would not be accurate to say that the protocol doesn't allow names containing eight-bit data.
过去，单播DNS使用的字符集非常有限。事实上，传统DNS通常仅限于26个字母、10个数字和连字符，甚至不允许使用空格或其他标点符号。为单播DNS解决这一问题的尝试受到了严重的限制，因为人们认为需要适应旧的错误遗留DNS实现。事实上，DNS规范本身实际上对名称中可能使用的字符没有限制，好的DNS实现可以毫无困难地处理任意八位数据。“DNS规范澄清”[RFC2181]直接讨论了第11节（“名称语法”）中允许的字符集主题，并明确指出DNS名称可能包含任意八位数据。然而，早在20世纪80年代，ARPANET主机名的旧规则要求主机名仅为字母、数字和连字符[RFC1034]，而且由于DNS的主要用途是存储主机地址记录，许多人认为DNS协议本身也受到同样的限制。可以准确地说，可能存在无法正确处理八位数据的假设性错误实现，但不能准确地说，协议不允许名称包含八位数据。
Multicast DNS is a new protocol and doesn't (yet) have old buggy legacy implementations to constrain the design choices. Accordingly, it adopts the simple obvious elegant solution: all names in Multicast DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode" [RFC5198] text.
多播DNS是一种新的协议，并且（目前）没有旧的缺陷遗留实现来限制设计选择。因此，它采用了简单而明显的优雅解决方案：多播DNS中的所有名称必须编码为预合成UTF-8[RFC3629]“Net Unicode”[RFC5198]文本。
Some users of 16-bit Unicode have taken to stuffing a "zero-width nonbreaking space" character (U+FEFF) at the start of each UTF-16 file, as a hint to identify whether the data is big-endian or little-endian, and calling it a "Byte Order Mark" (BOM). Since there is only one possible byte order for UTF-8 data, a BOM is neither necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at the start or anywhere else in a Multicast DNS name MUST be interpreted as being an actual intended part of the name, representing (just as for any other legal unicode value) an actual literal instance of that character (in this case a zero-width non-breaking space character).
Some users of 16-bit Unicode have taken to stuffing a "zero-width nonbreaking space" character (U+FEFF) at the start of each UTF-16 file, as a hint to identify whether the data is big-endian or little-endian, and calling it a "Byte Order Mark" (BOM). Since there is only one possible byte order for UTF-8 data, a BOM is neither necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at the start or anywhere else in a Multicast DNS name MUST be interpreted as being an actual intended part of the name, representing (just as for any other legal unicode value) an actual literal instance of that character (in this case a zero-width non-breaking space character).translate error, please retry
For names that are restricted to US-ASCII [RFC0020] letters, digits, and hyphens, the UTF-8 encoding is identical to the US-ASCII encoding, so this is entirely compatible with existing host names. For characters outside the US-ASCII range, UTF-8 encoding is used.
对于限制为US-ASCII[RFC0020]字母、数字和连字符的名称，UTF-8编码与US-ASCII编码相同，因此这与现有主机名完全兼容。对于US-ASCII范围以外的字符，使用UTF-8编码。
Multicast DNS implementations MUST NOT use any other encodings apart from precomposed UTF-8 (US-ASCII being considered a compatible subset of UTF-8). The reasons for selecting UTF-8 instead of Punycode [RFC3492] are discussed further in Appendix F.
多播DNS实现不得使用除预合成UTF-8（US-ASCII被视为UTF-8的兼容子集）之外的任何其他编码。附录F中进一步讨论了选择UTF-8而不是Punycode[RFC3492]的原因。
The simple rules for case-insensitivity in Unicast DNS [RFC1034] [RFC1035] also apply in Multicast DNS; that is to say, in name comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a querier issues a query for an address record with the name "myprinter.local.", then a responder having an address record with the name "MyPrinter.local." should issue a response. No other automatic equivalences should be assumed. In particular, all UTF-8 multibyte characters (codes 0x80 and higher) are compared by simple binary comparison of the raw byte values. Accented characters are *not* defined to be automatically equivalent to their unaccented counterparts. Where automatic equivalences are desired, this may be achieved through the use of programmatically generated CNAME records. For example, if a responder has an address record for an accented name Y, and a querier issues a query for a name X, where X is the same as Y with all the accents removed, then the responder may issue a response containing two resource records: a CNAME record "X CNAME Y", asserting that the requested name X (unaccented) is an alias for the true (accented) name Y, followed by the address record for Y.
单播DNS[RFC1034][RFC1035]中大小写不敏感的简单规则也适用于多播DNS；也就是说，在名称比较中，小写字母“a”到“z”（0x61到0x7A）与其大写等价物“a”到“z”（0x41到0x5A）匹配。因此，如果查询者对名为“myprinter.local.”的地址记录发出查询，则具有名为“myprinter.local.”的地址记录的响应者应发出响应。不应假设其他自动等效。特别是，所有UTF-8多字节字符（代码0x80及更高）都是通过原始字节值的简单二进制比较来比较的。重音字符*未*定义为自动等同于其非重音对应字符。如果需要自动等效，可以通过使用编程生成的CNAME记录来实现。例如，如果响应者有一个带重音的名称Y的地址记录，并且查询者发出一个名称X的查询，其中X与Y相同，且所有重音都已删除，则响应者可能发出一个包含两个资源记录的响应：一个CNAME记录“X CNAME Y”，断言请求的名称X（未带重音）是true的别名（重音）名称Y，后跟Y的地址记录。
The 1987 DNS specification [RFC1035] restricts DNS messages carried by UDP to no more than 512 bytes (not counting the IP or UDP headers). For UDP packets carried over the wide-area Internet in 1987, this was appropriate. For link-local multicast packets on today's networks, there is no reason to retain this restriction. Given that the packets are by definition link-local, there are no Path MTU issues to consider.
1987年的DNS规范[RFC1035]将UDP承载的DNS消息限制为不超过512字节（不包括IP或UDP标头）。对于1987年通过广域网传输的UDP数据包，这是合适的。对于当今网络上的链路本地多播数据包，没有理由保留此限制。由于分组是按定义链接本地的，所以没有路径MTU问题要考虑。
Multicast DNS messages carried by UDP may be up to the IP MTU of the physical interface, less the space required for the IP header (20 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
UDP承载的多播DNS消息可能达到物理接口的IP MTU，减去IP报头（IPv4为20字节；IPv6为40字节）和UDP报头（8字节）所需的空间。
In the case of a single Multicast DNS resource record that is too large to fit in a single MTU-sized multicast response packet, a Multicast DNS responder SHOULD send the resource record alone, in a single IP datagram, using multiple IP fragments. Resource records this large SHOULD be avoided, except in the very rare cases where they really are the appropriate solution to the problem at hand. Implementers should be aware that many simple devices do not reassemble fragmented IP datagrams, so large resource records SHOULD NOT be used except in specialized cases where the implementer knows
如果单个多播DNS资源记录太大，无法装入单个MTU大小的多播响应数据包，则多播DNS响应程序应使用多个IP片段在单个IP数据报中单独发送资源记录。应该避免这么大的资源记录，除非在非常罕见的情况下，它们确实是手头问题的适当解决方案。实现者应该知道，许多简单的设备不会重新组装碎片化的IP数据报，因此，除非在实现者知道的特殊情况下，否则不应使用大型资源记录
that all receivers implement reassembly, or where the large resource record contains optional data which is not essential for correct operation of the client.
所有接收器都实现重新组装，或者大型资源记录包含可选数据，这些数据对于客户端的正确操作不是必需的。
A Multicast DNS packet larger than the interface MTU, which is sent using fragments, MUST NOT contain more than one resource record.
使用片段发送的大于接口MTU的多播DNS数据包不得包含多个资源记录。
Even when fragmentation is used, a Multicast DNS packet, including IP and UDP headers, MUST NOT exceed 9000 bytes.
即使使用分段，多播DNS数据包（包括IP和UDP报头）也不得超过9000字节。
Note that 9000 bytes is also the maximum payload size of an Ethernet "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo" packets are not widely used, so it is advantageous to keep packets under 1500 bytes whenever possible. Even on hosts that normally handle Ethernet "Jumbo" packets and IP fragment reassembly, it is becoming more common for these hosts to implement power-saving modes where the main CPU goes to sleep and hands off packet reception tasks to a more limited processor in the network interface hardware, which may not support Ethernet "Jumbo" packets or IP fragment reassembly.
请注意，9000字节也是以太网“Jumbo”数据包[Jumbo]的最大有效负载大小。然而，在实践中，以太网“巨型”数据包并未得到广泛使用，因此尽可能将数据包保持在1500字节以下是有利的。即使在通常处理以太网“巨型”数据包和IP片段重组的主机上，这些主机也越来越普遍地实施省电模式，其中主CPU进入休眠状态，并将数据包接收任务交给网络接口硬件中更有限的处理器，这可能不支持以太网“巨型”数据包或IP片段重组。
This section describes specific rules pertaining to the allowable values for the header fields of a Multicast DNS message, and other message format considerations.
本节介绍与多播DNS消息头字段的允许值相关的特定规则，以及其他消息格式注意事项。
Multicast DNS implementations SHOULD listen for unsolicited responses issued by hosts booting up (or waking up from sleep or otherwise joining the network). Since these unsolicited responses may contain a useful answer to a question for which the querier is currently awaiting an answer, Multicast DNS implementations SHOULD examine all received Multicast DNS response messages for useful answers, without regard to the contents of the ID field or the Question Section. In Multicast DNS, knowing which particular query message (if any) is responsible for eliciting a particular response message is less interesting than knowing whether the response message contains useful information.
多播DNS实现应侦听主机启动（或从睡眠中醒来或以其他方式加入网络）发出的未经请求的响应。由于这些未经请求的响应可能包含对查询者当前正在等待回答的问题的有用答案，因此多播DNS实现应检查所有接收到的多播DNS响应消息以获得有用答案，而不考虑ID字段或问题部分的内容。在多播DNS中，知道哪个特定的查询消息（如果有的话）负责获取特定的响应消息不如知道响应消息是否包含有用的信息有趣。
Multicast DNS implementations MAY cache data from any or all Multicast DNS response messages they receive, for possible future use, provided of course that normal TTL aging is performed on these cached resource records.
多播DNS实现可以缓存来自它们接收的任何或所有多播DNS响应消息的数据，以备将来可能使用，当然前提是对这些缓存的资源记录执行正常的TTL老化。
In multicast query messages, the Query Identifier SHOULD be set to zero on transmission.
在多播查询消息中，查询标识符在传输时应设置为零。
In multicast responses, including unsolicited multicast responses, the Query Identifier MUST be set to zero on transmission, and MUST be ignored on reception.
在多播响应（包括未经请求的多播响应）中，查询标识符在传输时必须设置为零，在接收时必须忽略。
In legacy unicast response messages generated specifically in response to a particular (unicast or multicast) query, the Query Identifier MUST match the ID from the query message.
在专门为响应特定（单播或多播）查询而生成的传统单播响应消息中，查询标识符必须与查询消息中的ID匹配。
In query messages the QR bit MUST be zero. In response messages the QR bit MUST be one.
在查询消息中，QR位必须为零。在响应消息中，QR位必须为1。
In both multicast query and multicast response messages, the OPCODE MUST be zero on transmission (only standard queries are currently supported over multicast). Multicast DNS messages received with an OPCODE other than zero MUST be silently ignored.
在多播查询和多播响应消息中，操作码在传输时必须为零（当前仅通过多播支持标准查询）。必须静默忽略使用非零操作码接收的多播DNS消息。
In query messages, the Authoritative Answer bit MUST be zero on transmission, and MUST be ignored on reception.
在查询消息中，权威应答位在传输时必须为零，在接收时必须忽略。
In response messages for Multicast domains, the Authoritative Answer bit MUST be set to one (not setting this bit would imply there's some other place where "better" information may be found) and MUST be ignored on reception.
在多播域的响应消息中，权威应答位必须设置为1（不设置此位将意味着在其他地方可以找到“更好”的信息），并且在接收时必须忽略。
In query messages, if the TC bit is set, it means that additional Known-Answer records may be following shortly. A responder SHOULD record this fact, and wait for those additional Known-Answer records, before deciding whether to respond. If the TC bit is clear, it means that the querying host has no additional Known Answers.
在查询消息中，如果设置了TC位，则表示可能很快会出现其他已知应答记录。响应者应该记录这一事实，并等待这些额外的已知答案记录，然后再决定是否响应。如果TC位是清除的，则表示查询主机没有其他已知答案。
In multicast response messages, the TC bit MUST be zero on transmission, and MUST be ignored on reception.
在多播响应消息中，TC位在传输时必须为零，在接收时必须忽略。
In legacy unicast response messages, the TC bit has the same meaning as in conventional Unicast DNS: it means that the response was too large to fit in a single packet, so the querier SHOULD reissue its query using TCP in order to receive the larger response.
在传统单播响应消息中，TC位与传统单播DNS中的含义相同：它意味着响应太大，无法放入单个数据包中，因此查询者应使用TCP重新发出其查询，以便接收更大的响应。
In both multicast query and multicast response messages, the Recursion Desired bit SHOULD be zero on transmission, and MUST be ignored on reception.
在多播查询和多播响应消息中，递归所需位在传输时应为零，在接收时必须忽略。
In both multicast query and multicast response messages, the Recursion Available bit MUST be zero on transmission, and MUST be ignored on reception.
在多播查询和多播响应消息中，递归可用位在传输时必须为零，在接收时必须忽略。
In both query and response messages, the Zero bit MUST be zero on transmission, and MUST be ignored on reception.
在查询和响应消息中，零位在传输时必须为零，在接收时必须忽略。
In both multicast query and multicast response messages, the Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.
在多播查询和多播响应消息中，真实数据位[RFC2535]在传输时必须为零，在接收时必须忽略。
In both multicast query and multicast response messages, the Checking Disabled bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.
在多播查询和多播响应消息中，检查禁用位[RFC2535]在传输时必须为零，在接收时必须忽略。
In both multicast query and multicast response messages, the Response Code MUST be zero on transmission. Multicast DNS messages received with non-zero Response Codes MUST be silently ignored.
在多播查询和多播响应消息中，传输时响应代码必须为零。必须静默忽略使用非零响应代码接收的多播DNS消息。
In the Question Section of a Multicast DNS query, the top bit of the qclass field is used to indicate that unicast responses are preferred for this particular question. (See Section 5.4.)
在多播DNS查询的问题部分中，qclass字段的顶部位用于指示此特定问题首选单播响应。（见第5.4节。）
In the Resource Record Sections of a Multicast DNS response, the top bit of the rrclass field is used to indicate that the record is a member of a unique RRSet, and the entire RRSet has been sent together (in the same packet, or in consecutive packets if there are too many records to fit in a single packet). (See Section 10.2.)
在多播DNS响应的资源记录部分中，rrclass字段的顶部位用于指示该记录是唯一RRSet的成员，并且整个RRSet已一起发送（在同一个数据包中，或者在连续数据包中，如果有太多记录无法容纳在单个数据包中）。（见第10.2节。）
When generating Multicast DNS messages, implementations SHOULD use name compression wherever possible to compress the names of resource records, by replacing some or all of the resource record name with a compact two-byte reference to an appearance of that data somewhere earlier in the message [RFC1035].
在生成多播DNS消息时，实现应尽可能使用名称压缩来压缩资源记录的名称，方法是将部分或全部资源记录名称替换为一个紧凑的双字节引用，以引用消息中较早位置的该数据的外观[RFC1035]。
This applies not only to Multicast DNS responses, but also to queries. When a query contains more than one question, successive questions in the same message often contain similar names, and consequently name compression SHOULD be used, to save bytes. In addition, queries may also contain Known Answers in the Answer Section, or probe tiebreaking data in the Authority Section, and these names SHOULD similarly be compressed for network efficiency.
这不仅适用于多播DNS响应，也适用于查询。当查询包含多个问题时，同一消息中的连续问题通常包含相似的名称，因此应使用名称压缩来保存字节。此外，查询还可能在“答案”部分包含已知答案，或在“权限”部分包含探测分界数据，为了提高网络效率，这些名称也应该进行类似的压缩。
In addition to compressing the *names* of resource records, names that appear within the *rdata* of the following rrtypes SHOULD also be compressed in all Multicast DNS messages:
除了压缩资源记录的*名称*外，还应在所有多播DNS消息中压缩出现在以下RRTYPE的*rdata*中的名称：
NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
NS、CNAME、PTR、DNAME、SOA、MX、AFSDB、RT、KX、RP、PX、SRV、NSEC
Until future IETF Standards Action [RFC5226] specifying that names in the rdata of other types should be compressed, names that appear within the rdata of any type not listed above MUST NOT be compressed.
在未来的IETF标准行动[RFC5226]规定应压缩其他类型的rdata中的名称之前，不得压缩出现在上述未列出的任何类型的rdata中的名称。
Implementations receiving Multicast DNS messages MUST correctly decode compressed names appearing in the Question Section, and compressed names of resource records appearing in other sections.
接收多播DNS消息的实现必须正确解码问题部分中出现的压缩名称，以及其他部分中出现的资源记录的压缩名称。
In addition, implementations MUST correctly decode compressed names appearing within the *rdata* of the rrtypes listed above. Where possible, implementations SHOULD also correctly decode compressed names appearing within the *rdata* of other rrtypes known to the implementers at the time of implementation, because such forward-thinking planning helps facilitate the deployment of future implementations that may have reason to compress those rrtypes. It is possible that no future IETF Standards Action [RFC5226] will be created that mandates or permits the compression of rdata in new types, but having implementations designed such that they are capable of decompressing all known types helps keep future options open.
此外，实现必须正确解码出现在上面列出的RRTYPE的*rdata*中的压缩名称。在可能的情况下，实现还应正确解码在实现时实现者已知的其他RRTYPE的*rdata*中出现的压缩名称，因为这种前瞻性规划有助于促进将来部署可能有理由压缩这些RRTYPE的实现。未来可能不会有任何IETF标准行动[RFC5226]授权或允许以新类型压缩rdata，但设计能够解压缩所有已知类型的实现有助于保持未来选项的开放性。
One specific difference between Unicast DNS and Multicast DNS is that Unicast DNS does not allow name compression for the target host in an SRV record, because Unicast DNS implementations before the first SRV specification in 1996 [RFC2052] may not decode these compressed
单播DNS和多播DNS之间的一个具体区别是，单播DNS不允许在SRV记录中对目标主机进行名称压缩，因为在1996年第一个SRV规范[RFC2052]之前的单播DNS实现可能不会对这些压缩的主机进行解码
records properly. Since all Multicast DNS implementations were created after 1996, all Multicast DNS implementations are REQUIRED to decode compressed SRV records correctly.
正确记录。由于所有多播DNS实现都是在1996年之后创建的，因此所有多播DNS实现都需要正确解码压缩的SRV记录。
In legacy unicast responses generated to answer legacy queries, name compression MUST NOT be performed on SRV records.
在为回答遗留查询而生成的遗留单播响应中，不得对SRV记录执行名称压缩。
Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. There are, of course, necessary differences by virtue of it using multicast, and by virtue of it operating in a community of cooperating peers, rather than a precisely defined hierarchy controlled by a strict chain of formal delegations from the root. These differences are summarized below:
多播DNS尽可能共享单播DNS的熟悉API、命名语法、资源记录类型等。当然，由于它使用多播，并且由于它在合作伙伴社区中运行，而不是由严格的正式授权链从根本上控制的精确定义的层次结构，因此存在必要的差异。这些差异总结如下：
Multicast DNS... * uses multicast * uses UDP port 5353 instead of port 53 * operates in well-defined parts of the DNS namespace * has no SOA (Start of Authority) records * uses UTF-8, and only UTF-8, to encode resource record names * allows names up to 255 bytes plus a terminating zero byte * allows name compression in rdata for SRV and other record types * allows larger UDP packets * allows more than one question in a query message * defines consistent results for qtype "ANY" and qclass "ANY" queries * uses the Answer Section of a query to list Known Answers * uses the TC bit in a query to indicate additional Known Answers * uses the Authority Section of a query for probe tiebreaking * ignores the Query ID field (except for generating legacy responses) * doesn't require the question to be repeated in the response message * uses unsolicited responses to announce new records * uses NSEC records to signal nonexistence of records * defines a unicast-response bit in the rrclass of query questions * defines a cache-flush bit in the rrclass of response records * uses DNS RR TTL 0 to indicate that a record has been deleted * recommends AAAA records in the additional section when responding to rrtype "A" queries, and vice versa * monitors queries to perform Duplicate Question Suppression * monitors responses to perform Duplicate Answer Suppression... * ... and Ongoing Conflict Detection * ... and Opportunistic Caching
多播DNS…*使用多播*使用UDP端口5353而不是端口53*在DNS命名空间的定义良好的部分中运行*没有SOA（授权开始）记录*使用UTF-8，并且只有UTF-8，对资源记录名称进行编码*允许最多255个字节的名称加上终止的零字节*允许SRV和其他记录类型的rdata中的名称压缩*允许更大的UDP数据包*允许查询消息中有多个问题*定义qtype“ANY”和qclass“ANY”的一致结果查询*使用查询的“答案”部分列出已知答案*使用查询中的TC位指示其他已知答案*使用查询的“权限”部分进行探测断开*忽略查询ID字段（生成旧版响应除外）*不要求在响应消息中重复问题*使用未经请求的响应来宣布新记录*使用NSEC记录来表示记录不存在*在查询问题的rrclass中定义单播响应位*在响应记录的rrclass中定义缓存刷新位*使用DNS RR TTL 0指示记录已被删除*在响应rrtype“A”查询时在附加部分中推荐AAAA记录，反之亦然*监视查询以执行重复问题抑制*监视响应以执行重复答案抑制…*。。。以及正在进行的冲突检测*。。。和机会主义缓存
An IPv4-only host and an IPv6-only host behave as "ships that pass in the night". Even if they are on the same Ethernet, neither is aware of the other's traffic. For this reason, each physical link may have *two* unrelated ".local." zones, one for IPv4 and one for IPv6. Since for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments.
仅IPv4主机和仅IPv6主机的行为类似于“夜间通过的船只”。即使它们在同一个以太网上，它们都不知道对方的流量。因此，每个物理链路可能有*两个*不相关的“.local.”区域，一个用于IPv4，一个用于IPv6。由于出于实际目的，同一以太网上的一组仅IPv4主机和一组仅IPv6主机的行为就好像它们在两个完全独立的以太网段上一样，因此它们使用“.local.”区域的情况就不足为奇了，就像它们在两个完全独立的以太网段上一样。
A dual-stack (v4/v6) host can participate in both ".local." zones, and should register its name(s) and perform its lookups both using IPv4 and IPv6. This enables it to reach, and be reached by, both IPv4-only and IPv6-only hosts. In effect, this acts like a multihomed host, with one connection to the logical "IPv4 Ethernet segment", and a connection to the logical "IPv6 Ethernet segment". When such a host generates NSEC records, if it is using the same host name for its IPv4 addresses and its IPv6 addresses on that network interface, its NSEC records should indicate that the host name has both A and AAAA records.
双堆栈（v4/v6）主机可以同时参与“.local.”区域，并且应该注册其名称并使用IPv4和IPv6执行查找。这使它能够访问仅IPv4和仅IPv6的主机，也可以被这些主机访问。实际上，这就像一个多主机主机，一个连接到逻辑“IPv4以太网段”，一个连接到逻辑“IPv6以太网段”。当此类主机生成NSEC记录时，如果其IPv4地址和该网络接口上的IPv6地址使用相同的主机名，则其NSEC记录应表明主机名同时具有a和AAAA记录。
The algorithm for detecting and resolving name conflicts is, by its very nature, an algorithm that assumes cooperating participants. Its purpose is to allow a group of hosts to arrive at a mutually disjoint set of host names and other DNS resource record names, in the absence of any central authority to coordinate this or mediate disputes. In the absence of any higher authority to resolve disputes, the only alternative is that the participants must work together cooperatively to arrive at a resolution.
检测和解决名称冲突的算法本质上是一种假定合作参与者的算法。其目的是在没有任何中央机构协调或调解争议的情况下，允许一组主机获得一组相互不相交的主机名和其他DNS资源记录名。在没有任何更高的权力来解决争端的情况下，唯一的选择是参与者必须共同合作以达成解决方案。
In an environment where the participants are mutually antagonistic and unwilling to cooperate, other mechanisms are appropriate, like manually configured DNS.
在参与者相互对立且不愿合作的环境中，其他机制是合适的，如手动配置的DNS。
In an environment where there is a group of cooperating participants, but clients cannot be sure that there are no antagonistic hosts on the same physical link, the cooperating participants need to use IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can distinguish Multicast DNS messages from trusted participants (which they process as usual) from Multicast DNS messages from untrusted participants (which they silently discard).
在存在一组合作参与者的环境中，但客户端无法确保同一物理链路上没有敌对主机，合作参与者需要使用IPsec签名和/或DNSSEC[RFC4033]签名，以便能够区分多播DNS消息和受信任参与者（他们照常处理）来自不受信任的参与者的多播DNS消息（他们默默地丢弃）。
If DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. This is less critical for names ending with ".local.", because the user should be aware that those names have only local significance and no global authority is implied.
如果将对*全局*DNS名称的DNS查询发送到mDNS多播地址（在中断与更大互联网通信的网络中断期间），则使用DNSSEC*尤其重要，因为用户可能会觉得他或她正在与某个真实主机通信，事实上，他或她实际上是在与当地的某位主持人交流，而该主持人只是伪装成那个名字。对于以“.local.”结尾的名称，这一点不太重要，因为用户应该知道，这些名称仅具有本地意义，并不意味着具有全局权限。
Most computer users neglect to type the trailing dot at the end of a fully qualified domain name, making it a relative domain name (e.g., "www.example.com"). In the event of network outage, attempts to positively resolve the name as entered will fail, resulting in application of the search list, including ".local.", if present. A malicious host could masquerade as "www.example.com." by answering the resulting Multicast DNS query for "www.example.com.local.". To avoid this, a host MUST NOT append the search suffix ".local.", if present, to any relative (partially qualified) host name containing two or more labels. Appending ".local." to single-label relative host names is acceptable, since the user should have no expectation that a single-label host name will resolve as is. However, users who have both "example.com" and "local" in their search lists should be aware that if they type "www" into their web browser, it may not be immediately clear to them whether the page that appears is "www.example.com" or "www.local".
大多数计算机用户忽略了在完全限定域名的末尾键入尾随点，使其成为相对域名（例如，“www.example.com”）。在网络中断的情况下，尝试按输入的名称积极解析将失败，导致应用搜索列表，包括“.local.”（如果存在）。恶意主机可以通过回答“www.example.com.local.”的多播DNS查询伪装成“www.example.com.”。为了避免这种情况，主机不得将搜索后缀“.local.”（如果存在）附加到包含两个或多个标签的任何相对（部分限定）主机名。将“.local.”附加到单标签相对主机名是可以接受的，因为用户不应该期望单标签主机名将按原样解析。但是，在搜索列表中同时包含“example.com”和“local”的用户应该知道，如果他们在web浏览器中键入“www”，他们可能无法立即清楚显示的页面是“www.example.com”还是“www.local”。
Multicast DNS uses UDP port 5353. On operating systems where only privileged processes are allowed to use ports below 1024, no such privilege is required to use port 5353.
多播DNS使用UDP端口5353。在仅允许特权进程使用1024以下端口的操作系统上，使用端口5353不需要此类特权。
IANA has allocated the UDP port 5353 for the Multicast DNS protocol described in this document [SN].
IANA已为本文档[SN]中描述的多播DNS协议分配UDP端口5353。
IANA has allocated the IPv4 link-local multicast address 224.0.0.251 for the use described in this document [MC4].
IANA已将IPv4链路本地多播地址224.0.0.251分配给本文档[MC4]中所述的使用。
IANA has allocated the IPv6 multicast address set FF0X::FB (where "X" indicates any hexadecimal digit from '1' to 'F') for the use described in this document [MC6]. Only address FF02::FB (link-local scope) is currently in use by deployed software, but it is possible that in the future implementers may experiment with Multicast DNS using larger-scoped addresses, such as FF05::FB (site-local scope) [RFC4291].
IANA已将IPv6多播地址集FF0X:：FB（其中“X”表示从“1”到“F”的任何十六进制数字）分配给本文档[MC6]中描述的用途。部署的软件当前仅使用地址FF02:：FB（链路本地作用域），但将来实现者可能会使用更大作用域的地址（如FF05:：FB（站点本地作用域）[RFC4291]）来试验多播DNS。
IANA has implemented the following DNS records:
IANA已实现以下DNS记录：
MDNS.MCAST.NET. IN A 224.0.0.251 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.
MDNS.MCAST.NET。在224.0.0.251 251.0.0.224.IN-ADDR.ARPA中。在PTR MDNS.MCAST.NET中。
Entries for the AAAA and corresponding PTR records have not been made as there is not yet an RFC providing direction for the management of the IP6.ARPA domain relating to the IPv6 multicast address space.
由于还没有RFC为IP6.ARPA域的管理提供与IPv6多播地址空间相关的指导，因此尚未建立AAAA和相应PTR记录的条目。
The reuse of the top bit of the rrclass field in the Question and Resource Record Sections means that Multicast DNS can only carry DNS records with classes in the range 0-32767. Classes in the range 32768 to 65535 are incompatible with Multicast DNS. IANA has noted this fact, and if IANA receives a request to allocate a DNS class value above 32767, IANA will make sure the requester is aware of this implication before proceeding. This does not mean that allocations of DNS class values above 32767 should be denied, only that they should not be allowed until the requester has indicated that they are aware of how this allocation will interact with Multicast DNS. However, to date, only three DNS classes have been assigned by IANA (1, 3, and 4), and only one (1, "Internet") is actually in widespread use, so this issue is likely to remain a purely theoretical one.
重新使用问题和资源记录部分中rrclass字段的顶部位意味着多播DNS只能携带类在0-32767范围内的DNS记录。范围从32768到65535的类与多播DNS不兼容。IANA已经注意到这一事实，如果IANA收到分配高于32767的DNS类值的请求，IANA将确保请求者在继续之前知道这一含义。这并不意味着超过32767的DNS类值的分配应该被拒绝，只是在请求者表示他们知道此分配将如何与多播DNS交互之前，不应该允许这些分配。然而，到目前为止，IANA只分配了三个DNS类（1、3和4），并且只有一个（1，“互联网”）被广泛使用，因此这个问题可能仍然是一个纯粹的理论问题。
IANA has recorded the list of domains below as being Special-Use Domain Names [RFC6761]:
IANA已将以下域列表记录为特殊用途域名[RFC6761]：
.local. .254.169.in-addr.arpa. .8.e.f.ip6.arpa. .9.e.f.ip6.arpa. .a.e.f.ip6.arpa. .b.e.f.ip6.arpa.
地方的254.169.in-addr.arpa。8.e.f.ip6.arpa。9.e.f.ip6.arpa。a、 e.f.ip6.arpa。b、 e.f.ip6.arpa。
The six domains listed above, and any names falling within those domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.", "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the following ways:
上面列出的六个域以及属于这些域的任何名称（例如，“MyPrinter.local.”、“34.12.254.169.in addr.arpa.”、“Ink Jet._pdl-datastream._tcp.local.”）在以下方面是特殊的[RFC6761]：
1. Users may use these names as they would other DNS names, entering them anywhere that they would otherwise enter a conventional DNS name, or a dotted decimal IPv4 address, or a literal IPv6 address.
1. 用户可以像使用其他DNS名称一样使用这些名称，在任何地方输入这些名称，否则将输入常规DNS名称、点十进制IPv4地址或文字IPv6地址。
Since there is no central authority responsible for assigning dot-local names, and all devices on the local network are equally entitled to claim any dot-local name, users SHOULD be
由于没有负责分配dot本地名称的中央机构，并且本地网络上的所有设备都有权要求任何dot本地名称，因此用户应
aware of this and SHOULD exercise appropriate caution. In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.local" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information. As always with networking, end-to-end cryptographic security can be a useful tool. For example, when connecting with ssh, the ssh host key verification process will inform the user if it detects that the identity of the entity they are communicating with has changed since the last time they connected to that name.
意识到这一点，应采取适当的谨慎措施。在不受信任或不熟悉的网络环境中，用户应该意识到，使用“www.local”这样的名称实际上可能无法将他们连接到他们期望的网站，并且可能很容易将他们连接到不同的网页，甚至是伪造或欺骗他们的预期网站，目的是欺骗他们泄露机密信息。与网络一样，端到端加密安全性可能是一个有用的工具。例如，当连接到ssh时，ssh主机密钥验证过程将通知用户，如果它检测到他们正在与之通信的实体的标识自上次连接到该名称以来已发生更改。
2. Application software may use these names as they would other similar DNS names, and is not required to recognize the names and treat them specially. Due to the relative ease of spoofing dot-local names, end-to-end cryptographic security remains important when communicating across a local network, just as it is when communicating across the global Internet.
2. 应用软件可以像使用其他类似DNS名称一样使用这些名称，并且不需要识别这些名称并对其进行特殊处理。由于欺骗点本地名称相对容易，因此当通过本地网络进行通信时，端到端加密安全仍然很重要，就像在全球互联网上进行通信一样。
3. Name resolution APIs and libraries SHOULD recognize these names as special and SHOULD NOT send queries for these names to their configured (unicast) caching DNS server(s). This is to avoid unnecessary load on the root name servers and other name servers, caused by queries for which those name servers do not have useful non-negative answers to give, and will not ever have useful non-negative answers to give.
3. 名称解析API和库应将这些名称识别为特殊名称，并且不应向其配置的（单播）缓存DNS服务器发送对这些名称的查询。这是为了避免在根名称服务器和其他名称服务器上产生不必要的负载，这是由于这些名称服务器没有有用的非否定答案可以给出，并且永远不会有有用的非否定答案可以给出的查询所导致的。
4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries they may receive (from misbehaving name resolver libraries). This is to avoid unnecessary load on the root name servers and other name servers.
4. 缓存DNS服务器应将这些名称识别为特殊名称，并且不应尝试查找这些名称的NS记录，或以其他方式查询权威DNS服务器以尝试解析这些名称。相反，缓存DNS服务器应该为它们可能接收到的所有此类查询（从行为不端的名称解析程序库）生成即时的NXDOMAIN响应。这是为了避免根名称服务器和其他名称服务器上不必要的负载。
5. Authoritative DNS servers SHOULD NOT by default be configurable to answer queries for these names, and, like caching DNS servers, SHOULD generate immediate NXDOMAIN responses for all such queries they may receive. DNS server software MAY provide a configuration option to override this default, for testing purposes or other specialized uses.
5. 默认情况下，权威DNS服务器不应配置为回答这些名称的查询，并且，与缓存DNS服务器一样，应该为它们可能接收到的所有此类查询生成即时域响应。DNS服务器软件可以提供一个配置选项来覆盖此默认值，以用于测试或其他专门用途。
6. DNS server operators SHOULD NOT attempt to configure authoritative DNS servers to act as authoritative for any of these names. Configuring an authoritative DNS server to act as authoritative for any of these names may not, in many cases,
6. DNS服务器运营商不应尝试将权威DNS服务器配置为这些名称的权威服务器。在许多情况下，将权威DNS服务器配置为作为这些名称的权威服务器可能不会，
yield the expected result. Since name resolver libraries and caching DNS servers SHOULD NOT send queries for those names (see 3 and 4 above), such queries SHOULD be suppressed before they even reach the authoritative DNS server in question, and consequently it will not even get an opportunity to answer them.
产生预期的结果。由于名称解析程序库和缓存DNS服务器不应发送对这些名称的查询（请参见上面的3和4），因此在这些查询到达相关的权威DNS服务器之前，应该抑制这些查询，因此，它甚至没有机会回答这些查询。
7. DNS Registrars MUST NOT allow any of these names to be registered in the normal way to any person or entity. These names are reserved protocol identifiers with special meaning and fall outside the set of names available for allocation by registrars. Attempting to allocate one of these names as if it were a normal domain name will probably not work as desired, for reasons 3, 4, and 6 above.
7. DNS注册商不得允许以正常方式向任何个人或实体注册这些名称中的任何一个。这些名称是具有特殊含义的保留协议标识符，不属于注册器可分配的名称集。由于上述原因3、4和6，试图将这些名称中的一个作为普通域名进行分配可能无法正常工作。
The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti, Pekka Savola, Robby Simpson, 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. Special thanks also to Kerry Lynn for converting the document to xml2rfc form in May 2010, and to Area Director Ralph Droms for shepherding the document through its final steps.
在Ran Atkinson、Richard Brown、Freek Dijkstra、Erik Guttman、Kyle McKay、Pasi Sarolahti、Pekka Savola、Robby Simpson、Mark Townsley、Paul Vixie、Bill Woodcock和其他人的帮助下，对本文件中描述的概念进行了探索、开发和实施。特别感谢Bob Bradley、Josh Graessley、Scott Herscher、Rory McGuire、Roger Pantos和Kiren Sekar的重要贡献。还特别感谢Kerry Lynn在2010年5月将文档转换为xml2rfc格式，并感谢区域总监Ralph Droms指导文档完成最后的步骤。
[MC4] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses/>.
[MC4]IANA，“IPv4多播地址空间注册表”<http://www.iana.org/assignments/multicast-addresses/>.
[MC6] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ ipv6-multicast-addresses/>.
[MC6]IANA，“IPv6多播地址空间注册表”<http://www.iana.org/assignments/ ipv6多播地址/>。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020]Cerf，V.，“网络交换的ASCII格式”，RFC 20，1969年10月。
[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月。
[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月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[RFC6195]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 61952011年3月。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013.
[RFC6761]Cheshire，S.和M.Krochmal，“特殊用途域名”，RFC 67612013年2月。
[SN] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers/>.
[SN]IANA，“服务名称和传输协议端口号注册表”<http://www.iana.org/assignments/ 服务名称端口号/>。
[B4W] "Bonjour for Windows", <http://en.wikipedia.org/wiki/Bonjour_(software)>.
[B4W]“你好，Windows版”<http://en.wikipedia.org/wiki/Bonjour_（软件）>。
[BJ] Apple Bonjour Open Source Software, <http://developer.apple.com/bonjour/>.
[BJ]苹果早安开源软件<http://developer.apple.com/bonjour/>.
[IEEE.802.3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008, <http://standards.ieee.org/getieee802/802.3.html>.
[IEEE.802.3]“信息技术-系统间电信和信息交换-局域网和城域网-特定要求-第3部分：带冲突检测的载波侦听多址接入（CMSA/CD）接入方法和物理层规范”，IEEE标准802.3-2008，2008年12月， <http://standards.ieee.org/getieee802/802.3.html>.
[IEEE.802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2007, June 2007, <http://standards.ieee.org/getieee802/802.11.html>.
[IEEE.802.11]“信息技术-系统间电信和信息交换-局域网和城域网-特定要求-第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-2007，2007年6月<http://standards.ieee.org/getieee802/802.11.html>.
[Jumbo] "Ethernet Jumbo Frames", November 2009, <http://www.ethernetalliance.org/library/whitepaper/ ethernet-jumbo-frames/>.
[Jumbo]“以太网巨型帧”，2009年11月<http://www.ethernetalliance.org/library/whitepaper/ 以太网巨型帧/>。
[NIAS] Cheshire, S. "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001.
[NIAS]柴郡，S.“使用DNS发现抽象服务的命名实例”，正在进行的工作，2001年7月。
[NSD] "NsdManager | Android Developer", June 2012, <http://developer.android.com/reference/ android/net/nsd/NsdManager.html>.
[NSD]“NsdManager | Android开发者”，2012年6月<http://developer.android.com/reference/ android/net/nsd/NsdManager.html>。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052]Gulbrandsen，A.和P.Vixie，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2052，1996年10月。
[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月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake 3rd，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[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月。
[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月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[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月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[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月。
[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月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
[Zeroconf]Cheshire，S.和D.Steinberg，“零配置网络：最终指南”，O'Reilly Media，Inc.，ISBN 0-596-10100-7，2005年12月。
Arguments were made for and against using UDP port 53, the standard Unicast DNS port. Some of the arguments are given below. The arguments for using a different port were greater in number and more compelling, so that option was ultimately selected. The UDP port "5353" was selected for its mnemonic similarity to "53".
对使用UDP端口53（标准单播DNS端口）提出了赞成和反对的论据。下面给出了一些论点。使用不同端口的理由数量更多，也更具说服力，因此最终选择了该选项。选择UDP端口“5353”是因为其助记符与“53”相似。
Arguments for using UDP port 53:
使用UDP端口53的参数：
* This is "just DNS", so it should be the same port.
* 这是“DNS”，所以它应该是同一个端口。
* There is less work to be done updating old resolver libraries to do simple Multicast DNS queries. Only the destination address need be changed. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251 to a configuration file.
* 更新旧的解析器库以执行简单的多播DNS查询所需的工作较少。只需要更改目标地址。在某些情况下，只需将地址224.0.0.251添加到配置文件中，就可以在不更改任何代码的情况下实现这一点。
Arguments for using a different port (UDP port 5353):
使用不同端口（UDP端口5353）的参数：
* This is not "just DNS". This is a DNS-like protocol, but different.
* 这不仅仅是DNS。这是一个类似DNS的协议，但不同。
* Changing resolver library code to use a different port number is not hard. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251:5353 to a configuration file.
* 更改解析器库代码以使用不同的端口号并不困难。在某些情况下，只需将地址224.0.0.251:5353添加到配置文件中，就可以在不更改任何代码的情况下实现这一点。
* Using the same port number makes it hard to run a Multicast DNS responder and a conventional Unicast DNS server on the same machine. If a conventional Unicast DNS server wishes to implement Multicast DNS as well, it can still do that, by opening two sockets. Having two different port numbers allows this flexibility.
* 使用相同的端口号会使多播DNS响应程序和传统的单播DNS服务器难以在同一台机器上运行。如果传统的单播DNS服务器也希望实现多播DNS，它仍然可以通过打开两个套接字来实现。拥有两个不同的端口号允许这种灵活性。
* Some VPN software hijacks all outgoing traffic to port 53 and redirects it to a special DNS server set up to serve those VPN clients while they are connected to the corporate network. It is questionable whether this is the right thing to do, but it is common, and redirecting link-local multicast DNS packets to a remote server rarely produces any useful results. It does mean, for example, that a user of such VPN software becomes unable to access their local network printer sitting on their desk right next to their computer. Using a different UDP port helps avoid this particular problem.
* 一些VPN软件劫持所有发送到端口53的流量，并将其重定向到一个特殊的DNS服务器，该服务器设置为在这些VPN客户端连接到公司网络时为其提供服务。这样做是否正确值得怀疑，但这很常见，将链路本地多播DNS数据包重定向到远程服务器很少产生任何有用的结果。例如，这确实意味着，使用这种VPN软件的用户将无法访问坐在电脑旁边桌子上的本地网络打印机。使用不同的UDP端口有助于避免此特定问题。
* On many operating systems, unprivileged software may not send or receive packets on low-numbered ports. This means that any software sending or receiving Multicast DNS packets on port 53 would have to run as "root", which is an undesirable security risk. Using a higher-numbered UDP port avoids this restriction.
* 在许多操作系统上，非特权软件可能无法在编号较低的端口上发送或接收数据包。这意味着在端口53上发送或接收多播DNS数据包的任何软件都必须以“root”身份运行，这是一种不希望出现的安全风险。使用编号更高的UDP端口可以避免此限制。
Some discovery protocols use a range of multicast addresses, and determine the address to be used by a hash function of the name being sought. Queries are sent via multicast to the address as indicated by the hash function, and responses are returned to the querier via unicast. Particularly in IPv6, where multicast addresses are extremely plentiful, this approach is frequently advocated. For example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor Solicitation messages to the "solicited-node multicast address", which is computed as a function of the solicited IPv6 address.
一些发现协议使用一系列多播地址，并确定要被搜索名称的哈希函数使用的地址。查询通过多播发送到哈希函数指示的地址，响应通过单播返回给查询者。特别是在IPv6中，多播地址非常丰富，这种方法经常被提倡。例如，IPv6邻居发现[RFC4861]将邻居请求消息发送到“请求的节点多播地址”，该地址作为请求的IPv6地址的函数计算。
There are some disadvantages to using hashed multicast addresses like this in a service discovery protocol:
在服务发现协议中使用这样的哈希多播地址有一些缺点：
* When a host has a large number of records with different names, the host may have to join a large number of multicast groups. Each time a host joins or leaves a multicast group, this results in Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) traffic on the network announcing this fact. Joining a large number of multicast groups can place undue burden on the Ethernet hardware, which typically supports a limited number of multicast addresses efficiently. When this number is exceeded, the Ethernet hardware may have to resort to receiving all multicasts and passing them up to the host networking code for filtering in software, thereby defeating much of the point of using a multicast address range in the first place. Finally, many IPv6 stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply fails with an error if a client attempts to exceed this limit. Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
* 当主机具有大量具有不同名称的记录时，主机可能必须加入大量多播组。每次主机加入或离开多播组时，都会导致网络上的Internet组管理协议（IGMP）或多播侦听器发现（MLD）流量宣布这一事实。加入大量多播组会给以太网硬件带来不必要的负担，以太网硬件通常有效地支持有限数量的多播地址。当超过此数字时，以太网硬件可能不得不接收所有多播并将其传递给主机网络代码，以便在软件中进行过滤，从而在很大程度上挫败了首先使用多播地址范围的目的。最后，许多IPv6协议栈都有一个固定的IPv6_MAX_成员限制，如果客户端试图超过这个限制，代码就会失败并出错。IPV6_MAX_成员身份的通用值为20或31。
* Multiple questions cannot be placed in one packet if they don't all hash to the same multicast address.
* 如果多个问题没有全部散列到同一个多播地址，则不能将它们放在一个数据包中。
* Duplicate Question Suppression doesn't work if queriers are not seeing each other's queries.
* 如果查询者没有看到彼此的查询，则重复问题抑制不起作用。
* Duplicate Answer Suppression doesn't work if responders are not seeing each other's responses.
* 如果应答者看不到对方的应答，重复应答抑制就不起作用。
* Opportunistic Caching doesn't work.
* 机会主义缓存不起作用。
* Ongoing Conflict Detection doesn't work.
* 正在进行的冲突检测不起作用。
Multicast DNS names may be up to 255 bytes long (in the on-the-wire message format), not counting the terminating zero byte at the end.
多播DNS名称的长度可能高达255字节（采用在线消息格式），不包括结尾处的终止零字节。
"Domain Names - Implementation and Specification" [RFC1035] says:
“域名-实现和规范”[RFC1035]中说：
Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental.
DNS中的各种对象和参数都有大小限制。它们列在下面。有些很容易改变，有些则更基本。
labels 63 octets or less
标签为63个八位字节或更少
names 255 octets or less
名称不超过255个八位字节
...
...
the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
域名的总长度（即标签八位字节和标签长度八位字节）限制为255个八位字节或更少。
This text does not state whether this 255-byte limit includes the terminating zero at the end of every name.
此文本不说明此255字节限制是否包括每个名称末尾的终止零。
Several factors lead us to conclude that the 255-byte limit does *not* include the terminating zero:
有几个因素导致我们得出结论，255字节的限制*不*包括终止零：
o It is common in software engineering to have size limits that are a power of two, or a multiple of a power of two, for efficiency. For example, an integer on a modern processor is typically 2, 4, or 8 bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor is it to most people a particularly noteworthy number. It is noteworthy to computer scientists for only one reason -- because it is exactly one *less* than a power of two. When a size limit is exactly one less than a power of two, that suggests strongly that the one extra byte is being reserved for some specific reason -- in this case reserved, perhaps, to leave room for a terminating zero at the end.
o 在软件工程中，为了提高效率，通常会将大小限制为二的幂或二的幂的倍数。例如，现代处理器上的整数通常是2、4或8字节，而不是3或5字节。255不是二的幂，对大多数人来说也不是一个特别值得注意的数字。计算机科学家之所以注意到这一点，只有一个原因——因为它正好比二的幂小一倍。当一个大小限制正好是2的幂减1时，这就强烈地表明额外的一个字节是出于某种特定的原因而保留的——在这种情况下，保留可能是为了给末尾的终止零留出空间。
o In the case of DNS label lengths, the stated limit is 63 bytes. As with the total name length, this limit is exactly one less than a power of two. This label length limit also excludes the label length byte at the start of every label. Including that extra byte, a 63-byte label takes 64 bytes of space in memory or in a DNS message.
o 对于DNS标签长度，规定的限制为63字节。与总名称长度一样，此限制正好比2的幂小1。此标签长度限制还排除每个标签开头的标签长度字节。包括那个额外的字节，一个63字节的标签在内存或DNS消息中占用64字节的空间。
o It is common in software engineering for the semantic "length" of an object to be one less than the number of bytes it takes to store that object. For example, in C, strlen("foo") is 3, but sizeof("foo") (which includes the terminating zero byte at the end) is 4.
o 在软件工程中，对象的语义“长度”通常比存储该对象所需的字节数少一个。例如，在C语言中，strlen（“foo”）是3，但sizeof（“foo”）（包括结尾的终止零字节）是4。
o The text describing the total length of a domain name mentions explicitly that label length and data octets are included, but does not mention the terminating zero at the end. The zero byte at the end of a domain name is not a label length. Indeed, the value zero is chosen as the terminating marker precisely because it is not a legal length byte value -- DNS prohibits empty labels. For example, a name like "bad..name." is not a valid domain name because it contains a zero-length label in the middle, which cannot be expressed in a DNS message, because software parsing the message would misinterpret a zero label-length byte as being a zero "end of name" marker instead.
o 描述域名总长度的文本明确提到包括标签长度和数据八位字节，但没有提到末尾的终止零。域名末尾的零字节不是标签长度。实际上，选择值0作为终止标记正是因为它不是合法长度的字节值——DNS禁止空标签。例如，一个名为“坏….No.”的域名不是有效的域名，因为它在中间包含一个零长度标签，它不能用DNS消息来表达，因为软件解析该消息会将零标签长度字节误译为零的“名称结束”标记。
Finally, "Clarifications to the DNS Specification" [RFC2181] offers additional confirmation that, in the context of DNS specifications, the stated "length" of a domain name does not include the terminating zero byte at the end. That document refers to the root name, which is typically written as "." and is represented in a DNS message by a single lone zero byte (i.e., zero bytes of data plus a terminating zero), as the "zero length full name":
最后，“对DNS规范的澄清”[RFC2181]提供了额外的确认，即在DNS规范的上下文中，所述域名的“长度”不包括结尾处的终止零字节。该文档引用根名称，该名称通常写为“”，并在DNS消息中由一个单独的零字节（即零字节的数据加上一个终止的零）表示为“零长度全名”：
The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".".
长度为零的全名定义为表示DNS树的根，通常写入并显示为“”。
This wording supports the interpretation that, in a DNS context, when talking about lengths of names, the terminating zero byte at the end is not counted. If the root name (".") is considered to be zero length, then to be consistent, the length (for example) of "org" has to be 4 and the length of "ietf.org" has to be 9, as shown below:
该措辞支持这样的解释，即在DNS上下文中，当谈论名称的长度时，末尾终止的零字节不被计算在内。如果根名称（“.”）被认为是零长度，那么为了保持一致，“org”的长度（例如）必须是4，“ietf.org”的长度必须是9，如下所示：
------
| 0x00 | length = 0
------
------
| 0x00 | length = 0
------
------------------ ------
| 0x03 | o | r | g | | 0x00 | length = 4
------------------ ------
------------------ ------
| 0x03 | o | r | g | | 0x00 | length = 4
------------------ ------
----------------------------------------- ------
| 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
----------------------------------------- ------
----------------------------------------- ------
| 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
----------------------------------------- ------
This means that the maximum length of a domain name, as represented in a Multicast DNS message, up to but not including the final terminating zero, must not exceed 255 bytes.
这意味着多播DNS消息中表示的域名的最大长度（不包括最终终止零）不得超过255字节。
However, many Unicast DNS implementers have read these RFCs differently, and argue that the 255-byte limit does include the terminating zero, and that the "Clarifications to the DNS Specification" [RFC2181] statement that "." is the "zero length full name" was simply a mistake.
然而，许多单播DNS实现者对这些RFC的理解不同，他们认为255字节的限制确实包括终止零，并且“DNS规范澄清”[RFC2181]声明“.”是“零长度全名”只是一个错误。
Hence, implementers should be aware that other Unicast DNS implementations may limit the maximum domain name to 254 bytes plus a terminating zero, depending on how that implementer interpreted the DNS specifications.
因此，实现者应该知道，其他单播DNS实现可能会将最大域名限制为254字节加上终止零，这取决于该实现者如何解释DNS规范。
Compliant Multicast DNS implementations MUST support names up to 255 bytes plus a terminating zero, i.e., 256 bytes total.
兼容的多播DNS实现必须支持最多255个字节的名称加上终止零，即总共256个字节。
Some people have argued that sending responses via multicast is inefficient on the network. In fact, using multicast responses can result in a net lowering of overall multicast traffic for a variety of reasons, and provides other benefits too:
一些人认为通过多播发送响应在网络上效率低下。事实上，由于各种原因，使用多播响应可以导致整体多播通信量的净降低，并提供其他好处：
* Opportunistic Caching. One multicast response can update the caches on all machines on the network. If another machine later wants to issue the same query, and it already has the answer in its cache, it may not need to even transmit that multicast query on the network at all.
* 机会主义缓存。一个多播响应可以更新网络上所有机器上的缓存。如果另一台机器以后想要发出相同的查询，并且它的缓存中已经有了答案，那么它甚至可能根本不需要在网络上传输该多播查询。
* Duplicate Query Suppression. When more than one machine has the same ongoing long-lived query running, every machine does not have to transmit its own independent query. When one machine transmits a query, all the other hosts see the answers, so they can suppress their own queries.
* 重复查询抑制。当多台机器运行相同的长期查询时，每台机器不必传输自己的独立查询。当一台机器传输查询时，所有其他主机都会看到答案，因此它们可以抑制自己的查询。
* Passive Observation Of Failures (POOF). When a host sees a multicast query, but does not see the corresponding multicast response, it can use this information to promptly delete stale data from its cache. To achieve the same level of user-interface quality and responsiveness without multicast responses would require lower cache lifetimes and more frequent network polling, resulting in a higher packet rate.
* 故障被动观察（POOF）。当主机看到一个多播查询，但没有看到相应的多播响应时，它可以使用此信息立即从其缓存中删除过时的数据。要在没有多播响应的情况下实现相同级别的用户界面质量和响应能力，需要较低的缓存生存时间和更频繁的网络轮询，从而提高数据包速率。
* Passive Conflict Detection. Just because a name has been previously verified to be unique does not guarantee it will continue to be so indefinitely. By allowing all Multicast DNS
* 被动冲突检测。仅仅因为一个名称之前已被验证为唯一的，并不保证它将无限期地保持唯一。通过允许所有多播DNS
responders to constantly monitor their peers' responses, conflicts arising out of network topology changes can be promptly detected and resolved. If responses were not sent via multicast, some other conflict detection mechanism would be needed, imposing its own additional burden on the network.
响应者持续监控其对等方的响应，可以及时检测和解决因网络拓扑变化而产生的冲突。如果响应不是通过多播发送的，则需要其他一些冲突检测机制，从而给网络带来额外的负担。
* Use on devices with constrained memory resources: When using delayed responses to reduce network collisions, responders need to maintain a list recording to whom each answer should be sent. The option of multicast responses allows responders with limited storage, which cannot store an arbitrarily long list of response addresses, to choose to fail-over to a single multicast response in place of multiple unicast responses, when appropriate.
* 在内存资源受限的设备上使用：当使用延迟响应来减少网络冲突时，响应者需要维护一个列表记录每个响应应该发送给谁。多播响应选项允许存储有限的响应者（不能存储任意长的响应地址列表）选择故障切换到单个多播响应，以代替多个单播响应（如果适用）。
* Overlayed Subnets. In the case of overlayed subnets, multicast responses allow a receiver to know with certainty that a response originated on the local link, even when its source address may apparently suggest otherwise.
* 重叠子网。在覆盖子网的情况下，多播响应允许接收机确定响应源自本地链路，即使其源地址可能明显表明并非如此。
* Robustness in the face of misconfiguration: Link-local multicast transcends virtually every conceivable network misconfiguration. Even if you have a collection of devices where every device's IP address, subnet mask, default gateway, and DNS server address are all wrong, packets sent by any of those devices addressed to a link-local multicast destination address will still be delivered to all peers on the local link. This can be extremely helpful when diagnosing and rectifying network problems, since it facilitates a direct communication channel between client and server that works without reliance on ARP, IP routing tables, etc. Being able to discover what IP address a device has (or thinks it has) is frequently a very valuable first step in diagnosing why it is unable to communicate on the local network.
* 面对错误配置时的健壮性：链路本地多播几乎超越了所有可能的网络错误配置。即使您有一个设备集合，其中每个设备的IP地址、子网掩码、默认网关和DNS服务器地址都是错误的，由这些设备中的任何一个发送到链路本地多播目标地址的数据包仍将传递到本地链路上的所有对等方。这在诊断和纠正网络问题时非常有用，因为它有助于客户机和服务器之间的直接通信通道，不依赖ARP、IP路由表等，能够发现设备拥有（或认为拥有）什么IP地址在诊断it无法在本地网络上通信的原因时，通常是非常有价值的第一步。
Alternative methods of asserting nonexistence were considered, such as using an NXDOMAIN response, or emitting a resource record with zero-length rdata.
我们考虑了断言不存在的替代方法，例如使用NXDOMAIN响应，或者使用零长度rdata发送资源记录。
Using an NXDOMAIN response does not work well with Multicast DNS. A Unicast DNS NXDOMAIN response applies to the entire message, but for efficiency Multicast DNS allows (and encourages) multiple responses in a single message. If the error code in the header were NXDOMAIN, it would not be clear to which name(s) that error code applied.
使用NXDOMAIN响应无法与多播DNS配合使用。单播DNS域响应适用于整个消息，但为了提高效率，多播DNS允许（并鼓励）在单个消息中进行多个响应。如果标头中的错误代码是NXDOMAIN，则不清楚该错误代码应用于哪个名称。
Asserting nonexistence by emitting a resource record with zero-length rdata would mean that there would be no way to differentiate between a record that doesn't exist, and a record that does exist, with zero-
通过发出长度为零的rdata的资源记录来断言不存在意味着无法区分不存在的记录和确实存在的记录-
length rdata. By analogy, most file systems today allow empty files, so a file that exists with zero bytes of data is not considered equivalent to a filename that does not exist.
长度rdata。通过类比，当今大多数文件系统都允许空文件，因此，存在零字节数据的文件并不等同于不存在的文件名。
A benefit of asserting nonexistence through NSEC records instead of through NXDOMAIN responses is that NSEC records can be added to the Additional Section of a DNS response to offer additional information beyond what the querier explicitly requested. For example, in response to an SRV query, a responder should include A record(s) giving its IPv4 addresses in the Additional Section, and an NSEC record indicating which other types it does or does not have for this name. If the responder is running on a host that does not support IPv6 (or does support IPv6 but currently has no IPv6 address on that interface) then this NSEC record in the Additional Section will indicate this absence of AAAA records. In effect, the responder is saying, "Here's my SRV record, and here are my IPv4 addresses, and no, I don't have any IPv6 addresses, so don't waste your time asking". Without this information in the Additional Section, it would take the querier an additional round-trip to perform an additional query to ascertain that the target host has no AAAA records. (Arguably Unicast DNS could also benefit from this ability to express nonexistence in the Additional Section, but that is outside the scope of this document.)
通过NSEC记录而不是通过NXDOMAIN响应断言不存在的好处是，可以将NSEC记录添加到DNS响应的附加部分，以提供查询者明确请求之外的附加信息。例如，响应SRV查询时，响应程序应在附加部分中包含一条记录，给出其IPv4地址，以及一条NSEC记录，指示其是否具有该名称的其他类型。如果响应程序运行在不支持IPv6（或支持IPv6但当前该接口上没有IPv6地址）的主机上，则附加部分中的此NSEC记录将指示缺少AAAA记录。实际上，响应者说，“这是我的SRV记录，这是我的IPv4地址，不，我没有任何IPv6地址，所以不要浪费时间询问。”。如果附加部分中没有此信息，查询者将需要额外的往返来执行附加查询，以确定目标主机没有AAAA记录。（可以说，单播DNS也可以受益于在附加部分中表示不存在的功能，但这超出了本文档的范围。）
After many years of debate, as a result of the perceived need to accommodate certain DNS implementations that apparently couldn't handle any character that's not a letter, digit, or hyphen (and apparently never would be updated to remedy this limitation), the Unicast DNS community settled on an extremely baroque encoding called "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding solution, but it is complicated, hard to understand, and hard to implement, using sophisticated techniques including insertion unsort coding, generalized variable-length integers, and bias adaptation. The resulting encoding is remarkably compact given the constraints, but it's still not as good as simple straightforward UTF-8, and it's hard even to predict whether a given input string will encode to a Punycode string that fits within DNS's 63-byte limit, except by simply trying the encoding and seeing whether it fits. Indeed, the encoded size depends not only on the input characters, but on the order they appear, so the same set of characters may or may not encode to a legal Punycode string that fits within DNS's 63-byte limit, depending on the order the characters appear. This is extremely hard to present in a user interface that explains to users why one name is allowed, but another name containing the exact same characters is not. Neither Punycode nor any other of the "ASCII-Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
经过多年的争论，由于人们认为需要适应某些DNS实现，这些实现显然无法处理任何非字母、数字或连字符的字符（而且显然永远不会更新以弥补此限制），单播DNS社区决定采用一种称为“Punycode”的极为巴洛克式编码[RFC3492]. Punycode是一个非常巧妙的编码解决方案，但它非常复杂，难以理解，也难以实现，使用了复杂的技术，包括插入反排序编码、广义变长整数和偏差自适应。考虑到约束条件，结果编码非常紧凑，但仍然不如简单的UTF-8好，而且很难预测给定的输入字符串是否会编码为符合DNS 63字节限制的Punycode字符串，除非简单地尝试编码并查看它是否适合。事实上，编码大小不仅取决于输入字符，还取决于它们的显示顺序，因此同一组字符可能会或可能不会编码为符合DNS 63字节限制的合法双键码字符串，具体取决于字符的显示顺序。在向用户解释为什么允许使用一个名称，但不允许使用另一个包含完全相同字符的名称的用户界面中，这是非常困难的。不得使用Punycode或为单播DNS建议的任何其他“ASCII兼容编码”[RFC5890]
in Multicast DNS messages. Any text being represented internally in some other representation must be converted to canonical precomposed UTF-8 before being placed in any Multicast DNS message.
在多播DNS消息中。在某些其他表示形式中内部表示的任何文本在放入任何多播DNS消息之前必须转换为规范的预合成UTF-8。
Appendix G. Private DNS Namespaces
附录G.专用DNS名称空间
The special treatment of names ending in ".local." has been implemented in Macintosh computers since the days of Mac OS 9, and continues today in Mac OS X and iOS. There are also implementations for Microsoft Windows [B4W], Linux, and other platforms.
对以“.local.”结尾的名称的特殊处理从Macintosh操作系统9开始就在Macintosh计算机中实施，并在MacOSX和iOS中继续实施。还有针对Microsoft Windows[B4W]、Linux和其他平台的实现。
Some network operators setting up private internal networks ("intranets") have used unregistered top-level domains, and some may have used the ".local" top-level domain. Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users. Clients can be configured to send both Multicast and Unicast DNS queries in parallel for these names, and this does allow names to be looked up both ways, but this results in additional network traffic and additional delays in name resolution, as well as potentially creating user confusion when it is not clear whether any given result was received via link-local multicast from a peer on the same link, or from the configured unicast name server. Because of this, we recommend against using ".local" as a private Unicast DNS top-level domain. We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:
一些建立内部专用网络（“内部网”）的网络运营商使用了未注册的顶级域，一些运营商可能使用了“.local”顶级域。将“.local”用作私有顶级域与多播DNS冲突，可能会给用户带来问题。可以将客户端配置为并行发送这些名称的多播和单播DNS查询，这确实允许以两种方式查找名称，但这会导致额外的网络流量和名称解析的额外延迟，当不清楚是否通过链路本地多播从同一链路上的对等方或从配置的单播名称服务器接收到任何给定结果时，可能会造成用户混淆。因此，我们建议不要将“.local”用作专用单播DNS顶级域。我们不建议使用未注册的顶级域，但如果网络运营商决定这样做，则已在专用内部网络上使用以下顶级域，而不会因尝试重用“.local”而导致问题。为此：
.intranet. .internal. .private. .corp. .home. .lan.
.内部网。内部的私有的公司总部。局域网。
Appendix H. Deployment History
附录H.部署历史
In July 1997, in an email to the net-thinkers@thumper.vmeng.com mailing list, Stuart Cheshire first proposed the idea of running the AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of this and related IETF discussions, the IETF Zeroconf working group was chartered September 1999. After various working group discussions and other informal IETF discussions, several Internet-Drafts were written that were loosely related to the general themes of DNS and multicast, but did not address the service discovery aspect of NBP.
1997年7月，在一封电子邮件中-thinkers@thumper.vmeng.comStuart Cheshire首先提出了在IP上运行AppleTalk名称绑定协议[RFC6760]的想法。由于这次和相关的IETF讨论，IETF Zeroconf工作组于1999年9月成立。在各种工作组讨论和其他非正式IETF讨论之后，编写了几份与DNS和多播的一般主题松散相关的互联网草案，但没有涉及NBP的服务发现方面。
In April 2000, Stuart Cheshire registered IPv4 multicast address 224.0.0.251 with IANA [MC4] 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[MC4]注册了IPv4多播地址224.0.0.251，并开始编写代码，以测试和开发使用多播DNS执行类似NBP的服务发现的想法，该想法记录在一组三个互联网草案中：
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] proposed a way to perform NBP-like service discovery using DNS-compatible names and record types.
o “使用DNS发现抽象服务的命名实例”[NIAS]提出了一种使用DNS兼容名称和记录类型执行类似NBP的服务发现的方法。
o "Multicast DNS" (this document) 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”（本文档）指定了一种使用IP多播传输那些DNS兼容的查询和响应的方法，适用于没有传统单播DNS服务器的零配置环境。
In 2001, an update to Mac OS 9 added resolver library support for host name lookup using Multicast DNS. If the user typed a name such as "MyPrinter.local." into any piece of networking software that used the standard Mac OS 9 name lookup APIs, then those name lookup APIs would recognize the name as a dot-local name and query for it by sending simple one-shot Multicast DNS queries to 224.0.0.251:5353. This enabled the user to, for example, enter the name "MyPrinter.local." into their web browser in order to view a printer's status and configuration web page, or enter the name "MyPrinter.local." into the printer setup utility to create a print queue for printing documents on that printer.
2001年，Mac OS 9的更新增加了解析器库对使用多播DNS查找主机名的支持。如果用户在使用标准Mac OS 9名称查找API的任何网络软件中键入“MyPrinter.local.”等名称，则这些名称查找API将识别该名称为点本地名称，并通过向224.0.0.251:5353发送简单的一次性多播DNS查询来查询该名称。例如，这允许用户在其web浏览器中输入名称“MyPrinter.local.”以查看打印机的状态和配置网页，或在打印机设置实用程序中输入名称“MyPrinter.local.”以创建打印队列，以便在该打印机上打印文档。
Multicast DNS responder software, with full service discovery, first began shipping to end users in volume with the launch of Mac OS X 10.2 "Jaguar" in August 2002, and network printer makers (who had historically supported AppleTalk in their network printers and were receptive to IP-based technologies that could offer them similar ease-of-use) started adopting Multicast DNS shortly thereafter.
随着2002年8月Mac OS X 10.2“Jaguar”的推出，多播DNS响应程序软件（具有全服务发现功能）首先开始批量向最终用户提供，网络打印机制造商（他们在网络打印机中一直支持AppleTalk，并接受基于IP的技术，这些技术可以为他们提供类似的易用性）此后不久开始采用多播DNS。
In September 2002, Apple released the source code for the mDNSResponder daemon as Open Source under Apple's standard Apple Public Source License (APSL).
2002年9月，苹果根据苹果的标准苹果公共源代码许可证（APSL）发布了mDNSResponder守护程序的源代码，该守护程序是开源的。
Multicast DNS responder software became available for Microsoft Windows users in June 2004 with the launch of Apple's "Rendezvous for Windows" (now "Bonjour for Windows"), both in executable form (a
2004年6月，随着苹果推出“Windows集合”（现为“Windows万岁”），微软Windows用户可以使用多播DNS响应程序软件，这两种软件都是可执行的（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].
可供最终用户下载的安装程序）和作为开放源代码（苹果公司跨平台代码库中可公开访问的mDNSResponder CVS源代码库中支持的平台之一）[BJ]。
In August 2006, Apple re-licensed the cross-platform mDNSResponder source code under the Apache License, Version 2.0.
2006年8月，苹果根据Apache许可证2.0版重新许可了跨平台mDNSResponder源代码。
In addition to desktop and laptop computers running Mac OS X and Microsoft Windows, Multicast DNS is now implemented in a wide range of hardware devices, such as Apple's "AirPort" wireless base stations, iPhone and iPad, and in home gateways from other vendors, network printers, network cameras, TiVo DVRs, etc.
除了运行Mac OS X和Microsoft Windows的台式机和笔记本电脑外，多播DNS现在还应用于各种硬件设备中，如苹果的“机场”无线基站、iPhone和iPad，以及其他供应商的家庭网关、网络打印机、网络摄像头、TiVo DVR等。
The Open Source community has produced many independent implementations of Multicast DNS, some in C like Apple's mDNSResponder daemon, and others in a variety of different languages including Java, Python, Perl, and C#/Mono.
开源社区已经产生了许多独立的多播DNS实现，一些采用C语言，如Apple的mDNSResponder守护程序，另一些采用各种不同的语言，包括Java、Python、Perl和C#/Mono。
In January 2007, the IETF published the Informational RFC "Link-Local Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially similar to Multicast DNS, but incompatible in some small but important ways. In particular, the LLMNR design explicitly excluded support for service discovery, which made it an unsuitable candidate for a protocol to replace AppleTalk NBP [RFC6760].
2007年1月，IETF发布了信息RFC“链路本地多播名称解析（LLMNR）”[RFC4795]，它与多播DNS基本相似，但在一些小但重要的方面不兼容。特别是，LLMNR设计明确排除了对服务发现的支持，这使得它不适合替代AppleTalk NBP的协议[RFC6760]。
While the original focus of Multicast DNS and DNS-Based Service Discovery was for zero-configuration environments without a conventional Unicast DNS server, DNS-Based Service Discovery also works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over Unicast DNS [RFC6281].
虽然多播DNS和基于DNS的服务发现的最初重点是针对没有传统单播DNS服务器的零配置环境，但基于DNS的服务发现也可以使用单播DNS服务器工作，使用DNS更新[RFC2136][RFC3007]创建服务发现记录，并使用标准DNS查询对其进行查询。2007年10月，苹果推出了Mac OS X 10.5“Leopard”版的“回到我的Mac”服务，该服务在单播DNS上使用基于DNS的服务发现[RFC6281]。
In June 2012, Google's Android operating system added native support for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
2012年6月，谷歌的Android操作系统在Android 4.1“Jelly Bean”（API级别16）[nsd]中添加了对DNS-SD和多播DNS的本机支持，其中包含Android.net.nsd.NsdManager类。
Authors' Addresses
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 4368
EMail: marc@apple.com
Phone: +1 408 974 4368
EMail: marc@apple.com