Internet Engineering Task Force (IETF) A. Sullivan
Request for Comments: 8222 Oracle
Category: Informational September 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Sullivan
Request for Comments: 8222 Oracle
Category: Informational September 2017
ISSN: 2070-1721
Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery
在基于DNS的服务发现中选择用于传统DNS和其他解析系统的标签
Abstract
摘要
Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.
尽管名称不同，基于DNS的服务发现（DNS-SD）在查找服务时可以使用DNS以外的命名系统。此外，当使用DNS时，DNS-SD使用DNS的全部功能，而不是使用可用八位字节的子集。当某些环境使用符合应用程序国际化域名（IDNA）的DNS标签，而其他环境使用包含Unicode字符的标签（例如包含对应于编码为UTF-8的字符的八位字节）时，这一点尤为重要。为了在使用多个不同名称系统及其操作约定的环境中有效地使用DNS-SD，必须注意底层技术和操作环境的差异。本备忘录概述了传统DNS和其他解析系统在以这种方式互操作时选择标签的要求。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8222.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8222.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terms Used in This Document . . . . . . . 3
2. Why There Could Be a Problem at All . . . . . . . . . . . . . 4
3. Requirements for a Profile for Label Interoperation . . . . . 5
4. DNS-SD Portions . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The <Instance> Portion of the Service Instance Name . . . 6
4.2. The <Service> Portion of the Service
Instance Name . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The <Domain> Portion of the Service Instance Name . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terms Used in This Document . . . . . . . 3
2. Why There Could Be a Problem at All . . . . . . . . . . . . . 4
3. Requirements for a Profile for Label Interoperation . . . . . 5
4. DNS-SD Portions . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The <Instance> Portion of the Service Instance Name . . . 6
4.2. The <Service> Portion of the Service
Instance Name . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The <Domain> Portion of the Service Instance Name . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism for discovering services using queries to DNS ([RFC1034] and [RFC1035]) and to any other system that uses domain names, such as Multicast DNS (mDNS, [RFC6762]). Many applications that use DNS follow "Internet hostname" syntax [RFC952] for labels -- the so-called LDH (letters, digits, and hyphen) rule. That convention is the reason behind the development of Internationalized Domain Names for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], and [RFC5895]). It is worth noting that the LDH rule is a convention, and not a rule of the DNS; this is made entirely plain by Section 11 of [RFC2181], and discussed further in Section 3 of [RFC6055]. Nevertheless, there is a widespread belief that in many circumstances domain names cannot be used in the DNS unless they follow the LDH rule.
基于DNS的服务发现（DNS-SD，[RFC6763]）指定了一种使用对DNS（[RFC1034]和[RFC1035]）以及使用域名的任何其他系统（如多播DNS（MDN，[RFC6762]）的查询来发现服务的机制。许多使用DNS的应用程序都遵循标签的“Internet主机名”语法[RFC952]——即所谓的LDH（字母、数字和连字符）规则。这种惯例是开发应用程序国际化域名的原因（IDNA2008、[RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]、[RFC5894]和[RFC5895]）。值得注意的是，LDH规则是一项约定，而不是DNS规则；[RFC2181]第11节对此作了明确说明，并在[RFC6055]第3节中作了进一步讨论。然而，人们普遍认为，在许多情况下，域名不能在DNS中使用，除非它们遵循LDH规则。
At the same time, mDNS requires that labels be encoded in UTF-8 and permits a range of characters in labels that are not permitted by IDNA2008 or the LDH rule. For example, mDNS encourages the use of spaces and punctuation in mDNS names (see Section 4.2.3 of [RFC6763]). It does not restrict which Unicode code points may be used in those labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] format.
同时，mDNS要求标签以UTF-8编码，并允许标签中包含IDNA2008或LDH规则不允许的字符范围。例如，mDNS鼓励在mDNS名称中使用空格和标点符号（见[RFC6763]第4.2.3节）。它不限制在这些标签中可以使用哪些Unicode代码点，只要代码点是净Unicode[RFC5198]格式的UTF-8。
Users and developers of applications are, of course, frequently unconcerned with (or oblivious to) the name-resolution system(s) in service at any given moment; they are inclined simply to use the same domain names in different contexts. As a result, names entered into the same domain name slot might be resolved using different name resolution technologies. If a given name will not work across the various environments, then user expectations are likely to be best satisfied when at least some parts of the domain names to be queried are compatible with the rules and conventions for all the relevant technologies. Given the uses of DNS-SD, a choice for such compatibility likely lies with the application designer or service operator.
当然，应用程序的用户和开发人员通常不关心（或忘记）在任何给定时刻使用的名称解析系统；他们倾向于在不同的上下文中使用相同的域名。因此，输入到同一域名槽中的名称可能会使用不同的名称解析技术进行解析。如果一个给定的名称不能在各种环境中工作，那么当至少要查询的域名的某些部分与所有相关技术的规则和约定兼容时，用户的期望可能会得到最好的满足。考虑到DNS-SD的使用，此类兼容性的选择可能取决于应用程序设计者或服务运营商。
One approach to interoperability under these circumstances is to use a single operational convention (a "profile") for domain names under the different naming systems. This memo assumes such a use profile, and attempts to outline what is necessary to make it work without specifying any particular technology. It does assume, however, that the global DNS is likely to be implicated. Given the general tendency of all resolution eventually to fall through to the DNS, that assumption does not seem controversial.
在这些情况下，实现互操作性的一种方法是对不同命名系统下的域名使用单一操作约定（“概要”）。本备忘录假设这样一个使用概要，并试图概述使其工作所必需的内容，而不指定任何特定的技术。然而，它确实假设全局DNS可能受到牵连。考虑到所有解决方案最终都会落入DNS的总体趋势，这一假设似乎没有争议。
It is worth noting that users of DNS-SD do not use the service discovery names in the same way that users of other domain names might. In many cases, domain names can be entered as direct user input. But the service discovery context generally assumes that users are picking a service from a list. As a result, the sorts of application considerations that are appropriate to the general-purpose DNS name, and that resulted in the A-label/U-label split (see below) in IDNA2008, are not entirely the right approach for DNS-SD.
值得注意的是，DNS-SD的用户使用服务发现名称的方式与其他域名的用户使用服务发现名称的方式不同。在许多情况下，域名可以作为用户直接输入。但是服务发现上下文通常假定用户正在从列表中选择服务。因此，适用于通用DNS名称并导致IDNA2008中a-label/U-label拆分（见下文）的各种应用程序注意事项并不完全是DNS-SD的正确方法。
Wherever appropriate, this memo uses the terminology defined in Section 2 of [RFC5890]. In particular, the reader is assumed to be familiar with the terms "U-label", "LDH label", and "A-label" from that document. Similarly, the reader is assumed to be familiar with the U+NNNN notation for Unicode code points used in [RFC5890] and other documents dealing with Unicode code points. In the interests of brevity and consistency, the definitions are not repeated here.
在适当情况下，本备忘录使用[RFC5890]第2节中定义的术语。特别地，假定读者熟悉该文档中的术语“U-标签”、“LDH标签”和“A-标签”。同样，假定读者熟悉[RFC5890]和其他处理Unicode码点的文档中使用的Unicode码点的U+NNNN符号。为了简洁和一致，这里不再重复这些定义。
Sometimes this memo refers to names in the DNS as though the LDH rule and IDNA2008 are strict requirements. They are not. DNS labels are, in principle, just collections of octets; therefore, in principle, the LDH rule is not a constraint. In practice, applications sometimes intercept labels that do not conform to the LDH rule and apply IDNA and other transformations.
有时，本备忘录提及DNS中的名称，就好像LDH规则和IDNA2008是严格要求一样。事实并非如此。原则上，DNS标签只是八位字节的集合；因此，原则上，LDH规则不是约束。实际上，应用程序有时会截取不符合LDH规则的标签，并应用IDNA和其他转换。
DNS, perhaps unfortunately, has produced its own jargon. Unfamiliar DNS-related terms in this memo should be found in [RFC7719].
也许不幸的是，DNS产生了自己的术语。本备忘录中不熟悉的DNS相关术语可在[RFC7719]中找到。
The term "owner name" (common to the DNS vernacular; see above) is used here to apply not just to the domain names to be looked up in the DNS, but to any name that might be looked up either in the DNS or using another technology. Therefore, it includes names that might not actually exist anywhere. In addition, what follows depends on the idea that not every domain name will be looked up in the DNS. For instance, names ending in "local." (in the presentation format) are not ordinarily looked up using DNS, but instead looked up using mDNS.
这里使用的术语“所有者名称”（DNS术语通用；见上文）不仅适用于要在DNS中查找的域名，还适用于可能在DNS中或使用其他技术查找的任何名称。因此，它包括可能实际上不存在于任何地方的名称。此外，接下来的内容取决于并非每个域名都会在DNS中查找的想法。例如，以“local.”（表示格式）结尾的名称通常不使用DNS查找，而是使用MDN查找。
DNS-SD specifies three portions of the owner name for a DNS-SD resource record. These are the <Instance> portion, the <Service> portion, and the <Domain> portion. The owner name made of these three parts is called the "Service Instance Name". It is worth observing that a portion may be more than one label long. See Section 4.1 of [RFC6763]. Further discussion of the parts is found in Section 4.
DNS-SD为DNS-SD资源记录指定所有者名称的三个部分。这些是<Instance>部分、<Service>部分和<Domain>部分。由这三部分组成的所有者名称称为“服务实例名称”。值得注意的是，一部分可能不止一个标签长。见[RFC6763]第4.1节。第4节对各部分进行了进一步讨论。
Throughout this memo, mDNS is used liberally as the alternative resolution mechanism to DNS. This is for convenience rather than rigor: any alternative name resolution to DNS could present the same friction with the prevailing operational conventions of the global DNS. It so happens that mDNS is the overwhelmingly successful alternative as of this writing, so it is used in order to make the issues plainer to the reader. Other alternative resolution mechanisms may generally be read wherever mDNS appears in the text, except where details of the mDNS specification appear.
在本备忘录中，mDNS被广泛用作DNS的替代解析机制。这是为了方便而不是严格：DNS的任何替代名称解析都可能与全球DNS的主流操作惯例产生相同的摩擦。在撰写本文时，mDNS恰好是压倒性成功的替代方案，因此使用mDNS是为了让读者更清楚地了解问题。除mDNS规范的详细信息外，其他替代解决机制通常可以在文本中出现mDNS的任何地方阅读。
One might reasonably wonder why there is a problem to be solved at all. After all, DNS labels permit any octet whatsoever, and anything that can be useful with DNS-SD cannot use any names that are outside the protocol strictures of the DNS.
有人可能有理由怀疑，为什么会有一个问题需要解决。毕竟，DNS标签允许任何八位字节，任何对DNS-SD有用的名称都不能使用任何超出DNS协议限制的名称。
The reason for the trouble is twofold. First, and least troublesome, is the possibility of resolvers that are attempting to offer IDNA service system-wide. Given the design of IDNA2008, it is reasonable
麻烦的原因有两个。首先，也是最不麻烦的是，可能有解析器试图在系统范围内提供IDNA服务。考虑到IDNA2008的设计，它是合理的
to suppose that, on some systems, high-level name resolution libraries will perform the U-label/A-label transformation automatically, saving applications from these details. But system-level services do not always have available to them the resolution context, and they may apply the transformation in a way that foils rather than helps the application. Of course, if this were the main problem, it would presumably be self-correcting because the right answer would be, "Don't use those libraries for DNS-SD", and DNS-SD would not work reliably in cases where such libraries were in use. This would be unfortunate, but given that DNS-SD in Internet contexts is (as of this writing) not in ubiquitous use, it should not represent a fatal issue.
假设在某些系统上，高级名称解析库将自动执行U-label/A-label转换，从而从这些详细信息中保存应用程序。但是，系统级服务并不总是可以使用解析上下文，它们可能会以阻碍而不是帮助应用程序的方式应用转换。当然，如果这是主要问题，它可能是自我纠正的，因为正确的答案是“不要将这些库用于DNS-SD”，并且在使用这些库的情况下，DNS-SD将无法可靠地工作。这将是不幸的，但鉴于互联网环境中的DNS-SD（截至本文撰写之时）并不是无处不在的，它不应该是一个致命的问题。
The greater problem is that the "infrastructure" types of DNS service -- the root zone, the top-level domains, and so on -- have embraced IDNA and refuse registration of raw UTF-8 into their zones. As of this writing, there is (perhaps unfortunately) no reliable way to discover where these sorts of DNS services end. Nevertheless, some client programs (notably web browsers) have adopted a number of different policies about how domain names will be looked up and presented to users given the policies of the relevant DNS zone operators. None of these policies permit raw UTF-8. Since it is anticipated that DNS-SD when used with the DNS will be inside domain names beneath those kinds of "infrastructure" domains, the implications of IDNA2008 must be a consideration.
更大的问题是DNS服务的“基础设施”类型（根区域、顶级域等）采用IDNA并拒绝将原始UTF-8注册到其区域中。在撰写本文时，还没有（也许不幸的是）可靠的方法来发现这类DNS服务的终点。尽管如此，一些客户端程序（尤其是web浏览器）在给定相关DNS区域运营商的策略的情况下，对如何查找域名并向用户提供域名采取了许多不同的策略。这些政策都不允许使用原始UTF-8。由于预期DNS-SD与DNS一起使用时将位于这些类型的“基础设施”域下的域名内，因此必须考虑IDNA2008的影响。
For further exploration of issues relating to encoding of domain names generally, the reader should consult [RFC6055].
对于与域名编码相关的问题的进一步探讨，读者应参考[RFC6055]。
Any interoperability between DNS (including prevailing operational conventions) and other resolution technologies will require interoperability across the portions of a DNS-SD Service Instance Name that are implicated in regular DNS lookups. Only some portions are implicated. In any case, if a given portion is implicated, the profile will need to apply to all labels in that portion.
DNS（包括流行的操作约定）和其他解析技术之间的任何互操作性都需要在DNS-SD服务实例名称中与常规DNS查找相关的部分之间进行互操作。仅涉及部分内容。在任何情况下，如果涉及给定部分，则配置文件将需要应用于该部分中的所有标签。
In addition, because DNS-SD Service Instance Names can be used in a domain name slot, care must be taken by DNS-SD-aware resolvers to handle the different portions as outlined here, so that DNS-SD portions that do not use IDNA2008 will not be treated as U-labels and will not accidentally undergo IDNA processing.
此外，由于DNS-SD服务实例名称可以在域名槽中使用，DNS-SD感知解析程序必须小心处理此处概述的不同部分，以便不使用IDNA2008的DNS-SD部分不会被视为U标签，也不会意外地进行IDNA处理。
Because the profile will apply to names that might appear in the public DNS, and because other resolution mechanisms (such as mDNS) could permit labels that IDNA does not, the profile might reduce the labels that could be used with those other resolution mechanisms.
由于配置文件将应用于可能出现在公共DNS中的名称，并且由于其他解析机制（如MDN）可能允许IDNA不允许的标签，因此配置文件可能会减少可与这些其他解析机制一起使用的标签。
One consequence of this is that some recommendations from [RFC6763] will not really be possible to implement using names subject to the profile. In particular, Section 4.2.3 of [RFC6763] recommends that labels always be stored and communicated as UTF-8, even in the DNS. Because of the way that the public DNS is currently operated (see Section 2), the advice to store and transmit labels as UTF-8 in the DNS is likely either to encounter problems, to result in unnecessary traffic to the public DNS, or to do both. In particular, many labels in the <Domain> part of a Service Instance Name are unlikely to be found in the UTF-8 form in the public DNS tree for zones that are using IDNA2008. By contrast, for example, mDNS exclusively uses UTF-8.
这样做的一个后果是[RFC6763]中的一些建议实际上不可能使用受概要文件约束的名称来实现。特别是，[RFC6763]的第4.2.3节建议，即使在DNS中，标签也应始终作为UTF-8进行存储和通信。由于公共DNS当前的运行方式（参见第2节），在DNS中以UTF-8的形式存储和传输标签的建议可能会遇到问题，导致公共DNS不必要的流量，或者两者兼而有之。特别是，在使用IDNA2008的区域的公共DNS树中，不太可能在UTF-8表单中找到服务实例名称的<Domain>部分中的许多标签。相比之下，例如，MDN专门使用UTF-8。
U-labels cannot contain uppercase letters (see Sections 3.1.3 and 4.2 of [RFC5894]). That restriction extends to ASCII-range uppercase letters that work fine in LDH labels. It may be confusing that the character "A" works in the DNS when none of the characters in the label has a diacritic, but it does not work when there is such a diacritic in the label. Labels in mDNS names (or other resolution technologies) may contain uppercase characters, so the profile will need either to restrict the use of uppercase or to come up with a convention for case folding (even in the presence of diacritics) that is reliable and predictable to users.
U型标签不能包含大写字母（见[RFC5894]第3.1.3节和第4.2节）。该限制扩展到ASCII范围的大写字母，在LDH标签中可以很好地工作。当标签中的所有字符都没有变音符号时，字符“A”在DNS中起作用，但当标签中有变音符号时，字符“A”不起作用，这可能会令人困惑。mDNS名称中的标签（或其他解析技术）可能包含大写字符，因此配置文件需要限制大写字符的使用，或者为用户提供可靠且可预测的大小写折叠约定（即使存在变音符号）。
Service Instance Names are made up of three portions.
服务实例名称由三部分组成。
[RFC6763] is clear that the <Instance> portion of the Service Instance Name is intended for presentation to users; therefore, virtually any character is permitted in it. There are two ways that a profile might address this portion.
[RFC6763]很清楚，服务实例名称的<Instance>部分旨在向用户展示；因此，它实际上允许任何字符。配置文件有两种方式可以处理此部分。
The first way would be to treat this portion as likely to be intercepted by system-wide IDNA-aware (but otherwise context-unaware) resolvers or likely subject to strict IDNA-conformance requirements for publication in the relevant zone. In this case, the portion would need to be made subject to the profile, thereby curtailing what characters may appear in this portion. This approach permits DNS-SD to use any standard system resolver but presents inconsistencies with the DNS-SD specification and with DNS-SD use that is exclusively mDNS-based. Therefore, this strategy is rejected.
第一种方法是将此部分视为可能被系统范围的IDNA感知（但不知道上下文）解析器截获，或者可能受到相关区域中发布的严格IDNA一致性要求的约束。在这种情况下，该部分将需要受制于该简档，从而减少该部分中可能出现的字符。此方法允许DNS-SD使用任何标准系统解析器，但与DNS-SD规范和仅基于MDN的DNS-SD使用不一致。因此，这一战略遭到拒绝。
Instead, DNS-SD implementations can intercept the <Instance> portion of a Service Instance Name and ensure that those labels are never handed to IDNA-aware resolvers that might attempt to convert these
相反，DNS-SD实现可以截取服务实例名称的<Instance>部分，并确保这些标签永远不会交给可能尝试转换这些标签的IDNA感知解析程序
labels into A-labels. Under this approach, the DNS-SD <Instance> portion works as it always does, but at the cost of using special resolution code built into the DNS-SD system. A practical consequence of this is that zone operators need to be prepared not to apply the LDH rule to all labels, and they may need to make special concessions to ensure that the <Instance> portion can contain spaces, uppercase and lowercase, and any UTF-8 code point. Otherwise, they need to prepare a user interface to handle the exceptions that would be generated. Automatic conversion to A-labels is not acceptable.
将标签转换为A标签。在这种方法下，DNS-SD<Instance>部分一如既往地工作，但代价是使用内置在DNS-SD系统中的特殊解析代码。这样做的实际结果是，区域操作员需要做好准备，不将LDH规则应用于所有标签，并且他们可能需要做出特殊让步，以确保<Instance>部分可以包含空格、大写和小写以及任何UTF-8代码点。否则，他们需要准备一个用户界面来处理将生成的异常。不接受自动转换为A标签。
It is worth noting that this advice is not actually compatible with the advice in Section 4 of [RFC6055]. That section appears to assume that names are not really composed of subsections, but because [RFC6763] specifies portions of names, the advice in this memo is to follow the advice of [RFC6055] according to the portion of the domain name, rather than for the whole domain name. As a practical matter, this means special-purpose name resolution software for DNS-SD.
值得注意的是，该建议实际上与[RFC6055]第4节中的建议不兼容。该部分似乎假设名称并非真正由子部分组成，但由于[RFC6763]指定了名称的部分，因此本备忘录中的建议是根据域名的部分遵循[RFC6055]的建议，而不是针对整个域名。实际上，这意味着DNS-SD的专用名称解析软件。
DNS-SD includes a <Service> component in the Service Instance Name. This component is not really user-facing data; instead it is control data embedded in the Service Instance Name. This component includes so-called "underscore labels", which are labels prepended with U+005F (_). The underscore label convention was established by DNS SRV ([RFC2782]) for identifying metadata inside DNS names. A system-wide resolver (or DNS middlebox) that cannot handle underscore labels will not work with DNS-SD at all, so it is safe to suppose that such resolvers will not attempt to do special processing on these labels. Therefore, the <Service> portion of the Service Instance Name will not be subject to the profile. By the same token, underscore labels are never subject to IDNA processing (they are formally incompatible); therefore, concerns about IDNA are irrelevant for these labels.
DNS-SD在服务实例名称中包含一个<Service>组件。这个组件不是真正面向用户的数据；相反，它是嵌入在服务实例名称中的控制数据。此组件包括所谓的“下划线标签”，即以U+005F（5;）开头的标签。DNS SRV（[RFC2782]）建立了下划线标签约定，用于标识DNS名称内的元数据。无法处理下划线标签的系统范围解析程序（或DNS中间件）根本无法与DNS-SD一起使用，因此可以安全地假设此类解析程序不会尝试对这些标签进行特殊处理。因此，服务实例名称的<Service>部分将不受概要文件的约束。同样，下划线标签从不接受IDNA处理（它们在形式上是不兼容的）；因此，对IDNA的关注与这些标签无关。
The <Domain> portion of the Service Instance Name forms an integral part of the owner name submitted for DNS resolution. A system-wide resolver that is IDNA2008-aware is likely to interpret labels with UTF-8 in the owner name as candidates for IDNA2008 processing. More important, operators of internationalized domain names will frequently publish such names in the public DNS as A-labels; certainly, the topmost labels will always be A-labels. Therefore, these labels will need to be subject to the profile. DNS-SD implementations ought to identify the <Domain> portion of the Service Instance Name and treat it subject to IDNA2008 in case the domain is to be queried from the global DNS. (This document does not specify
服务实例名称的<Domain>部分构成提交用于DNS解析的所有者名称的组成部分。识别IDNA2008的系统范围解析程序可能会将所有者名称中带有UTF-8的标签解释为IDNA2008处理的候选标签。更重要的是，国际化域名的运营商将经常在公共DNS中发布此类名称作为A标签；当然，最上面的标签将始终是A标签。因此，这些标签需要以配置文件为准。DNS-SD实现应该识别服务实例名称的<Domain>部分，并根据IDNA2008对其进行处理，以防从全局DNS查询域。（本文件没有具体说明
how to do that and does not alter the specification in [RFC6763].) In the event that the <Domain> portion of the Service Instance Name fails to resolve, it is acceptable to substitute labels with plain UTF-8, starting at the lowest label in the DNS tree and working toward the root. This approach would differ from the rule for resolution published in [RFC6763], because this approach privileges IDNA2008-compatible labels over UTF-8 labels. There is more than one way to achieve such a result, but in terms of predictability, it is probably best if the lowest-level resolution component is able to learn the correct resolution context so that it can perform the correct transformations on the various domain portions.
如何做到这一点，并且不改变[RFC6763]中的规范。）如果服务实例名称的<Domain>部分无法解析，可以使用普通UTF-8替换标签，从DNS树中最低的标签开始，朝着根进行操作。这种方法不同于[RFC6763]中发布的解析规则，因为这种方法优先于UTF-8标签，而优先于IDNA2008兼容标签。实现这种结果的方法不止一种，但就可预测性而言，如果最低级别的分辨率组件能够学习正确的分辨率上下文，以便能够在各个域部分上执行正确的转换，则可能是最好的。
One might argue against the above restriction on either of two grounds:
有人可能会基于以下两个理由反对上述限制：
1. It is possible that the names may be in the DNS in UTF-8, and RFC 6763 already specifies a fallback strategy of progressively attempting first the UTF-8 label lookup (it might not be a U-label) and then, if possible, the A-label lookup.
1. 名称可能位于UTF-8中的DNS中，并且RFC 6763已经指定了一种回退策略，即先逐步尝试UTF-8标签查找（可能不是U标签），然后，如果可能，再尝试a标签查找。
2. Zone administrators that wish to support DNS-SD can publish a UTF-8 version of the zone along side the A-label version of the zone.
2. 希望支持DNS-SD的区域管理员可以在区域的a标签版本旁边发布该区域的UTF-8版本。
The first of these is rejected because it represents a potentially significant increase in DNS lookup traffic. It is possible for a DNS-SD application to identify the <Domain> portion of the Service Instance Name. The standard way to publish IDNs on the Internet uses IDNA. Therefore, additional lookups should not be encouraged. When [RFC6763] was published, the bulk of IDNs were lower in the tree. Now that there are internationalized labels in the root zone, it is desirable to minimize queries to the Internet infrastructure if they are sure to be answered in the negative.
第一个被拒绝，因为它代表DNS查找流量的潜在显著增加。DNS-SD应用程序可以识别服务实例名称的<Domain>部分。在Internet上发布IDN的标准方法使用IDNA。因此，不应鼓励额外的查找。[RFC6763]发布时，大部分IDN在树中的位置较低。现在根区域中有了国际化的标签，如果对Internet基础设施的查询肯定是否定的，那么最好将其最小化。
The second reason depends on the idea that it is possible to maintain two names in sync with one another. This is not strictly speaking true, although in this case the domain operator could simply create a DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. This still, however, relies on being able to reach the (UTF-8) name in question, and it is unlikely that the UTF-8 version of the zone will be delegated from anywhere. Moreover, in many organizations, the support for DNS-SD and the support for domain name delegations are not performed by the same department; depending on a coordination between the two will make the system more fragile, slower, or both.
第二个原因取决于这样一种想法，即可以保持两个名称之间的同步。严格来说，这不是事实，尽管在这种情况下，域操作员可以简单地创建一个从UTF-8名称到IDNA2008区域的DNAME记录[RFC6672]。然而，这仍然依赖于能够访问所讨论的（UTF-8）名称，而且不太可能从任何地方委派UTF-8版本的区域。此外，在许多组织中，对DNS-SD的支持和对域名授权的支持不是由同一部门执行的；取决于两者之间的协调，这将使系统更加脆弱、缓慢，或者两者兼而有之。
Some resolvers -- particularly those that are used in mixed DNS and non-DNS environments -- may be aware of different operational conventions in different parts of the DNS tree. For example, it may
一些解析器——特别是那些在混合DNS和非DNS环境中使用的解析器——可能知道DNS树的不同部分中存在不同的操作约定。例如，它可能
be possible for implementations to use hints about the boundary of an organization's domain name infrastructure in order to tell, for instance, that example.com. is part of the Example Organization, while com. is a large delegation-centric zone on the public Internet. In such cases, the resolution system might reverse its preferences to prefer plain UTF-8 labels when resolving names below the boundary point in the DNS tree. The result would be that any lookup past the boundary point and closer to the root would use LDH labels first, falling back to UTF-8 only after a failure; but a lookup below the boundary point would use UTF-8 labels first, and try other strategies only in case of negative answers. The mechanism to learn such a boundary is beyond the scope of this document.
实现可以使用关于组织域名基础设施边界的提示，例如，告诉example.com。是示例组织的一部分，而com。是公共互联网上一个大型的以代表团为中心的区域。在这种情况下，解析系统在解析DNS树中边界点以下的名称时，可能会将其首选项反转为首选纯UTF-8标签。结果是，任何超过边界点且靠近根的查找都将首先使用LDH标签，只有在失败后才返回UTF-8；但是在边界点以下的查找将首先使用UTF-8标签，并且只有在回答否定的情况下才尝试其他策略。了解这种界限的机制超出了本文件的范围。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
This memo presents some requirements for future development, but does not specify anything. It makes no additional security-specific requirements. Issues arising due to visual confusability of names apply to this case as well as to any other case of internationalized names, but interoperation between different resolution systems and conventions does not alter the severity of those issues.
这份备忘录提出了未来发展的一些要求，但没有具体说明。它没有附加特定于安全性的要求。由于名称的视觉混淆而产生的问题适用于本案例以及任何其他国际化名称案例，但不同解析系统和约定之间的互操作不会改变这些问题的严重性。
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，DOI 10.17487/RFC0952，1985年10月<https://www.rfc-editor.org/info/rfc952>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<https://www.rfc-editor.org/info/rfc2181>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 5198，DOI 10.17487/RFC5198，2008年3月<https://www.rfc-editor.org/info/rfc5198>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.
[RFC5892]Faltstrom，P.，Ed.“Unicode码点和应用程序的国际化域名（IDNA）”，RFC 5892，DOI 10.17487/RFC5892，2010年8月<https://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.
[RFC5893]Alvestrand，H.，Ed.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 5893，DOI 10.17487/RFC5893，2010年8月<https://www.rfc-editor.org/info/rfc5893>.
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.
[RFC5894]Klensin，J.，“应用程序的国际化域名（IDNA）：背景、解释和理由”，RFC 5894，DOI 10.17487/RFC5894，2010年8月<https://www.rfc-editor.org/info/rfc5894>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <https://www.rfc-editor.org/info/rfc5895>.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 5895，DOI 10.17487/RFC5895，2010年9月<https://www.rfc-editor.org/info/rfc5895>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, DOI 10.17487/RFC6055, February 2011, <https://www.rfc-editor.org/info/rfc6055>.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 6055，DOI 10.17487/RFC6055，2011年2月<https://www.rfc-editor.org/info/rfc6055>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 6672，DOI 10.17487/RFC6672，2012年6月<https://www.rfc-editor.org/info/rfc6672>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<https://www.rfc-editor.org/info/rfc7719>.
Acknowledgments
致谢
The author gratefully acknowledges the insights of Joe Abley, Stuart Cheshire, Paul Hoffman, Warren Kumari, Eliot Lear, Kerry Lynn, Juergen Schoenwaelder, and Dave Thaler. Kerry Lynn deserves special gratitude for his energy and persistence in pressing unanswered questions. Doug Otis sent many comments about visual confusability.
作者衷心感谢乔·艾布利、斯图亚特·切希尔、保罗·霍夫曼、沃伦·库马里、艾略特·李尔、克里·林恩、尤尔根·舍恩瓦埃尔德和戴夫·泰勒的见解。克里·林恩在紧迫的未回答问题上的精力和毅力值得特别感谢。道格·奥蒂斯（Doug Otis）就视觉混乱问题发表了许多评论。
Author's Address
作者地址
Andrew Sullivan Oracle Corporation 100 Milverton Drive Mississauga, ON L5R 4H1 Canada
Andrew Sullivan Oracle Corporation位于加拿大米西沙加米尔弗顿大道100号，L5R 4H1
Email: andrew.s.sullivan@oracle.com
Email: andrew.s.sullivan@oracle.com