RFC 8222 - Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8222
タイトル : RFC 8222 - DNSベースのサービス検出で従来のDNSおよびその他の解決システムで使用するラベルを選択する
翻訳編集 : 自動生成

[要約] RFC 8222は、DNSベースのサービスディスカバリにおいて、従来のDNSや他の解決システムで使用するためのラベルの選択に関するものです。このRFCの目的は、サービスディスカバリのための効果的なラベルの選択方法を提供することです。

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.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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

1. はじめに

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（mDNSなどのドメイン名を使用するその他のシステム）へのクエリを使用してサービスを検出するメカニズムを指定します。 [RFC6762]）。 DNSを使用する多くのアプリケーションは、ラベルの「インターネットホスト名」構文[RFC952]-いわゆるLDH（文字、数字、ハイフン）ルール-に従います。その規則が、アプリケーションの国際化ドメイン名（IDNA2008、[RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]、[RFC5894]、および[RFC5895]）の開発の背後にある理由です。 LDHルールは規則であり、DNSのルールではないことに注意してください。これは、[RFC2181]のセクション11によって完全に明確にされており、[RFC6055]のセクション3でさらに説明されています。それにもかかわらず、LDHルールに従わない限り、多くの状況でドメイン名をDNSで使用できないと広く信じられています。

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を参照）。コードポイントがNet-Unicode [RFC5198]形式のUTF-8である限り、これらのラベルで使用できるUnicodeコードポイントは制限されません。

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.

これらの状況での相互運用性への1つのアプローチは、異なるネーミングシステムでのドメイン名に単一の操作規則（「プロファイル」）を使用することです。このメモは、そのような使用プロファイルを想定しており、特定のテクノロジーを指定せずにそれを機能させるために必要なものを概説しようとします。ただし、グローバル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ラベル/ Uラベルの分割（以下を参照）をもたらすようなアプリケーションの考慮事項は、DNS-SDの完全な正しいアプローチではありません。

1.1. Conventions and Terms Used in This Document

1.1. このドキュメントで使用される規則と用語

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コードポイントのU + NNNN表記、およびUnicodeコードポイントを扱う他のドキュメントに精通していると想定されます。簡潔さと一貫性のために、ここでは定義を繰り返しません。

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.

LDHルールとIDNA2008が厳密な要件であるかのように、このメモはDNS内の名前を参照する場合があります。ではない。 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を使用して検索されませんが、mDNSを使用して検索されます。

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リソースレコードの所有者名の3つの部分を指定します。これらは、<Instance>部分、<Service>部分、および<Domain>部分です。これら3つの部分で構成される所有者名は、「サービスインスタンス名」と呼ばれます。 1つの部分が複数のラベルの長さになる可能性があることに注意してください。 [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が本文に記載されている場合はどこでも読み取ることができます。

2. Why There Could Be a Problem at All

2. なぜ問題があるのか

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

トラブルの理由は二つあります。まず、最も厄介なのは、システム全体にIDNAサービスを提供しようとするリゾルバーの可能性です。 IDNA2008の設計を考えると、一部のシステムでは、高レベルの名前解決ライブラリがUラベル/ Aラベル変換を自動的に実行し、これらの詳細からアプリケーションを保存すると想定するのが妥当です。ただし、システムレベルのサービスは、常に解決コンテキストを利用できるとは限らず、アプリケーションを支援するのではなく、失敗するような方法で変換を適用する場合があります。もちろん、これが主な問題である場合、正しい答えは「これらのライブラリを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]を参照してください。

3. Requirements for a Profile for Label Interoperation

3. ラベルの相互運用のためのプロファイルの要件

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ルックアップに関係するDNS-SDサービスインスタンス名の部分全体の相互運用性が必要です。一部のみが関係しています。いずれの場合も、特定の部分が関係している場合、プロファイルはその部分のすべてのラベルに適用する必要があります。

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に表示される可能性のある名前に適用され、他の解決メカニズム（mDNSなど）が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.

