Internet Engineering Task Force (IETF) K. Lynn
Request for Comments: 7558 Verizon Labs
Category: Informational S. Cheshire
ISSN: 2070-1721 Apple, Inc.
M. Blanchet
Viagenie
D. Migault
Ericsson
July 2015
Internet Engineering Task Force (IETF) K. Lynn
Request for Comments: 7558 Verizon Labs
Category: Informational S. Cheshire
ISSN: 2070-1721 Apple, Inc.
M. Blanchet
Viagenie
D. Migault
Ericsson
July 2015
Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions
基于DNS的可扩展服务发现（DNS-SD）/多播DNS（mDNS）扩展的要求
Abstract
摘要
DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD.
基于DNS的多播DNS（MDN）服务发现（DNS-SD）如今被广泛用于本地链路上的服务和名称的发现和解析，但也有扩展DNS-SD/MDN以支持本地链路之外的服务发现的使用案例。本文档提供了可伸缩DNS-SD的问题陈述和需求列表。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7558.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7558.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Namespace Considerations . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Namespace Considerations . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
DNS-based Service Discovery [DNS-SD] in combination with its companion technology Multicast DNS [mDNS] is widely used today for discovery and resolution of services and names on a local link. As users move to multi-link home or campus networks, however, they find that mDNS (by design) does not work across routers. DNS-SD can also be used in conjunction with conventional unicast DNS to enable wide-area service discovery, but this capability is not yet widely deployed. This disconnect between customer needs and current practice has led to calls for improvement, such as the Educause petition [EP].
基于DNS的服务发现[DNS-SD]及其配套技术多播DNS[mDNS]如今广泛用于本地链路上服务和名称的发现和解析。然而，当用户转向多链路家庭或校园网络时，他们发现MDN（按设计）不能跨路由器工作。DNS-SD还可以与传统的单播DNS结合使用，以实现广域服务发现，但此功能尚未广泛部署。客户需求与当前实践之间的这种脱节导致了需要改进的呼声，如Educause请愿书[EP]。
In response to this and similar evidence of market demand, several products now enable service discovery beyond the local link using different ad hoc techniques. As of yet, no consensus has emerged regarding which approach represents the best long-term direction for DNS-based Service Discovery protocol development.
为了响应市场需求的这一证据和类似证据，现在有几种产品使用不同的即席技术实现了本地链路之外的服务发现。到目前为止，还没有就哪种方法代表基于DNS的服务发现协议开发的最佳长期方向达成共识。
Multicast DNS in its present form is also not optimized for network technologies where multicast transmissions are relatively expensive. Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely affected by excessive mDNS traffic due to the higher network overhead of multicast transmissions. Wireless mesh networks such as IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944] are effectively multi-link subnets [RFC4903] where multicasts must be forwarded by intermediate nodes.
目前形式的多播DNS也没有针对多播传输相对昂贵的网络技术进行优化。由于多播传输的较高网络开销，诸如Wi-Fi[IEEE.802.11]之类的无线网络可能会受到过多MDN流量的不利影响。低功耗无线个人区域网（6LoWPAN）上的IPv6等无线网状网络[RFC4944]实际上是多链路子网[RFC4903]，其中多播必须由中间节点转发。
It is in the best interests of end users, network administrators, and vendors for all interested parties to cooperate within the context of the IETF to develop an efficient, scalable, and interoperable standards-based solution.
为了最终用户、网络管理员和供应商的最大利益，所有相关方应在IETF的背景下进行合作，以开发高效、可扩展和可互操作的基于标准的解决方案。
This document defines the problem statement and gathers requirements for scalable DNS-SD/mDNS extensions.
本文档定义了问题陈述，并收集了可扩展DNS-SD/mDNS扩展的需求。
Service: A listening endpoint (host and port) for a given application protocol. Services are identified by Service Instance Names.
服务：给定应用程序协议的侦听端点（主机和端口）。服务由服务实例名称标识。
DNS-SD: DNS-based Service Discovery [DNS-SD] is a conventional application of DNS resource records and messages to facilitate the naming, discovery, and location of services. When used alone, the term generally refers to the wide-area unicast protocol.
DNS-SD：基于DNS的服务发现[DNS-SD]是DNS资源记录和消息的常规应用程序，用于促进服务的命名、发现和定位。单独使用时，该术语通常指广域单播协议。
mDNS: Multicast DNS [mDNS] is a mechanism that facilitates distributed DNS-like capabilities (including DNS-SD) on a local link without need of traditional DNS infrastructure.
mDNS：多播DNS[mDNS]是一种机制，它可以在本地链路上促进分布式类似DNS的功能（包括DNS-SD），而无需传统的DNS基础设施。
SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future extension of DNS-SD (and perhaps mDNS) that meets the requirements set forth in this document.
SSD:Scalable Service Discovery（或Scalable DNS-SD）是DNS-SD（可能还有mDNS）的未来扩展，它满足本文档中规定的要求。
Scope of Discovery: A subset of a local or global namespace, e.g., a DNS subdomain, that is the target of a given SSD query.
发现范围：作为给定SSD查询目标的本地或全局命名空间（例如DNS子域）的子集。
Zero Configuration: A deployment of SSD that requires no administration (although some administration may be optional).
零配置：不需要管理的SSD部署（尽管某些管理可能是可选的）。
Incremental Deployment: An orderly transition, as a network installation evolves, from DNS-SD/mDNS to SSD.
增量部署：随着网络安装的发展，从DNS-SD/MDN到SSD的有序过渡。
Service discovery beyond the local link is perhaps the most important feature currently missing from the DNS-SD-over-mDNS framework (also written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and requirements are summarized below.
本地链路之外的服务发现可能是DNS SD over mDNS框架（也称为“DNS-SD over mDNS”或“DNS-SD/mDNS”）目前缺少的最重要功能。其他问题和要求概述如下。
A list of desired DNS-SD/mDNS improvements from network administrators in the research and education community was issued in the form of the Educause petition [EP]. The following is a summary of their technical issues:
研究和教育界的网络管理员以Educause请愿书[EP]的形式发布了所需DNS-SD/mDNS改进的列表。以下是其技术问题的摘要：
o It is common practice for enterprises and institutions to use wireless links for client access and wired links for server infrastructure; typically, they are on different subnets. Products that advertise services such as printing and multimedia streaming via DNS-SD over mDNS are not currently discoverable by client devices on other links. DNS-SD used with conventional unicast DNS does work when servers and clients are on different links, but the resource records that describe the services must somehow be entered into the unicast DNS namespace.
o 企业和机构通常使用无线链路访问客户端，使用有线链路访问服务器基础设施；通常，它们位于不同的子网上。通过MDN上的DNS-SD为打印和多媒体流等服务做广告的产品目前无法被其他链接上的客户端设备发现。当服务器和客户端位于不同的链路上时，与传统单播DNS一起使用的DNS-SD确实可以工作，但描述服务的资源记录必须以某种方式输入单播DNS命名空间。
o DNS-SD resource records may be entered manually into a unicast DNS zone file [STATIC], but this task must be performed by a DNS administrator. It is labor intensive and brittle when IP addresses of devices change dynamically, as is common when DHCP is used.
o DNS-SD资源记录可以手动输入单播DNS区域文件[静态]，但此任务必须由DNS管理员执行。当设备的IP地址动态变化时，它是劳动密集型和脆弱的，这在使用DHCP时很常见。
o Automatically adding DNS-SD records using DNS Update works, but it requires that the DNS server be configured to allow DNS Updates and that devices be configured with the DNS Update credentials to permit such updates, which has proven to be onerous.
o 使用DNS更新自动添加DNS-SD记录是可行的，但需要将DNS服务器配置为允许DNS更新，并使用DNS更新凭据配置设备以允许此类更新，这已被证明是繁重的。
Therefore, a mechanism is desired that populates the DNS namespace with the appropriate DNS-SD records with less manual administration than is typically needed for a conventional unicast DNS server.
因此，需要一种用适当的DNS-SD记录填充DNS命名空间的机制，与传统单播DNS服务器通常需要的手动管理相比，这种机制需要更少的手动管理。
The following is a summary of technical requirements:
以下是技术要求的摘要：
o It must scale to a range of hundreds to thousands of DNS-SD/mDNS-enabled devices in a given environment.
o 它必须在给定环境中扩展到数百到数千个启用DNS-SD/mDNS的设备。
o It must simultaneously operate over a variety of network link technologies, such as wired and wireless networks.
o 它必须同时在各种网络链路技术上运行，如有线和无线网络。
o It must not significantly increase network traffic (wired or wireless).
o 它不得显著增加网络流量（有线或无线）。
o It must be cost-effective to manage at up to enterprise scale.
o 以企业规模进行管理必须具有成本效益。
Multicast DNS was originally designed to run on Ethernet - the dominant link layer at the time. In shared-medium Ethernet networks, multicast frames place little additional demand on the shared network medium compared to unicast frames. In IEEE 802.11 networks, however, multicast frames are transmitted at a low data rate supported by all receivers. In practice, this data rate leads to a larger fraction of airtime being devoted to multicast transmission. Some network administrators block multicast traffic or use access points that transmit multicast frames using a series of link-layer unicast frames.
多播DNS最初设计为在以太网上运行——当时主要的链路层。在共享媒体以太网网络中，与单播帧相比，多播帧对共享网络媒体的额外需求很少。然而，在IEEE 802.11网络中，多播帧以所有接收器支持的低数据速率传输。在实践中，这种数据速率导致更多的广播时间用于多播传输。一些网络管理员阻止多播通信或使用使用一系列链路层单播帧传输多播帧的接入点。
Wireless links may be orders of magnitude less reliable than their wired counterparts. To improve transmission reliability, the IEEE 802.11 Medium Access Control (MAC) requires positive acknowledgement of unicast frames. It does not, however, support positive acknowledgement of multicast frames. As a result, it is common to observe higher loss rates of multicast frames on wireless network technologies than on wired network technologies.
无线链路的可靠性可能比有线链路低几个数量级。为了提高传输可靠性，IEEE 802.11媒体访问控制（MAC）要求对单播帧进行肯定确认。然而，它不支持多播帧的肯定确认。因此，无线网络技术上的多播帧丢失率通常高于有线网络技术。
Enabling service discovery on IEEE 802.11 networks requires that the number of multicast frames be restricted to a suitably low value or replaced with unicast frames to use the MAC's reliability features.
在IEEE 802.11网络上启用服务发现需要将多播帧的数量限制在适当的低值，或用单播帧替换，以使用MAC的可靠性功能。
Emerging wireless mesh networking technologies such as the Routing Protocol for LLNs (RPL) [RFC6550] and 6LoWPAN present several challenges for the current DNS-SD/mDNS design. First, link-local multicast scope [RFC4291] is defined as a single-hop neighborhood. A wireless mesh network representing a single logical subnet may often extend to multiple hops [RFC4903]; therefore, a larger multicast scope is required to span it [RFC7346]. Multicast DNS was intentionally not specified for greater than link-local scope because of the additional off-link multicast traffic that it would generate.
新兴的无线网状网络技术，如LLN路由协议（RPL）[RFC6550]和6LoWPAN，对当前的DNS-SD/mDNS设计提出了若干挑战。首先，将链路本地多播作用域[RFC4291]定义为单跳邻居。表示单个逻辑子网的无线网状网络通常可以扩展到多个跃点[RFC4903]；因此，需要更大的多播范围来跨越它[RFC7346]。由于多播DNS将生成额外的脱离链路多播流量，因此故意未为大于链路本地作用域的多播DNS指定。
Additionally, low-power nodes may be offline for significant periods either because they are "sleeping" or due to connectivity problems. In such cases, LLN nodes might fail to respond to queries or defend their names using the current design.
此外，低功耗节点可能会在相当长的时间内处于脱机状态，这可能是因为它们处于“睡眠”状态，也可能是由于连接问题。在这种情况下，LLN节点可能无法响应查询或使用当前设计保护其名称。
The following use cases are defined with different characteristics to help motivate, distinguish, and classify the target requirements. They cover a spectrum of increasing deployment and administrative complexity.
以下用例定义了不同的特性，以帮助激发、区分和分类目标需求。它们涵盖了不断增加的部署和管理复杂性。
(A) Personal Area Networks (PANs): The simplest example of a network may consist of a single client and server, e.g., one laptop and one printer, on a common link. PANs that do not contain a router may use Zero Configuration Networking [ZC] to self-assign link-local addresses [RFC3927] [RFC4862] and Multicast DNS [mDNS] to provide naming and service discovery, as is currently implemented and deployed in Mac OS X, iOS, Windows [B4W], and Android [NSD].
（A） 个人区域网络（PANs）：最简单的网络示例可能由一个客户端和服务器组成，例如，一台笔记本电脑和一台打印机，位于公共链路上。不包含路由器的PAN可以使用零配置网络[ZC]来自分配链路本地地址[RFC3927][RFC4862]和多播DNS[MDN]来提供命名和服务发现，正如目前在Mac OS X、iOS、Windows[B4W]和Android[NSD]中实现和部署的那样。
(B) Classic home or 'hotspot' networks, with the following properties:
（B） 具有以下属性的经典家庭或“热点”网络：
* Single exit router: The network may have one or more upstream providers or networks, but all outgoing and incoming traffic goes through a single router.
* 单出口路由器：网络可能有一个或多个上游提供商或网络，但所有传出和传入流量都通过一个路由器。
* One-level depth: A single physical link, or multiple physical links bridged to form a single logical link, that is connected to the default router. The single logical link provides a single broadcast domain, facilitating use of link-local Multicast DNS, and also ARP, which enables the home or 'hotspot' network to consist of just a single IPv4 subnet.
* 一级深度：连接到默认路由器的单个物理链路，或桥接成单个逻辑链路的多个物理链路。单一逻辑链路提供单一广播域，便于使用链路本地多播DNS和ARP，这使得家庭或“热点”网络仅由单个IPv4子网组成。
* Single administrative domain: All nodes under the same administrative authority. Note that this does not necessarily imply a network administrator.
* 单一管理域：同一管理权限下的所有节点。请注意，这并不一定意味着网络管理员。
(C) Advanced home and small business networks [RFC7368]:
（C） 高级家庭和小型企业网络[RFC7368]：
Like B, but consists of multiple wired and/or wireless links, connected by routers, generally behind a single exit router. However, the forwarding nodes are largely self-configuring and do not require routing protocol administration. Such networks should also not require DNS administration.
与B类似，但由多个有线和/或无线链路组成，由路由器连接，通常位于单个出口路由器后面。然而，转发节点基本上是自配置的，不需要路由协议管理。此类网络也不应要求DNS管理。
(D) Enterprise networks:
（D） 企业网络：
Consists of arbitrary network diameter under a single administrative authority. A large majority of the forwarding and security devices are configured, and multiple exit routers are
由单个管理权限下的任意网络直径组成。大部分转发和安全设备都已配置，并且多个出口路由器也已配置
more common. Large-scale conference-style networks, which are predominantly wireless access, e.g., as available at IETF meetings, also fall within this category.
更常见。大规模会议式网络，主要是无线接入，如IETF会议上提供的，也属于这一类。
(E) Higher-Education networks:
（E） 高等教育网络：
Like D, but the core network may be under a central administrative authority while leaf networks are under local administrative authorities.
与D类似，但核心网络可能位于中央管理机构之下，而叶网络位于地方管理机构之下。
(F) Mesh networks such as RPL/6LoWPAN:
（F） 网状网络，如RPL/6LoWPAN：
Multi-link subnets with prefixes defined by one or more border routers. May comprise any part of networks C, D, or E.
前缀由一个或多个边界路由器定义的多链路子网。可包括网络C、D或E的任何部分。
Any successful SSD solution(s) will have to strike the proper balance between competing goals such as scalability, deployability, and usability. With that in mind, none of the requirements listed below should be considered in isolation.
任何成功的SSD解决方案都必须在可扩展性、可部署性和可用性等相互竞争的目标之间取得适当的平衡。考虑到这一点，下面列出的任何要求都不应单独考虑。
REQ1: For use cases A, B, and C, there should be a Zero Configuration mode of operation. This implies that servers and clients should be able to automatically determine a default scope of discovery in which to advertise and discover services, respectively.
需求1：对于用例A、B和C，应该有零配置操作模式。这意味着服务器和客户端应该能够自动确定一个默认的发现范围，在该范围内分别发布和发现服务。
REQ2: For use cases C, D, and E, there should be a way to configure scopes of discovery that support a range of topologically independent zones (e.g., from department to campus wide). This capability must exist in the protocol; individual operators are not required to use this capability in all cases -- in particular, use case C should support Zero Configuration operation where that is desired. If multiple scopes are available, there must be a way to enumerate the choices from which a selection can be made. In use case C, either Zero Configuration (one flat list of resources) or configured (e.g., resources sorted by room) modes of operation should be available.
需求2：对于用例C、D和E，应该有一种方法来配置支持一系列拓扑独立区域（例如，从部门到校园范围）的发现范围。该能力必须存在于协议中；不要求每个操作员在所有情况下都使用此功能——特别是，用例C应该在需要时支持零配置操作。如果有多个作用域可用，则必须有一种方法来枚举可以进行选择的选项。在用例C中，零配置（一个简单的资源列表）或配置（例如，按房间排序的资源）操作模式都应该可用。
REQ3: As stated in REQ2 above, the discovery scope need not be aligned to network topology. For example, it may instead be aligned to physical proximity (e.g., building) or organizational structure (e.g., "Sales" vs. "Engineering").
REQ3：如上文REQ2所述，发现范围无需与网络拓扑对齐。例如，它可能与物理邻近性（例如，建筑）或组织结构（例如，“销售”与“工程”）相一致。
REQ4: For use cases C, D, and E, there should be an incremental way to deploy the solution.
需求4：对于用例C、D和E，应该有一种增量方式来部署解决方案。
REQ5: SSD should leverage and build upon current link scope DNS-SD/ mDNS protocols and deployments.
要求5：SSD应利用并构建当前链路范围的DNS-SD/mDNS协议和部署。
REQ6: SSD must not adversely affect or break any other current protocols or deployments.
要求6：SSD不得对任何其他当前协议或部署造成不利影响或破坏。
REQ7: SSD must be capable of operating across networks that are not limited to a single link or network technology, including clients and services on non-adjacent links.
要求7：SSD必须能够跨不限于单个链路或网络技术的网络运行，包括非相邻链路上的客户端和服务。
REQ8: It is desirable that a user or device be able to discover services within the sites or networks to which the user or device is connected.
要求8：希望用户或设备能够在用户或设备所连接的站点或网络内发现服务。
REQ9: SSD should operate efficiently on common link layers and link types.
要求9：SSD应在普通链路层和链路类型上高效运行。
REQ10: SSD should be considerate of networks where power consumption is a critical factor; for example, nodes may be in a low-power or sleeping state.
要求10：SSD应考虑功耗是关键因素的网络；例如，节点可能处于低功耗或休眠状态。
REQ11: SSD must be scalable to thousands of nodes with minimal configuration and without degrading network performance. A possible figure of merit is that, as the number of services increases, the amount of traffic due to SSD on a given link remains relatively constant.
要求11：SSD必须可扩展到数千个节点，且配置最少，且不会降低网络性能。一个可能的优点是，随着服务数量的增加，由于给定链路上的SSD而产生的通信量保持相对恒定。
REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered.
REQ12:SSD应能够提供一致的用户体验，无论是发现本地服务还是远程服务。
REQ13: The information presented by SSD should closely reflect the current state of discoverable services on the network. That is, new information should be available within a few seconds and stale information should not persist indefinitely. In networking, all information is necessarily somewhat out of date by the time it reaches the receiver, even if only by a few microseconds or less. Thus, timeliness is always an engineering trade-off against efficiency. The engineering decisions for SSD should appropriately balance timeliness against network efficiency.
要求13：SSD提供的信息应密切反映网络上可发现服务的当前状态。也就是说，新信息应该在几秒钟内可用，而过时的信息不应该无限期地存在。在网络中，所有信息在到达接收器时都必然有些过时，即使只有几微秒或更少。因此，及时性始终是一种与效率的工程权衡。SSD的工程决策应适当平衡及时性和网络效率。
REQ14: SSD should operate over existing networks (as described by use cases A through F above) without requiring changes to the network at the physical, link, or internetworking layers.
要求14：SSD应在现有网络上运行（如上述用例A至F所述），而无需在物理层、链路层或网络互连层对网络进行更改。
REQ15: The administrator of an advertised service should be able to control whether the service is advertised beyond the local link.
REQ15：播发服务的管理员应该能够控制该服务是否在本地链接之外播发。
The traditional unicast DNS namespace contains, for the most part, globally unique names. Multicast DNS provides every link with its own separate link-local namespace, where names are unique only within the context of that link. Clients discovering services may need to differentiate between local and global names and may need to determine when names in different namespaces identify the same service.
传统的单播DNS命名空间大部分包含全局唯一的名称。多播DNS为每个链路提供其自己的单独链路本地名称空间，其中名称仅在该链路的上下文中是唯一的。发现服务的客户端可能需要区分本地名称和全局名称，并且可能需要确定不同名称空间中的名称何时标识同一服务。
Devices on different links may have the same mDNS name (perhaps due to vendor defaults) because link-local mDNS names are only guaranteed to be unique on a per-link basis. This may lead to a local label disambiguation problem when results are aggregated (e.g., for presentation).
不同链路上的设备可能具有相同的MDN名称（可能是由于供应商的默认设置），因为链路本地MDN名称仅保证在每个链路上是唯一的。这可能会导致在聚合结果（例如，用于表示）时出现局部标签消歧问题。
SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure.
SSD应该支持服务实例名称中丰富的国际化标签，就像今天的DNS-SD/mDNS一样。SSD不得对全局DNS命名空间或基础架构产生负面影响。
The problem of publishing local services in the global DNS namespace may be generally viewed as exporting local resource records and their associated labels into some DNS zone. The issues related to defining labels that are interoperable between local and global namespaces are discussed in a separate document [INTEROP-LABELS].
在全局DNS命名空间中发布本地服务的问题通常被视为将本地资源记录及其相关标签导出到某些DNS区域。与定义本地和全局名称空间之间可互操作的标签相关的问题将在单独的文档[INTEROP-labels]中讨论。
Insofar as SSD may automatically gather DNS-SD resource records and publish them over a wide area, the security issues are likely to include the union of those discussed in the Multicast DNS [mDNS] and DNS-based Service Discovery [DNS-SD] specifications. The following sections highlight potential threats that are posed by deploying DNS-SD over multiple links or by automating DNS-SD administration.
就SSD可以自动收集DNS-SD资源记录并在广域上发布它们而言，安全问题可能包括多播DNS[MDN]和基于DNS的服务发现[DNS-SD]规范中讨论的那些记录的结合。以下各节重点介绍了通过多个链路部署DNS-SD或自动化DNS-SD管理所造成的潜在威胁。
In some scenarios, the owner of the advertised service may not have a clear indication of the scope of its advertisement.
在某些情况下，广告服务的所有者可能没有明确指示其广告的范围。
For example, since mDNS is currently restricted to a single link, the scope of the advertisement is limited, by design, to the shared link between client and server. If the advertisement propagates to a larger set of links than expected, this may result in unauthorized
例如，由于MDN当前仅限于单个链接，因此广告的范围在设计上仅限于客户端和服务器之间的共享链接。如果广告传播到比预期更大的链接集，这可能会导致未经授权的错误
clients (from the perspective of the owner) discovering and then potentially attempting to connect to the advertised service. It also discloses information (about the host and service) to a larger set of potential attackers.
客户端（从所有者的角度）发现并可能尝试连接到广告服务。它还将（关于主机和服务的）信息披露给更多的潜在攻击者。
Note that discovery of a service does not necessarily imply that the service is reachable by, or can be connected to, or can be used by, a given client. Specific access-control mechanisms are out of scope of this document.
请注意，服务的发现并不一定意味着该服务可由给定客户机访问、连接或使用。特定的访问控制机制不在本文档的范围内。
If the scope of the discovery is not properly set up or constrained, then information leaks will happen outside the appropriate network.
如果发现的范围未正确设置或限制，则信息泄漏将发生在适当的网络之外。
There is a possibility of conflicts between the local and global DNS namespaces. Without adequate feedback, a discovering client may not know if the advertised service is the correct one, therefore enabling potential attacks.
本地和全局DNS命名空间之间可能存在冲突。如果没有足够的反馈，发现客户机可能不知道广告服务是否正确，从而导致潜在的攻击。
DNSSEC can assert the validity but not the accuracy of records in a zone file. The trust model of the global DNS relies on the fact that human administrators either (a) manually enter resource records into a zone file or (b) configure the DNS server to authenticate a trusted device (e.g., a DHCP server) that can automatically maintain such records.
DNSSEC可以断言区域文件中记录的有效性，但不能断言其准确性。全局DNS的信任模型依赖于以下事实：（a）人工将资源记录输入区域文件，或（b）配置DNS服务器以验证可自动维护此类记录的受信任设备（例如DHCP服务器）。
An impostor may register on the local link and appear as a legitimate service. Such "rogue" services may then be automatically registered in unicast DNS-SD.
冒名顶替者可以在本地链接上注册并作为合法服务出现。这样的“流氓”服务随后可以在单播DNS-SD中自动注册。
Up to now, the "plug-and-play" nature of mDNS devices has relied only on physical connectivity. If a device is visible via mDNS, then it is assumed to be trusted. This is not likely to be the case in foreign networks.
到目前为止，mDNS设备的“即插即用”特性仅依赖于物理连接。如果设备通过MDN可见，则假定它是可信的。外国网络不太可能出现这种情况。
If there is a risk that clients may be fooled by the deployment of rogue services, then application-layer authentication should be considered as part of any security solution. Authentication of any particular service is outside the scope of this document.
如果存在客户机可能被恶意服务的部署所欺骗的风险，那么应用层身份验证应该被视为任何安全解决方案的一部分。任何特定服务的身份验证都不在本文档的范围内。
Access Control refers to the ability to restrict which users are able to use a particular service that might be advertised via DNS-SD. In this case, "use" of a service is different from the ability to "discover" or "reach" a service.
访问控制是指限制哪些用户能够使用可能通过DNS-SD发布的特定服务的能力。在这种情况下，服务的“使用”不同于“发现”或“到达”服务的能力。
While controlling access to an advertised service is outside the scope of DNS-SD, we note that access control today often is provided by existing site infrastructure (e.g., router access-control lists, firewalls) and/or by service-specific mechanisms (e.g., user authentication to the service). For example, networked printers can control access via a user ID and password. Apple's software supports such access control for USB printers shared via Mac OS X Printer Sharing, as do many networked printers themselves. So the reliance on existing service-specific security mechanisms (i.e., outside the scope of DNS-SD) does not create new security considerations.
虽然控制对广告服务的访问不在DNS-SD的范围内，但我们注意到，目前的访问控制通常由现有站点基础设施（例如，路由器访问控制列表、防火墙）和/或特定于服务的机制（例如，用户对服务的身份验证）提供。例如，联网打印机可以通过用户ID和密码控制访问。苹果的软件支持通过Mac OS X打印机共享对USB打印机进行访问控制，许多网络打印机本身也是如此。因此，依赖现有的特定于服务的安全机制（即，DNS-SD范围之外）不会产生新的安全考虑。
Mobile devices such as smart phones or laptops that can expose the location of their owners by registering services in arbitrary zones pose a risk to privacy. Such devices must not register their services in arbitrary zones without the approval ("opt-in") of their users. However, it should be possible to configure one or more "safe" zones in which mobile devices may automatically register their services.
移动设备，如智能手机或笔记本电脑，可以通过在任意区域注册服务暴露其所有者的位置，从而对隐私构成风险。未经用户批准（“选择加入”），此类设备不得在任意区域注册其服务。但是，应该可以配置一个或多个“安全”区域，移动设备可以在其中自动注册其服务。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[DNS-SD]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[mDNS]Cheshire，S.和M.Krocmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <http://www.rfc-editor.org/info/rfc3927>.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，DOI 10.17487/RFC3927，2005年5月<http://www.rfc-editor.org/info/rfc3927>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <http://www.rfc-editor.org/info/rfc4903>.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 4903，DOI 10.17487/RFC4903，2007年6月<http://www.rfc-editor.org/info/rfc4903>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 6550，DOI 10.17487/RFC6550，2012年3月<http://www.rfc-editor.org/info/rfc6550>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, DOI 10.17487/RFC7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>.
[RFC7346]Droms，R.，“IPv6多播地址范围”，RFC 7346，DOI 10.17487/RFC7346，2014年8月<http://www.rfc-editor.org/info/rfc7346>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <http://www.rfc-editor.org/info/rfc7368>.
[RFC7368]Chown，T.，Ed.，Arkko，J.，Brandt，A.，Troan，O.，和J.Weil，“IPv6家庭网络架构原则”，RFC 7368，DOI 10.17487/RFC7368，2014年10月<http://www.rfc-editor.org/info/rfc7368>.
[B4W] "Bonjour (software)", <http://en.wikipedia.org/wiki/Bonjour_(software)>.
[B4W]“你好（软件）”<http://en.wikipedia.org/wiki/Bonjour_（软件）>。
[EP] Badman, L., "Petitioning Apple: From Educause Higher Ed Wireless Networking Admin Group", July 2012, <https://www.change.org/p/from-educause-higher-ed-wireless-networking-admin-group>.
[EP]Badman，L.，“请愿苹果：来自Educause高等教育无线网络管理集团”，2012年7月<https://www.change.org/p/from-educause-higher-ed-wireless-networking-admin-group>.
[IEEE.802.11] IEEE Computer Society, "IEEE Standard for 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, <http://standards.ieee.org/about/get/802/802.11.html>.
[IEEE.802.11]IEEE计算机协会，“IEEE信息技术标准-系统局域网和城域网之间的电信和信息交换-特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11， <http://standards.ieee.org/about/get/802/802.11.html>.
[INTEROP-LABELS] Sullivan, A., "On Interoperation of Labels Between mDNS and DNS", Work in Progress, draft-sullivan-dnssd-mdns-dns-interop-01, October 2014.
[INTEROP-LABELS]Sullivan，A.“关于MDN和DNS之间标签的互操作”，正在进行的工作，草稿-Sullivan-dnssd-mDNS-DNS-INTEROP-01，2014年10月。
[NSD] Android, "NsdManager", <http://developer.android.com/reference/android/net/nsd/ NsdManager.html>.
[NSD]Android，“NsdManager”<http://developer.android.com/reference/android/net/nsd/ NsdManager.html>。
[STATIC] "Manually Adding DNS-SD Service Discovery Records to an Existing Name Server", July 2013, <http://www.dns-sd.org/ServerStaticSetup.html>.
[静态]“手动将DNS-SD服务发现记录添加到现有名称服务器”，2013年7月<http://www.dns-sd.org/ServerStaticSetup.html>.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
[ZC]Cheshire，S.和D.Steinberg，“零配置网络：最终指南”，O'Reilly Media，Inc.，ISBN 0-596-10100-7，2005年12月。
Acknowedgements
承认
We gratefully acknowledge contributions and review comments made by RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and Peter Van Der Stok.
我们衷心感谢RJ Atkinson、Tim Chown、邓广清、Ralph Droms、Educause、David Farmer、Matthew Gast、Thomas Narten、Doug Otis、David Thaler和Peter Van Der Stok的贡献和评论。
Authors' Addresses
作者地址
Kerry Lynn Verizon Labs 50 Sylvan Road Waltham, MA 95014 United States
Kerry Lynn Verizon实验室美国马萨诸塞州沃尔瑟姆Sylvan路50号，邮编95014
Phone: +1 781 296 9722
Email: kerry.lynn@verizon.com
Phone: +1 781 296 9722
Email: kerry.lynn@verizon.com
Stuart Cheshire Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 United States
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
Email: cheshire@apple.com
Phone: +1 408 974 3207
Email: cheshire@apple.com
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada
Marc Blanchet Viagenie 246魁北克省阿伯丁市，QC G1R 2E1加拿大
Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca
Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca
Daniel Migault Ericsson 8400 Boulevard Decarie Montreal, QC H4P 2N2 Canada
Daniel Migault Ericsson 8400 Boulevard Decare Montreal，QC H4P 2N2加拿大
Phone: +1 514 452 2160
Email: daniel.migault@ericsson.com
Phone: +1 514 452 2160
Email: daniel.migault@ericsson.com