[要約] RFC 6763は、DNSベースのサービスディスカバリに関する標準仕様であり、ネットワーク上のデバイスやサービスの自動検出を可能にします。その目的は、ユーザーが手動で設定することなく、ネットワーク内の利用可能なサービスを自動的に見つけることです。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6763 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
DNS-Based Service Discovery
DNSベースのサービス検出
Abstract
概要
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
このドキュメントでは、サービスの検出を容易にするために、DNSリソースレコードの名前と構造を指定します。クライアントが探しているサービスの種類と、クライアントがそのサービスを探しているドメインが与えられた場合、このメカニズムにより、クライアントは標準のDNSクエリを使用して、目的のサービスの名前付きインスタンスのリストを検出できます。このメカニズムは、DNSベースのサービス検出（DNS-SD）と呼ばれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6763.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6763で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............5
3. Design Goals ....................................................5
4. Service Instance Enumeration (Browsing) .........................6
4.1. Structured Service Instance Names ..........................6
4.2. User Interface Presentation ................................9
4.3. Internal Handling of Names .................................9
5. Service Instance Resolution ....................................10
6. Data Syntax for DNS-SD TXT Records .............................11
6.1. General Format Rules for DNS TXT Records ..................11
6.2. DNS-SD TXT Record Size ....................................12
6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13
6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14
6.5. Rules for Values in DNS-SD Key/Value Pairs ................16
6.6. Example TXT Record ........................................17
6.7. Version Tag ...............................................17
6.8. Service Instances with Multiple TXT Records ...............18
7. Service Names ..................................................19
7.1. Selective Instance Enumeration (Subtypes) .................21
7.2. Service Name Length Limits ................................23
8. Flagship Naming ................................................25
9. Service Type Enumeration .......................................27
10. Populating the DNS with Information ...........................27
11. Discovery of Browsing and Registration Domains (Domain
Enumeration) ..................................................28
12. DNS Additional Record Generation ..............................30
12.1. PTR Records ..............................................30
12.2. SRV Records ..............................................30
12.3. TXT Records ..............................................31
12.4. Other Record Types .......................................31
13. Working Examples ..............................................31
13.1. What web pages are being advertised from dns-sd.org? .....31
13.2. What printer-configuration web pages are there? ..........31
13.3. How do I access the web page called "Service
Discovery"? ..............................................32
14. IPv6 Considerations ...........................................32
15. Security Considerations .......................................32
16. IANA Considerations ...........................................32
17. Acknowledgments ...............................................33
18. References ....................................................33
18.1. Normative References .....................................33
18.2. Informative References ...................................34
Appendix A. Rationale for Using DNS as a Basis for Service
Discovery .............................................37
Appendix B. Ordering of Service Instance Name Components ..........38
B.1. Semantic Structure ........................................38
B.2. Network Efficiency ........................................39
B.3. Operational Flexibility ...................................39
Appendix C. What You See Is What You Get ..........................40
Appendix D. Choice of Factory-Default Names .......................42
Appendix E. Name Encodings in the Domain Name System ..............44
Appendix F. "Continuous Live Update" Browsing Model ...............45
Appendix G. Deployment History ....................................47
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
このドキュメントでは、サービスの検出を容易にするために、DNSリソースレコードの名前と構造を指定します。クライアントが探しているサービスの種類と、クライアントがそのサービスを探しているドメインが与えられた場合、このメカニズムにより、クライアントは標準のDNSクエリを使用して、目的のサービスの名前付きインスタンスのリストを検出できます。このメカニズムは、DNSベースのサービス検出（DNS-SD）と呼ばれます。
This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values.
このドキュメントでは、DNSメッセージの構造、および新しいオペレーションコード、レスポンスコード、リソースレコードタイプ、またはその他の新しいDNSプロトコル値への変更は提案していません。
This document specifies that a particular service instance can be described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. The SRV record has a name of the form "<Instance>.<Service>.<Domain>" and gives the target host and port where the service instance can be reached. The DNS TXT record of the same name gives additional information about this instance, in a structured form using key/value pairs, described in Section 6. A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "<Service>.<Domain>", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs.
このドキュメントでは、特定のサービスインスタンスがDNS SRV [RFC2782]およびDNS TXT [RFC1035]レコードを使用して記述できることを指定しています。 SRVレコードには、「<Instance>。<Service>。<Domain>」という形式の名前があり、サービスインスタンスに到達できるターゲットホストとポートを示します。同じ名前のDNS TXTレコードは、セクション6で説明されているキー/値ペアを使用した構造化された形式で、このインスタンスに関する追加情報を提供します。クライアントは、DNS PTRのクエリを使用して、特定のサービスタイプの使用可能なインスタンスのリストを検出します[RFC1035]「<Service>。<Domain>」という形式の名前を持つレコード。これは、前述のDNS SRV / TXTレコードペアの名前である0個以上の名前のセットを返します。
This specification is compatible with both Multicast DNS [RFC6762] and with today's existing Unicast DNS server and client software.
この仕様は、マルチキャストDNS [RFC6762]と今日の既存のユニキャストDNSサーバーおよびクライアントソフトウェアの両方と互換性があります。
When used with Multicast DNS, DNS-SD can provide zero-configuration operation -- just connect a DNS-SD/mDNS device, and its services are advertised on the local link with no further user interaction [ZC].
マルチキャストDNSとともに使用すると、DNS-SDはゼロ構成操作を提供できます。DNS-SD/ mDNSデバイスを接続するだけで、そのサービスはユーザーインタラクションなしでローカルリンクでアドバタイズされます[ZC]。
When used with conventional Unicast DNS, some configuration will usually be required -- such as configuring the device with the DNS domain(s) in which it should advertise its services, and configuring it with the DNS Update [RFC2136] [RFC3007] keys to give it permission to do so. In rare cases, such as a secure corporate network behind a firewall where no DNS Update keys are required, zero-configuration operation may be achieved by simply having the device register its services in a default registration domain learned from the network (see Section 11, "Discovery of Browsing and Registration Domains"), but this is the exception and usually security credentials will be required to perform DNS updates.
従来のユニキャストDNSで使用する場合、通常はいくつかの構成が必要になります。たとえば、サービスをアドバタイズするDNSドメインでデバイスを構成したり、DNS更新[RFC2136] [RFC3007]キーで構成したりします。許可を与えてください。 DNS更新キーが不要なファイアウォールの背後にある安全な企業ネットワークなどのまれなケースでは、ネットワークから学習したデフォルトの登録ドメインにデバイスのサービスを登録するだけで、構成なしの操作を実現できます（セクション11を参照）。 「ブラウジングと登録ドメインの検出」）、ただしこれは例外であり、通常、DNS更新を実行するにはセキュリティ資格情報が必要です。
Note that when using DNS-SD with Unicast DNS, the Unicast DNS-SD service does NOT have to be provided by the same DNS server hardware that is currently providing an organization's conventional host name lookup service. While many people think of "DNS" exclusively in the context of mapping host names to IP addresses, in fact, "the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose" [RFC2181]. By delegating the "_tcp" and "_udp" subdomains, all the workload related to DNS-SD can be offloaded to a different machine. This flexibility, to handle DNS-SD on the main DNS server or not, at the network administrator's discretion, is one of the benefits of using DNS.
ユニキャストDNSでDNS-SDを使用する場合、ユニキャストDNS-SDサービスは、組織の従来のホスト名参照サービスを現在提供しているのと同じDNSサーバーハードウェアによって提供される必要はないことに注意してください。多くの人々はホスト名をIPアドレスにマッピングするコンテキストでのみ「DNS」について考えていますが、実際、「DNSは一般的な（多少制限がある場合）階層型データベースであり、ほとんどすべての種類のデータをほぼすべての目的で保存できます「[RFC2181]。 「_tcp」および「_udp」サブドメインを委任することにより、DNS-SDに関連するすべてのワークロードを別のマシンにオフロードできます。メインのDNSサーバーでDNS-SDを処理するかどうかにかかわらず、ネットワーク管理者の裁量により、この柔軟性はDNSを使用する利点の1つです。
Even when the DNS-SD functions are delegated to a different machine, the benefits of using DNS remain: it is mature technology, well understood, with multiple independent implementations from different vendors, a wide selection of books published on the subject, and an established workforce experienced in its operation. In contrast, adopting some other service discovery technology would require every site in the world to install, learn, configure, operate, and maintain some entirely new and unfamiliar server software. Faced with these obstacles, it seems unlikely that any other service discovery technology could hope to compete with the ubiquitous deployment that DNS already enjoys. For further discussion, see Appendix A, "Rationale for Using DNS as a Basis for Service Discovery".
DNS-SD機能が別のマシンに委任されている場合でも、DNSを使用することの利点は残ります。これは成熟したテクノロジーであり、よく理解されています。さまざまなベンダーからの複数の独立した実装、このテーマについて出版された幅広い書籍、および確立されたその操作で経験した労働力。対照的に、他のいくつかのサービスディスカバリテクノロジーを採用するには、世界中のすべてのサイトで、まったく新しくなじみのないサーバーソフトウェアをインストール、学習、構成、運用、および保守する必要があります。これらの障害に直面すると、他のサービスディスカバリテクノロジーが、DNSがすでに享受しているユビキタスな展開と競争することを期待できる可能性は低いようです。詳細については、付録A「サービス検出の基礎としてDNSを使用する根拠」を参照してください。
This document is written for two audiences: for developers creating application software that offers or accesses services on the network, and for developers creating DNS-SD libraries to implement the advertising and discovery mechanisms. For both audiences, understanding the entire document is helpful. For developers creating application software, this document provides guidance on choosing instance names, service names, and other aspects that play a role in creating a good overall user experience. However, also understanding the underlying DNS mechanisms used to provide the service discovery facilities helps application developers understand the capabilities and limitations of those underlying mechanisms (e.g., name length limits). For library developers writing software to construct the DNS records (to advertise a service) and generate the DNS queries (to discover and use a service), understanding the ultimate user-experience goals helps them provide APIs that can meet those goals.
このドキュメントは、ネットワーク上のサービスを提供またはアクセスするアプリケーションソフトウェアを作成する開発者と、アドバタイズおよび検出メカニズムを実装するDNS-SDライブラリを作成する開発者の2人を対象としています。両方の読者にとって、ドキュメント全体を理解することは役に立ちます。アプリケーションソフトウェアを作成する開発者向けに、このドキュメントでは、インスタンス名、サービス名、および全体的な優れたユーザーエクスペリエンスの作成に役割を果たす他の側面の選択に関するガイダンスを提供します。ただし、サービスディスカバリ機能を提供するために使用される基礎となるDNSメカニズムを理解することも、アプリケーション開発者がそれらの基礎となるメカニズムの機能と制限（名前の長さの制限など）を理解するのに役立ちます。 （サービスを宣伝するために）DNSレコードを構築し、（サービスを発見して使用するために）DNSクエリを生成するソフトウェアを作成する図書館開発者にとって、究極のユーザー体験の目標を理解することは、それらの目標を達成できるAPIを提供するのに役立ちます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 「要件レベルを示すためのRFCで使用するキーワード」[RFC2119]で説明されているように解釈されます。
Of the many properties a good service discovery protocol needs to have, three of particular importance are:
優れたサービスディスカバリプロトコルに必要な多くのプロパティのうち、特に重要な3つは次のとおりです。
(i) The ability to query for services of a certain type in a certain logical domain, and receive in response a list of named instances (network browsing or "Service Instance Enumeration").
（i）特定の論理ドメイン内の特定のタイプのサービスを照会し、それに応答して名前付きインスタンスのリストを受信する機能（ネットワーク参照または「サービスインスタンス列挙」）。
(ii) Given a particular named instance, the ability to efficiently resolve that instance name to the required information a client needs to actually use the service, i.e., IP address and port number, at the very least (Service Instance Resolution).
（ii）特定の名前付きインスタンスが与えられた場合、クライアントがサービスを実際に使用するために最低限必要な情報、つまりIPアドレスとポート番号にそのインスタンス名を効率的に解決する機能（サービスインスタンスの解決）。
(iii) Instance names should be relatively persistent. If a user selects their default printer from a list of available choices today, then tomorrow they should still be able to print on that printer -- even if the IP address and/or port number where the service resides have changed -- without the user (or their software) having to repeat the step (i) (the initial network browsing) a second time.
（iii）インスタンス名は比較的永続的である必要があります。ユーザーが今日利用可能な選択肢のリストからデフォルトプリンターを選択した場合、明日はユーザーがいなくても、サービスが存在するIPアドレスやポート番号が変更されていても、明日もそのプリンターで印刷できるはずです。 （またはそのソフトウェア）ステップ（i）（最初のネットワーク参照）を2回繰り返す必要があります。
In addition, if it is to become successful, a service discovery protocol should be so simple to implement that virtually any device capable of implementing IP should not have any trouble implementing the service discovery software as well.
さらに、サービスディスカバリプロトコルを成功させるには、サービスディスカバリプロトコルを非常に簡単に実装できる必要があります。そのため、IPを実装できる実質的にすべてのデバイスで、サービスディスカバリソフトウェアの実装にも問題はありません。
These goals are discussed in more detail in the remainder of this document. A more thorough treatment of service discovery requirements may be found in "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760]. That document draws upon examples from two decades of operational experience with AppleTalk to develop a list of universal requirements that are broadly applicable to any potential service discovery protocol.
これらの目標については、このドキュメントの残りの部分で詳しく説明します。 「AppleTalkネームバインディングプロトコル（NBP）を置き換えるためのプロトコルの要件」[RFC6760]に、サービスディスカバリの要件のより完全な扱いがあります。このドキュメントは、AppleTalkの20年に及ぶ運用経験の例を利用して、潜在的なサービス検出プロトコルに広く適用できる普遍的な要件のリストを作成します。
Traditional DNS SRV records [RFC2782] are useful for locating instances of a particular type of service when all the instances are effectively indistinguishable and provide the same service to the client.
従来のDNS SRVレコード[RFC2782]は、すべてのインスタンスが事実上区別できず、同じサービスをクライアントに提供する場合に、特定のタイプのサービスのインスタンスを見つけるのに役立ちます。
For example, SRV records with the (hypothetical) name "_http._tcp.example.com." would allow a client to discover servers implementing the "_http._tcp" service (i.e., web servers) for the "example.com." domain. The unstated assumption is that all these servers offer an identical set of web pages, and it doesn't matter to the client which of the servers it uses, as long as it selects one at random according to the weight and priority rules laid out in the DNS SRV specification [RFC2782].
たとえば、「架空の」名前が「_http._tcp.example.com」であるSRVレコード。クライアントは、「example.com」の「_http._tcp」サービスを実装しているサーバー（つまり、Webサーバー）を検出できます。ドメイン。明言されていない仮定は、これらすべてのサーバーが同一のWebページのセットを提供することであり、クライアントが使用するサーバーのどれがクライアントに重要でなくても、レイアウトされた重みと優先順位ルールに従ってランダムに1つを選択します。 DNS SRV仕様[RFC2782]。
Instances of other kinds of service are less easily interchangeable. If a word processing application were to look up the (hypothetical) SRV record "_ipp._tcp.example.com." to find the list of Internet Printing Protocol (IPP) [RFC2910] printers at Example Co., then picking one at random and printing on it would probably not be what the user wanted.
他の種類のサービスのインスタンスは、互換性が低くなります。ワープロアプリケーションが（架空の）SRVレコード「_ipp._tcp.example.com」を検索する場合。 Example Co.でインターネット印刷プロトコル（IPP）[RFC2910]プリンタのリストを検索し、ランダムに1つを選択して印刷すると、ユーザーが望んだものとはおそらく異なります。
The remainder of this section describes how SRV records may be used in a slightly different way, to allow a user to discover the names of all available instances of a given type of service, and then select, from that list, the particular instance they desire.
このセクションの残りの部分では、SRVレコードをわずかに異なる方法で使用して、ユーザーが特定のタイプのサービスのすべての使用可能なインスタンスの名前を検出し、そのリストから希望する特定のインスタンスを選択する方法について説明します。
This document borrows the logical service-naming syntax and semantics from DNS SRV records, but adds one level of indirection. Instead of requesting records of type "SRV" with name "_ipp._tcp.example.com.", the client requests records of type "PTR" (pointer from one name to another in the DNS namespace) [RFC1035].
このドキュメントでは、DNS SRVレコードから論理サービスの名前付け構文とセマンティクスを借用していますが、1レベルの間接参照を追加しています。 「_ipp._tcp.example.com。」という名前の「SRV」タイプのレコードを要求する代わりに、クライアントは「PTR」タイプ（DNS名前空間内のある名前から別の名前へのポインター）[RFC1035]のレコードを要求します。
In effect, if one thinks of the domain name "_ipp._tcp.example.com." as being analogous to an absolute path to a directory in a file system, then DNS-SD's PTR lookup is akin to performing a listing of that directory to find all the entries it contains. (Remember that domain names are expressed in reverse order compared to path names -- an absolute path name starts with the root on the left and is read from left to right, whereas a fully qualified domain name starts with the root on the right and is read from right to left. If the fully qualified domain name "_ipp._tcp.example.com." were expressed as a file system path name, it would be "/com/example/_tcp/_ipp".) The result of this PTR lookup for the name "<Service>.<Domain>" is a set of zero or more PTR records giving Service Instance Names of the form:
実際、「_ ipp._tcp.example.com」というドメイン名を考えると、ファイルシステム内のディレクトリへの絶対パスに類似しているため、DNS-SDのPTRルックアップは、そのディレクトリのリストを実行して、そこに含まれるすべてのエントリを見つけるのと同じです。 （ドメイン名はパス名とは逆の順序で表現されることに注意してください-絶対パス名は左側のルートで始まり、左から右に読み取られますが、完全修飾ドメイン名は右側のルートで始まり、右から左に読みます。完全修飾ドメイン名「_ipp._tcp.example.com。」がファイルシステムのパス名として表現された場合、「/ com / example / _tcp / _ipp」になります。）この結果"<Service>。<Domain>"という名前のPTRルックアップは、次の形式のサービスインスタンス名を示す0個以上のPTRレコードのセットです。
Service Instance Name = <Instance> . <Service> . <Domain>
For explanation of why the components are in this order, see Appendix B, "Ordering of Service Instance Name Components".
コンポーネントがこの順序になっている理由については、付録B「サービスインスタンス名コンポーネントの順序」を参照してください。
The <Instance> portion of the Service Instance Name is a user-friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It MUST NOT contain ASCII control characters (byte values 0x00-0x1F and 0x7F) [RFC20] but otherwise is allowed to contain any characters, without restriction, including spaces, uppercase, lowercase, punctuation -- including dots -- accented characters, non-Roman text, and anything else that may be represented using Net-Unicode. For discussion of why the <Instance> name should be a user-visible, user-friendly name rather than an invisible machine-generated opaque identifier, see Appendix C, "What You See Is What You Get".
サービスインスタンス名の<Instance>部分は、任意のNet-Unicodeテキスト[RFC5198]で構成される使いやすい名前です。 ASCII制御文字（バイト値0x00-0x1Fおよび0x7F）[RFC20]を含めることはできませんが、スペース、大文字、小文字、句読点（ドットを含む）、アクセント付き文字、非ローマ字のテキスト、およびNet-Unicodeを使用して表現できるその他すべて。 <Instance>名が、非表示のマシン生成の不透明な識別子ではなく、ユーザーにわかりやすいわかりやすい名前である必要がある理由については、付録C「表示されるものは取得するもの」を参照してください。
The <Instance> portion of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can in many cases allow the device or service to be accessed without any manual configuration at all. The default name should be short and descriptive, and SHOULD NOT include the device's Media Access Control (MAC) address, serial number, or any similar incomprehensible hexadecimal string in an attempt to make the name globally unique. For discussion of why <Instance> names don't need to be (and SHOULD NOT be) made unique at the factory, see Appendix D, "Choice of Factory-Default Names".
ネットワーク上で提供されているサービスの名前の<Instance>部分は、サービスを設定するユーザーが構成できるようにする必要があります（SHOULD）。これにより、ユーザーはサービスに情報的な名前を付けることができます。ただし、デバイスまたはサービスでは、使用前にユーザーが名前を構成する必要はありません（SHOULD NOT）。多くの場合、デフォルト名を適切に選択することで、手動で構成しなくてもデバイスまたはサービスにアクセスできます。デフォルトの名前は短くわかりやすいものにする必要があります。また、名前をグローバルに一意にするために、デバイスのメディアアクセス制御（MAC）アドレス、シリアル番号、または類似の理解できない16進文字列を含めないでください。 <Instance>名を工場で一意にする必要がない（およびすべきでない）理由については、付録D「工場出荷時のデフォルト名の選択」を参照してください。
This <Instance> portion of the Service Instance Name is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. For further discussion of text encodings, see Appendix E, "Name Encodings in the Domain Name System".
サービスインスタンス名のこの<Instance>部分は、正規の事前構成されたUTF-8 [RFC3629] "Net-Unicode"（Unicode Normalization Form C）[RFC5198]テキストの単一のDNSラベルとしてDNSに直接格納されます。テキストエンコーディングの詳細については、付録E「ドメインネームシステムの名前エンコーディング」を参照してください。
DNS labels are currently limited to 63 octets in length. UTF-8 encoding can require up to four octets per Unicode character, which means that in the worst case, the <Instance> portion of a name could be limited to fifteen Unicode characters. However, the Unicode characters with longer octet lengths under UTF-8 encoding tend to be the more rarely used ones, and tend to be the ones that convey greater meaning per character.
現在、DNSラベルの長さは63オクテットに制限されています。 UTF-8エンコードでは、Unicode文字あたり最大4オクテットが必要になる可能性があります。つまり、最悪の場合、名前の<Instance>部分は15文字のUnicode文字に制限される可能性があります。ただし、UTF-8エンコーディングでのオクテット長が長いUnicode文字は、ほとんど使用されず、文字ごとの意味が大きくなる傾向があります。
Note that any character in the commonly used 16-bit Unicode Basic Multilingual Plane [Unicode6] can be encoded with no more than three octets of UTF-8 encoding. This means that an instance name can contain up to 21 Kanji characters, which is a sufficiently expressive name for most purposes.
一般的に使用される16ビットUnicode Basic Multilingual Plane [Unicode6]の文字は、3オクテット以下のUTF-8エンコーディングでエンコードできることに注意してください。つまり、インスタンス名には最大21の漢字を含めることができます。これは、ほとんどの目的にとって十分に表現力のある名前です。
The <Service> portion of the Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782]. The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it. The second label is either "_tcp" (for application protocols that run over TCP) or "_udp" (for all others). For more details, see Section 7, "Service Names".
サービスインスタンス名の<Service>部分は、SRVレコード[RFC2782]に対して既に確立されている規則に従って、DNSラベルのペアで構成されています。ペアの最初のラベルはアンダースコア文字であり、その後にサービス名[RFC6335]が続きます。サービス名は、サービスの機能と、サービスを実行するために使用するアプリケーションプロトコルを識別します。 2番目のラベルは、 "_ tcp"（TCPで実行されるアプリケーションプロトコルの場合）または "_udp"（その他すべての場合）です。詳細は、7項「サービス名」を参照してください。
The <Domain> portion of the Service Instance Name specifies the DNS subdomain within which those names are registered. It may be "local.", meaning "link-local Multicast DNS" [RFC6762], or it may be a conventional Unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." Because Service Instance Names are not host names, they are not constrained by the usual rules for host names [RFC1033] [RFC1034] [RFC1035], and rich-text service subdomains are allowed and encouraged, for example:
サービスインスタンス名の<ドメイン>部分は、それらの名前が登録されているDNSサブドメインを指定します。 「ローカル」、つまり「リンクローカルマルチキャストDNS」[RFC6762]を意味する場合と、「ietf.org。」、「cs.stanford.edu。」などの従来のユニキャストDNSドメイン名である場合があります。 「eng.us.ibm.com」サービスインスタンス名はホスト名ではないため、ホスト名の通常のルール[RFC1033] [RFC1034] [RFC1035]による制約を受けず、リッチテキストサービスのサブドメインが許可および推奨されます。次に例を示します。
Building 2, 1st Floor . example . com . Building 2, 2nd Floor . example . com . Building 2, 3rd Floor . example . com . Building 2, 4th Floor . example . com .
建物2、1階。例。 com。建物2、2階。例。 com。建物2、3階。例。 com。 2号館、4階。例。 com。
In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using the "Punycode" algorithm [RFC3492] to convert the UTF-8 name to an IDNA "A-label" [RFC5890], beginning with the top-level label, then issuing the query repeatedly, with successively more labels translated to IDNA A-labels each time, and giving up if it has converted all labels to IDNA A-labels and the query still fails.
さらに、サービスインスタンス名はホスト名の制限による制約を受けないため、このドキュメントでは、DNSに保存し、ネットワーク経由で通信し、単純な正規の事前構成されたUTF-8 [RFC3629]「Net-Unicode」としてエンコードすることをお勧めします（Unicode Normalization Form C）[RFC5198]テキスト。 DNSサーバーが問題の名前に対して否定応答を返す場合、クライアントソフトウェアは、「Punycode」アルゴリズム[RFC3492]を使用してクエリを再試行し、UTF-8名をIDNA "A-label" [RFC5890]に変換することを選択できます（MAY）。 ]、トップレベルのラベルから始めて、クエリを繰り返し発行します。そのたびに、IDNA Aラベルに変換されるラベルが順次追加され、すべてのラベルがIDNA Aラベルに変換されてもクエリが失敗する場合は、あきらめます。
The names resulting from the Service Instance Enumeration PTR lookup are presented to the user in a list for the user to select one (or more). Typically, only the first label is shown (the user-friendly <Instance> portion of the name).
ユーザーが1つ（または複数）を選択できるように、サービスインスタンス列挙PTRルックアップから得られた名前がリストでユーザーに提示されます。通常、最初のラベルのみが表示されます（名前のわかりやすい<Instance>部分）。
In the common case the <Service> and <Domain> are already known to the client software, these having been provided implicitly by the user in the first place, by the act of indicating the service being sought, and the domain in which to look for it. Note that the software handling the response should be careful not to make invalid assumptions though, since it *is* possible, though rare, for a service enumeration in one domain to return the names of services in a different domain. Similarly, when using subtypes (see Section 7.1, "Selective Instance Enumeration") the <Service> of the discovered instance may not be exactly the same as the <Service> that was requested.
一般的なケースでは、<Service>と<Domain>はすでにクライアントソフトウェアに認識されています。これらは、最初にユーザーによって暗黙的に提供されており、求められているサービスと、検索するドメインを示しています。それのための。あるドメインのサービス列挙が別のドメインのサービスの名前を返すことはまれですが可能ですので、応答を処理するソフトウェアは無効な仮定をしないように注意する必要があります。同様に、サブタイプを使用する場合（7.1項「選択的なインスタンス列挙」を参照）、検出されたインスタンスの<Service>は、要求された<Service>と正確に同じではない場合があります。
For further discussion of Service Instance Enumeration (browsing) user-interface considerations, see Appendix F, "'Continuous Live Update' Browsing Model".
サービスインスタンス列挙（ブラウジング）ユーザーインターフェイスの考慮事項の詳細については、付録F「「継続的なライブ更新」ブラウジングモデル」を参照してください。
Once the user has selected the desired named instance, the Service Instance Name may then be used immediately, or saved away in some persistent user-preference data structure for future use, depending on what is appropriate for the application in question.
ユーザーが目的の名前付きインスタンスを選択したら、サービスインスタンス名をすぐに使用するか、問題のアプリケーションに適切なものに応じて、将来の使用のために永続的なユーザー設定データ構造に保存できます。
If client software takes the <Instance>, <Service>, and <Domain> portions of a Service Instance Name and internally concatenates them together into a single string, then because the <Instance> portion is allowed to contain any characters, including dots, appropriate precautions MUST be taken to ensure that DNS label boundaries are properly preserved. Client software can do this in a variety of ways, such as character escaping.
クライアントソフトウェアがサービスインスタンス名の<Instance>、<Service>、および<Domain>部分を受け取り、それらを内部で1つの文字列に連結する場合、<Instance>部分にはドットを含む任意の文字を含めることができるため、 DNSラベルの境界が適切に保持されるように、適切な予防策を講じる必要があります。クライアントソフトウェアは、文字のエスケープなど、さまざまな方法でこれを実行できます。
This document RECOMMENDS that if concatenating the three portions of a Service Instance Name, any dots in the <Instance> portion be escaped following the customary DNS convention for text files: by preceding literal dots with a backslash (so "." becomes "\."). Likewise, any backslashes in the <Instance> portion should also be escaped by preceding them with a backslash (so "\" becomes "\\").
このドキュメントでは、サービスインスタンス名の3つの部分を連結する場合、テキストファイルの通常のDNS規則に従って、<Instance>部分のドットをエスケープすることを推奨しています。リテラルドットの前にバックスラッシュを付けることで（「。」が「\。 "）。同様に、<Instance>部分のバックスラッシュも、バックスラッシュを前に付けることでエスケープする必要があります（したがって、「\」は「\\」になります）。
Having done this, the three components of the name may be safely concatenated. The backslash-escaping allows literal dots in the name (escaped) to be distinguished from label-separator dots (not escaped), and the resulting concatenated string may be safely passed to standard DNS APIs like res_query(), which will interpret the backslash-escaped string as intended.
これを行うと、名前の3つのコンポーネントを安全に連結できます。バックスラッシュエスケープを使用すると、名前のリテラルドット（エスケープ）をラベルセパレータドット（エスケープしない）から区別でき、結果の連結文字列は、バックスラッシュを解釈するres_query()などの標準DNS APIに安全に渡すことができます。意図したとおりのエスケープ文字列。
When a client needs to contact a particular service, identified by a Service Instance Name, previously discovered via Service Instance Enumeration (browsing), it queries for the SRV and TXT records of that name. The SRV record for a service gives the port number and target host name where the service may be found. The TXT record gives additional information about the service, as described in Section 6, "Data Syntax for DNS-SD TXT Records".
クライアントがサービスインスタンス名で識別され、以前にサービスインスタンス列挙（ブラウジング）で発見された特定のサービスにアクセスする必要がある場合、クライアントはその名前のSRVおよびTXTレコードを照会します。サービスのSRVレコードは、サービスが見つかる可能性のあるポート番号とターゲットホスト名を示します。 TXTレコードは、セクション6「DNS-SD TXTレコードのデータ構文」で説明されているように、サービスに関する追加情報を提供します。
SRV records are extremely useful because they remove the need for preassigned port numbers. There are only 65535 TCP port numbers available. These port numbers are traditionally allocated one per application protocol [RFC6335]. Some protocols like the X Window System have a block of 64 TCP ports allocated (6000-6063). Using a different TCP port for each different instance of a given service on a given machine is entirely sensible, but allocating each application its own large static range, as was done for the X Window System, is not a practical way to do that. On any given host, most TCP ports are reserved for services that will never run on that particular host in its lifetime. This is very poor utilization of the limited port space. Using SRV records allows each host to allocate its available port numbers dynamically to those services actually running on that host that need them, and then advertise the allocated port numbers via SRV records. Allocating the available listening port numbers locally on a per-host basis as needed allows much better utilization of the available port space than today's centralized global allocation.
SRVレコードは、事前に割り当てられたポート番号を必要としないため、非常に役立ちます。使用できるTCPポート番号は65535のみです。これらのポート番号は、従来、アプリケーションプロトコルごとに1つ割り当てられています[RFC6335]。 X Window Systemなどの一部のプロトコルには、64個のTCPポートのブロックが割り当てられています（6000〜6063）。特定のマシン上の特定のサービスのインスタンスごとに異なるTCPポートを使用することはまったく理にかなっていますが、Xウィンドウシステムで行ったように、各アプリケーションに独自の大きな静的範囲を割り当てることは、そのための実用的な方法ではありません。特定のホストでは、ほとんどのTCPポートは、その特定のホスト上でその存続期間中に実行されることのないサービスのために予約されています。これは、限られたポートスペースの使用率が非常に低いことです。 SRVレコードを使用すると、各ホストは、使用可能なポート番号を、それらを必要とするホストで実際に実行されているサービスに動的に割り当て、SRVレコードを介して割り当てられたポート番号をアドバタイズできます。使用可能なリスニングポート番号を必要に応じてホストごとにローカルに割り当てると、現在の集中型グローバル割り当てよりも使用可能なポートスペースの利用率が大幅に向上します。
In the event that more than one SRV is returned, clients MUST correctly interpret the priority and weight fields -- i.e., lower-numbered priority servers should be used in preference to higher-numbered priority servers, and servers with equal priority should be selected randomly in proportion to their relative weights. However, in the overwhelmingly common case, a single advertised DNS-SD service instance is described by exactly one SRV record, and in this common case the priority and weight fields of the SRV record SHOULD both be set to zero.
複数のSRVが返された場合、クライアントは優先度フィールドと重みフィールドを正しく解釈する必要があります。つまり、優先度の高いサーバーよりも優先度の低いサーバーを使用し、優先度が等しいサーバーをランダムに選択する必要があります。それらの相対的な重みに比例して。ただし、圧倒的に一般的なケースでは、1つのアドバタイズされたDNS-SDサービスインスタンスが1つのSRVレコードで記述されます。この一般的なケースでは、SRVレコードの優先度フィールドと重みフィールドの両方をゼロに設定する必要があります。
Some services discovered via Service Instance Enumeration may need more than just an IP address and port number to completely identify the service instance. For example, printing via the old Unix LPR (port 515) protocol [RFC1179] often specifies a queue name [BJP]. This queue name is typically short and cryptic, and need not be shown to the user. It should be regarded the same way as the IP address and port number: it is another component of the addressing information required to identify a specific instance of a service being offered by some piece of hardware. Similarly, a file server may have multiple volumes, each identified by its own volume name. A web server typically has multiple pages, each identified by its own URL. In these cases, the necessary additional data is stored in a TXT record with the same name as the SRV record. The specific nature of that additional data, and how it is to be used, is service-dependent, but the overall syntax of the data in the TXT record is standardized, as described below.
サービスインスタンス列挙を介して検出された一部のサービスでは、サービスインスタンスを完全に識別するために、IPアドレスとポート番号だけでは不十分な場合があります。たとえば、古いUnix LPR（ポート515）プロトコル[RFC1179]を介した印刷では、キュー名[BJP]が指定されることがよくあります。このキュー名は通常短くて不可解であり、ユーザーに表示する必要はありません。これは、IPアドレスおよびポート番号と同じように見なされる必要があります。これは、ハードウェアの一部によって提供されているサービスの特定のインスタンスを識別するために必要なアドレッシング情報の別のコンポーネントです。同様に、ファイルサーバーには複数のボリュームがあり、それぞれが独自のボリューム名で識別されます。通常、Webサーバーには複数のページがあり、それぞれが独自のURLで識別されます。これらの場合、必要な追加データはSRVレコードと同じ名前のTXTレコードに保存されます。その追加データの具体的な性質とその使用方法はサービスに依存しますが、TXTレコード内のデータの全体的な構文は、以下で説明するように標準化されています。
Every DNS-SD service MUST have a TXT record in addition to its SRV record, with the same name, even if the service has no additional data to store and the TXT record contains no more than a single zero byte. This allows a service to have explicit control over the Time to Live (TTL) of its (empty) TXT record, rather than using the default negative caching TTL, which would otherwise be used for a "no error no answer" DNS response.
すべてのDNS-SDサービスには、SRVレコードに加えて、同じ名前のTXTレコードが必要です（サービスに格納する追加のデータがなく、TXTレコードに含まれるゼロバイトが1つ以下の場合でも）。これにより、デフォルトのネガティブキャッシングTTLを使用するのではなく、サービスが（空の）TXTレコードの存続時間（TTL）を明示的に制御できるようになります。
Note that this requirement for a mandatory TXT record applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. The DNS SRV record datatype [RFC2782] may still be used in other contexts without any requirement for accompanying PTR and TXT records.
必須のTXTレコードに対するこの要件は、DNS-SDサービスアドバタイズ、つまりこのドキュメントで指定されているPTR + SRV + TXT規則を使用してアドバタイズされるサービスにのみ適用されることに注意してください。 SRVレコードの一般的な要件ではありません。 DNS SRVレコードデータタイプ[RFC2782]は、PTRおよびTXTレコードを伴う必要なしに、他のコンテキストで引き続き使用できます。
A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total length is indicated by the length given in the resource record header in the DNS message. There is no way to tell directly from the data alone how long it is (e.g., there is no length count at the start, or terminating NULL byte at the end).
DNS TXTレコードの長さは最大65535（0xFFFF）バイトです。全長は、DNSメッセージのリソースレコードヘッダーで指定された長さで示されます。データの長さをデータのみから直接判別する方法はありません（たとえば、最初に長さのカウントがない、または最後にNULLバイトが終了している）。
Note that when using Multicast DNS [RFC6762] the maximum packet size is 9000 bytes, including the IP header, UDP header, and DNS message header, which imposes an upper limit on the size of TXT records of about 8900 bytes. In practice the maximum sensible size of a DNS-SD TXT record is smaller even than this, typically at most a few hundred bytes, as described below in Section 6.2.
マルチキャストDNS [RFC6762]を使用する場合、IPヘッダー、UDPヘッダー、DNSメッセージヘッダーを含む最大パケットサイズは9000バイトであり、TXTレコードのサイズに約8900バイトの上限が課せられることに注意してください。実際には、DNS-SD TXTレコードの実用的な最大サイズはこれよりも小さく、以下のセクション6.2で説明するように、通常は最大で数百バイトです。
The format of the data within a DNS TXT record is one or more strings, packed together in memory without any intervening gaps or padding bytes for word alignment.
DNS TXTレコード内のデータの形式は、1つ以上の文字列で、ギャップやワードアラインメントのパディングバイトを介在させずにメモリにまとめられます。
The format of each constituent string within the DNS TXT record is a single length byte, followed by 0-255 bytes of text data.
DNS TXTレコード内の各構成文字列の形式は、1バイトの長さで、その後に0〜255バイトのテキストデータが続きます。
These format rules for TXT records are defined in Section 3.3.14 of the DNS specification [RFC1035] and are not specific to DNS-SD. DNS-SD specifies additional rules for what data should be stored in those constituent strings when used for DNS-SD service advertising, i.e., when used to describe services advertised using the PTR+SRV+TXT convention specified in this document.
TXTレコードのこれらのフォーマットルールは、DNS仕様[RFC1035]のセクション3.3.14で定義されており、DNS-SDに固有のものではありません。 DNS-SDは、DNS-SDサービスアドバタイズに使用される場合、つまり、このドキュメントで指定されているPTR + SRV + TXT規則を使用してアドバタイズされるサービスを記述するために使用される場合に、これらの構成文字列に格納する必要があるデータに関する追加のルールを指定します。
An empty TXT record containing zero strings is not allowed [RFC1035]. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD clients MUST treat the following as equivalent:
ゼロの文字列を含む空のTXTレコードは許可されていません[RFC1035]。 DNS-SD実装は、空のTXTレコードを発行してはなりません（MUST NOT）。 DNS-SDクライアントは、次のものを同等のものとして扱う必要があります。
o A TXT record containing a single zero byte. (i.e., a single empty string.)
o 1つのゼロバイトを含むTXTレコード。 （つまり、単一の空の文字列）。
o An empty (zero-length) TXT record. (This is not strictly legal, but should one be received, it should be interpreted as the same as a single empty string.)
o 空（長さがゼロ）のTXTレコード。 （これは厳密には合法ではありませんが、受け取った場合、1つの空の文字列と同じように解釈されます。）
o No TXT record. (i.e., an NXDOMAIN or no-error-no-answer response.)
o TXTレコードがありません。 （つまり、NXDOMAINまたはno-error-no-answer応答）。
The total size of a typical DNS-SD TXT record is intended to be small -- 200 bytes or less.
一般的なDNS-SD TXTレコードの合計サイズは、200バイト以下と小さくすることを目的としています。
In cases where more data is justified (e.g., LPR printing [BJP]), keeping the total size under 400 bytes should allow it to fit in a single 512-byte DNS message [RFC1035].
より多くのデータが正当化される場合（LPR印刷[BJP]など）、合計サイズを400バイト未満に保つと、単一の512バイトDNSメッセージに収まるようになります[RFC1035]。
In extreme cases where even this is not enough, keeping the size of the TXT record under 1300 bytes should allow it to fit in a single 1500-byte Ethernet packet.
これでも不十分な極端な場合、TXTレコードのサイズを1300バイト未満に保つことで、1つの1500バイトのイーサネットパケットに収まるようになります。
Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time.
現時点では、1300バイトを超えるTXTレコードを使用することはお勧めしません。
Note that some Ethernet hardware vendors offer chipsets with Multicast DNS [RFC6762] offload, so that computers can sleep and still be discoverable on the network. Early versions of such chipsets were sometimes quite limited: for example, some were (unwisely) limited to handling TXT records no larger than 256 bytes (which meant that LPR printer services with larger TXT records did not work). Developers should be aware of this real-world limitation, and should understand that even hardware which is otherwise perfectly capable may have low-power and sleep modes that are more limited.
一部のイーサネットハードウェアベンダーは、マルチキャストDNS [RFC6762]オフロードを備えたチップセットを提供しているため、コンピューターがスリープ状態でもネットワーク上で検出可能であることに注意してください。このようなチップセットの初期バージョンは、かなり制限されている場合がありました。たとえば、TXTレコードの処理が256バイト以下に制限されている（つまり、より大きなTXTレコードを持つLPRプリンターサービスが機能しない）ものもありました。開発者はこの現実世界の制限に注意する必要があり、他の点では完全に機能するハードウェアでさえ、より制限された低電力モードとスリープモードがある場合があることを理解する必要があります。
DNS-SD uses DNS TXT records to store arbitrary key/value pairs conveying additional information about the named service. Each key/value pair is encoded as its own constituent string within the DNS TXT record, in the form "key=value" (without the quotation marks). Everything up to the first '=' character is the key (Section 6.4). Everything after the first '=' character to the end of the string (including subsequent '=' characters, if any) is the value (Section 6.5). No quotation marks are required around the value, even if it contains spaces, '=' characters, or other punctuation marks. Each author defining a DNS-SD profile for discovering instances of a particular type of service should define the base set of key/value attributes that are valid for that type of service.
DNS-SDはDNS TXTレコードを使用して、名前付きサービスに関する追加情報を伝達する任意のキーと値のペアを格納します。キーと値の各ペアは、DNS TXTレコード内の独自の構成文字列として、「key = value」の形式（引用符なし）でエンコードされます。最初の「=」文字までのすべてがキーです（セクション6.4）。最初の '='文字の後から文字列の終わりまでのすべて（存在する場合は、後続の '='文字を含む）が値です（6.5節）。値にスペース、「=」文字、またはその他の句読点が含まれている場合でも、値を引用符で囲む必要はありません。特定のタイプのサービスのインスタンスを検出するためのDNS-SDプロファイルを定義する各作成者は、そのタイプのサービスに有効なキー/値属性の基本セットを定義する必要があります。
Using this standardized key/value syntax within the TXT record makes it easier for these base definitions to be expanded later by defining additional named attributes. If an implementation sees unknown keys in a service TXT record, it MUST silently ignore them.
TXTレコード内でこの標準化されたキー/値構文を使用すると、追加の名前付き属性を定義することにより、これらの基本定義を後で簡単に拡張できます。実装がサービスTXTレコードで不明なキーを見つけた場合、それは暗黙のうちにそれらを無視しなければなりません（MUST）。
The target host name and TCP (or UDP) port number of the service are given in the SRV record. This information -- target host name and port number -- MUST NOT be duplicated using key/value attributes in the TXT record.
サービスのターゲットホスト名とTCP（またはUDP）ポート番号は、SRVレコードで提供されます。この情報（ターゲットホスト名とポート番号）は、TXTレコードのキー/値属性を使用して重複してはなりません。
The intention of DNS-SD TXT records is to convey a small amount of useful additional information about a service. Ideally, it should not be necessary for a client to retrieve this additional information before it can usefully establish a connection to the service. For a well-designed application protocol, even if there is no information at all in the TXT record, it should be possible, knowing only the host name, port number, and protocol being used, to communicate with that listening process and then perform version- or feature-negotiation to determine any further options or capabilities of the service instance. For example, when connecting to an AFP (Apple Filing Protocol) server [AFP] over TCP, the client enters into a protocol exchange with the server to determine which version of AFP the server implements and which optional features or capabilities (if any) are available.
DNS-SD TXTレコードの目的は、サービスに関する少量の有用な追加情報を伝えることです。理想的には、クライアントがサービスへの接続を有効に確立する前に、クライアントがこの追加情報を取得する必要はないはずです。適切に設計されたアプリケーションプロトコルの場合、TXTレコードに情報がまったくない場合でも、使用されているホスト名、ポート番号、およびプロトコルのみを知っていれば、そのリスニングプロセスと通信してバージョンを実行することができます。 -または、サービスインスタンスのその他のオプションまたは機能を決定するための機能ネゴシエーション。たとえば、TCP経由でAFP（Apple Filing Protocol）サーバー[AFP]に接続する場合、クライアントはサーバーとプロトコル交換を行い、サーバーが実装するAFPのバージョンと、オプションの機能または機能（ある場合）を決定します。利用可能です。
For protocols designed with adequate in-band version- and feature-negotiation, any information in the TXT record should be viewed as a performance optimization -- when a client discovers many instances of a service, the TXT record allows the client to know some rudimentary information about each instance without having to open a TCP connection to each one and interrogate every service instance separately. Care should be taken when doing this to ensure that the information in the TXT record is in agreement with the information that would be retrieved by a client connecting over TCP.
適切なインバンドバージョンおよび機能ネゴシエーションで設計されたプロトコルの場合、TXTレコードの情報はパフォーマンスの最適化と見なす必要があります。クライアントがサービスの多くのインスタンスを検出すると、TXTレコードにより、クライアントは基本的な情報を知ることができます。各インスタンスへのTCP接続を開いたり、各サービスインスタンスに個別に問い合わせたりすることなく、各インスタンスに関する情報。これを行うときは、TXTレコードの情報が、TCPを介して接続するクライアントによって取得される情報と一致するように注意する必要があります。
There are legacy protocols that provide no feature negotiation capability, and in these cases it may be useful to convey necessary information in the TXT record. For example, when printing using LPR [RFC1179], the LPR protocol provides no way for the client to determine whether a particular printer accepts PostScript, what version of PostScript, etc. In this case it is appropriate to embed this information in the TXT record [BJP], because the alternative would be worse -- passing around written instructions to the users, arcane manual configuration of "/etc/printcap" files, etc.
機能ネゴシエーション機能を提供しないレガシープロトコルがあり、これらの場合、TXTレコードで必要な情報を伝達することが役立つ場合があります。たとえば、LPR [RFC1179]を使用して印刷する場合、LPRプロトコルは、特定のプリンターがPostScriptを受け入れるかどうか、PostScriptのバージョンなどをクライアントが判断する方法を提供しません。この場合、この情報をTXTレコードに埋め込むことが適切です。 [BJP]代替案の方が悪いため-ユーザーに書面による指示を渡す、 "/ etc / printcap"ファイルの不可解な手動設定など
The engineering decision about what keys to define for the TXT record needs to be decided on a case-by-case basis for each service type. For some service types it is appropriate to communicate information via the TXT record as well as (or instead of) via in-band communication in the application protocol.
TXTレコードにどのキーを定義するかに関するエンジニアリング上の決定は、サービスタイプごとにケースバイケースで決定する必要があります。一部のサービスタイプでは、TXTレコードを介して（またはその代わりに）アプリケーションプロトコルの帯域内通信を介して情報を通信することが適切です。
The key MUST be at least one character. DNS-SD TXT record strings beginning with an '=' character (i.e., the key is missing) MUST be silently ignored.
キーは少なくとも1文字でなければなりません。 「=」文字で始まるDNS-SD TXTレコード文字列（つまり、キーが欠落している）は、黙って無視する必要があります。
The key SHOULD be no more than nine characters long. This is because it is beneficial to keep packet sizes small for the sake of network efficiency. When using DNS-SD in conjunction with Multicast DNS [RFC6762] this is important because multicast traffic is especially expensive on 802.11 wireless networks [IEEEW], but even when using conventional Unicast DNS, keeping the TXT records small helps improve the chance that responses will fit within the original DNS 512-byte size limit [RFC1035]. Also, each constituent string of a DNS TXT record is limited to 255 bytes, so excessively long keys reduce the space available for that key's values.
キーは9文字以内にする必要があります。これは、ネットワーク効率を高めるために、パケットサイズを小さく保つことが有益だからです。 DNS-SDをマルチキャストDNS [RFC6762]と組み合わせて使用する場合、マルチキャストトラフィックは802.11ワイヤレスネットワーク[IEEEW]で特に高価になるため、これは重要です。元のDNS 512バイトサイズ制限[RFC1035]内に収まる。また、DNS TXTレコードの各構成文字列は255バイトに制限されているため、キーが長すぎると、そのキーの値に使用できるスペースが減少します。
The keys in key/value pairs can be as short as a single character. A key name needs only to be unique and unambiguous within the context of the service type for which it is defined. A key name is intended solely to be a machine-readable identifier, not a human-readable essay giving detailed discussion of the purpose of a parameter, with a URL for a web page giving yet more details of the specification. For ease of development and debugging, it can be valuable to use key names that are mnemonic textual names, but excessively verbose keys are wasteful and inefficient, hence the recommendation to keep them to nine characters or fewer.
キーと値のペアのキーは、単一の文字と同じくらい短くすることができます。キー名は、それが定義されているサービスタイプのコンテキスト内で一意かつ明確である必要があります。キー名は、機械で読み取り可能な識別子のみを意図しており、パラメーターの目的について詳細に説明する人間が読み取れるエッセイではなく、仕様のさらに詳細を示すWebページのURLが含まれています。開発とデバッグを容易にするために、ニーモニックテキスト名であるキー名を使用することは価値がありますが、過度に冗長なキーは無駄で非効率的であるため、9文字以下に保つことをお勧めします。
The characters of a key MUST be printable US-ASCII values (0x20-0x7E) [RFC20], excluding '=' (0x3D).
キーの文字は、「=」（0x3D）を除いて、印刷可能なUS-ASCII値（0x20-0x7E）[RFC20]である必要があります。
Spaces in the key are significant, whether leading, trailing, or in the middle -- so don't include any spaces unless you really intend that.
キーのスペースは、先頭、末尾、中央のいずれであっても重要です。本当に意図しない限り、スペースを含めないでください。
Case is ignored when interpreting a key, so "papersize=A4", "PAPERSIZE=A4", and "Papersize=A4" are all identical.
キーを解釈するとき、大文字と小文字は無視されるため、「papersize = A4」、「PAPERSIZE = A4」、および「Papersize = A4」はすべて同じです。
If there is no '=' in a DNS-SD TXT record string, then it is a boolean attribute, simply identified as being present, with no value.
DNS-SD TXTレコード文字列に「=」がない場合、それはブール属性であり、単に存在すると識別され、値はありません。
A given key SHOULD NOT appear more than once in a TXT record. The reason for this simplifying rule is to facilitate the creation of client libraries that parse the TXT record into an internal data structure (such as a hash table or dictionary object that maps from keys to values) and then make that abstraction available to client code. The rule that a given key may not appear more than once simplifies these abstractions because they aren't required to support the case of returning more than one value for a given key.
指定されたキーは、TXTレコードに複数回出現してはいけません（SHOULD NOT）。この簡略化ルールの理由は、TXTレコードを内部データ構造（キーから値にマップするハッシュテーブルやディクショナリオブジェクトなど）に解析し、その抽象化をクライアントコードで利用できるようにするクライアントライブラリの作成を容易にするためです。特定のキーが複数回出現しないというルールは、特定のキーに対して複数の値を返す場合をサポートする必要がないため、これらの抽象化を簡素化します。
If a client receives a TXT record containing the same key more than once, then the client MUST silently ignore all but the first occurrence of that attribute. For client implementations that process a DNS-SD TXT record from start to end, placing key/value pairs into a hash table using the key as the hash table key, this means that if the implementation attempts to add a new key/value pair into the table and finds an entry with the same key already present, then the new entry being added should be silently discarded instead. Client implementations that retrieve key/value pairs by searching the TXT record for the requested key should search the TXT record from the start and simply return the first matching key they find.
クライアントが同じキーを複数回含むTXTレコードを受け取った場合、クライアントは、その属性の最初の出現以外はすべて黙って無視しなければなりません（MUST）。 DNS-SD TXTレコードを最初から最後まで処理するクライアント実装では、キーをハッシュテーブルキーとして使用して、キー/値ペアをハッシュテーブルに配置します。これは、実装が新しいキー/値ペアをテーブルを検索し、同じキーがすでに存在するエントリを見つけた場合、追加される新しいエントリは代わりに通知なく破棄されます。 TXTレコードで要求されたキーを検索してキーと値のペアを取得するクライアント実装は、TXTレコードを最初から検索し、最初に一致したキーを返すだけです。
When examining a TXT record for a given key, there are therefore four categories of results that may be returned:
したがって、特定のキーのTXTレコードを調べる場合、返される可能性のある結果の4つのカテゴリがあります。
* Attribute not present (Absent)
* 属性が存在しない（存在しない）
* Attribute present, with no value (e.g., "passreq" -- password required for this service)
* 属性が存在し、値はありません（例：「passreq」-このサービスにはパスワードが必要です）
* Attribute present, with empty value (e.g., "PlugIns=" -- the server supports plugins, but none are presently installed)
* 空の値を持つ属性が存在します（例： "PlugIns ="-サーバーはプラグインをサポートしていますが、現在インストールされているものはありません）
* Attribute present, with non-empty value (e.g., "PlugIns=JPEG,MPEG2,MPEG4")
* 空ではない値を持つ属性が存在します（例： "PlugIns = JPEG、MPEG2、MPEG4"）
Each author defining a DNS-SD profile for discovering instances of a particular type of service should define the interpretation of these different kinds of result. For example, for some keys, there may be a natural true/false boolean interpretation:
特定のタイプのサービスのインスタンスを検出するためのDNS-SDプロファイルを定義する各作成者は、これらの異なる種類の結果の解釈を定義する必要があります。たとえば、一部のキーでは、自然な真/偽のブール解釈がある場合があります。
* Absent implies 'false' * Present implies 'true'
* 不在は「偽」を意味する*存在は「真」を意味する
For other keys it may be sensible to define other semantics, such as value/no-value/unknown:
他のキーについては、値/値なし/不明など、他のセマンティクスを定義することが賢明な場合があります。
* Present with value implies that value. (e.g., "Color=4" for a four-color ink-jet printer or "Color=6" for a six-color ink-jet printer)
* 価値とともに存在するとは、その価値を意味します。 （たとえば、4色インクジェットプリンタの場合は「Color = 4」、6色インクジェットプリンタの場合は「Color = 6」）
* Present with empty value implies 'false'. (e.g., not a color printer)
* 空の値で存在すると、「false」を意味します。 （例：カラープリンターではない）
* Absent implies 'Unknown'. (e.g., a print server connected to some unknown printer where the print server doesn't actually know if the printer does color or not -- which gives a very bad user experience and should be avoided wherever possible)
* 不在は「不明」を意味します。 （たとえば、プリンターがカラーかどうかを実際に認識していない不明なプリンターに接続されているプリントサーバー-これはユーザーエクスペリエンスが非常に悪いため、可能な限り回避する必要があります）
Note that this is a hypothetical example, not an example of actual key/value keys used by DNS-SD network printers, which are documented in the "Bonjour Printing Specification" [BJP].
これは架空の例であり、「Bonjour Printing Specification」[BJP]に記載されているDNS-SDネットワークプリンターが使用する実際のキー/値キーの例ではないことに注意してください。
If there is an '=' in a DNS-SD TXT record string, then everything after the first '=' to the end of the string is the value. The value can contain any eight-bit values including '='. The value MUST NOT be enclosed in additional quotation marks or any similar punctuation; any quotation marks, or leading or trailing spaces, are part of the value.
DNS-SD TXTレコード文字列に「=」がある場合、最初の「=」以降の文字列の最後までのすべてが値です。値には、「=」を含む任意の8ビット値を含めることができます。値を追加の引用符または同様の句読点で囲まないでください。引用符、または先頭または末尾のスペースは値の一部です。
The value is opaque binary data. Often the value for a particular attribute will be US-ASCII [RFC20] or UTF-8 [RFC3629] text, but it is legal for a value to be any binary data.
値は不透明なバイナリデータです。多くの場合、特定の属性の値はUS-ASCII [RFC20]またはUTF-8 [RFC3629]テキストになりますが、値が任意のバイナリデータであることは正当です。
Generic debugging tools should generally display all attribute values as a hex dump, with accompanying text alongside displaying the UTF-8 interpretation of those bytes, except for attributes where the debugging tool has embedded knowledge that the value is some other kind of data.
一般的なデバッグツールは、通常、すべての属性値を16進ダンプとして表示し、それらのバイトのUTF-8解釈を表示するテキストとともに、デバッグツールが値が他の種類のデータであるという知識が埋め込まれている属性を除きます。
Authors defining DNS-SD profiles SHOULD NOT generically convert binary attribute data types into printable text using hexadecimal representation, Base-64 [RFC4648], or Unix-to-Unix (UU) encoding, merely for the sake of making the data appear to be printable text when seen in a generic debugging tool. Doing this simply bloats the size of the TXT record, without actually making the data any more understandable to someone looking at it in a generic debugging tool.
DNS-SDプロファイルを定義する作成者は、一般的にバイナリデータ型を、16進数表現、Base-64 [RFC4648]、またはUnix-to-Unix（UU）エンコーディングを使用して印刷可能なテキストに一般的に変換しないでください。一般的なデバッグツールで表示される印刷可能なテキスト。これを行うと、TXTレコードのサイズが膨らむだけで、汎用のデバッグツールでデータを見る人が実際にデータを理解しにくくなります。
The TXT record below contains three syntactically valid key/value strings. (The meaning of these key/value pairs, if any, would depend on the definitions pertaining to the service in question that is using them.)
以下のTXTレコードには、構文的に有効な3つのキー/値文字列が含まれています。 （これらのキーと値のペアの意味は、もしあれば、それらを使用している問題のサービスに関連する定義に依存します。）
-------------------------------------------------------
| 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
-------------------------------------------------------
It is recommended that authors defining DNS-SD profiles include an attribute of the form "txtvers=x", where "x" is a decimal version number in US-ASCII [RFC20] text (e.g., "txtvers=1" or "txtvers=8"), in their definition, and require it to be the first key/value pair in the TXT record. This information in the TXT record can be useful to help clients maintain backwards compatibility with older implementations if it becomes necessary to change or update the specification over time. Even if the profile author doesn't anticipate the need for any future incompatible changes, having a version number in the TXT record provides useful insurance should incompatible changes become unavoidable [RFC6709]. Clients SHOULD ignore TXT records with a txtvers number higher (or lower) than the version(s) they know how to interpret.
DNS-SDプロファイルを定義する作成者には、「txtvers = x」という形式の属性を含めることをお勧めします。「x」はUS-ASCII [RFC20]テキストの10進数のバージョン番号です（たとえば、「txtvers = 1」または「txtvers」 = 8 "）、それらの定義では、TXTレコードの最初のキーと値のペアである必要があります。 TXTレコードのこの情報は、仕様を長期にわたって変更または更新する必要が生じた場合に、クライアントが古い実装との下位互換性を維持するのに役立ちます。プロファイルの作成者が将来の互換性のない変更の必要性を予想していなくても、TXTレコードにバージョン番号を含めると、互換性のない変更が避けられなくなった場合に役立つ保険になります[RFC6709]。クライアントは、解釈方法がわかっているバージョンよりも大きい（または小さい）txtvers番号のTXTレコードを無視する必要があります（SHOULD）。
Note that the version number in the txtvers tag describes the version of the specification governing the defined keys and the meaning of those keys for that particular TXT record, not the version of the application protocol that will be used if the client subsequently decides to contact that service. Ideally, every DNS-SD TXT record specification starts at txtvers=1 and stays that way forever. Improvements can be made by defining new keys that older clients silently ignore. The only reason to increment the version number is if the old specification is subsequently found to be so horribly broken that there's no way to do a compatible forward revision, so the txtvers number has to be incremented to tell all the old clients they should just not even try to understand this new TXT record.
txtversタグのバージョン番号は、定義されたキーを管理する仕様のバージョンと、特定のTXTレコードのそれらのキーの意味を説明するものであり、クライアントがその後連絡することにした場合に使用されるアプリケーションプロトコルのバージョンではありません。サービス。理想的には、すべてのDNS-SD TXTレコード仕様はtxtvers = 1で始まり、そのように永久にとどまります。古いクライアントが黙って無視する新しいキーを定義することにより、改善を行うことができます。バージョン番号をインクリメントする唯一の理由は、古い仕様がひどく壊れて互換性のあるフォワードリビジョンを実行する方法がないことが判明した場合です。そのため、txtvers番号をインクリメントして、古いクライアントすべてに通知してはいけないことを伝える必要があります。この新しいTXTレコードを理解してみてください。
If there is a need to indicate which version number(s) of the application protocol the service implements, the recommended key for this is "protovers".
サービスが実装するアプリケーションプロトコルのバージョン番号を示す必要がある場合、これに推奨されるキーは「プロトコル」です。
Generally speaking, every DNS-SD service instance has exactly one TXT record. However, it is possible for a particular protocol's DNS-SD advertising specification to state that it allows multiple TXT records. In this case, each TXT record describes a different variant of the same logical service, offered using the same underlying protocol on the same port, described by the same SRV record.
一般的に言えば、すべてのDNS-SDサービスインスタンスには1つのTXTレコードがあります。ただし、特定のプロトコルのDNS-SDアドバタイズメント仕様で、複数のTXTレコードを許可することが明記されている場合があります。この場合、各TXTレコードは、同じSRVレコードで記述された、同じポートで同じ基本プロトコルを使用して提供される、同じ論理サービスの異なるバリアントを記述します。
Having multiple TXT records to describe a single service instance is very rare, and to date, of the many hundreds of registered DNS-SD service types [SN], only one makes use of this capability, namely LPR printing [BJP]. This capability is used when a printer conceptually supports multiple logical queue names, where each different logical queue name implements a different page description language, such as 80-column monospaced plain text, seven-bit Adobe PostScript, eight-bit ("binary") PostScript, or some proprietary page description language. When multiple TXT records are used to describe multiple logical LPR queue names for the same underlying service, printers include two additional keys in each TXT record: 'qtotal', which specifies the total number of TXT records associated with this SRV record, and 'priority', which gives the printer's relative preference for this particular TXT record. Clients then select the most preferred TXT record that meets the client's needs [BJP]. The only reason multiple TXT records are used is because the LPR protocol lacks in-band feature-negotiation capabilities for the client and server to agree on a data representation for the print job, so this information has to be communicated out-of-band instead using the DNS-SD TXT records. Future protocol designs should not follow this bad example by mimicking this inadequacy of the LPR printing protocol.
単一のサービスインスタンスを説明する複数のTXTレコードを持つことは非常にまれであり、これまでに登録された何百ものDNS-SDサービスタイプ[SN]のうち、LPR印刷[BJP]だけがこの機能を利用します。この機能は、プリンターが概念的に複数の論理キュー名をサポートする場合に使用されます。各論理キュー名は、80桁の等幅プレーンテキスト、7ビットAdobe PostScript、8ビット（「バイナリ」）などの異なるページ記述言語を実装します。 PostScript、または独自のページ記述言語。同じ基本サービスの複数の論理LPRキュー名を記述するために複数のTXTレコードが使用される場合、プリンターは各TXTレコードに2つの追加キーを含みます： 'qtotal'、これはこのSRVレコードに関連付けられたTXTレコードの合計数を指定し、 'priority '、これは、この特定のTXTレコードに対するプリンターの相対的な優先順位を示します。次にクライアントは、クライアントのニーズを満たす最も好ましいTXTレコードを選択します[BJP]。複数のTXTレコードが使用される唯一の理由は、LPRプロトコルにクライアントとサーバーが印刷ジョブのデータ表現に同意するためのインバンド機能ネゴシエーション機能がないため、代わりにこの情報をアウトオブバンドで通信する必要があるためですDNS-SD TXTレコードを使用します。今後のプロトコル設計では、LPR印刷プロトコルのこの不十分さを模倣することで、この悪い例に従うべきではありません。
The <Service> portion of a Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782].
サービスインスタンス名の<Service>部分は、SRVレコード[RFC2782]に対して既に確立されている規則に従って、DNSラベルのペアで構成されています。
The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it.
ペアの最初のラベルはアンダースコア文字であり、その後にサービス名[RFC6335]が続きます。サービス名は、サービスの機能と、サービスを実行するために使用するアプリケーションプロトコルを識別します。
For applications using TCP, the second label is "_tcp".
TCPを使用するアプリケーションの場合、2番目のラベルは「_tcp」です。
For applications using any transport protocol other than TCP, the second label is "_udp". This applies to all other transport protocols, including User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control Protocol (DCCP) [RFC4340], Adobe's Real Time Media Flow Protocol (RTMFP), etc. In retrospect, perhaps the SRV specification should not have used the "_tcp" and "_udp" labels at all, and instead should have used a single label "_srv" to carve off a subdomain of DNS namespace for this use, but that specification is already published and deployed. At this point there is no benefit in changing established practice. While "_srv" might be aesthetically nicer than "_udp", it is not a user-visible string, and all that is required protocol-wise is (i) that it be a label that can form a DNS delegation point, and (ii) that it be short so that it does not take up too much space in the packet, and in this respect either "_udp" or "_srv" is equally good. Thus, it makes sense to use "_tcp" for TCP-based services and "_udp" for all other transport protocols -- which are in fact, in today's world, often encapsulated over UDP -- rather than defining a new subdomain for every new transport protocol.
TCP以外のトランスポートプロトコルを使用するアプリケーションの場合、2番目のラベルは「_udp」です。これは、User Datagram Protocol（UDP）、Stream Control Transmission Protocol（SCTP）[RFC4960]、Datagram Congestion Control Protocol（DCCP）[RFC4340]、AdobeのReal Time Media Flow Protocol（RTMFP）など、他のすべてのトランスポートプロトコルに適用されます。振り返ってみると、SRV仕様では「_tcp」および「_udp」ラベルをまったく使用するべきではなく、代わりに単一のラベル「_srv」を使用してこの使用のためにDNS名前空間のサブドメインを切り分けるべきでしたが、その仕様はすでに公開され、配備されています。この時点では、確立されたプラクティスを変更してもメリットはありません。 「_srv」は「_udp」よりも見た目が良いかもしれませんが、ユーザーに表示される文字列ではなく、プロトコル的に必要なのは、（i）DNS委任ポイントを形成できるラベルであること、および（ii ）パケット内でスペースを取りすぎないように短くすること。この点で、「_ udp」または「_srv」のどちらも同じように使用できます。したがって、TCPベースのサービスに「_tcp」を使用し、他のすべてのトランスポートプロトコルに「_udp」を使用することは理にかなっています。トランスポートプロトコル。
Note that this usage of the "_udp" label for all protocols other than TCP applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. Other specifications that are independent of DNS-SD and not intended to interoperate with DNS-SD records are not in any way constrained by how DNS-SD works just because they also use the DNS SRV record datatype [RFC2782]; they are free to specify their own naming conventions as appropriate.
TCP以外のすべてのプロトコルの「_udp」ラベルのこの使用法は、DNS-SDサービスアドバタイズ、つまりこのドキュメントで指定されているPTR + SRV + TXT規則を使用してアドバタイズされるサービスにのみ適用されることに注意してください。 SRVレコードの一般的な要件ではありません。 DNS-SDに依存せず、DNS-SDレコードとの相互運用を目的としていない他の仕様は、DNS SRVレコードデータタイプ[RFC2782]も使用しているという理由だけで、DNS-SDの動作方法によって制約を受けることはありません。必要に応じて、独自の命名規則を自由に指定できます。
The rules for Service Names [RFC6335] state that they may be no more than fifteen characters long (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, must not contain consecutive hyphens, and must contain at least one letter. The requirement to contain at least one letter is to disallow Service Names such as "80" or
サービス名[RFC6335]のルールでは、文字、数字、ハイフンのみで構成され、15文字を超えてはならず（必須のアンダースコアは数えない）、文字の先頭と末尾に文字または数字を含めることはできません。連続するハイフン。少なくとも1文字を含める必要があります。少なくとも1つの文字を含める要件は、「80」や
"6000-6063", which could be misinterpreted as port numbers or port number ranges. While both uppercase and lowercase letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings "HTTP" and "http" refer to the same service.
「6000-6063」。ポート番号またはポート番号の範囲として誤って解釈される可能性があります。ニーモニックを明確にするために大文字と小文字の両方を使用できますが、比較のために大文字と小文字は無視されるため、文字列「HTTP」と「http」は同じサービスを参照します。
Wise selection of a Service Name is important, and the choice is not always as obvious as it may appear.
サービス名の賢明な選択は重要であり、その選択は、表示されるほど明確ではありません。
In many cases, the Service Name merely names and refers to the on-the-wire message format and semantics being used. FTP is "ftp", IPP printing is "ipp", and so on.
多くの場合、サービス名は単に使用されている送信中のメッセージ形式とセマンティクスに名前を付けて参照します。 FTPは「ftp」、IPP印刷は「ipp」などです。
However, it is common to "borrow" an existing protocol and repurpose it for a new task. This is entirely sensible and sound engineering practice, but that doesn't mean that the new protocol is providing the same semantic service as the old one, even if it borrows the same message formats. For example, the network music sharing protocol implemented by iTunes on Macintosh and Windows is built upon "HTTP GET" commands. However, that does *not* mean that it is sensible or useful to try to access one of these music servers by connecting to it with a standard web browser. Consequently, the DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" (Digital Audio Access Protocol), not "_http._tcp".
ただし、既存のプロトコルを「借用」し、新しいタスクに再利用することは一般的です。これは完全に賢明で健全なエンジニアリング手法ですが、同じメッセージ形式を借用しても、新しいプロトコルが古いプロトコルと同じセマンティックサービスを提供しているという意味ではありません。たとえば、MacintoshおよびWindowsのiTunesによって実装されるネットワーク音楽共有プロトコルは、「HTTP GET」コマンドに基づいて構築されています。ただし、これは、標準のWebブラウザで接続してこれらの音楽サーバーのいずれかにアクセスすることが賢明または有用であることを意味しません。したがって、iTunesによってアドバタイズ（および参照）されるDNS-SDサービスは、「_ http._tcp」ではなく「_daap._tcp」（デジタルオーディオアクセスプロトコル）です。
If iTunes were to advertise that it offered "_http._tcp" service, that would cause iTunes servers to appear in conventional web browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox, Chrome, etc.), which is of little use since an iTunes music library offers no HTML pages containing human-readable content that a web browser could display.
iTunesが「_http._tcp」サービスを提供していることを宣伝すると、iTunesサーバーが従来のWebブラウザー（Safari、Camino、OmniWeb、Internet Explorer、Firefox、Chromeなど）に表示されるようになります。 iTunesミュージックライブラリは、Webブラウザが表示できる人間が読めるコンテンツを含むHTMLページを提供しません。
Equally, if iTunes were to browse for "_http._tcp" service, that would cause it to discover generic web servers, such as the embedded web servers in devices like printers, which is of little use since printers generally don't have much music to offer.
同様に、iTunesが「_http._tcp」サービスを参照すると、プリンタなどのデバイスに埋め込まれたWebサーバーなど、汎用のWebサーバーが検出されます。これは、プリンタには一般的に多くの音楽がないため、ほとんど役に立ちません。提供する。
Analogously, Sun Microsystems's Network File System (NFS) is built on top of Sun Microsystems's Remote Procedure Call (Sun RPC) mechanism, but that doesn't mean it makes sense for an NFS server to advertise that it provides "Sun RPC" service. Likewise, Microsoft's Server Message Block (SMB) file service is built on top of Netbios running over IP, but that doesn't mean it makes sense for an SMB file server to advertise that it provides "Netbios-over-IP" service. The DNS-SD name of a service needs to encapsulate both the "what" (semantics) and the "how" (protocol implementation) of the service, since knowledge of both is necessary for a client to use the service meaningfully. Merely advertising that a service was built on top of Sun RPC is no use if the client has no idea what the service does.
同様に、Sun Microsystemsのネットワークファイルシステム（NFS）は、Sun Microsystemsのリモートプロシージャコール（Sun RPC）メカニズムの上に構築されていますが、NFSサーバーが「Sun RPC」サービスを提供していることをアドバタイズしても意味があるわけではありません。同様に、Microsoftのサーバーメッセージブロック（SMB）ファイルサービスは、IP経由で実行されているNetbiosの上に構築されていますが、SMBファイルサーバーが「Netbios-over-IP」サービスを提供していることをアドバタイズしても意味がないわけではありません。クライアントがサービスを有意義に使用するには両方の知識が必要であるため、サービスのDNS-SD名はサービスの「何」（セマンティクス）と「どのように」（プロトコル実装）の両方をカプセル化する必要があります。クライアントがサービスの内容を知らない場合、サービスがSun RPCの上に構築されたことを単に通知するだけでは意味がありません。
Another common question is whether the service type advertised by iTunes should be "_daap._http._tcp." This would also be incorrect. Similarly, a protocol designer implementing a network service that happens to use the Simple Object Access Protocol [SOAP] should not feel compelled to have "_soap" appear somewhere in the Service Name. Part of the confusion here is that the presence of "_tcp" or "_udp" in the <Service> portion of a Service Instance Name has led people to assume that the visible structure of the <Service> should reflect the private internal structure of how the protocol was implemented. This is not correct. All that is required is that the service be identified by some unique opaque Service Name. Making the Service Name be English text that is at least marginally descriptive of what the service does may be convenient, but it is by no means essential.
別の一般的な質問は、iTunesによってアドバタイズされるサービスタイプが「_daap._http._tcp」である必要があるかどうかです。これも正しくありません。同様に、Simple Object Access Protocol [SOAP]をたまたま使用するネットワークサービスを実装するプロトコル設計者は、サービス名のどこかに "_soap"が表示されることを強いられないはずです。ここでの混乱の一部は、サービスインスタンス名の<Service>部分に "_tcp"または "_udp"が存在することにより、<Service>の可視構造は、プロトコルが実装されました。これは正しくありません。必要なのは、サービスが一意の不透明なサービス名で識別されることだけです。サービス名を英語のテキストにすることは、サービスが何をするかを少なくとも少し説明するのに便利かもしれませんが、それは決して必須ではありません。
This document does not attempt to define a sophisticated (e.g., Turing complete, or even regular expression) query language for service discovery, nor do we believe one is necessary.
このドキュメントは、サービスディスカバリ用の洗練された（例：チューリング完全、さらには正規表現）クエリ言語を定義しようとするものではありません。
However, there are some limited circumstances where narrowing the set of results may be useful. For example, many network printers offer a web-based user interface, for management and administration, using HTML/HTTP. A web browser wanting to discover all advertised web pages issues a query for "_http._tcp.<Domain>". On the other hand, there are cases where users wish to manage printers specifically, not to discover web pages in general, and it is good accommodate this. In this case, we define the "_printer" subtype of "_http._tcp", and to discover only the subset of pages advertised as having that subtype property, the web browser issues a query for "_printer._sub._http._tcp.<Domain>".
ただし、結果のセットを狭めることが役立つ場合があるいくつかの限られた状況があります。たとえば、多くのネットワークプリンターは、HTML / HTTPを使用して、管理と管理のためのWebベースのユーザーインターフェイスを提供しています。アドバタイズされたすべてのWebページを検出したいWebブラウザは、 "_ http._tcp。<ドメイン>"に対するクエリを発行します。一方で、一般的にはウェブページを発見するのではなく、具体的にプリンターを管理したいというケースもあり、これに対応した方が良いでしょう。この場合、「_ http._tcp」の「_printer」サブタイプを定義し、そのサブタイププロパティを持つものとして宣伝されているページのサブセットのみを検出するために、Webブラウザーは「_printer._sub._http._tcp。<ドメイン> "。
The Safari web browser on Mac OS X 10.5 "Leopard" and later uses subtypes in this way. If an "_http._tcp" service is discovered both via "_printer._sub._http._tcp" browsing and via "_http._tcp" browsing then it is displayed in the "Printers" section of Safari's UI. If a service is discovered only via "_http._tcp" browsing then it is displayed in the "Webpages" section of Safari's UI. This can be seen by using the commands below on Mac OS X to advertise two "fake" services. The service instance "A web page" is displayed in the "Webpages" section of Safari's Bonjour list, while the instance "A printer's web page" is displayed in the "Printers" section.
Mac OS X 10.5「Leopard」以降のSafari Webブラウザーは、この方法でサブタイプを使用します。 「_http._tcp」サービスが「_printer._sub._http._tcp」ブラウジングと「_http._tcp」ブラウジングの両方で検出された場合、SafariのUIの「プリンター」セクションに表示されます。 "_http._tcp"ブラウジングによってのみサービスが検出された場合、そのサービスはSafariのUIの[Webページ]セクションに表示されます。これは、Mac OS Xで以下のコマンドを使用して2つの「偽の」サービスを宣伝することで確認できます。 SafariのBonjourリストの「Webページ」セクションにサービスインスタンス「A Webページ」が表示され、「プリンター」セクションにインスタンス「AプリンターのWebページ」が表示されます。
dns-sd -R "A web page" _http._tcp local 100 dns-sd -R "A printer's web page" _http._tcp,_printer local 101
dns-sd -R "A Webページ" _http._tcpローカル100 dns-sd -R "AプリンターのWebページ" _http._tcp、_printerローカル101
Note that the advertised web page's Service Instance Name is unchanged by the use of subtypes -- it is still something of the form
アドバタイズされたWebページのサービスインスタンス名は、サブタイプを使用しても変更されないことに注意してください。
"The Server._http._tcp.example.com.", and the advertised web page is still discoverable using a standard browsing query for services of type "_http._tcp". The subdomain in which HTTP server SRV records are registered defines the namespace within which HTTP server names are unique. Additional subtypes (e.g., "_printer") of the basic service type (e.g., "_http._tcp") serve to allow clients to query for a narrower set of results, not to create more namespace.
"Server._http._tcp.example.com。"、およびアドバタイズされたWebページは、タイプ "_http._tcp"のサービスに対する標準のブラウジングクエリを使用して引き続き検出できます。 HTTPサーバーのSRVレコードが登録されているサブドメインは、HTTPサーバー名が一意である名前空間を定義します。基本的なサービスタイプ（「_http._tcp」など）の追加のサブタイプ（「_printer」など）は、クライアントがより多くの名前空間を作成するのではなく、より狭い結果セットをクエリできるようにするために役立ちます。
Using DNS zone file syntax, the service instance "A web page" is advertised using one PTR record, while the instance "A printer's web page" is advertised using two: the primary service type and the additional subtype. Even though the "A printer's web page" service is advertised two different ways, both PTR records refer to the name of the same SRV+TXT record pair:
DNSゾーンファイルの構文を使用すると、サービスインスタンス「A Webページ」は1つのPTRレコードを使用してアドバタイズされ、インスタンス「AプリンターのWebページ」は2つのプライマリサービスタイプと追加のサブタイプを使用してアドバタイズされます。 「プリンターのWebページ」サービスは2つの異なる方法でアドバタイズされますが、両方のPTRレコードは同じSRV + TXTレコードペアの名前を参照します。
; One PTR record advertises "A web page" _http._tcp.local. PTR A\032web\032page._http._tcp.local.
; 1つのPTRレコードが「A Webページ」_http._tcp.localをアドバタイズします。 PTR A \ 032web \ 032page._http._tcp.local。
; Two different PTR records advertise "A printer's web page" _http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local. _printer._sub._http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local.
; 2つの異なるPTRレコードが「AプリンターのWebページ」_http._tcp.localをアドバタイズします。 PTR A \ 032printer's \ 032web \ 032page._http._tcp.local。 _printer._sub._http._tcp.local。 PTR A \ 032printer's \ 032web \ 032page._http._tcp.local。
Subtypes are appropriate when it is desirable for different kinds of client to be able to browse for services at two levels of granularity. In the example above, we describe two classes of HTTP clients: general web browsing clients that are interested in all web pages, and specific printer management tools that would like to discover only web UI pages advertised by printers. The set of HTTP servers on the network is the same in both cases; the difference is that some clients want to discover all of them, whereas other clients only want to find the subset of HTTP servers whose purpose is printer administration.
サブタイプは、さまざまな種類のクライアントが2つのレベルの粒度でサービスを参照できることが望ましい場合に適しています。上記の例では、HTTPクライアントの2つのクラスについて説明します。すべてのWebページに関心のある一般的なWebブラウジングクライアントと、プリンターによってアドバタイズされるWeb UIページのみを検出する特定のプリンター管理ツールです。ネットワーク上のHTTPサーバーのセットはどちらの場合も同じです。違いは、一部のクライアントはそれらのすべてを検出したいのに対し、他のクライアントは目的がプリンター管理であるHTTPサーバーのサブセットのみを検出したいということです。
Subtypes are only appropriate in two-level scenarios such as this one, where some clients want to find the full set of services of a given type, and at the same time other clients only want to find some subset. Generally speaking, if there is no client that wants to find the entire set, then it's neither necessary nor desirable to use the subtype mechanism. If all clients are browsing for some particular subtype, and no client exists that browses for the parent type, then a new Service Name representing the logical service should be defined, and software should simply advertise and browse for that particular service type directly. In particular, just because a particular network service happens to be implemented in terms of some other underlying protocol, like HTTP, Sun RPC, or SOAP, doesn't mean that it's sensible for that service to be defined as a subtype of "_http", "_sunrpc", or "_soap". That would only be useful if there were some class of client for which it is sensible to say, "I want to discover a service on the network, and I don't care what it does, as long as it does it using the SOAP XML RPC mechanism."
サブタイプは、一部のクライアントが特定のタイプのサービスの完全なセットを検索し、同時に他のクライアントが一部のサブセットのみを検索するような、2レベルのシナリオでのみ適切です。一般的に言えば、セット全体を検索したいクライアントがいない場合、サブタイプメカニズムを使用する必要はなく、また望ましくもありません。すべてのクライアントが特定のサブタイプを参照していて、親タイプを参照するクライアントが存在しない場合は、論理サービスを表す新しいサービス名を定義し、ソフトウェアはその特定のサービスタイプを直接アドバタイズして参照するだけです。特に、特定のネットワークサービスがHTTP、Sun RPC、SOAPなどの他の基盤となるプロトコルで実装されているからといって、そのサービスを「_http」のサブタイプとして定義することが賢明であるとは限りません、「_ sunrpc」、または「_soap」。これは、「ネットワーク上でサービスを発見したいのですが、SOAPを使用してサービスを行う限り、何をするかは気にしません」と言うのが賢明なクライアントのクラスが存在する場合にのみ役立ちます。 XML RPCメカニズム。」
Subtype strings are not required to begin with an underscore, though they often do. As with the TXT record key/value pairs, the list of possible subtypes, if any (including whether some or all begin with an underscore) are defined and specified separately for each basic service type.
サブタイプ文字列は、アンダースコアで始まる必要はありませんが、アンダースコアで始まることがよくあります。 TXTレコードのキーと値のペアの場合と同様に、可能なサブタイプのリスト（一部またはすべてがアンダースコアで始まるかどうかを含む）が定義され、基本サービスタイプごとに個別に指定されます。
Subtype strings (e.g., "_printer" in the example above) may be constructed using arbitrary 8-bit data values. In many cases these data values may be UTF-8 [RFC3629] representations of text, or even (as in the example above) plain ASCII [RFC20], but they do not have to be. Note, however, that even when using arbitrary 8-bit data for subtype strings, DNS name comparisons are still case-insensitive, so (for example) the byte values 0x41 and 0x61 will be considered equivalent for subtype comparison purposes.
サブタイプ文字列（上記の例では「_printer」）は、任意の8ビットデータ値を使用して構築できます。多くの場合、これらのデータ値はテキストのUTF-8 [RFC3629]表現、または（上記の例のように）プレーンなASCII [RFC20]ですが、そうである必要はありません。ただし、サブタイプ文字列に任意の8ビットデータを使用する場合でも、DNS名の比較では大文字と小文字が区別されないため、（たとえば）バイト値0x41と0x61はサブタイプ比較の目的で同等と見なされます。
As specified above, Service Names are allowed to be no more than fifteen characters long. The reason for this limit is to conserve bytes in the domain name for use both by the network administrator (choosing service domain names) and by the end user (choosing instance names).
上記で指定したように、サービス名は15文字以下にする必要があります。この制限の理由は、ネットワーク管理者（サービスドメイン名を選択）とエンドユーザー（インスタンス名を選択）の両方が使用するドメイン名のバイトを節約するためです。
A fully qualified domain name may be up to 255 bytes long, plus one byte for the final terminating root label at the end. Domain names used by DNS-SD take the following forms:
完全修飾ドメイン名は、最大255バイトの長さに、最後の最後の終了ルートラベル用に1バイトを加えたものにすることができます。 DNS-SDで使用されるドメイン名は、次の形式を取ります。
<sn>._tcp . <servicedomain> . <parentdomain>. <Instance> . <sn>._tcp . <servicedomain> . <parentdomain>. <sub>._sub . <sn>._tcp . <servicedomain> . <parentdomain>.
<sn> ._ tcp。 <servicedomain>。 <親ドメイン>。 <インスタンス>。 <sn> ._ tcp。 <servicedomain>。 <親ドメイン>。 <sub> ._ sub。 <sn> ._ tcp。 <servicedomain>。 <親ドメイン>。
The first example shows the name used for PTR queries. The second shows a Service Instance Name, i.e., the name of the service's SRV and TXT records. The third shows a subtype browsing name, i.e., the name of a PTR record pointing to a Service Instance Name (see Section 7.1, "Selective Instance Enumeration").
最初の例は、PTRクエリに使用される名前を示しています。 2番目は、サービスインスタンス名、つまり、サービスのSRVおよびTXTレコードの名前を示しています。 3番目は、サブタイプの参照名、つまりサービスインスタンス名を指すPTRレコードの名前を示します（7.1項「選択的なインスタンス列挙」を参照）。
The Service Name <sn> may be up to 15 bytes, plus the underscore and length byte, making a total of 17. Including the "_udp" or "_tcp" and its length byte, this makes 22 bytes.
サービス名<sn>は最大15バイト、アンダースコアおよび長さバイトに加えて合計17になります。「_ udp」または「_tcp」とその長さバイトを含めると、22バイトになります。
The instance name <Instance> may be up to 63 bytes. Including the length byte used by the DNS format when the name is stored in a packet, that makes 64 bytes.
インスタンス名<Instance>は最大63バイトです。名前がパケットに格納されるときにDNS形式で使用される長さバイトを含めると、64バイトになります。
When using subtypes, the subtype identifier is allowed to be up to 63 bytes, plus the length byte, making 64. Including the "_sub" and its length byte, this makes 69 bytes.
サブタイプを使用する場合、サブタイプIDは最大63バイトに長さバイトを加えて64にすることができます。「_ sub」とその長さバイトを含めると、これは69バイトになります。
Typically, DNS-SD service records are placed into subdomains of their own beneath a company's existing domain name. Since these subdomains are intended to be accessed through graphical user interfaces, not typed on a command line, they are frequently long and descriptive. Including the length byte, the user-visible service domain may be up to 64 bytes.
通常、DNS-SDサービスレコードは、会社の既存のドメイン名の下にある独自のサブドメインに配置されます。これらのサブドメインは、コマンドラインで入力するのではなく、グラフィカルユーザーインターフェイスを介してアクセスすることを目的としているため、多くの場合、長くて説明的です。長さバイトを含め、ユーザーに表示されるサービスドメインは最大64バイトです。
Of our available 255 bytes, we have now accounted for 69+22+64 = 155 bytes. This leaves 100 bytes to accommodate the organization's existing domain name <parentdomain>. When used with Multicast DNS, <parentdomain> is "local.", which easily fits. When used with parent domains of 100 bytes or less, the full functionality of DNS-SD is available without restriction. When used with parent domains longer than 100 bytes, the protocol risks exceeding the maximum possible length of domain names, causing failures. In this case, careful choice of short <servicedomain> names can help avoid overflows. If the <servicedomain> and <parentdomain> are too long, then service instances with long instance names will not be discoverable or resolvable, and applications making use of long subtype names may fail.
利用可能な255バイトのうち、69 + 22 + 64 = 155バイトを占めています。これにより、組織の既存のドメイン名<parentdomain>に対応するために100バイトが残ります。マルチキャストDNSで使用する場合、<parentdomain>は「ローカル」であり、簡単に適合します。 100バイト以下の親ドメインで使用すると、DNS-SDのすべての機能が制限なしに利用できます。 100バイトを超える親ドメインで使用すると、プロトコルはドメイン名の最大長を超えて、障害を引き起こすリスクがあります。この場合、短い<servicedomain>名を注意深く選択すると、オーバーフローを回避できます。 <servicedomain>と<parentdomain>が長すぎると、長いインスタンス名を持つサービスインスタンスが検出または解決できなくなり、長いサブタイプ名を使用するアプリケーションが失敗する可能性があります。
Because of this constraint, we choose to limit Service Names to 15 characters or less. Allowing more characters would not increase the expressive power of the protocol and would needlessly reduce the maximum <parentdomain> length that may be safely used.
この制約のため、サービス名は15文字以下に制限することにしました。より多くの文字を許可しても、プロトコルの表現力は向上せず、安全に使用できる<parentdomain>の最大長が不必要に短くなります。
Note that <Instance> name lengths affect the maximum number of services of a given type that can be discovered in a given <servicedomain>. The largest Unicast DNS response than can be sent (typically using TCP, not UDP) is 64 kB. Using DNS name compression, a Service Instance Enumeration PTR record requires 2 bytes for the (compressed) name, plus 10 bytes for type, class, ttl, and rdata length. The rdata of the PTR record requires up to 64 bytes for the <Instance> part of the name, plus 2 bytes for a name compression pointer to the common suffix, making a maximum of 78 bytes total. This means that using maximum-sized <Instance> names, up to 839 instances of a given service type can be discovered in a given <servicedomain>.
<Instance>名の長さは、特定の<servicedomain>で検出できる特定のタイプのサービスの最大数に影響することに注意してください。送信できる最大のユニキャストDNS応答（通常、UDPではなくTCPを使用）は64 kBです。 DNS名の圧縮を使用すると、サービスインスタンス列挙PTRレコードには、（圧縮された）名前に2バイト、タイプ、クラス、ttl、およびrdataの長さに10バイトが必要です。 PTRレコードのrdataは、名前の<Instance>部分に最大64バイト、さらに共通サフィックスへの名前圧縮ポインターに最大2バイトを必要とし、合計で最大78バイトになります。つまり、最大サイズの<Instance>名を使用すると、特定のサービスタイプの最大839個のインスタンスを特定の<servicedomain>で検出できます。
Multicast DNS aggregates response packets, so it does not have the same hard limit, but in practice it is also useful for up to a few hundred instances of a given service type, but probably not thousands.
マルチキャストDNSは応答パケットを集約するため、同じハード制限はありませんが、実際には、特定のサービスタイプの数百までのインスタンスに役立ちますが、おそらく数千ではありません。
However, displaying even 100 instances in a flat list is probably too many to be helpful to a typical user. If a network has more than 100 instances of a given service type, it's probably appropriate to divide those services into logical subdomains by building, by floor, by department, etc.
ただし、フラットなリストに100個のインスタンスを表示するだけでも、通常のユーザーには役立たないでしょう。ネットワークに特定のサービスタイプのインスタンスが100を超える場合、それらのサービスを、建物ごと、フロアごと、部門ごとなどに論理サブドメインに分割するのがおそらく適切です。
In some cases, there may be several network protocols available that all perform roughly the same logical function. For example, the printing world has the lineprinter (LPR) protocol [RFC1179] and the Internet Printing Protocol (IPP) [RFC2910], both of which cause printed sheets to be emitted from printers in much the same way. In addition, many printer vendors send their own proprietary page description language (PDL) data over a TCP connection to TCP port 9100, herein referred to generically as the "pdl-datastream" protocol. In an ideal world, we would have only one network printing protocol, and it would be sufficiently good that no one felt a compelling need to invent a different one. However, in practice, multiple legacy protocols do exist, and a service discovery protocol has to accommodate that.
場合によっては、すべてがほぼ同じ論理機能を実行するいくつかのネットワークプロトコルが利用できる場合があります。たとえば、印刷の世界にはラインプリンター（LPR）プロトコル[RFC1179]とインターネット印刷プロトコル（IPP）[RFC2910]があり、どちらも印刷されたシートをプリンターからほぼ同じ方法で排出します。さらに、多くのプリンターベンダーは、独自のページ記述言語（PDL）データをTCP接続を介してTCPポート9100に送信します。ここでは、「pdl-datastream」プロトコルと総称します。理想的な世界では、ネットワーク印刷プロトコルは1つしかなく、別のプロトコルを発明する必要性を誰もが感じなかったとしても十分です。ただし、実際には複数のレガシープロトコルが存在し、サービスディスカバリプロトコルはこれに対応する必要があります。
Many printers implement all three printing protocols: LPR, IPP, and pdl-datastream. For the benefit of clients that may speak only one of those protocols, all three are advertised.
多くのプリンターは、LPR、IPP、pdl-datastreamの3つの印刷プロトコルをすべて実装しています。これらのプロトコルの1つだけを話すクライアントの利益のために、3つすべてがアドバタイズされます。
However, some clients may implement two, or all three of those printing protocols. When a client looks for all three service types on the network, it will find three distinct services -- an LPR service, an IPP service, and a pdl-datastream service -- all of which cause printed sheets to be emitted from the same physical printer.
ただし、クライアントによっては、これらの印刷プロトコルのうち2つまたは3つすべてを実装している場合があります。クライアントがネットワーク上の3つのサービスタイプをすべて検索すると、LPRサービス、IPPサービス、およびpdl-datastreamサービスという3つの異なるサービスが見つかります。これらすべてにより、印刷されたシートが同じ物理的なサービスから排出されます。プリンター。
In a case like this, where multiple protocols all perform effectively the same function, a client may browse for all the service types it supports and display all the discovered instance names in a single aggregated list. Where the same instance name is discovered more than once because that entity supports more than one service type (e.g. a single printer which implements multiple printing protocols) the duplicates should be suppressed and the name should appear only once in the list. When the user indicates their desire to print on a given named printer, the printing client is responsible for choosing which of the available protocols will best achieve the desired effect, without, for example, requiring the user to make a manual choice between LPR and IPP.
このような場合、複数のプロトコルがすべて実質的に同じ機能を実行し、クライアントはサポートするすべてのサービスタイプを参照し、検出されたすべてのインスタンス名を1つの集約リストに表示できます。エンティティが複数のサービスタイプ（たとえば、複数の印刷プロトコルを実装する単一のプリンター）をサポートしているために同じインスタンス名が複数回検出される場合、重複は抑制され、名前はリストに1回だけ表示されます。ユーザーが特定の名前付きプリンターで印刷したいという希望を示した場合、印刷クライアントは、ユーザーが手動でLPRとIPPを選択する必要なしに、使用可能なプロトコルのどれが望ましい効果を最もよく達成するかを選択する責任があります。 。
As described so far, this all works very well. However, consider the case of: some future printer that only supports IPP printing, and some other future printer that only supports pdl-datastream printing.
これまで説明したように、これはすべて非常にうまく機能します。ただし、IPP印刷のみをサポートする将来の一部のプリンターと、pdl-datastream印刷のみをサポートするその他の将来のプリンターの場合を考慮してください。
The namespaces for different service types are intentionally disjoint (it is acceptable and desirable to be able to have both a file server called "Sales Department" and a printer called "Sales Department"). However, it is not desirable, in the common case, to allow two different printers both to be called "Sales Department" merely because those two printers implement different printing protocols.
異なるサービスタイプの名前空間は意図的に切り離されています（「営業部」と呼ばれるファイルサーバーと「営業部」と呼ばれるプリンターの両方を使用できることが許容され、望ましいです）。ただし、一般的なケースでは、2つのプリンタが異なる印刷プロトコルを実装しているという理由だけで、2つの異なるプリンタの両方を「営業部門」と呼ぶことを許可することは望ましくありません。
To help guard against this, when there are two or more network protocols that perform roughly the same logical function, one of the protocols is declared the "flagship" of the fleet of related protocols. Typically the flagship protocol is the oldest and/or best-known protocol of the set.
これを防ぐために、ほぼ同じ論理機能を実行する2つ以上のネットワークプロトコルがある場合、プロトコルの1つが、関連する一連のプロトコルの「フラグシップ」として宣言されます。通常、フラグシッププロトコルは、セットの最も古く、かつ/または最もよく知られているプロトコルです。
If a device does not implement the flagship protocol, then it instead creates a placeholder SRV record (priority=0, weight=0, port=0, target host = host name of device) with that name. If, when it attempts to create this SRV record, it finds that a record with the same name already exists, then it knows that this name is already taken by some other entity implementing at least one of the protocols from the fleet, and it must choose another. If no SRV record already exists, then the act of creating it stakes a claim to that name so that future devices in the same protocol fleet will detect a conflict when they try to use it.
デバイスがフラグシッププロトコルを実装していない場合、代わりにその名前でプレースホルダーSRVレコード（優先度= 0、重み= 0、ポート= 0、ターゲットホスト=デバイスのホスト名）を作成します。このSRVレコードを作成しようとしたときに、同じ名前のレコードがすでに存在することがわかった場合、この名前は、フリートからプロトコルの少なくとも1つを実装している他のエンティティによってすでに使用されていることがわかります。別のものを選びます。 SRVレコードが既に存在しない場合、それを作成することにより、同じプロトコル群の将来のデバイスがそれを使用しようとすると競合が検出されるように、その名前に対する要求が発生します。
Note: When used with Multicast DNS [RFC6762], the target host field of the placeholder SRV record MUST NOT be the empty root label. The SRV record needs to contain a real target host name in order for the Multicast DNS conflict detection rules to operate. If two different devices were to create placeholder SRV records both using a null target host name (just the root label), then the two SRV records would be seen to be in agreement, and no conflict would be detected.
注：マルチキャストDNS [RFC6762]で使用する場合、プレースホルダーSRVレコードのターゲットホストフィールドを空のルートラベルにすることはできません。マルチキャストDNS競合検出ルールが機能するには、SRVレコードに実際のターゲットホスト名が含まれている必要があります。 2つの異なるデバイスが両方ともnullのターゲットホスト名（ルートラベルのみ）を使用してプレースホルダーSRVレコードを作成する場合、2つのSRVレコードは一致していると見なされ、競合は検出されません。
By defining a common well-known flagship protocol for the class, future devices that may not even know about each other's protocols establish a common ground where they can coordinate to verify uniqueness of names.
共通のよく知られているフラグシッププロトコルをクラスに定義することにより、互いのプロトコルについてさえ知らない将来のデバイスは、名前の一意性を検証するために調整できる共通の基盤を確立します。
No PTR record is created advertising the presence of empty flagship SRV records, since they do not represent a real service being advertised, and hence are not (and should not be) discoverable via Service Instance Enumeration (browsing).
空のフラグシップSRVレコードの存在をアドバタイズするPTRレコードは作成されません。これは、アドバタイズされている実際のサービスを表すものではないため、サービスインスタンス列挙（ブラウジング）で検出できない（そして検出できないはずです）ためです。
In general, a normal client is not interested in finding *every* service on the network, just the services that the client knows how to use.
一般に、通常のクライアントは、ネットワーク上の*すべての*サービスを見つけることには関心がなく、クライアントが使用方法を知っているサービスだけを見つけます。
However, for problem diagnosis and network management tools, it may be useful for network administrators to find the list of advertised service types on the network, even if those Service Names are just opaque identifiers and not particularly informative in isolation.
ただし、問題の診断およびネットワーク管理ツールの場合、サービス名が単に不透明な識別子であり、個別に情報を提供するものではない場合でも、ネットワーク管理者がネットワーク上でアドバタイズされたサービスタイプのリストを見つけると役立つ場合があります。
For this purpose, a special meta-query is defined. A DNS query for PTR records with the name "_services._dns-sd._udp.<Domain>" yields a set of PTR records, where the rdata of each PTR record is the two-label <Service> name, plus the same domain, e.g., "_http._tcp.<Domain>". Including the domain in the PTR rdata allows for slightly better name compression in Unicast DNS responses, but only the first two labels are relevant for the purposes of service type enumeration. These two-label service types can then be used to construct subsequent Service Instance Enumeration PTR queries, in this <Domain> or others, to discover instances of that service type.
この目的のために、特別なメタクエリが定義されています。 「_services._dns-sd._udp。<ドメイン>」という名前のPTRレコードのDNSクエリは、一連のPTRレコードを生成します。各PTRレコードのrdataは、2つのラベルの<サービス>名と同じドメインです。たとえば、「_ http._tcp。<ドメイン>」。ドメインをPTR rdataに含めると、ユニキャストDNS応答での名前の圧縮がわずかに改善されますが、サービスタイプの列挙の目的に関連するのは最初の2つのラベルのみです。これらの2つのラベルのサービスタイプを使用して、この<ドメイン>またはその他のサービスインスタンス列挙PTRクエリを作成し、そのサービスタイプのインスタンスを検出できます。
How a service's PTR, SRV, and TXT records make their way into the DNS is outside the scope of this document, but, for illustrative purposes, some examples are given here.
サービスのPTR、SRV、およびTXTレコードがDNSに到達する方法は、このドキュメントの範囲外ですが、説明のために、ここではいくつかの例を示します。
On some networks, the administrator might manually enter the records into the name server's configuration file.
一部のネットワークでは、管理者が手動でレコードをネームサーバーの構成ファイルに入力する場合があります。
A network monitoring tool could output a standard zone file to be read into a conventional DNS server. For example, a tool that can find networked PostScript laser printers using AppleTalk NBP could find the list of printers, communicate with each one to find its IP address, PostScript version, installed options, etc., and then write out a DNS zone file describing those printers and their capabilities using DNS resource records. That information would then be available to IP-only clients that implement DNS-SD but not AppleTalk NBP.
ネットワーク監視ツールは、標準のゾーンファイルを出力して、従来のDNSサーバーに読み込むことができます。たとえば、AppleTalk NBPを使用してネットワーク化されたPostScriptレーザープリンターを見つけることができるツールは、プリンターのリストを見つけ、それぞれと通信して、そのIPアドレス、PostScriptバージョン、インストールされているオプションなどを見つけ、次にDNSゾーンファイルを書き出すことができます。これらのプリンターとDNSリソースレコードを使用するそれらの機能。その情報は、DNS-SDを実装しているがAppleTalk NBPを実装していないIPのみのクライアントが利用できます。
A printer manager device that has knowledge of printers on the network through some other management protocol could also output a zone file or use DNS Update [RFC2136] [RFC3007].
他の管理プロトコルを介してネットワーク上のプリンターを認識しているプリンターマネージャーデバイスも、ゾーンファイルを出力したり、DNSアップデートを使用したりできます[RFC2136] [RFC3007]。
Alternatively, a printer manager device could implement enough of the DNS protocol that it is able to answer DNS queries directly, and Example Co.'s main DNS server could delegate the "_ipp._tcp.example.com." subdomain to the printer manager device.
または、プリンターマネージャーデバイスは、DNSクエリに直接応答できる十分なDNSプロトコルを実装でき、Example Co.のメインDNSサーバーは "_ipp._tcp.example.com"を委任できます。プリンタマネージャデバイスへのサブドメイン。
IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] to automatically register their own PTR, SRV, and TXT records with the DNS server.
IPプリンターは、ダイナミックDNSアップデート[RFC2136] [RFC3007]を使用して、独自のPTR、SRV、およびTXTレコードをDNSサーバーに自動的に登録できます。
Zeroconf printers answer Multicast DNS queries on the local link for their own PTR, SRV, and TXT names ending with ".local." [RFC6762].
Zeroconfプリンターは、「。local」で終わる独自のPTR、SRV、およびTXT名のローカルリンクでマルチキャストDNSクエリに応答します。 [RFC6762]。
One of the motivations for DNS-based Service Discovery is to enable a visiting client (e.g., a Wi-Fi-equipped [IEEEW] laptop computer, tablet, or mobile telephone) arriving on a new network to discover what services are available on that network, without any manual configuration. The logic that discovering services without manual configuration is a good idea also dictates that discovering recommended registration and browsing domains without manual configuration is a similarly good idea.
DNSベースのサービスディスカバリの動機の1つは、新しいネットワークにアクセスする訪問クライアント（たとえば、Wi-Fiが装備された[IEEEW]ラップトップコンピュータ、タブレット、または携帯電話）が、どのサービスが利用できるかを発見できるようにすることです。手動設定なしのネットワーク。手動設定なしでサービスを検出することは良いアイデアであるというロジックは、手動設定なしで推奨される登録とブラウジングドメインを検出することも同様に良いアイデアであることを示しています。
This discovery is performed using DNS queries, using Unicast or Multicast DNS. Five special RR names are reserved for this purpose:
この検出は、DNSクエリを使用して、ユニキャストまたはマルチキャストDNSを使用して実行されます。この目的のために、5つの特別なRR名が予約されています。
b._dns-sd._udp.<domain>. db._dns-sd._udp.<domain>. r._dns-sd._udp.<domain>. dr._dns-sd._udp.<domain>. lb._dns-sd._udp.<domain>.
b._dns-sd._udp。<ドメイン>。 db._dns-sd._udp。<ドメイン>。 r._dns-sd._udp。<ドメイン>。 dr._dns-sd._udp。<ドメイン>。 lb._dns-sd._udp。<ドメイン>。
By performing PTR queries for these names, a client can learn, respectively:
これらの名前に対してPTRクエリを実行することにより、クライアントはそれぞれ次のことを学習できます。
o A list of domains recommended for browsing.
o ブラウジングに推奨されるドメインのリスト。
o A single recommended default domain for browsing.
o ブラウジングに推奨される単一のデフォルトドメイン。
o A list of domains recommended for registering services using Dynamic Update.
o 動的更新を使用してサービスを登録するために推奨されるドメインのリスト。
o A single recommended default domain for registering services.
o サービスを登録するための単一の推奨デフォルトドメイン。
o The "legacy browsing" or "automatic browsing" domain(s). Sophisticated client applications that care to present choices of domain to the user use the answers learned from the previous four queries to discover the domains to present. In contrast, many current applications browse without specifying an explicit domain, allowing the operating system to automatically select an appropriate domain on their behalf. It is for this class of application that the "automatic browsing" query is provided, to allow the network administrator to communicate to the client operating systems which domain(s) should be used automatically for these applications.
o「レガシーブラウジング」または「自動ブラウジング」ドメイン。ドメインの選択をユーザーに提示することを重視する高度なクライアントアプリケーションは、前の4つのクエリから学習した回答を使用して、提示するドメインを検出します。対照的に、現在の多くのアプリケーションは、明示的なドメインを指定せずに参照するため、オペレーティングシステムが適切なドメインを自動的に選択できます。このクラスのアプリケーションでは、「自動ブラウジング」クエリが提供されており、ネットワーク管理者は、これらのアプリケーションでどのドメインを自動的に使用する必要があるかをクライアントオペレーティングシステムと通信できます。
These domains are purely advisory. The client or user is free to register services and/or browse in any domains. The purpose of these special queries is to allow software to create a user interface that displays a useful list of suggested choices to the user, from which the user may make an informed selection, or ignore the offered suggestions and manually enter their own choice.
これらのドメインは、単なる助言です。クライアントまたはユーザーは、サービスを登録したり、任意のドメインで閲覧したりできます。これらの特別なクエリの目的は、提案された選択肢の有用なリストをユーザーに表示するユーザーインターフェイスをソフトウェアが作成できるようにすることです。そこからユーザーは情報に基づいた選択を行うか、提供された提案を無視して手動で自分の選択を入力できます。
The <domain> part of the Domain Enumeration query name may be "local." (meaning "perform the query using link-local multicast") or it may be learned through some other mechanism, such as the DHCP "Domain" option (option code 15) [RFC2132], the DHCP "Domain Search" option (option code 119) [RFC3397], or IPv6 Router Advertisement Options [RFC6106].
ドメイン列挙クエリ名の<domain>部分は「ローカル」である可能性があります。 （「リンクローカルマルチキャストを使用してクエリを実行する」の意味）またはDHCP "ドメイン"オプション（オプションコード15）[RFC2132]、DHCP "ドメイン検索"オプション（オプションコード119）[RFC3397]、またはIPv6ルーターアドバタイズメントオプション[RFC6106]。
The <domain> part of the query name may also be derived a different way, from the host's IP address. The host takes its IP address and calculates the logical AND of that address and its subnet mask, to derive the 'base' address of the subnet (the 'network address' of that subnet, or, equivalently, the IP address of the 'all-zero' host address on that subnet). It then constructs the conventional DNS "reverse mapping" name corresponding to that base address, and uses that as the <domain> part of the name for the queries described above. For example, if a host has the address 192.168.12.34, with the subnet mask 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, and to discover the recommended automatic browsing domain(s) for devices on this subnet, the host issues a DNS PTR query for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
クエリ名の<domain>部分は、ホストのIPアドレスから別の方法で取得することもできます。ホストはそのIPアドレスを取得し、そのアドレスとそのサブネットマスクの論理ANDを計算して、サブネットの「ベース」アドレス（そのサブネットの「ネットワークアドレス」、または同等に「すべて」のIPアドレスを導出しますそのサブネット上の-zero 'ホストアドレス）。次に、そのベースアドレスに対応する従来のDNS「リバースマッピング」名を作成し、それを上記のクエリの名前の<domain>部分として使用します。たとえば、ホストのアドレスが192.168.12.34で、サブネットマスクが255.255.0.0の場合、サブネットの「ベース」アドレスは192.168.0.0であり、このデバイスの推奨自動ブラウジングドメインを検出しますサブネットの場合、ホストは「lb._dns-sd._udp.0.0.168.192.in-addr.arpa」という名前のDNS PTRクエリを発行します。
Equivalent address-derived Domain Enumeration queries should also be done for the host's IPv6 address(es).
同等のアドレスから派生したドメイン列挙クエリも、ホストのIPv6アドレスに対して実行する必要があります。
Address-derived Domain Enumeration queries SHOULD NOT be done for IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses [RFC4862].
アドレス派生ドメイン列挙クエリは、IPv4リンクローカルアドレス[RFC3927]またはIPv6リンクローカルアドレス[RFC4862]に対して実行してはなりません（SHOULD NOT）。
Sophisticated clients may perform Domain Enumeration queries both in "local." and in one or more unicast domains, using both name-derived and address-derived queries, and then present the user with an combined result, aggregating the information received from all sources.
洗練されたクライアントは、「ローカル」でドメイン列挙クエリを実行できます。また、1つ以上のユニキャストドメインで、名前から派生したクエリとアドレスから派生したクエリの両方を使用して、すべてのソースから受信した情報を集約した結果をユーザーに提示します。
DNS has an efficiency feature whereby a DNS server may place additional records in the additional section of the DNS message. These additional records are records that the client did not explicitly request, but the server has reasonable grounds to expect that the client might request them shortly, so including them can save the client from having to issue additional queries.
DNSには、DNSサーバーがDNSメッセージの追加セクションに追加レコードを配置できる効率機能があります。これらの追加レコードは、クライアントが明示的に要求しなかったレコードですが、サーバーには、クライアントが間もなく要求する可能性があることを期待する合理的な根拠があるため、それらを含めると、クライアントが追加のクエリを発行する必要がなくなります。
This section recommends which additional records SHOULD be generated to improve network efficiency, for both Unicast and Multicast DNS-SD responses.
このセクションでは、ユニキャストとマルチキャストの両方のDNS-SD応答について、ネットワーク効率を向上させるために追加のレコードを生成する必要があることを推奨しています。
Note that while servers SHOULD add these additional records for efficiency purposes, as with all DNS additional records, it is the client's responsibility to determine whether or not to trust them.
すべてのDNS追加レコードと同様に、サーバーは効率を高めるためにこれらの追加レコードを追加する必要がありますが、それらを信頼するかどうかを決定するのはクライアントの責任です。
Generally speaking, stub resolvers that talk to a single recursive name server for all their queries will trust all records they receive from that recursive name server (whom else would they ask?). Recursive name servers that talk to multiple authoritative name servers should verify that any records they receive from a given authoritative name server are "in bailiwick" for that server, and ignore them if not.
一般的に言って、すべてのクエリについて単一の再帰ネームサーバーと通信するスタブリゾルバは、その再帰ネームサーバーから受信するすべてのレコードを信頼します（他に誰に尋ねますか？）。複数の権威ネームサーバーと通信する再帰ネームサーバーは、特定の権威ネームサーバーから受信するすべてのレコードがそのサーバーの「bailiwick」にあることを確認し、そうでない場合は無視します。
Clients MUST be capable of functioning correctly with DNS servers (and Multicast DNS Responders) that fail to generate these additional records automatically, by issuing subsequent queries for any further record(s) they require. The additional-record generation rules in this section are RECOMMENDED for improving network efficiency, but are not required for correctness.
クライアントは、必要な追加のレコードに対して後続のクエリを発行することにより、これらの追加レコードを自動的に生成できないDNSサーバー（およびマルチキャストDNSレスポンダー）で正しく機能する必要があります。このセクションの追加レコード生成ルールは、ネットワーク効率を向上させるために推奨されていますが、正確さのために必須ではありません。
When including a DNS-SD Service Instance Enumeration or Selective Instance Enumeration (subtype) PTR record in a response packet, the server/responder SHOULD include the following additional records:
DNS-SDサービスインスタンス列挙または選択的インスタンス列挙（サブタイプ）PTRレコードを応答パケットに含める場合、サーバー/レスポンダーは次の追加レコードを含める必要があります（SHOULD）。
o The SRV record(s) named in the PTR rdata. o The TXT record(s) named in the PTR rdata. o All address records (type "A" and "AAAA") named in the SRV rdata.
o PTR rdataで指定されたSRVレコード。 o PTR rdataで指定されたTXTレコード。 o SRV rdataで指定されたすべてのアドレスレコード（タイプ "A"および "AAAA"）。
When including an SRV record in a response packet, the server/responder SHOULD include the following additional records:
SRVレコードを応答パケットに含める場合、サーバー/レスポンダーは次の追加レコードを含める必要があります（SHOULD）。
o All address records (type "A" and "AAAA") named in the SRV rdata.
o SRV rdataで指定されたすべてのアドレスレコード（タイプ「A」および「AAAA」）。
When including a TXT record in a response packet, no additional records are required.
TXTレコードを応答パケットに含める場合、追加のレコードは必要ありません。
In response to address queries, or other record types, no new additional records are recommended by this document.
アドレスクエリまたはその他のレコードタイプに応じて、このドキュメントでは新しい追加のレコードは推奨されていません。
The following examples were prepared using standard unmodified nslookup and standard unmodified BIND running on GNU/Linux.
以下の例は、GNU / Linuxで実行される標準の未変更のnslookupと標準の未変更のBINDを使用して作成されました。
Note: In real products, this information is obtained and presented to the user using graphical network browser software, not command-line tools. However, if you wish, you can try these examples for yourself as you read along, using the nslookup command already available on most Unix machines.
注：実際の製品では、この情報はコマンドラインツールではなくグラフィカルネットワークブラウザソフトウェアを使用して取得され、ユーザーに提示されます。ただし、必要に応じて、大部分のUNIXマシンですでに使用可能なnslookupコマンドを使用して、これらの例を読み進めることができます。
nslookup -q=ptr _http._tcp.dns-sd.org. _http._tcp.dns-sd.org name = Zeroconf._http._tcp.dns-sd.org _http._tcp.dns-sd.org name = Multicast\032DNS._http._tcp.dns-sd.org _http._tcp.dns-sd.org name = Service\032Discovery._http._tcp.dns-sd.org _http._tcp.dns-sd.org name = Stuart's\032Printer._http._tcp.dns-sd.org
nslookup -q = ptr _http._tcp.dns-sd.org。 _http._tcp.dns-sd.org name = Zeroconf._http._tcp.dns-sd.org _http._tcp.dns-sd.org name = Multicast \ 032DNS._http._tcp.dns-sd.org _http._tcp。 dns-sd.org name = Service \ 032Discovery._http._tcp.dns-sd.org _http._tcp.dns-sd.org name = Stuart's \ 032Printer._http._tcp.dns-sd.org
Answer: There are four, called "Zeroconf", "Multicast DNS", "Service Discovery", and "Stuart's Printer".
回答：「Zeroconf」、「Multicast DNS」、「Service Discovery」、「Stuart's Printer」の4つがあります。
Note that nslookup escapes spaces as "\032" for display purposes, but a graphical DNS-SD browser should not.
nslookupは、表示用にスペースを「\ 032」としてエスケープしますが、グラフィカルなDNS-SDブラウザではエスケープしないでください。
nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org. _printer._sub._http._tcp.dns-sd.org name = Stuart's\032Printer._http._tcp.dns-sd.org
nslookup -q = ptr _printer._sub._http._tcp.dns-sd.org。 _printer._sub._http._tcp.dns-sd.org name = Stuart's \ 032Printer._http._tcp.dns-sd.org
Answer: "Stuart's Printer" is the web configuration UI of a network printer.
回答：「Stuart's Printer」は、ネットワークプリンターのWeb設定UIです。
nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org."
Service\032Discovery._http._tcp.dns-sd.org
priority = 0, weight = 0, port = 80, host = dns-sd.org
Service\032Discovery._http._tcp.dns-sd.org
text = "txtvers=1" "path=/"
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org internet address = 64.142.82.154
ns1.dns-sd.org internet address = 64.142.82.152
Answer: You need to connect to dns-sd.org port 80, path "/". The address for dns-sd.org is also given (64.142.82.154).
回答：dns-sd.orgのポート80、パス「/」に接続する必要があります。 dns-sd.orgのアドレスも指定されています（64.142.82.154）。
IPv6 has only minor differences from IPv4.
IPv6とIPv4の違いはわずかです。
The address of the SRV record's target host is given by the appropriate IPv6 "AAAA" address records instead of (or in addition to) IPv4 "A" records.
SRVレコードのターゲットホストのアドレスは、IPv4 "A"レコードの代わりに（またはそれに加えて）適切なIPv6 "AAAA"アドレスレコードによって指定されます。
Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree, which is different from the IPv4 reverse-mapping tree and has longer names in it.
アドレスベースのドメイン列挙クエリは、IPv4リバースマッピングツリーとは異なり、名前が長いIPv6リバースマッピングツリーの下の名前を使用して実行されます。
Since DNS-SD is just a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates.
DNS-SDは、既存のDNSシステムでレコードに名前を付けて使用する方法の仕様にすぎないため、DNSクエリとDNS更新にすでに適用されているものに加えて、特定の追加のセキュリティ要件はありません。
For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important.
DNSクエリの場合、情報の信頼性が重要な場合は、DNSセキュリティ拡張機能（DNSSEC）[RFC4033]を使用する必要があります。
For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.
DNS更新の場合、安全な更新[RFC2136] [RFC3007]を使用して、DNSレコードを更新する権限を持つクライアントを制御する必要があります。
IANA manages the namespace of unique Service Names [RFC6335].
IANAは一意のサービス名[RFC6335]の名前空間を管理します。
When a protocol service advertising specification includes subtypes, these should be documented in the protocol specification in question and/or in the "notes" field of the registration request sent to IANA. In the event that a new subtype becomes relevant after a protocol specification has been published, this can be recorded by requesting that IANA add it to the "notes" field. For example, vendors of network printers advertise their embedded web servers using the subtype _printer. This allows printer management clients to browse for only printer-related web servers by browsing for the _printer subtype. While the existence of the _printer subtype of _http._tcp is not directly relevant to the HTTP protocol specification, it is useful to record this usage in the IANA registry to help avoid another community of developers inadvertently using the same subtype string for a different purpose. The namespace of possible subtypes is separate for each different service type. For example, the existence of the _printer subtype of _http._tcp does not imply that the _printer subtype is defined or has any meaning for any other service type.
プロトコルサービスアドバタイズメントの仕様にサブタイプが含まれている場合、これらは問題のプロトコル仕様および/またはIANAに送信された登録要求の「ノート」フィールドに文書化されている必要があります。プロトコル仕様が公開された後に新しいサブタイプが関連するようになった場合、IANAがそれを「ノート」フィールドに追加するように要求することにより、これを記録できます。たとえば、ネットワークプリンターのベンダーは、サブタイプ_printerを使用して組み込みWebサーバーをアドバタイズします。これにより、プリンター管理クライアントは、_printerサブタイプを参照して、プリンター関連のWebサーバーのみを参照できます。 _http._tcpの_printerサブタイプの存在はHTTPプロトコル仕様に直接関係しませんが、IANAレジストリにこの使用法を記録して、別の目的で同じサブタイプ文字列を誤って使用する開発者の別のコミュニティを回避するのに役立ちます。可能なサブタイプのネームスペースは、サービスタイプごとに異なります。たとえば、_http._tcpの_printerサブタイプの存在は、_printerサブタイプが定義されていること、または他のサービスタイプに対して何らかの意味があることを意味するものではありません。
When IANA records a Service Name registration, if the new application protocol is one that conceptually duplicates existing functionality of an older protocol, and the implementers desire the Flagship Naming behavior described in Section 8, then the registrant should request that IANA record the name of the flagship protocol in the "notes" field of the new registration. For example, the registrations for "ipp" and "pdl-datastream" both reference "printer" as the flagship name for this family of printing-related protocols.
IANAがサービス名登録を記録するとき、新しいアプリケーションプロトコルが古いプロトコルの既存の機能を概念的に複製するものであり、実装者がセクション8で説明されているフラグシップ命名動作を望む場合、登録者はIANAに名前の記録を要求する必要があります。新規登録の「ノート」フィールドのフラグシッププロトコル。たとえば、「ipp」と「pdl-datastream」の登録はどちらも、この印刷関連プロトコルファミリのフラグシップ名として「printer」を参照しています。
The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions.
このドキュメントで説明されている概念は、Ran Atkinson、Richard Brown、Freek Dijkstra、Ralph Droms、Erik Guttman、Pasi Sarolahti、Pekka Savola、Mark Townsley、Paul Vixie、Bill Woodcockなどの協力を得て、調査、開発、実装されています。 Bob Bradley、Josh Graessley、Scott Herscher、Rory McGuire、Roger Pantos、およびKiren Sekarの多大な貢献に特に感謝します。
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、RFC 20、1969年10月。
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987.
[RFC1033] Lottor、M。、「ドメイン管理者操作ガイド」、RFC 1033、1987年11月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「Dynamic Configuration of IPv4 Link-Local Addresses」、RFC 3927、2005年5月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワーク交換用のUnicode形式」、RFC 5198、2008年3月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスタールンド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[AFP] Mac OS X Developer Library, "Apple Filing Protocol Programming Guide", <http://developer.apple.com/ documentation/Networking/Conceptual/AFP/>.
[AFP] Mac OS X開発者ライブラリ、「Apple Filing Protocol Programming Guide」、<http://developer.apple.com/documentation/Networking/Conceptual/AFP/>。
[BJ] Apple Bonjour Open Source Software, <http://developer.apple.com/bonjour/>.
[BJ] Apple Bonjourオープンソースソフトウェア、<http://developer.apple.com/bonjour/>。
[BJP] Bonjour Printing Specification, <https://developer.apple.com/bonjour/ printing-specification/bonjourprinting-1.0.2.pdf>.
[BJP] Bonjour印刷仕様、<https://developer.apple.com/bonjour/printing-specification / bonjourprinting-1.0.2.pdf>。
[IEEEW] IEEE 802 LAN/MAN Standards Committee, <http://standards.ieee.org/wireless/>.
[IEEEW] IEEE 802 LAN / MAN標準委員会、<http://standards.ieee.org/wireless/>。
[NIAS] Cheshire, S., "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001.
[NIAS] Cheshire、S。、「DNSを使用した抽象サービスの名前付きインスタンスの発見」、進行中の作業、2001年7月。
[NSD] "NsdManager | Android Developer", June 2012, <http://developer.android.com/reference/android/ net/nsd/NsdManager.html>.
[NSD]「NsdManager | Android Developer」、2012年6月、<http://developer.android.com/reference/android/ net / nsd / NsdManager.html>。
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990.
[RFC1179] McLaughlin、L。、「ラインプリンターデーモンプロトコル」、RFC 1179、1990年8月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、April 1997。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、1997年7月。
[RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910] Herriot、R.、Ed。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「Internet Printing Protocol / 1.1：Encoding and Transport」、RFC 2910、2000年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397] Aboba、B。およびS. Cheshire、「Dynamic Host Configuration Protocol（DHCP）Domain Search Option」、RFC 3397、2002年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年1月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R。、およびL. Zhang、「Understanding Apple's Back to My Mac（BTMM）Service」、RFC 6281、2011年6月。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、2012年9月。
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, February 2013.
[RFC6760] Cheshire、S。およびM. Krochmal、「プロトコルがAppleTalk Name Binding Protocol（NBP）を置き換えるための要件」、RFC 6760、2013年2月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、2013年2月。
[SN] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers/>.
[SN] IANA、「サービス名およびトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/ service-names-port-numbers />。
[SOAP] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C Proposed Recommendation 24 June 2003, <http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.
[SOAP] Mitra、N。、「SOAPバージョン1.2パート0：プライマー」、W3C Proposed Recommendation 2003年6月24日、<http://www.w3.org/TR/2003/REC-soap12-part0-20030624>。
[Unicode6] The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6) <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode6] Unicodeコンソーシアム。 Unicode Standard、バージョン6.0.0（Mountain View、CA：Unicode Consortium、2011。ISBN978-1-936213-01-6）<http://www.unicode.org/versions/Unicode6.0.0/> 。
[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、「Zero Configuration Networking：The Definitive Guide」、O'Reilly Media、Inc.、ISBN 0-596-10100-7、2005年12月。
Over the years, there have been many proposed ways to do network service discovery with IP, but none achieved ubiquity in the marketplace. Certainly none has achieved anything close to the ubiquity of today's deployment of DNS servers, clients, and other infrastructure.
長年にわたり、IPを使用してネットワークサービスを検出する方法は数多く提案されてきましたが、市場でユビキタスを実現する方法はありませんでした。確かに、今日のDNSサーバー、クライアント、およびその他のインフラストラクチャの普及に近いものを達成したものはありません。
The advantage of using DNS as the basis for service discovery is that it makes use of those existing servers, clients, protocols, infrastructure, and expertise. Existing network analyzer tools already know how to decode and display DNS packets for network debugging.
サービス検出の基礎としてDNSを使用する利点は、DNSが既存のサーバー、クライアント、プロトコル、インフラストラクチャ、専門知識を利用することです。既存のネットワークアナライザツールは、ネットワークデバッグのためにDNSパケットをデコードおよび表示する方法をすでに知っています。
For ad hoc networks such as Zeroconf environments, peer-to-peer multicast protocols are appropriate. Using DNS-SD running over Multicast DNS [RFC6762] provides zero-configuration ad hoc service discovery, while maintaining the DNS-SD semantics and record types described here.
Zeroconf環境などのアドホックネットワークでは、ピアツーピアマルチキャストプロトコルが適しています。マルチキャストDNS [RFC6762]で実行されるDNS-SDを使用すると、ここで説明するDNS-SDセマンティクスとレコードタイプを維持しながら、構成不要のアドホックサービスディスカバリが提供されます。
In larger networks, a high volume of enterprise-wide IP multicast traffic may not be desirable, so any credible service discovery protocol intended for larger networks has to provide some facility to aggregate registrations and lookups at a central server (or servers) instead of working exclusively using multicast. This requires some service discovery aggregation server software to be written, debugged, deployed, and maintained. This also requires some service discovery registration protocol to be implemented and deployed for clients to register with the central aggregation server. Virtually every company with an IP network already runs a DNS server, and DNS already has a dynamic registration protocol [RFC2136] [RFC3007]. Given that virtually every company already has to operate and maintain a DNS server anyway, it makes sense to take advantage of this expertise instead of also having to learn, operate, and maintain a different service registration server. It should be stressed again that using the same software and protocols doesn't necessarily mean using the same physical piece of hardware. The DNS-SD service discovery functions do not have to be provided by the same piece of hardware that is currently providing the company's DNS name service. The "_tcp.<Domain>" and "_udp.<Domain>" subdomains may be delegated to a different piece of hardware. However, even when the DNS-SD service is being provided by a different piece of hardware, it is still the same familiar DNS server software, with the same configuration file syntax, the same log file format, and so forth.
大規模なネットワークでは、企業全体の大量のIPマルチキャストトラフィックは望ましくない場合があるため、大規模なネットワークを対象とした信頼できるサービス検出プロトコルは、機能する代わりに中央サーバー（複数の場合もある）で登録とルックアップを集約する機能を提供する必要がありますマルチキャストのみを使用します。これには、サービス検出集約サーバーソフトウェアの作成、デバッグ、展開、および保守が必要です。これには、クライアントが中央集約サーバーに登録するために、いくつかのサービス検出登録プロトコルを実装および展開する必要もあります。事実上、IPネットワークを持つすべての企業はDNSサーバーを実行しており、DNSにはすでに動的登録プロトコル[RFC2136] [RFC3007]があります。事実上すべての企業がDNSサーバーを既に運用および保守している必要があることを考えると、別のサービス登録サーバーを学習、運用、および保守する必要がなく、この専門知識を活用することは理にかなっています。同じソフトウェアとプロトコルを使用しても、ハードウェアの同じ物理部分を使用することを必ずしも意味しないことを再度強調する必要があります。 DNS-SDサービス検出機能は、現在会社のDNSネームサービスを提供しているハードウェアと同じハードウェアによって提供される必要はありません。 「_tcp。<ドメイン>」および「_udp。<ドメイン>」サブドメインは、別のハードウェアに委任される場合があります。ただし、DNS-SDサービスが別のハードウェアで提供されている場合でも、構成ファイルの構文やログファイルの形式などが同じで、使い慣れたDNSサーバーソフトウェアと同じです。
Service discovery needs to be able to provide appropriate security. DNS already has existing mechanisms for security [RFC4033].
サービスディスカバリは、適切なセキュリティを提供できる必要があります。 DNSにはすでにセキュリティのための既存のメカニズムがあります[RFC4033]。
In summary:
要約すれば：
Service discovery requires a central aggregation server. DNS already has one: a DNS server.
サービス検出には、中央集約サーバーが必要です。 DNSにはすでにDNSサーバーがあります。
Service discovery requires a service registration protocol. DNS already has one: DNS Dynamic Update.
サービス検出には、サービス登録プロトコルが必要です。 DNSにはすでにDNS動的更新があります。
Service discovery requires a query protocol. DNS already has one: DNS queries.
サービス検出にはクエリプロトコルが必要です。 DNSにはすでにDNSクエリがあります。
Service discovery requires security mechanisms. DNS already has security mechanisms: DNSSEC.
サービスディスカバリにはセキュリティメカニズムが必要です。 DNSにはすでにセキュリティメカニズムがあります：DNSSEC。
Service discovery requires a multicast mode for ad hoc networks. Using DNS-SD in conjunction with Multicast DNS provides this, using peer-to-peer multicast instead of a DNS server.
サービス検出には、アドホックネットワークのマルチキャストモードが必要です。 DNS-SDをマルチキャストDNSと組み合わせて使用すると、DNSサーバーの代わりにピアツーピアマルチキャストを使用してこれを実現できます。
It makes more sense to use the existing software that every network needs already, instead of deploying an entire parallel system just for service discovery.
サービス検出のためだけに並列システム全体を展開するのではなく、すべてのネットワークにすでに必要な既存のソフトウェアを使用する方が理にかなっています。
There have been questions about why services are named using DNS Service Instance Names of the form:
次の形式のDNSサービスインスタンス名を使用してサービスに名前を付ける理由についての質問があります。
Service Instance Name = <Instance> . <Service> . <Domain>
instead of:
の代わりに：
Service Instance Name = <Service> . <Instance> . <Domain>
There are three reasons why it is beneficial to name service instances with the parent domain as the most-significant (rightmost) part of the name, then the abstract service type as the next-most significant, and then the specific instance name as the least-significant (leftmost) part of the name. These reasons are discussed below in Sections B.1, B.2, and B.3.
親ドメインを名前の最も重要な（右端の）部分としてサービスインスタンスに名前を付け、次に抽象サービスタイプを次に重要、次に特定のインスタンス名を最も低くすることが有益である理由は3つあります。 -名前の重要な（左端）部分。これらの理由については、以下のセクションB.1、B.2、およびB.3で説明します。
The facility being provided by browsing ("Service Instance Enumeration") is effectively enumerating the leaves of a tree structure. A given domain offers zero or more services. For each of those service types, there may be zero or more instances of that service.
ブラウジングによって提供される機能（「サービスインスタンス列挙」）は、ツリー構造の葉を効果的に列挙しています。特定のドメインが提供するサービスは0個以上です。これらのサービスタイプごとに、そのサービスのインスタンスが0個以上存在する場合があります。
The user knows what type of service they are seeking. (If they are running an FTP client, they are looking for FTP servers. If they have a document to print, they are looking for entities that speak some known printing protocol.) The user knows in which organizational or geographical domain they wish to search. (The user does not want a single flat list of every single printer on the planet, even if such a thing were possible.) What the user does not know in advance is whether the service they seek is offered in the given domain, or if so, the number of instances that are offered and the names of those instances.
ユーザーは、求めているサービスの種類を知っています。 （FTPクライアントを実行している場合、FTPサーバーを探しています。印刷するドキュメントがある場合、既知の印刷プロトコルを話すエンティティを探しています。）ユーザーは、検索する組織または地理的なドメインを知っています。 。 （ユーザーは、そのようなことが可能であったとしても、地球上のすべての単一プリンターの単一フラットリストを望んでいません。）ユーザーが事前に知らないのは、求めるサービスが特定のドメインで提供されているかどうか、またはしたがって、提供されるインスタンスの数とそれらのインスタンスの名前です。
Hence, having the instance names be the leaves of the tree is consistent with this semantic model.
したがって、インスタンス名をツリーの葉にすることは、このセマンティックモデルと一致します。
Having the service types be the terminal leaves of the tree would imply that the user knows the domain name and the name of the service instance, but doesn't have any idea what the service does. We would argue that this is a less useful model.
サービスタイプをツリーの最終リーフにすることは、ユーザーがドメイン名とサービスインスタンスの名前を知っていることを意味しますが、サービスが何をしているのかはわかりません。これはあまり有用なモデルではないと主張します。
When a DNS response contains multiple answers, name compression works more effectively if all the names contain a common suffix. If many answers in the packet have the same <Service> and <Domain>, then each occurrence of a Service Instance Name can be expressed using only the <Instance> part followed by a two-byte compression pointer referencing a previous appearance of "<Service>.<Domain>". This efficiency would not be possible if the <Service> component appeared first in each name.
DNS応答に複数の回答が含まれている場合、すべての名前に共通のサフィックスが含まれていると、名前の圧縮がより効果的に機能します。パケット内の多くの回答が同じ<Service>と<Domain>を持っている場合、サービスインスタンス名の各出現は、<Instance>部分とその後に続く "<サービス>。<ドメイン>」。 <Service>コンポーネントが各名前の最初にある場合、この効率は不可能です。
This name structure allows subdomains to be delegated along logical service boundaries. For example, the network administrator at Example Co. could choose to delegate the "_tcp.example.com." subdomain to a different machine, so that the machine handling service discovery doesn't have to be the machine that handles other day-to-day DNS operations. (It *can* be the same machine if the administrator so chooses, but the administrator is free to make that choice.) Furthermore, if the network administrator wishes to delegate all information related to IPP printers to a machine dedicated to that specific task, this is easily done by delegating the "_ipp._tcp.example.com." subdomain to the desired machine. It is also convenient to set security policies on a per-zone/per-subdomain basis. For example, the administrator may choose to enable DNS Dynamic Update [RFC2136] [RFC3007] for printers registering in the
この名前構造により、サブドメインを論理サービス境界に沿って委任できます。たとえば、Example Co.のネットワーク管理者は、「_ tcp.example.com」を委任することを選択できます。別のマシンへのサブドメイン。これにより、サービス検出を処理するマシンは、他の日常のDNS操作を処理するマシンである必要はありません。 （管理者が選択した場合は、同じマシンである可能性がありますが、管理者は自由に選択できます。）さらに、ネットワーク管理者がIPPプリンターに関連するすべての情報をその特定のタスク専用のマシンに委任したい場合は、これは、「_ ipp._tcp.example.com」を委任することで簡単に行えます。目的のマシンへのサブドメイン。ゾーンごと、サブドメインごとにセキュリティポリシーを設定すると便利です。たとえば、管理者はDNS動的更新[RFC2136] [RFC3007]を有効にして、
"_ipp._tcp.example.com." subdomain, but not for other zones/subdomains. This easy flexibility would not exist if the <Service> component appeared first in each name.
「_ipp._tcp.example.com」サブドメイン。ただし、他のゾーン/サブドメインは対象外。 <Service>コンポーネントが各名前の最初にある場合、この簡単な柔軟性はありません。
Some service discovery protocols decouple the true service identifier from the name presented to the user. The true service identifier used by the protocol is an opaque unique identifier, often represented using a long string of hexadecimal digits, which should never be seen by the typical user. The name presented to the user is merely one of the decorative ephemeral attributes attached to this opaque identifier.
一部のサービス検出プロトコルは、ユーザーに提示された名前から実際のサービス識別子を切り離します。プロトコルで使用される真のサービス識別子は不透明な一意の識別子であり、多くの場合、16進数の長い文字列を使用して表されます。これは通常のユーザーには表示されません。ユーザーに提示される名前は、この不透明な識別子に添付された装飾的な一時的な属性の1つにすぎません。
The problem with this approach is that it decouples user perception from network reality:
このアプローチの問題は、ユーザーの認識をネットワークの現実から切り離すことです。
* What happens if there are two service instances, with different unique ids, but they have inadvertently been given the same user-visible name? If two instances appear in an on-screen list with the same name, how does the user know which is which?
* 一意のIDが異なる2つのサービスインスタンスがあり、それらに誤って同じユーザーに表示される名前が付けられた場合はどうなりますか？画面上のリストに2つのインスタンスが同じ名前で表示される場合、ユーザーはどのインスタンスがどれであるかをどのようにして知るのですか？
* Suppose a printer breaks down, and the user replaces it with another printer of the same make and model, and configures the new printer with the exact same name as the one being replaced: "Stuart's Printer". Now, when the user tries to print, the on-screen print dialog tells them that their selected default printer is "Stuart's Printer". When they browse the network to see what is there, they see a printer called "Stuart's Printer", yet when the user tries to print, they are told that the printer "Stuart's Printer" can't be found. The hidden internal unique identifier that the software is trying to find on the network doesn't match the hidden internal unique identifier of the new printer, even though its apparent "name" and its logical purpose for being there are the same. To remedy this, the user typically has to delete the print queue they have created, and then create a new (apparently identical) queue for the new printer, so that the new queue will contain the right hidden internal unique identifier. Having all this hidden information that the user can't see makes for a confusing and frustrating user experience, and exposing long, ugly hexadecimal strings to the user and forcing them to understand what they mean is even worse.
* プリンターが故障し、ユーザーが同じメーカーとモデルの別のプリンターに交換し、新しいプリンターを交換するプリンターとまったく同じ名前で構成するとします。「Stuart's Printer」。これで、ユーザーが印刷しようとすると、画面上の印刷ダイアログに、選択したデフォルトのプリンターが「Stuart's Printer」であることが通知されます。そこに何があるかを確認するためにネットワークを閲覧すると、「Stuart's Printer」というプリンターが表示されますが、ユーザーが印刷しようとすると、プリンター「Stuart's Printer」が見つからないことが通知されます。ソフトウェアがネットワーク上で見つけようとしている非表示の内部一意識別子は、新しいプリンタの非表示の内部一意識別子と一致しませんが、その「名前」と存在するための論理的な目的は同じです。これを修正するには、通常、ユーザーが作成した印刷キューを削除してから、新しいプリンターに新しい（明らかに同一の）キューを作成する必要があります。これにより、新しいキューに適切な非表示の内部一意識別子が含まれます。ユーザーが見ることができないこのすべての隠された情報があると、混乱してイライラするユーザーエクスペリエンスが発生し、長くて醜い16進数の文字列がユーザーに公開されて、ユーザーが意味を理解することはさらに悪くなります。
* Suppose an existing printer is moved to a new department, and given a new name and a new function. Changing the user-visible name of that piece of hardware doesn't change its hidden internal unique identifier. Users who had previously created a print queue for that printer will still be accessing the same hardware by its unique identifier, even though the logical service that used to be offered by that hardware has ceased to exist.
*既存のプリンターが新しい部門に移動され、新しい名前と新しい機能が与えられたとします。そのハードウェアのユーザーに表示される名前を変更しても、隠された内部の一意の識別子は変更されません。以前にそのプリンター用の印刷キューを作成したユーザーは、そのハードウェアによって提供されていた論理サービスが存在しなくなっても、その一意の識別子によって同じハードウェアにアクセスします。
Solving these problems requires the user or administrator to be aware of the supposedly hidden unique identifier, and to set its value correctly as hardware is moved around, repurposed, or replaced, thereby contradicting the notion that it is a hidden identifier that human users never need to deal with. Requiring the user to understand this expert behind-the-scenes knowledge of what is *really* going on is just one more burden placed on the user when they are trying to diagnose why their computers and network devices are not working as expected.
これらの問題を解決するには、ユーザーまたは管理者が隠されていると思われる一意の識別子を認識し、ハードウェアの移動、転用、または交換時に値を正しく設定する必要があります。これにより、ユーザーが決して必要としない隠し識別子であるという概念に矛盾します対処する。ユーザーが自分のコンピューターとネットワークデバイスが期待どおりに動作していない理由を診断しようとするとき、「実際に」何が起こっているかについてのこの舞台裏の知識を理解するようユーザーに要求することは、ユーザーに課されるもう1つの負担です。
These anomalies and counterintuitive behaviors can be eliminated by maintaining a tight bidirectional one-to-one mapping between what the user sees on the screen and what is really happening "behind the curtain". If something is configured incorrectly, then that is apparent in the familiar day-to-day user interface that everyone understands, not in some little-known, rarely used "expert" interface.
これらの異常と直感に反する動作は、ユーザーが画面に表示するものと「カーテンの後ろ」で実際に起こっていることの間の厳密な双方向の1対1のマッピングを維持することによって排除できます。何かが正しく構成されていない場合、それは、あまり知られていない、あまり使用されない「エキスパート」インターフェースではなく、誰もが理解しているおなじみの日常のユーザーインターフェースで明らかです。
In summary: in DNS-SD the user-visible name is also the primary identifier for a service. If the user-visible name is changed, then conceptually the service being offered is a different logical service -- even though the hardware offering the service may have stayed the same. If the user-visible name doesn't change, then conceptually the service being offered is the same logical service -- even if the hardware offering the service is new hardware brought in to replace some old equipment.
要約すると、DNS-SDでは、ユーザーに表示される名前もサービスの主要な識別子です。ユーザーに表示される名前が変更された場合、サービスを提供するハードウェアが同じままであったとしても、提供されるサービスは概念的には別の論理サービスになります。ユーザーに表示される名前が変更されない場合、概念的には、提供されているサービスは同じ論理サービスです。サービスを提供するハードウェアが、古い機器を置き換えるために導入された新しいハードウェアであってもです。
There are certainly arguments on both sides of this debate. Nonetheless, the designers of any service discovery protocol have to make a choice between having the primary identifiers be hidden, or having them be visible, and these are the reasons that we chose to make them visible. We're not claiming that there are no disadvantages of having primary identifiers be visible. We considered both alternatives, and we believe that the few disadvantages of visible identifiers are far outweighed by the many problems caused by use of hidden identifiers.
この議論の両側には確かに議論があります。それにもかかわらず、サービス検出プロトコルの設計者は、プライマリ識別子を非表示にするか、表示するかを選択する必要があります。これらが、表示することを選択した理由です。プライマリ識別子が表示されることの欠点がないとは主張していません。私たちは両方の選択肢を検討しましたが、目に見える識別子のいくつかの不利な点は、隠された識別子の使用によって引き起こされる多くの問題をはるかに上回っていると考えています。
When a DNS-SD service is advertised using Multicast DNS [RFC6762], if there is already another service of the same type advertising with the same name then automatic name conflict resolution will occur. As described in the Multicast DNS specification [RFC6762], upon detecting a conflict, the service should:
マルチキャストDNS [RFC6762]を使用してDNS-SDサービスをアドバタイズする場合、同じ名前でアドバタイズする同じタイプの別のサービスがすでに存在すると、名前の自動競合解決が行われます。マルチキャストDNS仕様[RFC6762]で説明されているように、競合を検出すると、サービスは次のようになります。
1. Automatically select a new name (typically by appending or incrementing a digit at the end of the name), 2. Try advertising with the new name, and 3. Upon success, record the new name in persistent storage.
1. 新しい名前を自動的に選択します（通常、名前の末尾に数字を追加または増分します）。2。新しい名前で広告を試みます。3。成功したら、新しい名前を永続ストレージに記録します。
This renaming behavior is very important, because it is key to providing user-friendly instance names in the out-of-the-box factory-default configuration. Some product developers apparently have not realized this, because there are some products today where the factory-default name is distinctly unfriendly, containing random-looking strings of characters, such as the device's Ethernet address in hexadecimal. This is unnecessary and undesirable, because the point of the user-visible name is that it should be friendly and meaningful to human users. If the name is not unique on the local network then the protocol will remedy this as necessary. It is ironic that many of the devices with this design mistake are network printers, given that these same printers also simultaneously support AppleTalk-over-Ethernet, with nice user-friendly default names (and automatic conflict detection and renaming). Some examples of good factory-default names are:
この名前変更動作は、すぐに使用できる工場出荷時のデフォルト構成でユーザーフレンドリーなインスタンス名を提供するための鍵であるため、非常に重要です。一部の製品開発者は明らかにこれに気付いていません。工場出荷時のデフォルト名が明らかに不親切で、ランダムに見える文字列（16進数のデバイスのイーサネットアドレスなど）が含まれている製品があるためです。ユーザーに表示される名前のポイントは、人間のユーザーにとって親しみやすく、意味のあるものである必要があるためです。名前がローカルネットワーク上で一意でない場合、プロトコルは必要に応じてこれを修正します。皮肉なことに、これらの同じプリンターは、AppleTalk-over-Ethernetも同時にサポートし、使いやすいデフォルト名（および自動競合検出と名前変更）を備えているため、この設計ミスのあるデバイスの多くはネットワークプリンターです。適切な工場出荷時のデフォルト名の例は次のとおりです。
Brother 5070N Canon W2200 HP LaserJet 4600 Lexmark W840 Okidata C5300 Ricoh Aficio CL7100 Xerox Phaser 6200DX
Brother 5070N Canon W2200 HP LaserJet 4600 Lexmark W840 Okidata C5300 Ricoh Aficio CL7100 Xerox Phaser 6200DX
To make the case for why adding long, ugly factory-unique serial numbers to the end of names is neither necessary nor desirable, consider the cases where the user has (a) only one network printer, (b) two network printers, and (c) many network printers.
名前の末尾に長くて醜い工場固有のシリアル番号を追加する必要がない、または望ましくない理由を説明するために、ユーザーが（a）ネットワークプリンターを1つだけ、（b）ネットワークプリンターを2つ、および（ c）多くのネットワークプリンター。
(a) In the case where the user has only one network printer, a simple name like (to use a vendor-neutral example) "Printer" is more user-friendly than an ugly name like "Printer_0001E68C74FB". Appending ugly hexadecimal goop to the end of the name to make sure the name is unique is irrelevant to a user who only has one printer anyway.
（a）ユーザーがネットワークプリンターを1つだけ持っている場合、（ベンダーに依存しない例を使用する場合） "Printer"のような単純な名前は、 "Printer_0001E68C74FB"のような醜い名前よりもユーザーフレンドリーです。名前が一意であることを確認するために名前の最後に醜い16進数のgoopを追加することは、いずれにせよ1台のプリンターしか持たないユーザーには関係ありません。
(b) In the case where the user gets a second network printer, having the new printer detect that the name "Printer" is already in use and automatically name itself "Printer (2)" instead, provides a good user experience. For most users, remembering that the old printer is "Printer" and the new one is "Printer (2)" is easy and intuitive. Seeing a printer called "Printer_0001E68C74FB" and another called "Printer_00306EC3FD1C" is a lot less helpful.
（b）ユーザーが2番目のネットワークプリンターを取得した場合、新しいプリンターに「Printer」という名前がすでに使用されていることを検出させ、代わりに自動的に「Printer（2）」という名前を付けると、優れたユーザーエクスペリエンスが提供されます。ほとんどのユーザーにとって、古いプリンターは「プリンター」であり、新しいプリンターは「プリンター（2）」であることを覚えておくのは簡単で直感的です。 「Printer_0001E68C74FB」と呼ばれるプリンタと「Printer_00306EC3FD1C」と呼ばれる別のプリンタを見ると、それほど役に立ちません。
(c) In the case of a network with ten network printers, seeing a list of ten names all of the form "Printer_xxxxxxxxxxxx" has effectively taken what was supposed to be a list of user-friendly rich-text names (supporting mixed case, spaces, punctuation, non-Roman characters, and other symbols) and turned it into just about the worst user interface imaginable: a list of incomprehensible random-looking strings of letters and digits. In a network with a lot of printers, it would be advisable for the people setting up the printers to take a moment to give each one a descriptive name, but in the event they don't, presenting the users with a list of sequentially numbered printers is a much more desirable default user experience than showing a list of raw Ethernet addresses.
（c）ネットワークプリンタが10台あるネットワークの場合、すべての形式が「Printer_xxxxxxxxxxxx」の10個の名前のリストを表示すると、ユーザーフレンドリなリッチテキスト名のリスト（大/小文字混合をサポート）スペース、句読点、ローマ字以外の文字、およびその他の記号）を使用して、考えられる限りで最悪のユーザーインターフェイス（文字と数字のわかりにくいランダムな文字列のリスト）に変換しました。多数のプリンターがあるネットワークでは、プリンターを設定する人がそれぞれに説明的な名前を付けるのに少し時間がかかることをお勧めしますが、そうしない場合は、ユーザーに連続番号のリストを提示しますプリンターは、生のイーサネットアドレスのリストを表示するよりもはるかに望ましいデフォルトのユーザーエクスペリエンスです。
Although the original DNS specifications [RFC1033] [RFC1034] [RFC1035] recommend that host names contain only letters, digits, and hyphens (because of the limitations of the typing-based user interfaces of that era), Service Instance Names are not host names. Users generally access a service by selecting it from a list presented by a user interface, not by typing in its Service Instance Name. "Clarifications to the DNS Specification" [RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that the traditional letters-digits-hyphens rule applies only to conventional host names:
元のDNS仕様[RFC1033] [RFC1034] [RFC1035]では、ホスト名には文字、数字、ハイフンのみを含めることを推奨していますが（その時代のタイピングベースのユーザーインターフェイスの制限のため）、サービスインスタンス名はホスト名ではありません。ユーザーは通常、サービスインスタンス名を入力するのではなく、ユーザーインターフェイスが表示するリストからサービスを選択してアクセスします。 「DNS仕様の明確化」[RFC2181]は、セクション11（「名前の構文」）で許容される文字セットの主題を直接説明しており、従来の文字、数字、ハイフンの規則は従来のホスト名にのみ適用されると明示的に述べています。
Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose.
ドメインネームシステムは、インターネットホスト名をデータにマッピングし、インターネットアドレスをホスト名にマッピングする目的でのみ機能すると想定される場合があります。これは不正解です。DNSは一般的な（多少制限がある場合）階層型データベースであり、ほとんどすべての目的で、ほとんどすべての種類のデータを格納できます。
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.
DNS自体は、リソースレコードの識別に使用できる特定のラベルに1つの制限のみを課します。その1つの制限は、ラベルの長さとフルネームに関連しています。 1つのラベルの長さは1〜63オクテットに制限されています。完全なドメイン名は255オクテット（区切り文字を含む）に制限されています。長さ0のフルネームは、DNSツリーのルートを表すものとして定義され、通常は「。」として記述および表示されます。これらの制限はさておき、リソースレコードのラベルとして使用できるバイナリ文字列。同様に、任意のバイナリ文字列は、その値の一部またはすべて（SOA、NS、MX、PTR、CNAME、および追加される可能性のあるその他すべて）としてドメイン名を含む任意のレコードの値として機能できます。 DNSプロトコルの実装では、使用できるラベルに制限を課してはなりません。特に、DNSサーバーには、一部のDNSクライアントプログラムでは受け入れられないラベルが含まれているため、ゾーンの提供を拒否してはなりません。
Note that just because DNS-based Service Discovery supports arbitrary UTF-8-encoded names doesn't mean that any particular user or administrator is obliged to make use of that capability. Any user is free, if they wish, to continue naming their services using only letters, digits, and hyphens, with no spaces, capital letters, or other punctuation.
DNSベースのサービスディスカバリが任意のUTF-8でエンコードされた名前をサポートしているからといって、特定のユーザーまたは管理者がその機能を利用する義務があるわけではないことに注意してください。ユーザーは、必要に応じて、スペース、大文字、その他の句読点なしで、文字、数字、ハイフンのみを使用してサービスに名前を付けることができます。
Appendix F. "Continuous Live Update" Browsing Model
付録F.「継続的なライブ更新」ブラウジングモデル
Of particular concern in the design of DNS-SD, especially when used in conjunction with ad hoc Multicast DNS, is the dynamic nature of service discovery in a changing network environment. Other service discovery protocols seem to have been designed with an implicit unstated assumption that the usage model is:
DNS-SDの設計で特に懸念されるのは、特にアドホックマルチキャストDNSと組み合わせて使用する場合、変化するネットワーク環境でのサービス検出の動的な性質です。他のサービス検出プロトコルは、使用モデルが次のとおりであるという暗黙の明言されていない仮定で設計されているようです：
(a) client software calls the service discovery API, (b) service discovery code spends a few seconds getting a list of instances available at a particular moment in time, and then (c) client software displays the list for the user to select from.
（a）クライアントソフトウェアがサービスディスカバリAPIを呼び出す、（b）サービスディスカバリコードが数秒かけて特定の瞬間に利用可能なインスタンスのリストを取得し、（c）クライアントソフトウェアがユーザーが選択できるリストを表示する。
Superficially this usage model seems reasonable, but the problem is that it's too optimistic. It only considers the success case, where the software immediately finds the service instance the user is looking for.
表面的にはこの使用モデルは合理的であるように見えますが、問題は楽観的すぎることです。ソフトウェアがユーザーが探しているサービスインスタンスをすぐに見つける成功ケースのみを考慮します。
In the case where the user is looking for (say) a particular printer, and that printer is not turned on or not connected, the user first has to attempt to remedy the problem, and then has to click a "refresh" button to retry the service discovery to find out whether they were successful. Because nothing happens instantaneously in networking, and packets can be lost, necessitating some number of retransmissions, a service discovery search is not instantaneous and typically takes a few seconds. As a result, a fairly typical user experience is:
ユーザーが（たとえば）特定のプリンターを探していて、そのプリンターの電源が入っていない、または接続されていない場合、ユーザーはまず問題を解決する必要があり、次に「更新」ボタンをクリックして再試行する必要があります。それらが成功したかどうかを調べるためのサービス検出。ネットワーキングでは瞬時に何も起こらず、パケットが失われる可能性があり、いくつかの再送信が必要になるため、サービスディスカバリ検索は瞬時ではなく、通常は数秒かかります。その結果、かなり一般的なユーザーエクスペリエンスは次のようになります。
(a) display an empty window, (b) display some animation like a searchlight sweeping back and forth for ten seconds, and then (c) at the end of the ten-second search, display a static list showing what was discovered.
（a）空のウィンドウを表示する、（b）サーチライトが10秒間往復するようなアニメーションを表示する、そして（c）10秒間の検索の最後に、発見されたものを示す静的リストを表示する。
Every time the user clicks the "refresh" button they have to endure another ten-second wait, and every time the discovered list is finally shown at the end of the ten-second wait, it's already beginning to get stale and out-of-date the moment it's displayed on the screen.
ユーザーが「更新」ボタンをクリックするたびに、さらに10秒間待機する必要があり、検出されたリストが10秒間の待機の最後に最終的に表示されるたびに、リストはすでに古くなっており、画面に表示された日付。
The service discovery user experience that the DNS-SD designers had in mind has some rather different properties:
DNS-SD設計者が念頭に置いていたサービス検出のユーザーエクスペリエンスには、かなり異なるプロパティがいくつかあります。
1. Displaying the initial list of discovered services should be effectively instantaneous -- i.e., typically 0.1 seconds, not 10 seconds.
1. 検出されたサービスの初期リストの表示は、事実上瞬時である必要があります。つまり、通常は10秒ではなく0.1秒です。
2. The list of discovered services should not be getting stale and out-of-date from the moment it's displayed. The list should be 'live' and should continue to update as new services are discovered. Because of the delays, packet losses, and retransmissions inherent in networking, it is to be expected that sometimes, after the initial list is displayed showing the majority of discovered services, a few remaining stragglers may continue to trickle in during the subsequent few seconds. Even after this stable list has been built and displayed, it should remain 'live' and should continue to update. At any future time, be it minutes, hours, or even days later, if a new service of the desired type is discovered, it should be displayed in the list automatically, without the user having to click a "refresh" button or take any other explicit action to update the display.
2. 検出されたサービスのリストは、表示された瞬間から古くなって古くなってはいけません。リストは「ライブ」である必要があり、新しいサービスが発見されても更新を続ける必要があります。ネットワーキングに固有の遅延、パケット損失、および再送信のために、発見されたサービスの大部分を示す最初のリストが表示された後、残りのいくつかのストラグラーがその後の数秒間トリックルし続けることが予想されます。この安定したリストが作成および表示された後でも、「ライブ」のままであり、更新を続ける必要があります。数分後、数時間後、または数日後のいずれかの時点で、目的のタイプの新しいサービスが検出された場合、ユーザーが「更新」ボタンをクリックしたり、何も実行したりすることなく、自動的にリストに表示されます。表示を更新するその他の明示的なアクション。
3. With users getting in the habit of leaving service discovery windows open, and expecting them to show a continuous 'live' view of current network reality, this gives us an additional requirement: deletion of stale services. When a service discovery list shows just a static snapshot at a moment in time, then the situation is simple: either a service was discovered and appears in the list, or it was not and does not. However, when our list is live and updates continuously with the discovery of new services, then this implies the corollary: when a service goes away, it needs to *disappear* from the service discovery list. Otherwise, the service discovery list would simply grow monotonically over time, accreting stale data, and would require a periodic "refresh" (or complete dismissal and recreation) to restore correct display.
3. ユーザーがサービスディスカバリウィンドウを開いたままにし、現在のネットワーク現実の継続的な「ライブ」ビューを表示することを期待する習慣を身に付けると、これにより、古いサービスの削除という追加の要件が得られます。サービス検出リストに現時点で静的なスナップショットのみが表示されている場合、状況は単純です。サービスが検出されてリストに表示されるか、検出されずに表示されません。ただし、リストがライブであり、新しいサービスの発見に伴って継続的に更新される場合、これは当然のことを意味します。サービスがなくなると、サービス発見リストから*消える*必要があります。そうしないと、サービス検出リストは時間の経過とともに単調に増加し、古いデータが増え、正しい表示に戻すには定期的な「更新」（または完全な破棄と再作成）が必要になります。
4. Another consequence of users leaving service discovery windows open for extended periods of time is that these windows should update not only in response to services coming and going, but also in response to changes in configuration and connectivity of the client machine itself. For example, if a user opens a service discovery window when the client machine has no network connectivity, then the window will typically appear empty, with no discovered services. When the user connects an Ethernet cable or joins an 802.11 [IEEEW] wireless network the window should then automatically populate with discovered services, without requiring any explicit user action. If the user disconnects the Ethernet cable or turns off 802.11 wireless then all the services discovered via that network interface should automatically disappear. If the user switches from one 802.11 wireless access point to another, the service discovery window should automatically update to remove all the services discovered via the old wireless access point, and add all the services discovered via the new one.
4. ユーザーがサービスディスカバリウィンドウを長時間開いたままにしておくと、これらのウィンドウは、サービスの送受信だけでなく、クライアントマシン自体の構成や接続の変更にも応答して更新される必要があります。たとえば、クライアントマシンにネットワーク接続がないときにユーザーがサービスディスカバリウィンドウを開くと、ウィンドウは通常、空で表示され、サービスは検出されません。ユーザーがイーサネットケーブルを接続するか、802.11 [IEEEW]ワイヤレスネットワークに参加すると、明示的なユーザーアクションを必要とせずに、ウィンドウに検出されたサービスが自動的に読み込まれます。ユーザーがイーサネットケーブルを切断するか、802.11ワイヤレスをオフにすると、そのネットワークインターフェイスを介して検出されたすべてのサービスが自動的に表示されなくなります。ユーザーが1つの802.11ワイヤレスアクセスポイントから別のワイヤレスアクセスポイントに切り替えると、サービス検出ウィンドウが自動的に更新され、古いワイヤレスアクセスポイントを介して検出されたすべてのサービスが削除され、新しいワイヤレスアクセスポイントを介して検出されたすべてのサービスが追加されます。
Appendix G. Deployment History
付録G.展開履歴
In July 1997, in an email to the net-thinkers@thumper.vmeng.com mailing list, Stuart Cheshire first proposed the idea of running the AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of this and related IETF discussions, the IETF Zeroconf working group was chartered September 1999. After various working group discussions and other informal IETF discussions, several Internet-Drafts were written that were loosely related to the general themes of DNS and multicast, but did not address the service discovery aspect of NBP.
1997年7月、net-thinkers @ thumper.vmeng.comメーリングリストへの電子メールで、Stuart Cheshireは最初にIPを介してAppleTalk Name Binding Protocol [RFC6760]を実行するというアイデアを提案しました。これと関連するIETFディスカッションの結果、IETF Zeroconfワーキンググループは1999年9月にチャーターされました。さまざまなワーキンググループディスカッションと他の非公式のIETFディスカッションの後、DNSとマルチキャストの一般的なテーマに緩やかに関連するいくつかのインターネットドラフトが書かれました。しかし、NBPのサービス検出の側面については触れていません。
In April 2000, Stuart Cheshire registered IPv4 multicast address 224.0.0.251 with IANA and began writing code to test and develop the idea of performing NBP-like service discovery using Multicast DNS, which was documented in a group of three Internet-Drafts:
2000年4月、スチュアートチェシャーはIPv4マルチキャストアドレス224.0.0.251をIANAに登録し、マルチキャストDNSを使用してNBPのようなサービスディスカバリを実行するアイデアをテストおよび開発するコードの作成を開始しました。これは、3つのインターネットドラフトのグループで文書化されています。
o "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk Name Binding Protocol, because many in the IETF community had little first-hand experience using AppleTalk, and confusion in the IETF community about what AppleTalk NBP did was causing confusion about what would be required in an IP-based replacement.
o 「AppleTalkネームバインディングプロトコル（NBP）を置き換えるプロトコルの要件」[RFC6760]は、AppleTalkネームバインディングプロトコルを説明する概要です。これは、IETFコミュニティの多くはAppleTalkを使用した直接の経験がほとんどなく、IETFコミュニティで混乱しているためです。 AppleTalk NBPが何をしたかについて、IPベースの交換に何が必要かについて混乱が生じていました。
o "Discovering Named Instances of Abstract Services using DNS" [NIAS], which later became this document, proposed a way to perform NBP-like service discovery using DNS-compatible names and record types.
o 「DNSを使用した抽象サービスの名前付きインスタンスの検出」[NIAS]は、後でこのドキュメントになり、DNS互換の名前とレコードタイプを使用してNBPのようなサービス検出を実行する方法を提案しました。
o "Multicast DNS" [RFC6762] specifies a way to transport those DNS-compatible queries and responses using IP multicast, for zero-configuration environments where no conventional Unicast DNS server was available.
o 「マルチキャストDNS」[RFC6762]は、従来のユニキャストDNSサーバーが利用できなかったゼロ構成環境で、IPマルチキャストを使用してそれらのDNS互換のクエリと応答を転送する方法を指定します。
In 2001, an update to Mac OS 9 added resolver library support for host name lookup using Multicast DNS. If the user typed a name such as "MyPrinter.local." into any piece of networking software that used the standard Mac OS 9 name lookup APIs, then those name lookup APIs would recognize the name as a dot-local name and query for it by sending simple one-shot Multicast DNS queries to 224.0.0.251:5353. This enabled the user to, for example, enter the name "MyPrinter.local." into their web browser in order to view a printer's status and configuration web page, or enter the name "MyPrinter.local." into the printer setup utility to create a print queue for printing documents on that printer.
2001年、Mac OS 9へのアップデートにより、マルチキャストDNSを使用したホスト名ルックアップのリゾルバーライブラリサポートが追加されました。ユーザーが「MyPrinter.local」などの名前を入力した場合標準のMac OS 9の名前検索APIを使用するネットワークソフトウェアに挿入すると、これらの名前検索APIは名前をドットローカル名として認識し、単純なワンショットマルチキャストDNSクエリを224.0.0.251に送信することでクエリします5353。これにより、ユーザーは、たとえば「MyPrinter.local」という名前を入力できます。プリンタのステータスと設定のWebページを表示するためにWebブラウザに入力するか、「MyPrinter.local」という名前を入力します。プリンタセットアップユーティリティを使用して、そのプリンタでドキュメントを印刷するための印刷キューを作成します。
Multicast DNS responder software, with full service discovery, first began shipping to end users in volume with the launch of Mac OS X 10.2 "Jaguar" in August 2002, and network printer makers (who had historically supported AppleTalk in their network printers and were receptive to IP-based technologies that could offer them similar ease-of-use) started adopting Multicast DNS shortly thereafter.
マルチキャストDNSレスポンダーソフトウェアは、完全なサービスディスカバリを備え、2002年8月にMac OS X 10.2 "Jaguar"を発表し、ネットワークプリンターメーカー（これまでネットワークプリンターでAppleTalkをサポートし、受け入れていた）によって、最初に大量にエンドユーザーに出荷されました。同様の使いやすさを提供できるIPベースのテクノロジーへの変更）は、その後まもなくマルチキャストDNSの採用を開始しました。
In September 2002, Apple released the source code for the mDNSResponder daemon as Open Source under Apple's standard Apple Public Source License (APSL).
2002年9月、アップルはmDNSResponderデーモンのソースコードを、アップルの標準アップルパブリックソースライセンス（APSL）に基づくオープンソースとしてリリースしました。
Multicast DNS responder software became available for Microsoft Windows users in June 2004 with the launch of Apple's "Rendezvous for Windows" (now "Bonjour for Windows"), both in executable form (a downloadable installer for end users) and as Open Source (one of the supported platforms within Apple's body of cross-platform code in the publicly accessible mDNSResponder CVS source code repository) [BJ].
マルチキャストDNSレスポンダソフトウェアは、実行可能形式（エンドユーザー向けのダウンロード可能なインストーラ）とオープンソース（1つ公にアクセス可能なmDNSResponder CVSソースコードリポジトリのアップルのクロスプラットフォームコードの本体内でサポートされているプラットフォームの一部）[BJ]。
In August 2006, Apple re-licensed the cross-platform mDNSResponder source code under the Apache License, Version 2.0.
2006年8月、アップルはクロスプラットフォームのmDNSResponderソースコードをApacheライセンスバージョン2.0に基づいて再ライセンスしました。
In addition to desktop and laptop computers running Mac OS X and Microsoft Windows, Multicast DNS is now implemented in a wide range of hardware devices, such as Apple's "AirPort" wireless base stations, iPhone and iPad, and in home gateways from other vendors, network printers, network cameras, TiVo DVRs, etc.
Mac OS XおよびMicrosoft Windowsを実行しているデスクトップおよびラップトップコンピュータに加えて、マルチキャストDNSはAppleの「AirPort」ワイヤレスベースステーション、iPhoneおよびiPadなどの幅広いハードウェアデバイス、および他のベンダーのホームゲートウェイに実装されています。ネットワークプリンター、ネットワークカメラ、TiVo DVRなど
The Open Source community has produced many independent implementations of Multicast DNS, some in C like Apple's mDNSResponder daemon, and others in a variety of different languages including Java, Python, Perl, and C#/Mono.
オープンソースコミュニティは、AppleのmDNSResponderデーモンのようにCにあるものや、Java、Python、Perl、C＃/ Monoを含むさまざまな異なる言語のマルチキャストDNSの多くの独立した実装を生み出しています。
In January 2007, the IETF published the Informational RFC "Link-Local Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially similar to Multicast DNS, but incompatible in some small but important ways. In particular, the LLMNR design explicitly excluded support for service discovery, which made it an unsuitable candidate for a protocol to replace AppleTalk NBP [RFC6760].
2007年1月、IETFは情報RFC「リンクローカルマルチキャスト名前解決（LLMNR）」[RFC4795]を公開しました。これは、マルチキャストDNSと実質的に類似していますが、いくつかの小さな重要な点で互換性がありません。特に、LLMNR設計はサービス検出のサポートを明示的に除外したため、AppleTalk NBP [RFC6760]を置き換えるプロトコルの候補としては不適切でした。
While the original focus of Multicast DNS and DNS-Based Service Discovery was for zero-configuration environments without a conventional Unicast DNS server, DNS-Based Service Discovery also works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over Unicast DNS [RFC6281].
マルチキャストDNSとDNSベースのサービスディスカバリの本来の焦点は、従来のユニキャストDNSサーバーのないゼロ構成環境でしたが、DNSベースのサービスディスカバリは、ユニキャストDNSサーバーを使用して機能し、DNSアップデート[RFC2136] [RFC3007]を使用してサービスを作成しますそれらを照会するための検出レコードと標準DNSクエリ。 AppleのBack to My Macサービスは、2007年10月にMac OS X 10.5 "Leopard"でリリースされ、ユニキャストDNS [RFC6281]を介したDNSベースのサービス検出を使用しています。
In June 2012, Google's Android operating system added native support for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
2012年6月、GoogleのAndroidオペレーティングシステムは、Android 4.1「Jelly Bean」（APIレベル16）[NSD]のandroid.net.nsd.NsdManagerクラスでDNS-SDおよびマルチキャストDNSのネイティブサポートを追加しました。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 4368
EMail: marc@apple.com