この結果の1つは、[RFC6763]からのいくつかの推奨事項は、プロファイルの対象となる名前を使用して実装することは実際には不可能であることです。特に、[RFC6763]のセクション4.2.3では、DNSであっても、ラベルは常にUTF-8として保存および通信することを推奨しています。現在パブリックDNSが運用されている方法（セクション2を参照）のため、DNSにラベルをUTF-8として保存および送信するためのアドバイスは、問題が発生するか、パブリックDNSへの不要なトラフィックが発生するか、または両方を行います。特に、サービスインスタンス名の<ドメイン>部分にある多くのラベルが、IDNA2008を使用しているゾーンのパブリックDNSツリーのUTF-8形式で見つかることはほとんどありません。対照的に、たとえば、mDNSは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を参照）。その制限は、LDHラベルで正常に機能するASCII範囲の大文字にまで及びます。ラベルの文字に分音符号がない場合、文字「A」はDNSで機能しますが、ラベルにそのような分音符号がある場合は機能しません。 mDNS名（または他の解決技術）のラベルには大文字が含まれている可能性があるため、プロファイルでは大文字の使用を制限するか、大文字と小文字を区別する（発音区別符号が存在する場合でも）信頼性が高く予測可能な規則を考案する必要があります。ユーザーに。

4. DNS-SD Portions

4. DNS-SD部分

Service Instance Names are made up of three portions.

サービスインスタンス名は3つの部分で構成されます。

4.1. The <Instance> Portion of the Service Instance Name

4.1. サービスインスタンス名の<Instance>部分

