[要約] RFC 3958は、SRV RRsとDDDSを使用したドメインベースのアプリケーションサービスの場所特定に関するものであり、その目的は、ドメイン内のアプリケーションサービスの場所を動的に見つけるための仕組みを提供することです。
Network Working Group L. Daigle
Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
SRV RR と動的委任検出サービス (DDDS) を使用したドメインベースのアプリケーション サービスの場所
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
このメモは、厳格なドメイン命名規則 (いわゆるネームハック) に依存せずにサービスの場所を指定できる、アプリケーション サービス命名のための一般化されたメカニズムを定義します。この提案では、ドメイン名、アプリケーション サービス名、およびアプリケーション プロトコルをターゲット サーバーとポートに動的にマッピングするための Dynamic Delegation Discovery System (DDDS) アプリケーションを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application to map domain name, application service name, and application protocol dynamically to target server and port.
このメモは、厳格なドメイン命名規則 (いわゆるネームハック) に依存せずにサービスの場所を指定できる、アプリケーション サービス命名のための一般化されたメカニズムを定義します。この提案では、ドメイン名、アプリケーション サービス名、およびアプリケーション プロトコルをターゲット サーバーとポートに動的にマッピングするための Dynamic Delegation Discovery System (DDDS -- [4] を参照) アプリケーションを定義しています。
As discussed in section 5, existing approaches to using DNS records for dynamically determining the current host for a given application service are limited in terms of the use cases supported. To address some of the limitations, this document defines a DDDS Application to map service+protocol+domain to specific server addresses by using both NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as a more general version of the use of SRV and/or a very restricted application of the use of NAPTR resource records.
セクション 5 で説明したように、特定のアプリケーション サービスの現在のホストを動的に決定するために DNS レコードを使用する既存のアプローチは、サポートされるユース ケースの点で制限されています。いくつかの制限に対処するために、この文書では、NAPTR [5] と SRV ([3]) の両方の DNS リソース レコードを使用して、サービス プロトコル ドメインを特定のサーバー アドレスにマップする DDDS アプリケーションを定義します。これは、SRV の使用のより一般的なバージョン、および/または NAPTR リソース レコードの使用の非常に限定されたアプリケーションとして見ることができます。
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 BCP 14, RFC 2119 [1].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [1] に記載されているように解釈されます。
The precise details of the specification of this DDDS application are given in Section 6. This section defines the usage of the DDDS application.
この DDDS アプリケーションの仕様の正確な詳細は、セクション 6 に記載されています。このセクションでは、DDDS アプリケーションの使用法を定義します。
"Application service" is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag. For example, retrieving mail is a type of application service that can be implemented by different application-layer protocols (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered for it. (Note that this has not been done, and there are no plans to do so at the time of this writing.)
「アプリケーション サービス」とは、提供するために使用されるプロトコルに依存しない、ある種のアプリケーションの総称です。各アプリケーション サービスは、IANA 登録タグに関連付けられます。たとえば、メールの取得は、さまざまなアプリケーション層プロトコル (POP3、IMAP4 など) によって実装できるアプリケーション サービスの一種です。「RetMail」などのタグを登録できます。(これはまだ行われておらず、この記事の執筆時点でも行う予定はないことに注意してください。)
An "application protocol" is used to implement the application service. These are also associated with IANA-registered tags. Using the mail example above, "POP3" and "IMAP4" could be registered as application protocol tags. If multiple transports are available for the application, separate tags should be defined for each transport.
アプリケーションサービスの実装には「アプリケーションプロトコル」が使用されます。これらは IANA 登録タグにも関連付けられています。上記のメールの例を使用すると、アプリケーション プロトコル タグとして「POP3」と「IMAP4」を登録できます。アプリケーションで複数のトランスポートを使用できる場合は、トランスポートごとに個別のタグを定義する必要があります。
The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "RetMail:POP3" would be sufficient for a client to identify a server with which it can communicate.
その目的は、アプリケーション サービス タグとプロトコル タグの組み合わせが、既知のペア (たとえば、「RetMail:POP3」) を見つけるだけで、クライアントが通信できるサーバーを識別するのに十分なほど具体的である必要があることです。
Some protocols support multiple application services. For example, LDAP is an application protocol and can be found supporting various services (e.g., "whitepages", "directory enabled networking".
一部のプロトコルは複数のアプリケーション サービスをサポートします。たとえば、LDAP はアプリケーション プロトコルであり、さまざまなサービス (「ホワイトページ」、「ディレクトリ対応ネットワーキング」など) をサポートしていることがわかります。
As defined in section 6, NAPTR records are used to store application service+protocol information for a given domain. Following the DDDS standard, these records are looked up, and the rewrite rules (contained in the NAPTR records) are used to determine the successive DNS lookups until a desirable target is found.
セクション 6 で定義されているように、NAPTR レコードは、特定のドメインのアプリケーション サービス プロトコル情報を保存するために使用されます。DDDS 標準に従って、これらのレコードが検索され、(NAPTR レコードに含まれる) 書き換えルールを使用して、目的のターゲットが見つかるまで連続する DNS ルックアップが決定されます。
For the rest of this section, refer to the set of NAPTR resource records for example.com, shown in the figure below, where "WP" is the imagined application service tag for "white pages" and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
このセクションの残りの部分については、次の図に示す example.com の NAPTR リソース レコードのセットを参照してください。ここで、「WP」は「ホワイト ページ」の想像上のアプリケーション サービス タグであり、「EM」はアプリケーション サービス タグです。想像上の「Extensible Messaging」アプリケーション サービス。
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
A client retrieves all the NAPTR records associated with the target domain name (example.com, above). These are to be sorted in terms of increasing ORDER and increasing PREF within each ORDER.
クライアントは、ターゲット ドメイン名 (上記の example.com) に関連付けられたすべての NAPTR レコードを取得します。これらは、ORDER の増加と各 ORDER 内の PREF の増加という観点からソートされます。
Starting with the first sorted NAPTR record, the client examines the SERVICE field to find a match. In the case of the S-NAPTR DDDS application, this means a SERVICE field that includes the tags for the desired application service and a supported application protocol.
最初にソートされた NAPTR レコードから始めて、クライアントは SERVICE フィールドを調べて一致するものを見つけます。S-NAPTR DDDS アプリケーションの場合、これは、目的のアプリケーション サービスとサポートされているアプリケーション プロトコルのタグを含む SERVICE フィールドを意味します。
If more than one NAPTR record matches, they are processed in increasing sort order.
複数の NAPTR レコードが一致する場合、それらは昇順で処理されます。
A NAPTR record with an empty FLAG field is "non-terminal" -- that is, more NAPTR RR lookups are to be performed. Thus, to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is used as the target of the next DNS lookup -- for NAPTR RRs.
FLAG フィールドが空の NAPTR レコードは「非終端」です。つまり、さらに多くの NAPTR RR ルックアップが実行されます。したがって、S-NAPTR で空の FLAG フィールドを持つ NAPTR レコードを処理するには、NAPTR RR の次の DNS ルックアップのターゲットとして REPLACEMENT フィールドが使用されます。
In S-NAPTR, the only terminal flags are "S" and "A". These are called "terminal" NAPTR lookups because they denote the end of the DDDS/NAPTR processing rules. In the case of an "S" flag, the REPLACEMENT field is used as the target of a DNS query for SRV RRs, and normal SRV processing is applied. In the case of an "A" flag, an address record is sought for the REPLACEMENT field target (and the default protocol port is assumed).
S-NAPTR では、終端フラグは「S」と「A」のみです。これらは、DDDS/NAPTR 処理ルールの終わりを示すため、「ターミナル」NAPTR ルックアップと呼ばれます。「S」フラグの場合、REPLACEMENT フィールドは SRV RR の DNS クエリのターゲットとして使用され、通常の SRV 処理が適用されます。「A」フラグの場合、REPLACEMENT フィールドのターゲットのアドレス レコードが検索されます (デフォルトのプロトコル ポートが想定されます)。
As shown in the example set above, it is possible to have multiple possible targets for a single application service+protocol pair. These are to be pursued in order until a server is successfully contacted or all possible matching NAPTR records have been successively pursued through terminal lookup and server contact. That is, a client must backtrack and attempt other resolution paths in the case of failure.
上記の例で示したように、単一のアプリケーション サービス プロトコル ペアに対して複数のターゲットを設定することが可能です。これらは、サーバーへの接続に成功するか、端末検索とサーバー接続を通じて一致する可能性のあるすべての NAPTR レコードが連続して追跡されるまで、順番に追跡されます。つまり、失敗した場合、クライアントは後戻りして他の解決パスを試行する必要があります。
"Failure" is declared, and backtracking must be used, when
「失敗」が宣言され、バックトラッキングを使用する必要がある場合、
o the designated remote server (host and port) fails to provide appropriate security credentials for the *originating* domain;
o 指定されたリモート サーバー (ホストとポート) が、*元の* ドメインに適切なセキュリティ資格情報を提供できません。
o connection to the designated remote server otherwise fails -- the specifics terms of which are defined when an application protocol is registered; or
o それ以外の場合は、指定されたリモート サーバーへの接続は失敗します。その詳細な条件は、アプリケーション プロトコルの登録時に定義されます。または
o the S-NAPTR-designated DNS lookup fails to yield expected results -- e.g., no A RR for an "A" target, no SRV record for an "S" target, or no NAPTR record with appropriate application service and protocol for a NAPTR lookup. Except in the case of the very first NAPTR lookup, this last is a configuration error: the fact that example.com has a NAPTR record pointing to "bunyip.example" for the "WP:Whois++" service and protocol means the administrator of example.com believes that service exists. If bunyip.example has no "WP:Whois++" NAPTR record, the application client MUST backtrack and try the next available "WP:Whois++" option from example.com. As there is none, the whole resolution fails.
o S-NAPTR 指定の DNS ルックアップが予期した結果を生成しません。たとえば、「A」ターゲットの A RR がない、「S」ターゲットの SRV レコードがない、NAPTR に適切なアプリケーション サービスとプロトコルを含む NAPTR レコードがないなどです。見上げる。最初の NAPTR ルックアップの場合を除いて、これは構成エラーです。example.com に「WP:Whois」サービスおよびプロトコルの「bunyip.example」を指す NAPTR レコードがあるという事実は、example の管理者を意味します。.com はサービスが存在すると信じています。bunyip.example に "WP:Whois " NAPTR レコードがない場合、アプリケーション クライアントはバックトラックして、example.com から次に利用可能な "WP:Whois " オプションを試行しなければなりません (MUST)。何もないため、解決全体が失敗します。
An application client first queries for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
アプリケーション クライアントは、最初に、名前付きアプリケーション サービスのドメインの NAPTR RR をクエリします。最初の DNS クエリは、元のターゲット ドメイン (上記の example.com) 内の NAPTR RR に対するものです。
In the case of an application client that supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol.
特定のアプリケーション サービスに対して複数のプロトコルをサポートするアプリケーション クライアントの場合、アプリケーションが正常に接続されるか、アプリケーション クライアントが正常に接続されるまで、PREF および ORDER ランキングで潜在的な端末の検索をすべて調査し、1 つのプロトコルに対して S-NAPTR 解決を完全に追求しなければなりません (MUST)。そのプロトコルにはもう可能性はありません。
That is, the client MUST NOT start looking for one protocol, observe that a successive NAPTR RR set supports another of its preferred protocols, and continue the S-NAPTR resolution based on that protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there is no reason to believe that it does so on behalf of example.com (as there is no such pointer in example.com's NAPTR RR set).
つまり、クライアントは、あるプロトコルの検索を開始して、後続の NAPTR RR セットが別の優先プロトコルをサポートしていることを確認し、そのプロトコルに基づいて S-NAPTR 解決を継続してはなりません (MUST NOT)。たとえば、someisp.example がプロトコル「ProtB」で「EM」サービスを提供しているとしても、それが example.com に代わって提供していると信じる理由はありません (example.com の NAPTR RR セットにはそのようなポインタがないため)）。
It MAY choose which protocol to try first based on its own preference, or on the PREF ranking in the first set of NAPTR records (i.e., those for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
それは、自身の優先設定、または NAPTR レコードの最初のセット (つまり、ターゲットの名前付きドメインのレコード) の PREF ランキングに基づいて、どのプロトコルを最初に試行するかを選択してもよい(MAY)。ただし、選択したプロトコルは最初の NAPTR RR セットにリストされなければなりません。
It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid-resolution.
複数のプロトコルに対して同時に DDDS 解決を実行することを選択してもよい(MAY)。その場合、上記の要件は各プロトコルに個別に適用される。つまり、解像度の途中でプロトコルを切り替えないでください。
The purpose of S-NAPTR is to provide application standards developers with a more powerful framework (than SRV RRs alone) for naming service targets, without requiring each application protocol (or service) standard to define a separate DDDS application.
S-NAPTR の目的は、各アプリケーション プロトコル (またはサービス) 標準で個別の DDDS アプリケーションを定義する必要がなく、サービス ターゲットに名前を付けるための (SRV RR 単独よりも) より強力なフレームワークをアプリケーション標準開発者に提供することです。
Note that this approach is intended specifically for use when it makes sense to associate services with particular domain names (e.g., e-mail addresses, SIP addresses, etc). A non-goal is having all manner of label mapped into domain names in order to use this.
このアプローチは、サービスを特定のドメイン名 (電子メール アドレス、SIP アドレスなど) に関連付けることが合理的である場合に使用することを特に目的としていることに注意してください。非目標は、これを使用するためにあらゆる種類のラベルをドメイン名にマッピングすることです。
This document does not address how to select the domain for which the service+protocol is being sought. Other conventions will have to define how this might be used (e.g., new messaging standards can define what domain to use from their URIs or how to step down from foobar.example.com to example.com, if applicable).
この文書では、サービス プロトコルを検索するドメインの選択方法については説明しません。他の規約では、これがどのように使用されるかを定義する必要があります (たとえば、新しいメッセージング標準では、URI からどのドメインを使用するか、または該当する場合は foobar.example.com から example.com にステップダウンする方法を定義できます)。
Although this document proposes a DDDS application that does not use all the features of NAPTR resource records, it is not intended to imply that DNS resolvers should fail to implement all aspects of the NAPTR RR standard. A DDDS application is a client use convention.
この文書では、NAPTR リソース レコードのすべての機能を使用しない DDDS アプリケーションを提案していますが、DNS リゾルバーが NAPTR RR 標準のすべての側面を実装できなければならないと示唆することは意図されていません。DDDS アプリケーションはクライアントの使用規則です。
The rest of this section outlines the specific elements that protocol developers must determine and document to make use of S-NAPTR.
このセクションの残りの部分では、プロトコル開発者が S-NAPTR を利用するために決定し、文書化する必要がある特定の要素について概説します。
Application protocol developers who wish to make use of S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
S-NAPTR の利用を希望するアプリケーション プロトコル開発者は、セクション 7 で説明されているように、関連するアプリケーション サービスおよびアプリケーション プロトコル タグを登録するための準備を整える必要があります。
One other important aspect that must be defined is the expected behaviour for interacting with the servers that are reached via S-NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? What should it consider a failure that causes it to return to the S-NAPTR process to determine the next serviceable target, which by definition will have a lower preference ranking.
定義する必要があるもう 1 つの重要な側面は、S-NAPTR 経由で到達するサーバーと対話するために予期される動作です。具体的には、どのような状況でクライアントは S-NAPTR 経由で見つかったターゲットを再試行する必要がありますか?次のサービス可能なターゲットを決定するために S-NAPTR プロセスに戻る原因となった障害をどのように考慮すべきでしょうか (定義上、優先順位が低くなります)。
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it try the next-preferred target in the S-NAPTR chain of resolution? Should it only try the next-preferred target if it receives a protocol-specific permanent error message?
たとえば、クライアントがサーバーから「接続が拒否されました」というメッセージを受け取った場合、一定の期間 (プロトコルに依存します) 再試行する必要がありますか?それとも、S-NAPTR 解決チェーンで次に優先されるターゲットを試すべきでしょうか?プロトコル固有の永続的なエラー メッセージを受信した場合にのみ、次に優先されるターゲットを試行する必要がありますか?
The most important thing is to select one expected behaviour and document it as part of the use of S-NAPTR.
最も重要なことは、予想される動作を 1 つ選択し、S-NAPTR の使用の一部として文書化することです。
As noted earlier, failure to provide appropriate credentials to identify the server as being authoritative for the original target domain is always considered a failure condition.
前述したように、元のターゲット ドメインに対して権限のあるサーバーであることを識別するための適切な資格情報の提供に失敗すると、常に障害状態とみなされます。
As noted in section 8, use of the DNS for server location increases the importance of using protocol-specific handshakes to determine and confirm the identity of the server that is eventually reached.
セクション 8 で述べたように、サーバーの場所に DNS を使用すると、最終的に到達するサーバーの ID を決定および確認するためにプロトコル固有のハンドシェイクを使用する重要性が高まります。
Therefore, application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR.
したがって、S-NAPTR を使用するアプリケーション プロトコル開発者は、クライアントが S-NAPTR を通じて見つかったサーバーに接続するときに予期される識別ハンドシェイクの仕組みを特定する必要があります。
Although S-NAPTR aims to provide a "straightforward" application of DDDS and use of NAPTR records, it is still possible to create very complex chains and dependencies with the NAPTR and SRV records.
S-NAPTR は、DDDS の「単純な」アプリケーションと NAPTR レコードの使用を提供することを目的としていますが、NAPTR レコードと SRV レコードを使用して非常に複雑なチェーンと依存関係を作成する可能性があります。
Therefore, domain administrators are called upon to use S-NAPTR with as much restraint as possible while still achieving their service design goals.
したがって、ドメイン管理者は、サービス設計の目標を達成しながら、可能な限り抑制して S-NAPTR を使用することが求められます。
The complete set of NAPTR, SRV, and A RRs "reachable" through the S-NAPTR process for a particular application service can be thought of as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or SRV records; each SRV record points to several A record lookups. Even though a particular client can "prune" the tree to use only those records referring to application protocols supported by the client, the tree could be quite deep, and retracing the tree to retry other targets can become expensive if the tree has many branches.
特定のアプリケーション サービスの S-NAPTR プロセスを通じて「到達可能な」NAPTR、SRV、および A RR の完全なセットは、「ツリー」と考えることができます。取得された各 NAPTR RR は、さらに多くの NAPTR または SRV レコードを指します。各 SRV レコードは複数の A レコード ルックアップを指します。特定のクライアントがツリーを「プルーニング」して、そのクライアントがサポートするアプリケーション プロトコルを参照するレコードのみを使用することができますが、ツリーは非常に深くなる可能性があり、ツリーに多くの分岐がある場合は、ツリーを再トレースして他のターゲットを再試行するとコストが高くなる可能性があります。
Therefore,
したがって、
o fewer branches is better: For both NAPTR and SRV records, provide different targets with varying preferences where appropriate (e.g., to provide backup services) but don't look for reasons to provide more; and
o ブランチは少ないほど良い: NAPTR レコードと SRV レコードの両方について、必要に応じてさまざまな設定を持つ異なるターゲットを提供します (バックアップ サービスを提供するなど)。ただし、より多くのブランチを提供する理由を探す必要はありません。そして
o shallower is better: Avoid using NAPTR records to "rename" services within a zone. Use NAPTR records to identify services hosted elsewhere (i.e., where you cannot reasonably provide the SRV records in your own zone).
o 浅いほど良い: ゾーン内のサービスの「名前変更」に NAPTR レコードを使用することは避けてください。NAPTR レコードを使用して、他の場所 (つまり、独自のゾーンで SRV レコードを合理的に提供できない場所) でホストされているサービスを識別します。
To understand DDDS/NAPTR properly, an implementor must read [4]. However, the most important aspect to keep in mind is that if the application cannot successfully connect to one target, the application will be expected to continue through the S-NAPTR tree to try the (less preferred) alternatives.
DDDS/NAPTR を正しく理解するには、実装者は [4] を読む必要があります。ただし、留意すべき最も重要な側面は、アプリケーションが 1 つのターゲットに正常に接続できない場合、アプリケーションは引き続き S-NAPTR ツリーを介して (あまり好ましくない) 代替手段を試行することが期待されるということです。
The basic intended use cases for which S-NAPTR has been developed are as follows
S-NAPTR が開発された基本的な使用目的は次のとおりです。
o Service discovery within a domain. For example, this can be used to find the "authoritative" server for some type of service within a domain (see the specific example in section 4.2).
o ドメイン内のサービス検出。たとえば、これを使用して、ドメイン内のあるタイプのサービスの「権限のある」サーバーを見つけることができます (セクション 4.2 の具体的な例を参照)。
o Multiple protocols. This is already common today as new application services are defined, and is increasingly a problem. It includes the case of extensible messaging (a hypothetical service), which can be offered with multiple protocols (see section 4.3).
o 複数のプロトコル。これは、新しいアプリケーション サービスが定義される今日ではすでに一般的になっており、ますます問題になっています。これには、複数のプロトコルで提供できる拡張可能なメッセージング (仮想サービス) のケースが含まれます (セクション 4.3 を参照)。
o Remote hosting. Each of the above use cases applies within the administration of a single domain. However, one domain operator may elect to engage another organization to provide an application service. See section 4.4 for an example that cannot be served by SRV records alone.
o リモートホスティング。上記の各使用例は、単一ドメインの管理内に当てはまります。ただし、あるドメイン オペレータは、アプリケーション サービスを提供するために別の組織と提携することを選択する場合があります。SRV レコードだけでは提供できない例については、セクション 4.4 を参照してください。
There are occasions when it is useful to be able to determine the "authoritative" server for a given application service within a domain. This is "discovery", as there is no a priori knowledge as to whether or where the service is offered; it is therefore important to determine the location and characteristics of the offered service.
ドメイン内の特定のアプリケーション サービスの「権限のある」サーバーを判断できると便利な場合があります。サービスが提供されるかどうか、またはどこで提供されるかについて先験的な知識がないため、これは「発見」です。したがって、提供されるサービスの場所と特徴を決定することが重要です。
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.
たとえば、特定のドメイン内 (またはドメイン用) で動作する特定のアプリケーション (サーバー) に関連付けられたキーまたは証明書を見つけるための汎用メカニズムについての議論が高まっています。以下は、特定のドメインのアプリケーション キーまたは証明書データを保存するための仮想ケースです。前提条件として、資格情報レジストリ (CredReg) サービスが、サーバーによって運用されている (またはドメインに対して) キー/証明書を保持するリーフ ノード サービスとして定義されているということです。) ドメイン。特定のドメインにサービスを提供するために複数のプロトコルが利用できることが想定されています。この DDDS ベースのアプローチは、情報を保持する CredReg サーバーを見つけるために使用されます。
Thus, the set of NAPTR records for thinkingcat.example might look like this:
したがって、 Thinkingcat.example の NAPTR レコードのセットは次のようになります。
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacement
Note that the application service might be offered in another domain using a different set of application protocols:
アプリケーション サービスは、別のアプリケーション プロトコルのセットを使用して別のドメインで提供される場合があることに注意してください。
anotherdomain.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service "" ; regexp foo.anotherdomain.example. ; replacement )
別のドメインの例。;;優先フラグの順序 IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; サービス "" ; 正規表現 foo.anotherdomain.example. ; 置換 )
Extensible messaging, a hypothetical application service, will be used for illustrative purposes. (For an example of a real application service with multiple protocols, see [9] and [10]). Assuming that "EM" was registered as an application service, this DDDS application could be used to determine the available services for delivery to a target.
拡張可能なメッセージング (仮想アプリケーション サービス) を説明の目的で使用します。(複数のプロトコルを使用した実際のアプリケーション サービスの例については、[9] および [10] を参照してください)。「EM」がアプリケーション サービスとして登録されていると仮定すると、この DDDS アプリケーションを使用して、ターゲットに配信できる利用可能なサービスを決定できます。
Two particular features of this hypothetical extensible messaging should be noted:
この仮想的な拡張可能メッセージングの 2 つの特別な機能に注目してください。
1. Gatewaying is expected to bridge communications across protocols.
1. ゲートウェイは、プロトコル間の通信を橋渡しすることが期待されています。
2. Extensible messaging servers are likely to be operated out of a different domain than that of the extensible messaging address, and servers of different protocols may be offered by independent organizations.
2. 拡張可能メッセージング サーバーは、拡張可能メッセージング アドレスとは異なるドメインで運用される可能性が高く、異なるプロトコルのサーバーが独立した組織によって提供される場合があります。
For example, "thinkingcat.example" may support its own servers for the "ProtA" extensible messaging protocol but rely on outsourcing from "example.com" for "ProtC" and "ProtB" servers.
たとえば、「 Thinkingcat.example 」は、「 ProtA 」拡張可能メッセージング プロトコルについては独自のサーバーをサポートしますが、「 ProtC 」および「 ProtB 」サーバーについては「example.com」からのアウトソーシングに依存する場合があります。
Using this DDDS-based approach, thinkingcat.example can indicate a preference ranking for the different types of servers for the extensible messaging service, yet the out-sourcer can independently rank the preference and ordering of servers. This independence is not achievable through the use of SRV records alone.
この DDDS ベースのアプローチを使用すると、 Thinkingcat.example は、拡張可能なメッセージング サービスのさまざまな種類のサーバーの優先順位を示すことができますが、アウトソーサーはサーバーの優先順位と順序を独立してランク付けできます。この独立性は、SRV レコードだけを使用するだけでは実現できません。
Thus, to find the EM services for thinkingcat.example, the NAPTR records for thinkingcat.example are retrieved:
したがって、 Thinkingcat.example の EM サービスを見つけるには、 Thinkingcat.example の NAPTR レコードが取得されます。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement ) IN NAPTR 100 30 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement )
思考猫の例。;;優先フラグの順序 IN NAPTR 100 10 "s" "EM:ProtA" ( ; サービス "" ; regexp _ProtA._tcp. Thinkingcat.example. ; 置換 ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; サービス ""; 正規表現 _ProtB._tcp.example.com. ; 置換) IN NAPTR 100 30 "s" "EM:ProtC" (; サービス "" ; 正規表現 _ProtC._tcp.example.com. ; 置換)
Then the administrators at example.com can manage the preference rankings of the servers they use to support the ProtB service:
これにより、example.com の管理者は、ProtB サービスをサポートするために使用するサーバーの優先順位を管理できます。
_ProtB._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtB._tcp.example.com。;;Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com。IN SRV 20 0 10001backup.em.example.com。IN SRV 30 0 10001 Nuclearfallout.オーストラリア-isp.例。
In the Instant Message hosting example in Section 4.3, the service owner (thinkingcat.example) had to host pointers to the hosting service's SRV records in the thinkingcat.example domain.
セクション 4.3 のインスタント メッセージ ホスティングの例では、サービス所有者 (thingcat.example) はホスティング サービスの SRV レコードへのポインターを Thinkingcat.example ドメインにホストする必要がありました。
A better approach is to have one NAPTR RR in the thinkingcat.example domain point to all the hosted services. The hosting domain has NAPTR records for each service to map them to whatever local hosts it chooses (this may change from time to time).
より良いアプローチは、 Thinkingcat.example ドメイン内の 1 つの NAPTR RR がホストされているすべてのサービスを指すようにすることです。ホスティング ドメインには、各サービスの NAPTR レコードがあり、選択したローカル ホストにサービスをマップします (これは時々変更される可能性があります)。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service "" ; regexp thinkingcat.example.com. ; replacement )
思考猫の例。;;優先フラグの順序 IN NAPTR 100 10 "s" "EM:ProtA" ( ; サービス "" ; regexp _ProtA._tcp. Thinkingcat.example. ; 置換 ) IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; サービス "" ; 正規表現 Thinkingcat.example.com. ; 置換)
Then the administrators at example.com can break out the individual application protocols and manage the preference rankings of the servers they use to support the ProtB service (as before):
次に、example.com の管理者は、個々のアプリケーション プロトコルを分割し、ProtB サービスをサポートするために使用するサーバーの優先順位を管理できます (以前と同様)。
thinkingcat.example.com. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement )
Thinkingcat.example.com。;;優先フラグの順序 IN NAPTR 100 10 "s" "EM:ProtC" ( ; サービス "" ; regexp _ProtC._tcp.example.com. ; 置換) IN NAPTR 100 20 "s" "EM:ProtB" ( ; サービス ""; 正規表現 _ProtB._tcp.example.com. ; 置換)
_ProtC._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtC._tcp.example.com。;;Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com。IN SRV 20 0 10001backup.em.example.com。IN SRV 30 0 10001 Nuclearfallout.オーストラリア-isp.例。
Note that the above sections assume that there was one service available (via S-NAPTR) per domain. Often, this will not be the case. Assuming that thinkingcat.example had the CredReg service set up as described in Section 4.2 and had the extensible messaging service set up as described in Section 4.4, then a client querying for the NAPTR RR set from thinkingcat.com would get the following answer:
上記のセクションでは、ドメインごとに (S-NAPTR 経由で) 利用可能なサービスが 1 つあることを前提としていることに注意してください。多くの場合、そうではありません。Thinkingcat.example にセクション 4.2 の説明に従って CredReg サービスが設定され、セクション 4.4 の説明に従って拡張可能なメッセージング サービスが設定されていると仮定すると、クライアントが Thinkingcat.com から NAPTR RR セットをクエリすると、次の答えが得られます。
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)
Sorting them by increasing "ORDER", the client would look through the SERVICE strings to determine whether there was a NAPTR RR that matched the application service it was looking for, with an application protocol it could use. The client would use the first (lowest PREF) record that matched to continue.
「ORDER」を増やして並べ替えると、クライアントは SERVICE 文字列を調べて、使用できるアプリケーション プロトコルとともに、探しているアプリケーション サービスに一致する NAPTR RR があるかどうかを判断します。クライアントは、一致した最初の (最も低い PREF) レコードを使用して続行します。
Consider the example in section 4.3. Visually, the sequence of steps required for the client to reach the final server for a "ProtB" service for EM for the thinkingcat.example domain is as follows:
セクション 4.3 の例を考えてみましょう。視覚的には、クライアントが Thinkingcat.example ドメインの EM の「ProtB」サービスの最終サーバーに到達するために必要な一連の手順は次のとおりです。
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
1. The name server (NS) for thinkingcat.example is reached with a request for all NAPTR records.
1. Thinkingcat.example のネーム サーバー (NS) に、すべての NAPTR レコードに対するリクエストが到達します。
2. The server responds with the NAPTR records shown in section 4.3.
2. サーバーはセクション 4.3 に示す NAPTR レコードで応答します。
3. The second NAPTR record matches the desired criteria; it has an "s" flag and a replacement fields of "_ProtB._tcp.example.com". So the client looks up SRV records for that target, ultimately making the request of the NS for example.com.
3. 2 番目の NAPTR レコードは、必要な基準に一致します。「s」フラグと「_ProtB._tcp.example.com」の置換フィールドがあります。したがって、クライアントはそのターゲットの SRV レコードを検索し、最終的に NS (example.com など) にリクエストを行います。
4. The response includes the SRV records listed in Section 4.3.
4. 応答には、セクション 4.3 にリストされている SRV レコードが含まれます。
5. The client attempts to reach the server with the lowest PREF in the SRV list -- looking up the A record for the SRV record's target (bigiron.example.com).
5. クライアントは、SRV リストの中で最も低い PREF を持つサーバーに到達しようとします。SRV レコードのターゲット (bigiron.example.com) の A レコードを検索します。
6. The example.com NS responds with an error message -- no such machine!
6. example.com NS はエラー メッセージで応答します -- そのようなマシンはありません!
7. The client attempts to reach the second server in the SRV list and looks up the A record for backup.em.example.com.
7. クライアントは SRV リストの 2 番目のサーバーにアクセスしようとし、backup.em.example.com の A レコードを検索します。
8. The client gets the A record with the IP address for backup.em.example.com from example.com's NS.
8. クライアントは、example.com の NS から、backup.em.example.com の IP アドレスを持つ A レコードを取得します。
9. The client connects to that IP address, on port 10001 (from the SRV record), by using ProtB over tcp.
9. クライアントは、ProtB over tcp を使用して、ポート 10001 (SRV レコードから) の IP アドレスに接続します。
10. The server responds with an "OK" message.
10. サーバーは「OK」メッセージで応答します。
11. The client uses ProtB to challenge that this server has credentials to operate the service for the original domain (thinkingcat.example)
11. クライアントは ProtB を使用して、このサーバーが元のドメイン (thingcat.example) のサービスを操作するための資格情報を持っているかどうかを確認します。
12. The server responds, and the rest is EM.
12. サーバーが応答し、残りは EM です。
Increasingly, application protocol standards use domain names to identify server targets and stipulate that clients should look up SRV resource records to determine the host and port providing the server. This enables a distinction between naming an application service target and actually hosting the server. It also increases flexibility in hosting the target service, as follows:
アプリケーション プロトコル標準では、サーバー ターゲットを識別するためにドメイン名を使用することが増えており、クライアントが SRV リソース レコードを検索してサーバーを提供するホストとポートを決定する必要があると規定しています。これにより、アプリケーション サービス ターゲットの名前付けと実際のサーバーのホストを区別できるようになります。また、次のように、ターゲット サービスをホスティングする際の柔軟性も向上します。
o The server may be operated by a completely different organization without having to list the details of that organization's DNS setup (SRVs).
o サーバーは、組織の DNS 設定 (SRV) の詳細をリストすることなく、まったく異なる組織によって運用されている可能性があります。
o Multiple instances can be set up (e.g., for load balancing or secondaries).
o 複数のインスタンスをセットアップできます (負荷分散またはセカンダリなど)。
o It can be moved from time to time without disrupting clients' access, etc.
o クライアントのアクセスなどを中断することなく、随時移動できます。
This approach is quite useful, but section 5.1 outlines some of its inherent limitations.
このアプローチは非常に便利ですが、セクション 5.1 では、その固有の制限の一部について概説します。
That is, although SRV records can be used to map from a specific service name and protocol for a specific domain to a specific server, SRV records are limited to one layer of indirection and are focused on server administration rather than on application naming. Furthermore, although the DDDS specification and use of NAPTR allows multiple levels of redirection before the target server machine with an SRV record is located, this proposal requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR. These restrictions make the client's resolution process much more predictable and efficient than it would be with some potential uses of NAPTR records. This is dubbed "S-NAPTR" -- a "S"traightforward use of NAPTR records.
つまり、SRV レコードを使用して、特定のドメインの特定のサービス名とプロトコルから特定のサーバーにマッピングできますが、SRV レコードは 1 つの間接層に限定されており、アプリケーションの名前付けではなくサーバー管理に重点を置いています。さらに、DDDS 仕様と NAPTR の使用では、SRV レコードを持つターゲット サーバー マシンが見つかる前に複数レベルのリダイレクトが可能ですが、この提案では、NAPTR の REGEXP フィールドを使用せず、ドメイン名に厳密にバインドされた NAPTR のサブセットのみが必要です。。これらの制限により、クライアントの解決プロセスは、NAPTR レコードの潜在的な使用に比べてはるかに予測可能かつ効率的になります。これは「S-NAPTR」と呼ばれ、NAPTR レコードの「S」をそのまま使用したものです。
An expected question at this point is: this is so similar in structure to SRV records, why are we doing this with DDDS/NAPTR?
この時点で予想される質問は、「これは SRV レコードと構造が非常に似ているのに、なぜ DDDS/NAPTR を使用するのか?」というものです。
Limitations of SRV include the following:
SRV の制限には次のようなものがあります。
o SRV provides a single layer of indirection; the outcome of an SRV lookup is a new domain name for which the A RR is to be found.
o SRV は単一の間接層を提供します。SRV ルックアップの結果は、A RR が見つかる新しいドメイン名です。
o the purpose of SRV is to address individual server administration issues, not to provide application naming: As stated in [3], "The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups".
o SRV の目的は、個々のサーバー管理の問題に対処することであり、アプリケーションに名前を付けることではありません。[3] で述べられているように、「SRV RR を使用すると、管理者は単一ドメインに対して複数のサーバーを使用し、ほとんど手間をかけずにサービスをホスト間で移動できます。」、一部のホストをサービスのプライマリ サーバーとして指定し、他のホストをバックアップとして指定します。」
o Target servers by "service" (e.g., "ldap") and "protocol" (e.g., "tcp") in a given domain. The definition of these terms implies specific things (e.g., that protocol should be one of UDP or TCP) without being precise. Restriction to UDP and TCP is insufficient for the uses described here.
o 特定のドメイン内の「サービス」（「ldap」など）および「プロトコル」（「tcp」など）によってサーバーをターゲットにします。これらの用語の定義は、正確ではありませんが、特定の事柄 (たとえば、プロトコルは UDP または TCP のいずれかである必要があるなど) を暗示しています。UDP と TCP への制限は、ここで説明する用途には不十分です。
The basic answer is that SRV records provide mappings from protocol names to host and port. The use cases described herein require an additional layer -- from some service label to servers that may in be hosted within different administrative domains. We could tweak SRV to say that the next lookup could be something other than an address record, but this is more complex than is necessary for most applications of SRV.
基本的な答えは、SRV レコードがプロトコル名からホストおよびポートへのマッピングを提供するということです。ここで説明する使用例には、いくつかのサービス ラベルから、異なる管理ドメイン内でホストされる可能性があるサーバーに至るまで、追加のレイヤーが必要です。SRV を微調整して、次のルックアップがアドレス レコード以外のものになるようにすることもできますが、これは SRV のほとんどのアプリケーションで必要な以上に複雑です。
This is a trick question. NAPTR records cannot appear in the wild; see [4]. They must be part of a DDDS application.
これはひっかけ質問です。NAPTR レコードは実際には出現できません。[4]を参照してください。これらは DDDS アプリケーションの一部である必要があります。
The purpose here is to define a single, common mechanism (the DDDS application) to use NAPTR when all that is desired is simple DNS-based location of services. This should be easy for applications to use -- a few simple IANA registrations, and it's done.
ここでの目的は、シンプルな DNS ベースのサービスの位置情報だけが必要な場合に NAPTR を使用するための単一の共通メカニズム (DDDS アプリケーション) を定義することです。これはアプリケーションにとって簡単に使用できるはずです。簡単な IANA 登録をいくつか行うだけで完了します。
Also, NAPTR has very powerful tools for expressing "rewrite" rules. This power (==complexity) makes some protocol designers and service administrators nervous. The concern is that these rewrites can translate into unintelligible, noodle-like rule sets that are difficult to test and administer.
また、NAPTR には、「書き換え」ルールを表現するための非常に強力なツールがあります。この能力 (== 複雑さ) によって、一部のプロトコル設計者やサービス管理者は不安になります。懸念されるのは、これらの書き換えによって、テストや管理が困難な、理解できないヌードルのようなルール セットに変換される可能性があることです。
The proposed DDDS application specifically uses a subset of NAPTR's abilities. Only "replacement" expressions are allowed, not "regular expressions".
提案されている DDDS アプリケーションは、特に NAPTR の機能のサブセットを使用します。使用できるのは「置換」式のみであり、「正規表現」は使用できません。
This section formally defines the DDDS application, as described in [4].
このセクションでは、[4] で説明されているように、DDDS アプリケーションを正式に定義します。
The Application Unique String is domain label for which an authoritative server for a particular service is sought.
アプリケーション固有文字列は、特定のサービスに対する権限のあるサーバーが検索されるドメイン ラベルです。
The "First Well-Known Rule" is identity -- that is, the output of the rule is the Application-Unique String, the domain label for which the authoritative server for a particular service is sought.
「最初のよく知られたルール」はアイデンティティです。つまり、ルールの出力はアプリケーション固有文字列、つまり特定のサービスの権限のあるサーバーが検索されるドメイン ラベルです。
The expected output of this Application is the information necessary for a client to connect to authoritative server(s) (host, port, protocol) for a particular application service within a given domain.
このアプリケーションの予期される出力は、クライアントが特定のドメイン内の特定のアプリケーション サービスの権限のあるサーバー (ホスト、ポート、プロトコル) に接続するために必要な情報です。
This DDDS Application uses only 2 of the Flags defined for the URI/ URN Resolution Application ([6]): "S" and "A". No other Flags are valid.
この DDDS アプリケーションは、URI/URN 解決アプリケーション ([6]) に定義されたフラグのうち、「S」と「A」の 2 つだけを使用します。他のフラグは有効ではありません。
Both are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a domain label for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain.
どちらも端末検索用です。これは、ルールが最後のルールであり、フラグが次のステージがどうあるべきかを決定することを意味します。「S」フラグは、このルールの出力が 1 つ以上の SRV [3] レコードが存在するドメイン ラベルであることを意味します。「A」は、ルールの出力がドメイン名であり、そのドメインのアドレス レコードを検索するために使用される必要があることを意味します。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
DDDS アルゴリズムと一致し、フラグ文字列が空の場合、次の検索は別の NAPTR レコード (置換ターゲット用) です。
Service Parameters for this Application take the form of a string of characters that follow this ABNF ([2]):
このアプリケーションのサービス パラメータは、この ABNF ([2]) に続く文字列の形式を取ります。
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
Thus, the Service Parameters may consist of an empty string, an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
したがって、サービス パラメーターは、空の文字列、アプリ サービス、または「:」記号で区切られた 1 つ以上のアプリ プロトコル仕様を持つアプリ サービスで構成されます。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application ([6]). The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). As "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
これは、URI DDDS アプリケーション ([6]) で使用される構文に似ていますが、同じではないことに注意してください。DDDS DNS データベースでは、各 DDDS アプリケーションが許可されるサービス文字列の構文を定義する必要があります。ここでの構文は、任意の URI スキーム名で有効な文字を使用できるように拡張されています ([8] を参照)。「 」 (RFC3404 サービス パラメータ文字列で使用される区切り文字) は URI スキーム名に使用できる文字であるため、ここでは区切り文字として「:」が選択されています。
The "app-service" must be an IANA-registered service; see Section 7 for instructions on registering new application service tags.
「app-service」は IANA に登録されたサービスである必要があります。新しいアプリケーション サービス タグの登録手順については、セクション 7 を参照してください。
The protocol identifiers valid for the "app-protocol" production are standard, registered protocols; see section 7 for instructions on registering new application protocol tags.
「app-protocol」プロダクションに有効なプロトコル識別子は、標準の登録済みプロトコルです。新しいアプリケーション プロトコル タグの登録手順については、セクション 7 を参照してください。
Only substitution Rules are permitted for this application. That is, no regular expressions are allowed.
このアプリケーションでは置換ルールのみが許可されます。つまり、正規表現は使用できません。
At present only one DDDS Database is specified for this Application. [5] specifies that a DDDS Database using the NAPTR DNS resource record contain the rewrite rules. The Keys for this database are encoded as domain-names.
現在、このアプリケーションには DDDS データベースが 1 つだけ指定されています。[5] は、NAPTR DNS リソース レコードを使用する DDDS データベースに書き換えルールが含まれることを指定します。このデータベースのキーはドメイン名としてエンコードされます。
The First Well-Known Rule produces a domain name, and this is the Key used for the first look up. The NAPTR records for that domain are requested.
最初のよく知られたルールによってドメイン名が生成され、これが最初の検索に使用されるキーになります。そのドメインの NAPTR レコードが要求されます。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of [5] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNS サーバーは、フラグ値を解釈し、その情報を使用して、DNS パケットの追加情報部分に適切な NAPTR、SRV、または A レコードを含めてもよい(MAY)。クライアントには追加情報を確認することが推奨されますが、必須ではありません。NAPTR レコードと DNS 応答パケットの追加情報セクションの詳細については、[5] の「追加情報処理」セクションを参照してください。
This document calls for two IANA registries: one for application service tags, and one for application protocol tags.
この文書では、2 つの IANA レジストリが必要です。1 つはアプリケーション サービス タグ用、もう 1 つはアプリケーション プロトコル タグ用です。
IANA has established and will maintain a registry for S-NAPTR Application Service Tags, listing at least the following information for each such tag:
IANA は、S-NAPTR アプリケーション サービス タグのレジストリを確立および維持し、各タグについて少なくとも次の情報をリストします。
o Application Service Tag: A string conforming with the IANA-registered-service defined in section 6.5.
o アプリケーション サービス タグ: セクション 6.5 で定義されている IANA 登録サービスに準拠する文字列。
o Defining publication: The RFC used to define the Application Service Tag, as defined in the registration process, below.
o 定義出版物: 以下の登録プロセスで定義されているように、アプリケーション サービス タグを定義するために使用される RFC。
An initial Application Service Tag registration is contained in [9].
最初のアプリケーション サービス タグ登録は [9] に含まれています。
IANA has established and will maintain a registry for S-NAPTR Application Protocol Tags, listing at least the following information for each such tag:
IANA は、S-NAPTR アプリケーション プロトコル タグのレジストリを確立し、維持します。このレジストリには、各タグについて少なくとも次の情報がリストされています。
o Application Protocol Tag: A string conforming with the iana-registered-protocol defined in section 6.5.
o アプリケーション プロトコル タグ: セクション 6.5 で定義されている iana-registered-protocol に準拠する文字列。
o Defining publication: The RFC used to define the Application Protocol Tag, as defined in the registration process, below.
o 定義出版物: 以下の登録プロセスで定義されているように、アプリケーション プロトコル タグを定義するために使用される RFC。
An initial Application Protocol Tag registration is defined in [10].
最初のアプリケーション プロトコル タグ登録は [10] で定義されています。
All application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk.
「x-」で始まるすべてのアプリケーション サービスおよびプロトコル タグは実験的とみなされ、同じ文字列の重複使用を防止するための規定はありません。実装者は自らの責任でそれらを使用します。
All other application service and protocol tags are registered based on the "specification required" option defined in [7], with the further stipulation that the "specification" is an RFC (of any category).
他のすべてのアプリケーション サービスおよびプロトコル タグは、[7] で定義されている「仕様が必要」オプションに基づいて登録されますが、「仕様」は (任意のカテゴリの) RFC であるというさらなる規定があります。
No further restrictions are placed on the tags except that they must conform with the syntax defined below (Section 6.5).
以下に定義されている構文 (セクション 6.5) に準拠する必要があることを除き、タグにはそれ以上の制限はありません。
The defining RFC must clearly identify and describe, for each tag being registered,
定義する RFC では、登録されるタグごとに、以下を明確に識別して説明する必要があります。
o application protocol or service tag,
o アプリケーションプロトコルまたはサービスタグ、
o intended usage,
o 使用目的、
o interoperability considerations,
o 相互運用性に関する考慮事項、
o security considerations (see section 8 of this document for further discussion of the types of considerations that are applicable), and
o セキュリティに関する考慮事項 (該当する考慮事項の種類の詳細については、このドキュメントのセクション 8 を参照してください)、および
o any relevant related publications.
o 関連する関連出版物。
The security of this approach to application service location is only as good as the security of the DNS queries along the way. If any of them is compromised, bogus NAPTR and SRV records could be inserted to redirect clients to unintended destinations. This problem is hardly unique to S-NAPTR (or NAPTR in general). A full discussion of the security threats pertaining to DNS can be found in [11].
アプリケーション サービスの場所に対するこのアプローチのセキュリティは、途中での DNS クエリのセキュリティと同じくらい優れています。これらのいずれかが侵害されると、偽の NAPTR レコードや SRV レコードが挿入され、クライアントが意図しない宛先にリダイレクトされる可能性があります。この問題は、S-NAPTR (または NAPTR 一般) に固有のものではありません。DNS に関連するセキュリティ上の脅威についての詳しい説明は、[11] にあります。
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] can be used to ensure the validity of the DNS records received.
DNS ベクトル攻撃から保護するために、セキュア DNS (DNSSEC) [12] を使用して、受信した DNS レコードの有効性を確認できます。
Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to ensure that the correct destination has been reached. Many application protocols such as HTTPS, BEEP, and IMAP define the necessary handshake mechanisms to accomplish this task. Newly defined application protocols should take this into consideration and incorporate appropriate mechanisms.
DNSSEC が使用されているかどうかに関係なく、アプリケーションは、正しい宛先に到達したことを確認するために、何らかの形式のエンドツーエンド認証を定義する必要があります。HTTPS、BEEP、IMAP などの多くのアプリケーション プロトコルは、このタスクを実行するために必要なハンドシェイク メカニズムを定義しています。新しく定義されたアプリケーション プロトコルはこれを考慮し、適切なメカニズムを組み込む必要があります。
The basic mechanism works as follows:
基本的なメカニズムは次のように機能します。
1. During some portion of the protocol handshake, the client sends to the server the original name of the desired destination (i.e., no transformations that may have resulted from NAPTR replacements, SRV targets, or CNAME changes). In certain cases where the application protocol does not have such a feature but TLS may be used, it is possible to use the "server_name" TLS extension.
1. プロトコル ハンドシェイクの一部の間、クライアントはサーバーに目的の宛先の元の名前を送信します (つまり、NAPTR の置換、SRV ターゲット、または CNAME の変更によって生じた可能性のある変換はありません)。アプリケーション プロトコルにそのような機能がなくても TLS が使用される場合には、「server_name」TLS 拡張機能を使用できます。
2. The server sends back to the client a credential with the appropriate name. For X.509 certificates, the name would be in either the subjectDN or the subjectAltName field. For Kerberos, the name would be a service principle name.
2. サーバーは、適切な名前の資格情報をクライアントに送り返します。X.509 証明書の場合、名前は subjectDN または subjectAltName フィールドのいずれかにあります。Kerberos の場合、名前はサービス原則名になります。
3. Using the matching semantics defined by the application protocol, the client compares the name in the credential with the name sent to the server.
3. アプリケーション プロトコルによって定義された一致セマンティクスを使用して、クライアントは資格情報内の名前とサーバーに送信された名前を比較します。
4. If the names match and the credentials have integrity, there is reasonable assurance that the correct end point has been reached.
4. 名前が一致し、資格情報に整合性がある場合は、正しいエンドポイントに到達したことが合理的に保証されます。
5. The client and server establish an integrity-protected channel.
5. クライアントとサーバーは、整合性が保護されたチャネルを確立します。
Note that this document does not define either the handshake mechanism, the specific credential naming fields, nor the name-matching semantics. Definitions of S-NAPTR for particular application protocols MUST define these.
この文書では、ハンドシェイク メカニズム、特定の資格情報の名前付けフィールド、名前一致のセマンティクスのいずれも定義していないことに注意してください。特定のアプリケーション プロトコルの S-NAPTR の定義では、これらを定義する必要があります。
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted Hardie for discussion and input that have (hopefully!) provoked clarifying revisions to this document.
このドキュメントの改訂を明確にするきっかけとなった (できれば!) ディスカッションと意見を提供してくれた Dave Blacka、Patrik Faltstrom、Sally Floyd、Ted Hardie に多大な感謝を申し上げます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] クロッカー、D.編および P. Overell、「構文仕様のための拡張 BNF: ABNF」、RFC 2234、1997 年 11 月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsen, A.、Vixie, P.、および L. Esibov、「サービスの場所を指定するための DNS RR (DNS SRV)」、RFC 2782、2000 年 2 月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] Mealing, M.、「Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS」、RFC 3401、2002 年 10 月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealing, M.、「Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database」、RFC 3403、2002 年 10 月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[6] Mealing, M.、「動的委任発見システム (DDDS) 第 4 部: 統一リソース識別子 (URI)」、RFC 3404、2002 年 10 月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten, T. および H. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998 年 10 月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] Berners-Lee, T.、Fielding, R.、および L. Masinter、「Uniform Resource Identifiers (URI): Generic Syntax」、RFC 2396、1998 年 8 月。
[9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[9] Newton, A. および M. Sanz、「IRIS: インターネット レジストリ情報サービス (IRIS) のドメイン レジストリ (dreg) タイプ」、RFC 3982、2005 年 1 月。
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
[10] Newton, A. および M. Sanz、「ブロック拡張可能交換プロトコル (BEEP) を介したインターネット レジストリ情報サービス (IRIS) の使用」、RFC 3983、2005 年 1 月。
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
[11] アトキンス D. および R. オースタイン、「ドメイン ネーム システムの脅威分析」、進行中、2004 年 4 月。
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[12] Arends, R.、Larson, M.、Austein, R.、および D. Massey、「DNS セキュリティ拡張機能のプロトコル変更」、進行中の作業、2004 年 5 月。
Assuming the client supports 1 protocol for a particular application service, the following pseudocode outlines the expected process to find the first (best) target for the client, using S-NAPTR.
クライアントが特定のアプリケーション サービスに対して 1 つのプロトコルをサポートしていると仮定すると、次の疑似コードは、S-NAPTR を使用してクライアントの最初の (最適な) ターゲットを見つけるための予想されるプロセスの概要を示します。
target = [initial domain]
naptr-done = false
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
if (not empty [FLAG in cur-rr]) naptr-done = true }
if (空ではない [cur-rr のフラグ]) naptr-done = true }
port = -1
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
; now, whether it was an "S" or an "A" in the NAPTR, we
; have the target for an A record lookup
host = [DNSlookup of target]
return (host, port)
戻り値 (ホスト、ポート)
The pseudocode in Appendix A is crafted to find the first, most preferred host-port pair for a particular application service and protocol. If, for any reason, that host-port pair did not work (connection refused, application-level error), the client is expected to try the next host-port in the S-NAPTR tree.
付録 A の疑似コードは、特定のアプリケーション サービスおよびプロトコルに対して最初の最も優先されるホストとポートのペアを見つけるように作成されています。何らかの理由で、そのホストとポートのペアが機能しなかった場合 (接続が拒否され、アプリケーション レベルのエラーが発生した場合)、クライアントは S-NAPTR ツリー内の次のホストとポートを試行することが期待されます。
The pseudocode above does not permit retries -- once complete, it sheds all context of where in the S-NAPTR tree it finished. Therefore, client software writers could
上記の疑似コードは再試行を許可しません。完了すると、S-NAPTR ツリー内のどこで終了したかに関するすべてのコンテキストが破棄されます。したがって、クライアント ソフトウェア作成者は、
o entwine the application-specific protocol with the DNS lookup and RRset processing described in the pseudocode and continue the S-NAPTR processing if the application code fails to connect to a located host-port pair;
o アプリケーション固有のプロトコルを、疑似コードで説明されている DNS ルックアップおよび RRset 処理と結びつけ、アプリケーション コードが特定されたホストとポートのペアへの接続に失敗した場合は、S-NAPTR 処理を続行します。
o use callbacks for the S-NAPTR processing; or
o S-NAPTR 処理にコールバックを使用します。または
o use an S-NAPTR resolution routine that finds *all* valid servers for the required application service and protocol from the originating domain and that provides them in a sorted order for the application to try.
o S-NAPTR 解決ルーチンを使用します。これは、発信元ドメインから必要なアプリケーション サービスとプロトコルに「すべて」の有効なサーバーを検索し、それらをアプリケーションが試行できるようにソートされた順序で提供します。
Sample Python code for S-NAPTR resolution is available from http://www.verisignlabs.com/pysnaptr-0.1.tgz
S-NAPTR 解決のためのサンプル Python コードは、http://www.verisignlabs.com/pysnaptr-0.1.tgz から入手できます。
Authors' Addresses
著者の住所
Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
EMail: anewton@verisignlabs.com
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。