[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>部分がユーザーへの提示を目的としていることは明らかです。したがって、事実上すべての文字が許可されています。プロファイルがこの部分に対処する方法は2つあります。

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仕様と、mDNSベースのみである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 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.

代わりに、DNS-SD実装は、サービスインスタンス名の<Instance>部分をインターセプトして、これらのラベルがこれらのラベルをAラベルに変換しようとする可能性のあるIDNA対応リゾルバーに渡されないようにします。このアプローチでは、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用の専用の名前解決ソフトウェアを意味します。

4.2. The <Service> Portion of the Service Instance Name

4.2. サービスインスタンス名の<Service>部分

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（_）が前に付いたラベルが含まれます。アンダースコアラベル規則は、DNS SRV（[RFC2782]）によって、DNS名内のメタデータを識別するために確立されました。アンダースコアラベルを処理できないシステム全体のリゾルバー（またはDNSミドルボックス）はDNS-SDではまったく機能しないため、そのようなリゾルバーはこれらのラベルに対して特別な処理を行わないと想定しても安全です。したがって、サービスインスタンス名の<Service>部分はプロファイルの影響を受けません。同様に、アンダースコアラベルはIDNA処理の対象にはなりません（形式的に互換性がありません）。したがって、IDNAに関する懸念はこれらのラベルには無関係です。

4.3. The <Domain> Portion of the Service Instance Name

4.3. サービスインスタンス名の<ドメイン>部分

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

サービスインスタンス名の<ドメイン>部分は、DNS解決のために送信される所有者名の不可欠な部分を形成します。 IDNA2008対応のシステム全体のリゾルバーは、所有者名にUTF-8が含まれるラベルをIDNA2008処理の候補として解釈する可能性があります。さらに重要なことに、国際化ドメイン名のオペレーターは、そのような名前をAラベルとしてパブリックDNSに頻繁に公開します。確かに、一番上のラベルは常にAラベルになります。したがって、これらのラベルはプロファイルの対象となる必要があります。 DNS-SD実装は、サービスインスタンス名の<ドメイン>部分を識別し、ドメインがグローバルDNSからクエリされる場合に備えて、それをIDNA2008に従って処理する必要があります。（このドキュメントでは、その方法を指定せず、[RFC6763]の仕様を変更しません。）サービスインスタンス名の<Domain>部分が解決できない場合は、ラベルをプレーンなUTF-で置き換えることができます8、DNSツリーの最下位ラベルから始まり、ルートに向かって作業します。このアプローチは、UTF-8ラベルよりもIDNA2008互換ラベルを優先するため、[RFC6763]で公開されている解決のルールとは異なります。このような結果を達成する方法は複数ありますが、予測可能性の観点からは、さまざまなドメイン部分で正しい変換を実行できるように、最低レベルの解決コンポーネントが正しい解決コンテキストを学習できることがおそらく最良です。。

One might argue against the above restriction on either of two grounds:

次の2つの理由のいずれかに関する上記の制限に反対する可能性があります。

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. 名前がDNSにUTF-8で含まれている可能性があり、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.

これらの1つ目は、DNSルックアップトラフィックが大幅に増加する可能性があるため、拒否されます。 DNS-SDアプリケーションは、サービスインスタンス名の<ドメイン>部分を識別できます。インターネット上でIDNを公開する標準的な方法では、IDNAを使用します。したがって、追加のルックアップは推奨されません。 [RFC6763]が公開されたとき、IDNの大部分はツリーの下位にありました。ルートゾーンに国際化されたラベルがあるので、否定的に答えられることが確実な場合は、インターネットインフラストラクチャへのクエリを最小限に抑えることが望ましいです。

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.

2番目の理由は、2つの名前を互いに同期して維持することが可能であるという考えに依存します。これは厳密には正しくありませんが、この場合、ドメインオペレーターは、UTF-8名からIDNA2008ゾーンへのDNAMEレコード[RFC6672]を簡単に作成できます。ただし、これは問題の（UTF-8）名に到達できることに依存しているため、ゾーンのUTF-8バージョンがどこからでも委任されることはほとんどありません。さらに、多くの組織では、DNS-SDのサポートとドメイン名委任のサポートが同じ部門で実行されていません。 2つの間の調整に応じて、システムはより壊れやすく、遅くなり、またはその両方になります。

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

一部のリゾルバー（特に、DNSと非DNSの混合環境で使用されるリゾルバー）は、DNSツリーのさまざまな部分でのさまざまな操作規則を認識している場合があります。たとえば、example.comなどに伝えるために、実装が組織のドメイン名インフラストラクチャの境界に関するヒントを使用することが可能である場合があります。は組織例の一部ですが、comです。パブリックインターネット上の大きな委任中心のゾーンです。そのような場合、解決システムは、DNSツリーの境界ポイントより下の名前を解決するときに、プレーンUTF-8ラベルを優先するように設定を逆にする可能性があります。その結果、境界ポイントを超えてルートに近いルックアップでは、最初にLDHラベルが使用され、失敗した場合にのみUTF-8にフォールバックします。ただし、境界ポイントより下のルックアップでは最初にUTF-8ラベルが使用され、否定的な回答の場合にのみ他の戦略が試されます。このような境界を学習するメカニズムは、このドキュメントの範囲外です。

5. IANA Considerations

5. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

6. Security Considerations

6. セキュリティに関する考慮事項

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.

このメモは、将来の開発のためのいくつかの要件を示していますが、何も指定していません。追加のセキュリティ固有の要件はありません。名前の視覚的な混同性に起因して発生する問題は、この場合だけでなく、国際化された名前の他のどの場合にも当てはまりますが、異なる解決システムと規則の間の相互運用は、これらの問題の重大度を変更しません。

7. Informative References

7. 参考引用

[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、「DoD Internet host table specification」、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、「Clarifications to the DNS Specification」、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 RR（DNS SRV）」、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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、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。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、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。、編、「アプリケーションの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]アルベストランド、H。、エド。およびC. Karp、「Right-to-Left Scripts for Internationalized Domain Names for Applications（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、「DNAME Redirection in the DNS」、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]チェシャーS.およびM.クロマル、「マルチキャスト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. Krochmal、「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 / RFC7719、2015年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.

著者は、Joe Abley、Stuart Cheshire、Paul Hoffman、Warren Kumari、Eliot Lear、Kerry Lynn、Juergen Schoenwaelder、およびDave Thalerの洞察に感謝の意を表します。ケリー・リンは、彼のエネルギーと粘り強く未回答の質問に粘り強く感謝します。 Doug Otisは、視覚的な混乱について多くのコメントを送信しました。

Author's Address

著者のアドレス

Andrew Sullivan Oracle Corporation 100 Milverton Drive Mississauga, ON L5R 4H1 Canada

アンドリューサリバンオラクルコーポレーション100 Milverton Driveミシソーガ、オンタリオ州L5R 4H1カナダ

   Email: andrew.s.sullivan@oracle.com