[要約] RFC 3761は、E.164番号とURIの間の動的なデリゲーションディスカバリーシステム（DDDS）アプリケーション（ENUM）に関するものであり、ENUMの目的は、電話番号をインターネット上のリソースに関連付けるための標準化された方法を提供することです。
Network Working Group P. Faltstrom
Request for Comments: 3761 Cisco Systems, Inc.
Obsoletes: 2916 M. Mealling
Category: Standards Track VeriSign
April 2004
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
E.164からユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401.
このドキュメントでは、E.164番号を保存するためのドメイン名システム（DNS）の使用について説明します。より具体的には、1つのE.164番号に接続された利用可能なサービスを識別するためにDNSを使用する方法。RFC 2916は、RFC 3401で指定されたドキュメントシリーズで見つかった動的委任ディスカバリーシステム（DDDS）アプリケーションの仕様に沿ったものに並べるために、特に廃止されます。RFC 3401で説明したドキュメント。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use for these mechanisms for private dialing plans. . . . 3
1.3. Application of local policy . . . . . . . . . . . . . . . 3
2. The ENUM Application Specifications . . . . . . . . . . . . . 4
2.1. Application Unique String . . . . . . . . . . . . . . . . 5
2.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5
2.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5
2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2. Services Parameters. . . . . . . . . . . . . . . . 7
2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . . 8
3. Registration mechanism for Enumservices . . . . . . . . . . . 8
3.1. Registration Requirements . . . . . . . . . . . . . . . . 8
3.1.1. Functionality Requirement. . . . . . . . . . . . . 8
3.1.2. Naming requirement . . . . . . . . . . . . . . . . 9
3.1.3. Security requirement . . . . . . . . . . . . . . . 9
3.1.4. Publication Requirements . . . . . . . . . . . . . 10
3.2. Registration procedure. . . . . . . . . . . . . . . . . . 10
3.2.1. IANA Registration. . . . . . . . . . . . . . . . . 10
3.2.2. Registration Template. . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
9.2. Informative References. . . . . . . . . . . . . . . . . . 16
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401 [6]. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401 [6].
このドキュメントでは、E.164番号を保存するためのドメイン名システム（DNS）の使用について説明します。より具体的には、1つのE.164番号に接続された利用可能なサービスを識別するためにDNSを使用する方法。RFC 3401 [6]で指定されたドキュメントシリーズで見つかった動的委任ディスカバリーシステム（DDDS）アプリケーションの仕様と一致するように、RFC 2916を特別に廃止します。RFC 3401 [6]で説明されているドキュメントを読むことなく、このドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
Through transformation of International Public Telecommunication Numbers in the international format [5], called within this document E.164 numbers, into DNS names and the use of existing DNS services like delegation through NS records and NAPTR records, one can look up what services are available for a specific E.164 in a decentralized way with distributed management of the different levels in the lookup process.
このドキュメントE.164番号内でDNS名に呼ばれる国際的な通信番号[5]の国際的な電気通信番号の変換、およびNSレコードやNAPTRレコードを介した委任などの既存のDNSサービスの使用を通じて、サービスはどのサービスと見上げることができますかルックアッププロセスで異なるレベルの分散管理を伴う分散型の方法で特定のE.164が利用可能です。
The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations.
ドメイン「E164.ARPA」は、E.164番号を保存するためにDNSのインフラストラクチャを提供するために入力されています。分散操作を促進するために、このドメインはサブドメインに分割されます。DNSにリストされたいE.164番号の保有者は、ゾーンに添付されているポリシーに従って適切なゾーン管理者に連絡する必要があります。通常のDNS操作と同様に、ゾーンに関連するSOAリソースレコードを調べて、この情報を探し始める必要があります。
Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.
もちろん、他のドメインと同様に、そのようなリストのポリシーはサブドメインベースで制御され、世界のさまざまな地域で異なる場合があります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC 3403 [2].
他のすべての大文字は、RFC 3403 [2]にあるDDDSアルゴリズムの仕様にある語彙から取得されます。
This document describes the operation of these mechanisms in the context of numbers allocated according to the ITU-T recommendation E.164. The same mechanisms might be used for private dialing plans. If these mechanisms are re-used, the suffix used for the private dialing plan MUST NOT be e164.arpa, to avoid conflict with this specification. Parties to the private dialing plan will need to know the suffix used by their private dialing plan for correct operation of these mechanisms. Further, the application unique string used SHOULD be the full number as specified, but without the leading '+', and such private use MUST NOT be called "ENUM".
このドキュメントでは、ITU-Tの推奨事項E.164に従って割り当てられた数字のコンテキストでのこれらのメカニズムの動作について説明します。同じメカニズムがプライベートダイヤルプランに使用される場合があります。これらのメカニズムが再利用されている場合、プライベートダイヤル計画に使用される接尾辞は、この仕様との競合を避けるために、E164.ARPAであってはなりません。プライベートダイヤルプランの当事者は、これらのメカニズムの正しい操作のために、プライベートダイヤルプランで使用される接尾辞を知る必要があります。さらに、使用されるアプリケーションの一意の文字列は、指定された完全な数値である必要がありますが、主要な ''がありません。そのような私的使用は「enum」と呼ばれてはなりません。
The Order field in the NAPTR record specifies in what order the DNS records are to be interpreted. This is because DNS does not guarantee the order of records returned in the answer section of a DNS packet. In most ENUM cases this isn't an issue because the typical regular expression will be '!^.*$!' since the first query often results in a terminal Rule.
NAPTRレコードの順序フィールドは、DNSレコードをどの順序で解釈するかを指定します。これは、DNSがDNSパケットの回答セクションで返されたレコードの順序を保証しないためです。ほとんどの列挙の場合、典型的な正規表現は「！^。*$！」になるため、これは問題ではありません。多くの場合、最初のクエリは端末ルールになるためです。
But there are other cases (non-terminal Rules) where two different Rules both match the given Application Unique String. As each Rule is evaluated within the algorithm, one may match a more significant piece of the AUS than the other. For example, by using a non-terminal NAPTR a given set of numbers is sent to some private-dialing-plan-specific zone. Within that zone there are two Rules that state that if a match is for the entire exchange and the service is SIP related then the first, SIP-specific rule is used. But the other Rule matches a longer piece of the AUS, specifying that for some other service (instant messaging) that the Rule denotes a departmental level service. If the shorter matching Rule comes before the longer match, it can 'mask' the other rules. Thus, the order in which each Rule is tested against the AUS is an important corner case that many DDDS applications take advantage of.
ただし、2つの異なるルールが指定されたアプリケーションの一意の文字列と一致する他のケース（非末端ルール）があります。各ルールはアルゴリズム内で評価されるため、一方は他のルールよりもAUのより重要な部分と一致する場合があります。たとえば、非末端NAPTRを使用することにより、特定の数値セットがプライベートダイアリングプラン固有のゾーンに送信されます。そのゾーン内には、一致が交換全体のものであり、サービスがSIPに関連している場合、最初のSIP固有のルールが使用されていることを示す2つのルールがあります。しかし、もう1つのルールは、AUSのより長い部分と一致しており、他のサービス（インスタントメッセージング）については、ルールが部門レベルのサービスを示していることを指定しています。より短い一致ルールが長い一致の前に来る場合、他のルールを「隠す」ことができます。したがって、各ルールがAUSに対してテストされる順序は、多くのDDDSアプリケーションが利用する重要なコーナーケースです。
In the case where the zone authority wishes to state that two Rules have the same effect or are identical in usage, then the Order for those records is set to the same value. In that case, the Preference is used to specify a locally over-ridable suggestion by the zone authority that one Rule might simply be better than another for some reason.
ゾーン当局が2つのルールが同じ効果を持っているか、使用が同一であると述べたい場合、それらのレコードの順序は同じ値に設定されます。その場合、選好は、ある理由で、あるルールが別のルールよりも優れている可能性があるというゾーン当局によるローカルに過剰にridableな提案を指定するために使用されます。
For ENUM this specifies where a client is allowed to apply local policy and where it is not. The Order field in the NAPTR is a request from the holder of the E.164 number that the records be handled in a specific way. The Preference field is merely a suggestion from that E.164 holder that one record might be better than another. A client implementing ENUM MUST adhere to the Order field but can simply take the Preference value "on advisement" as part of a client context specific selection method.
ENUMの場合、これは、クライアントがローカルポリシーを適用できる場所とそうでない場所を指定します。NAPTRの注文フィールドは、e.164番号の所有者からのリクエストであり、レコードを特定の方法で処理することです。優先フィールドは、あるレコードが別のレコードよりも優れている可能性があるというE.164ホルダーからの単なる提案です。列挙を実装するクライアントは、順序フィールドに接着する必要がありますが、クライアントコンテキスト固有の選択方法の一部として、「アドバイスで」の優先値を単純に取得することができます。
This template defines the ENUM DDDS Application according to the rules and requirements found in [7]. The DDDS database used by this Application is found in [2] which is the document that defines the NAPTR DNS Resource Record type.
このテンプレートは、[7]で見つかったルールと要件に従って列挙DDDSアプリケーションを定義します。このアプリケーションで使用されているDDDSデータベースは、[2]にあります。これは、NAPTR DNSリソースレコードタイプを定義するドキュメントです。
ENUM is only applicable for E.164 numbers. ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. Since there are numerous dialing plans which can change over time, it is probably impossible for a client application to have perfect knowledge about every valid and dialable E.164 number. Therefore a client application, doing everything within its power, can end up with what it thinks is a syntactically correct E.164 number which in reality is not actually valid or dialable. This implies that applications MAY send DNS queries when, for example, a user mistypes a number in a user interface. Because of this, there is the risk that collisions between E.164 numbers and non-E.164 numbers can occur. To mitigate this risk, the E2U portion of the service field MUST NOT be used for non-E.164 numbers.
ENUMはE.164番号にのみ適用されます。ENUMに準拠したアプリケーションは、E.164番号であると考えているものに対してDNSのみをクエリする必要があります。時間の経過とともに変化する可能性のあるダイヤルプランが多数あるため、クライアントアプリケーションがすべての有効でダイヤル可能なe.164番号について完全な知識を持つことはおそらく不可能です。したがって、クライアントアプリケーションは、その力の中ですべてを実行することで、実際には実際には有効またはダイヤル可能ではない構文的に正しいe.164番号であると考えるものになります。これは、たとえばユーザーがユーザーインターフェイス内の番号を誤って誤っている場合、アプリケーションがDNSクエリを送信する可能性があることを意味します。このため、E.164数と非E.164の数値との間の衝突が発生するリスクがあります。このリスクを軽減するには、サービスフィールドのE2U部分を非E.164数に使用してはなりません。
The Application Unique String is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The "+" is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.
アプリケーションの一意の文字列は、数字の先頭に表示される ''文字を除き、完全に資格のあるE.164番号を差し引いて非桁の文字を差し引いています。「」は、e.164ネームスペースの一部ではない他の電話番号と区別するために、AUSのよく理解されたアンカーを提供するために保持されています。
For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non-digits except for "+" are removed, yielding "+441164960348".
たとえば、E.164数は「44-116-496-0348」として開始できます。構文糖がAUSに許可されないようにするために、「「」を除くすべての非桁が除去され、「441164960348」が生成されます。
The First Well Known Rule for this Application is the identity rule. The output of this rule is the same as the input. This is because the E.164 namespace and this Applications databases are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself.
このアプリケーションの最初によく知られているルールは、IDルールです。このルールの出力は、入力と同じです。これは、e.164ネームスペースとこのアプリケーションデータベースが、名前自体から直接名前から名前空間の最小の粒度に直接移動できるように編成されているためです。
Take the previous example, the AUS is "+441164960348". Applying the First Well Known Rule produces the exact same string, "+441164960348".
前の例を見てみると、AUSは「441164960348」です。最初によく知られているルールを適用すると、まったく同じ文字列「441164960348」が生成されます。
The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [4].
最後のDDDSループの出力は、RFC2396で見つかった収集されたABNFの「絶対的な」生成に従って、その絶対形式の均一なリソース識別子です[4]。
At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) [2] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names.
現在、このアプリケーションに指定されているDDDSデータベースは1つだけです。「動的委任発見システム（DDDS）パート3：DNSデータベース」（RFC 3403）[2]は、NAPTR DNSリソースレコードを使用して書き換えルールを含めるDDDSデータベースを指定します。このデータベースのキーは、ドメイン名としてエンコードされています。
The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name according to this algorithm:
Enumアプリケーションの最初のよく知られているルールの出力は、E.164数を引いたものです。これをこのデータベースの一意のキーに変換するために、このアルゴリズムに従って文字列がドメイン名に変換されます。
1. Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the Key "+442079460148". This step would simply remove the leading "+", producing "442079460148".
1. 数字を除き、すべての文字を削除します。たとえば、最初によく知られているルールは、キー「442079460148」を作成しました。このステップは、単に主要な「」を削除し、「442079460148」を生成します。
2. Put dots (".") between each digit. Example: 4.4.2.0.7.9.4.6.0.1.4.8
2. 各数字の間にドット（ "。"）を置きます。例：4.4.2.0.7.9.4.6.0.1.4.8
3. Reverse the order of the digits. Example: 8.4.1.0.6.4.9.7.0.2.4.4
3. 数字の順序を逆にします。例：8.4.1.0.6.4.4.9.7.0.2.4.4
4. Append the string ".e164.arpa" to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa
4. 文字列「.e164.arpa」を最後に追加します。例：8.4.1.0.6.4.4.9.7.0.2.4.4.E164.ARPA
This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS.
このドメイン名は、最終結果を含む可能性のあるNAPTRレコードを要求するために使用されるか、フラグフィールドが空白の場合、DNSからドメイン名の形で新しいキーを生成します。
Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information. It is also easy to contemplate an ENUM enhanced nameserver that understand the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret Flag values and use that information to include appropriate resource 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 RFC 3403 [2], Section 4.2 for more information on NAPTR records and the Additional Information section of a DNS response packet.
一部の名前サーバーの実装は、特定のDNS応答の追加情報セクションに挿入されたアイテムについてインテリジェントになろうとします。たとえば、Bindは、パケットに1つをエンコードするたびに、ドメインに対して権威あるかどうかを判断しようとします。もしそうなら、パケットが許容される最大長に達するまで、そのドメインに対して見つけたレコードを答えの追加情報セクションに挿入します。したがって、クライアントがこの追加情報を確認することは潜在的に役立ちます。また、提供されているNAPTRレコードの実際の内容を理解しているEnum Enhanced NameServerを、より適切な情報を応答の追加情報セクションに挿入することも簡単です。したがって、DNSサーバーはフラグ値を解釈し、その情報を使用して、DNSパケットの追加情報部分に適切なリソースレコードを含めることができます。クライアントは追加情報を確認することをお勧めしますが、そうする必要はありません。NAPTRレコードの詳細とDNS応答パケットの追加情報セクションについては、RFC 3403 [2]、セクション4.2の追加情報処理セクションを参照してください。
The character set used to encode the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain-names.
置換式のエンコードに使用される文字セットはUTF-8です。許可された入力文字は、E.164番号のどこにでも許可されているすべての文字です。鍵に入れることが許可されている文字は、現在DNSドメイン名で定義されている文字です。
This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [4]. See RFC 3404 [3].
このデータベースには、DDDSアルゴリズムが終了したときに信号を送信するフラグを含むフィールドが含まれています。現時点では、「u」というフラグが1つだけです。これは、このルールが最後のルールであり、ルールの出力がURIであることを意味します[4]。RFC 3404 [3]を参照してください。
If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.
クライアントが未知のフラグでレコードに遭遇した場合、それを無視して次のルールに移動する必要があります。フラグはフィールドに配置された解釈を制御できるため、このテストは任意の順序よりも優先されます。
A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target.
新規旗は、レコックスが特定のターゲットと一致するかどうかを判断することが不可能になるように、regexpおよび/または交換場の解釈を変更する可能性があります。
If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new Key in the DDDS loop (i.e., causing the client to query for new NAPTR records at the domain-name that is the result of this Rule).
このフラグが存在しない場合、このルールは非末端です。ルールが非端末の場合、クライアントはこの書き換えルールによって生成されたキーをDDDSループの新しいキーとして使用する必要があります（つまり、クライアントはこのルールの結果であるドメイン名で新しいNAPTRレコードをクエリします。）。
Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record.
このアプリケーションのサービスパラメータは、次の形式を取り、NAPTRレコードのサービスフィールドにあります。
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by 1 or more or more Enumservices which indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.
言い換えれば、非オプションの「E2U」（記録衝突を緩和するために列挙のみを書き換えるためにルールを書き直すために使用される）に続いて、特定のエンドポイントが提供する機能のクラスを示す1つ以上のencresvicesが続きます。各Enumserviceは、最初の「文字」で示されます。
Enumservice specifications contain the functional specification (i.e., what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the Enumservice and URI schemes or protocols. The mapping, if any, must be made explicit in the specification for the Enumservice itself. A registration of a specific Type also has to specify the Subtypes allowed.
Enumservice仕様には、機能仕様（つまり、使用できるもの）、有効なプロトコル、および返される可能性のあるURIスキームが含まれています。EnumserviceおよびURIスキームまたはプロトコルの文法には、テキスト文字列「タイプ」または「サブタイプ」の間に暗黙のマッピングがないことに注意してください。マッピングは、もしあれば、Enumservice自体の仕様で明示的にする必要があります。特定のタイプの登録も、許可されているサブタイプを指定する必要があります。
The only exception to the registration rule is for Types and Subtypes used for experimental purposes, and those are to start with the facet "X-". These elements are unregistered, experimental, and should be used only with the active agreement of the parties exchanging them.
登録ルールの唯一の例外は、実験目的で使用されるタイプとサブタイプのことであり、それらはファセット「X-」から始めることです。これらの要素は未登録の実験的であり、それらを交換する当事者の積極的な合意でのみ使用する必要があります。
The registration mechanism is specified in Section 3.
登録メカニズムはセクション3で指定されています。
There has been some confusion over what exactly an ENUM Resolver returns and what relation that has to the 'Note 1' section in RFC 3402. On first reading it seems as though it might be possible for an ENUM Resolver to return two Rules.
Enum Resolverが正確にどのように戻っているのか、RFC 3402の「Note 1」セクションとの関係については、いくつかの混乱がありました。最初の読み取りでは、Enum Resolverが2つのルールを返す可能性があるようです。
The ENUM algorithm always returns a single rule. Specific applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm.
enumアルゴリズムは常に単一のルールを返します。特定のアプリケーションには、複数の結果または速度選択を提示できるアプリケーション固有の知識または施設がある場合がありますが、これらはアルゴリズムの動作を変更することはありません。
As specified in the ABNF found in Section 2.4.2, an 'enumservice' is made up of 'types' and 'subtypes'. For any given 'type', the allowable 'subtypes' must be specified in the registration. There is currently no concept of a registered 'subtype' outside the scope of a given 'type'. Thus the registration process uses the 'type' as its main key within the IANA Registry. While the combination of each type and all of its subtypes constitutes the allowed values for the 'enumservice' field, it is not sufficient to simply document those values. A complete registration will also include the allowed URI schemes, a functional specification, security considerations, intended usage, and any other information needed to allow for interoperability within ENUM. In order to be a registered ENUM Service, the entire specification, including the template, requires approval by the IESG and publication of the Enumservice registration specification as an RFC.
セクション2.4.2で見つかったABNFで指定されているように、「Enumservice」は「タイプ」と「サブタイプ」で構成されています。任意の「タイプ」については、登録時に許容される「サブタイプ」を指定する必要があります。現在、特定の「タイプ」の範囲外に登録された「サブタイプ」の概念はありません。したがって、登録プロセスは、「タイプ」をIANAレジストリ内の主要なキーとして使用します。各タイプとそのすべてのサブタイプの組み合わせは、「Enumservice」フィールドの許容値を構成しますが、これらの値を単純に文書化するだけでは不十分です。完全な登録には、許可されたURIスキーム、機能仕様、セキュリティに関する考慮事項、意図された使用法、および列挙内の相互運用性を可能にするために必要なその他の情報も含まれます。登録済みのenumサービスになるために、テンプレートを含む仕様全体には、IESGによる承認と、RFCとしてのEnumservice登録仕様の公開が必要です。
Service registration proposals are all expected to conform to various requirements laid out in the following sections.
サービス登録提案はすべて、以下のセクションに記載されているさまざまな要件に準拠することが期待されています。
A registered Enumservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it.
登録されたEnumserviceは、1つのNaptrリソースレコードを別のNaptrリソースレコードを選択する際に、選択メカニズムとして機能できる必要があります。つまり、登録は、そのまさにNAPTRレコードを使用するときに予想されることを指定しなければならないことを意味します。
Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, and, when needed, other information which will have to be transferred into the URI resolution process itself (LDAP Distinguished Names, transferring of the AUS into the resulting URI, etc).
具体的には、登録済みのeNumserviceは、Enumserviceに使用される可能性のあるURIスキームを指定する必要があります。必要に応じて、URI解像度プロセス自体に転送する必要がある他の情報（ldap distinguished names、ausの転送を指定する必要があります。結果のURIなど）。
An Enumservice MUST be unique in order to be useful as a selection criteria. Since an Enumservice is made up of a type and a type-dependent subtype, it is sufficient to require that the 'type' itself be unique. The 'type' MUST be unique, conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use.
Enumserviceは、選択基準として役立つためにユニークでなければなりません。Enumserviceはタイプとタイプ依存のサブタイプで構成されているため、「タイプ」自体が一意であることを要求するだけで十分です。「タイプ」は一意であり、セクション2.4.2で指定されたABNFに準拠している必要があり、実験的で私的な使用のために予約されているファセット「X-」から始めてはなりません。
The subtype, being dependent on the type, MUST be unique within a given 'type'. It must conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use. The subtype for one type MAY be the same as a subtype for a different registered type but it is not sufficient to simply reference another type's subtype. The function of each subtype must be specified in the context of the type being registered.
タイプに依存するサブタイプは、特定の「タイプ」内で一意でなければなりません。セクション2.4.2で指定されているABNFに準拠する必要があり、実験的なプライベート使用のために予約されているファセット「X」から始めてはなりません。1つのタイプのサブタイプは、異なる登録型のサブタイプと同じかもしれませんが、別のタイプのサブタイプを単純に参照するだけでは不十分です。各サブタイプの関数は、登録されているタイプのコンテキストで指定する必要があります。
An analysis of security issues is required for all registered Enumservices. (This is in accordance with the basic requirements for all IETF protocols.)
すべての登録済みエンムサービスには、セキュリティ問題の分析が必要です。（これは、すべてのIETFプロトコルの基本要件に従っています。）
All descriptions of security issues must be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this Enumservice" must not be confused with "the security issues associated with this Enumservice have not been assessed".
セキュリティの問題のすべての説明は、登録ツリーに関係なく、可能な限り正確でなければなりません。特に、「このenyserviceに関連するセキュリティの問題はない」という声明は、「このencresviceに関連するセキュリティの問題が評価されていない」と混同してはなりません。
There is no requirement that an Enumservice must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of an Enumservice.
Enumserviceが安全であるか、完全にリスクがないことを要求する必要はありません。それにもかかわらず、Enumserviceの登録では、すべての既知のセキュリティリスクを特定する必要があります。
The security considerations section of all registrations is subject to continuing evaluation and modification.
すべての登録のセキュリティ上の考慮事項セクションは、継続的な評価と変更の対象となります。
Some of the issues that should be looked at in a security analysis of an Enumservice are:
Enumserviceのセキュリティ分析で検討すべき問題のいくつかは、次のとおりです。
1. Complex Enumservices may include provisions for directives that institute actions on a user's resources. In many cases provision can be made to specify arbitrary actions in an unrestricted fashion which may then have devastating results. Especially if there is a risk for a new ENUM lookup, and because of that an infinite loop in the overall resolution process of the E.164.
1. 複雑なEnumservicesには、ユーザーのリソースに関するアクションを制定する指令に関する規定が含まれる場合があります。多くの場合、無制限の方法で任意のアクションを指定するために提供することができます。特に、新しい列挙ルックアップのリスクがあり、そのため、E.164の全体的な解像度プロセスにおける無限ループがある場合。
2. Complex Enumservices may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information that either facilitates a subsequent attack or else violates the users privacy in some way.
2. 複雑なEnumservicesには、直接有害ではないが、その後の攻撃を容易にするか、何らかの方法でユーザーにプライバシーに違反する情報の開示をもたらす可能性のある行動を起こす指令の規定が含まれる場合があります。
3. An Enumservice might be targeted for applications that require some sort of security assurance but do not provide the necessary security mechanisms themselves. For example, an Enumservice could be defined for storage of confidential security services information such as alarm systems or message service passcodes, which in turn require an external confidentiality service.
3. Enumserviceは、何らかのセキュリティ保証を必要とするが、必要なセキュリティメカニズム自体を提供しないアプリケーションの対象となる場合があります。たとえば、アラームシステムやメッセージサービスパスコードなどの機密セキュリティサービス情報を保存するために、Enumserviceを定義できます。これには、外部の機密性サービスが必要です。
Proposals for Enumservices registrations MUST be published as one of the following documents; RFC on the Standards Track, Experimental RFC, or as a BCP.
Enumservices登録の提案は、以下のドキュメントのいずれかとして公開する必要があります。標準トラック、実験RFC、またはBCPとしてのRFC。
IANA will retain copies of all Enumservice registration proposals and "publish" them as part of the Enumservice Registration tree itself.
IANAは、すべてのEnumservice登録提案のコピーを保持し、Enumservice登録ツリー自体の一部としてそれらを「公開」します。
Provided that the Enumservice has obtained the necessary approval, and the RFC is published, IANA will register the Enumservice and make the Enumservice registration available to the community in addition to the RFC publication itself.
Enumserviceが必要な承認を取得し、RFCが公開されている場合、IANAはEnumserviceを登録し、RFCの出版物自体に加えてコミュニティが利用できるようにします。
Enumservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI: "ftp://ftp.iana.org/assignments/enum-services/".
Enumservice登録はIANAリポジトリで公開され、次のURIで匿名FTPを介して利用可能になります： "ftp://ftp.iana.org/assignments/enum-services/"。
Change control of Enumservices stay with the IETF via the RFC publication process. Especially, Enumservice registrations may not be deleted; Enumservices which are no longer believed appropriate for use can be declared OBSOLETE by publication of a new RFC and a change to their "intended use" field; such Enumservice will be clearly marked in the lists published by IANA.
Enumservicesの制御を変更するRFC出版プロセスを介してIETFにとどまります。特に、Enumservice登録は削除されない場合があります。使用に適していないと考えられているEnumservicesは、新しいRFCの公開と「意図した使用」フィールドへの変更により、時代遅れと宣言できます。このようなEnumserviceは、IANAが公開したリストに明確にマークされます。
Enumservice Type:
Enumserviceタイプ：
Enumservice Subtype(s):
Enumservice subtype（s）：
URI Scheme(s):
URIスキーム：
Functional Specification:
機能仕様：
Security considerations:
セキュリティ上の考慮事項：
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
意図された使用法：（一般的な、限られた使用または時代遅れの1つ）
Author:
著者：
Any other information that the author deems interesting:
著者が面白いと思うその他の情報：
Note: In the case where a particular field has no value, that field is left completely blank, especially in the case where a given type has no subtypes.
注：特定のフィールドに値がない場合、特に特定のタイプにサブタイプがない場合、そのフィールドは完全に空白のままになります。
The examples below use theoretical services that contain Enumservices which might not make sense, but that are still used for educational purposes. For example, the protocol used is in some cases exactly the same string as the URI scheme. That was the specification in RFC 2916, but this 'default' specification of an Enumservice is no longer allowed. All Enumservices need to be registered explicitly by the procedure specified in section Section 3.
以下の例では、意味をなさないかもしれないが、教育目的で使用されているencresvicesを含む理論サービスを使用しています。たとえば、使用されるプロトコルは、場合によってはURIスキームとまったく同じ文字列です。これはRFC 2916の仕様でしたが、encerviceのこの「デフォルト」仕様は許可されなくなりました。セクション3で指定された手順により、すべてのEnumservicesを明示的に登録する必要があります。
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" . NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .
$ origin 3.8.0.0.6.9.2.3.6.1.4.4.E164.ARPA。naptr 10 100 "u" "e2u sip" "！^。*$！sip：info@example.com！"。Naptr 10 101 "U" "E2U H323" "！^。*$！H323：info@example.com！"。NAPTR 10 102 "U" "E2U MSG" "！^。*$！mailto：info@example.com！"。
This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the tokens "sip", "h323", and "msg" are Types registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names.
これは、ドメイン3.8.0.0.6.9.2.3.6.1.4.4.E164.ARPAが説明しています。SIPによって、次にH.323を介して音声を介して、3番目はメッセージングのSMTPによって連絡することが望ましい。トークンの「SIP」、「H323」、および「MSG」はIANAに登録されているタイプであり、同じ名前のプロトコルまたはURIスキームとの暗黙的なつながりがないことに注意してください。
In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (specified by the URI schemes sip, h323 and mailto) to know what node to contact for each.
すべての場合において、解決プロセスの次のステップは、各プロトコルの解像度メカニズムを使用して（URIスキームSIP、H323、およびMailToで指定）、それぞれに接触するノードを知ることです。
RFC 2916 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions to be provided by the IAB. The domain was delegated according to those instructions. Names within this zone are to be delegated to parties according to the ITU-T Recommendation E.164. The names allocated should be hierarchic in accordance with ITU-T Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.
RFC 2916（このドキュメントが置き換えられた）は、IAABが提供する指示に従ってE164.ARPAドメインを委任するようにIANAに要求しました。ドメインは、これらの指示に従って委任されました。このゾーン内の名前は、ITU-Tの推奨事項E.164に従って当事者に委任されます。割り当てられた名前は、ITU-Tの推奨事項E.164に従って階層的である必要があり、コードはその推奨に従って割り当てる必要があります。
IAB is to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa is to change, as ITU-T TSB has an operational working relationship with this technical contact which needs to be reestablished.
IABは、ITU-T TSBが再確立する必要があるこの技術的接触と運用上の作業関係を持っているため、ドメインE164.ARPAの技術的な連絡先が変更されるため、ITU-T TSBと調整します。
Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert.
ゾーンE164.ARPAの代表団（E164.ARPAの委任されたドメインの代表団ではない）は、専門家のレビュー後に行う必要があり、IESGは指定された専門家を任命します。
IANA has created a registry for Enumservices as specified in Section 3. Whenever a new Enumservice is registered by the RFC process in the IETF, IANA is at the time of publication of the RFC to register the Enumservice and add a pointer to the RFC itself.
IANAは、セクション3で指定されているように、Enumservicesのレジストリを作成しました。IETFのRFCプロセスによって新しいEnumserviceが登録されるたびに、IANAはRFCの公開時にEnamserviceを登録し、RFC自体へのポインターを追加します。
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kind of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.
EnumはDNSを使用しているため、現在の形式では不安定なプロトコルであるため、データが本物であることを保証するメカニズムはありません。列挙はグローバルインターネットに展開されるため、さまざまな種類の攻撃の一般的なターゲットになることが期待されており、基礎となるDNSインフラストラクチャを攻撃することは、Enumサービス自体を攻撃する1つの方法です。
There are multiple types of attacks that can happen against DNS that ENUM implementations should be aware of. The following threats are taken from Threat Analysis Of The Domain Name System [10]:
DNSに対して発生する可能性のある攻撃には、実装が認識されるべき攻撃には複数のタイプがあります。次の脅威は、ドメイン名システムの脅威分析から取られています[10]：
Packet Interception Some of the simplest threats against DNS are various forms of packet interception: monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so forth. In any of these scenarios, the attacker can simply tell either party (usually the resolver) whatever it wants that party to believe. While packet interception attacks are far from unique to DNS, DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network.
パケットインターセプトDNに対する最も単純な脅威のいくつかは、さまざまな形式のパケット傍受です：中間の攻撃、リクエストに応じて盗聴したリクエストと、リゾルバーへの実際の応答を打ち負かすスプーフィングされた応答など。これらのシナリオのいずれかで、攻撃者は、その当事者に信じたいことを何でも、どちらの当事者（通常はリゾルバー）を伝えることができます。パケットインターセプト攻撃はDNSとはほど遠いものとはほど遠いものの、DNSのクエリまたは応答全体を単一の署名しない、暗号化されていないUDPパケットで送信するという通常の動作により、これらの攻撃は、共有またはトランジットネットワークでパケットを傍受する機能を備えた悪人にとって特に簡単になります。。
ID Guessing and Query Prediction Since the ID field in the DNS header is only a 16-bit field and the server UDP port associated with DNS is a well-known value, there are only 2**32 possible combinations of ID and client UDP port for a given client and server. Thus it is possible for a reasonable brute force attack to allow an attacker to masquerade as a trusted server. In most respects, this attack is similar to a packet interception attack except that it does not require the attacker to be on a transit or shared network.
ID推測とクエリ予測DNSヘッダーのIDフィールドは16ビットフィールドであり、DNSに関連付けられているサーバーUDPポートはよく知られているため、IDとクライアントのUDPポートの組み合わせが2 ** 32しかありません特定のクライアントとサーバー用。したがって、合理的なブルートフォース攻撃により、攻撃者が信頼できるサーバーを装ってもらうことができます。ほとんどの点で、この攻撃は、攻撃者がトランジットまたは共有ネットワーク上にいる必要がないことを除いて、パケット傍受攻撃に似ています。
Name-based Attacks Name-based attacks use the actual DNS caching behavior as a tool to insert bad data into a victim's cache, thus potentially subverting subsequent decisions based on DNS names. Most examples occur with CNAME, NS and DNAME Resource Records as they redirect a victim's query to another location. The common thread in all of these attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker's choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks.
名前ベースの攻撃名ベースの攻撃は、実際のDNSキャッシュ動作を、悪いデータを被害者のキャッシュに挿入するツールとして使用し、DNS名に基づいてその後の決定を潜在的に破壊する可能性があります。ほとんどの例は、被害者の質問を別の場所にリダイレクトするため、CNAME、NS、およびDNAMEリソースレコードで発生します。これらのすべての攻撃の一般的なスレッドは、応答メッセージが攻撃者が攻撃者の選択の任意のDNS名を導入し、攻撃者がそれらの名前に関連付けられているというさらなる情報を提供することを可能にすることです。被害者がそれらの名前に関連付けられたデータの知識をよりよく持っていない限り、被害者はこのクラスの攻撃に対して防御するのに苦労するでしょう。
Betrayal By A Trusted Server Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent. Many client machines are only configured with stub resolvers, and use trusted servers to perform all of their DNS queries on their behalf. In many cases the trusted server is furnished by the user's ISP and advertised to the client via DHCP or PPP options. Besides accidental betrayal of this trust relationship (via server bugs, successful server break-ins, etc), the server itself may be configured to give back answers that are not what the user would expect (whether in an honest attempt to help the user or to further some other goal such as furthering a business partnership between the ISP and some third party).
信頼できるサーバーによる裏切りパケットインターセプト攻撃の別のバリエーションは、偶然であろうと意図によって、それほど信頼できないことが判明した信頼できるサーバーです。多くのクライアントマシンは、スタブリゾルバーでのみ構成されており、信頼できるサーバーを使用して、すべてのDNSクエリを代表して実行します。多くの場合、信頼できるサーバーはユーザーのISPによって提供され、DHCPまたはPPPオプションを介してクライアントに宣伝されます。この信頼関係の偶発的な裏切り（サーバーバグ、サーバーの侵入などを成功させるなど）に加えて、サーバー自体は、ユーザーが期待するものではない回答を返すように構成されている場合があります（ユーザーを支援する正直な試みであろうと、ISPといくつかのサードパーティの間のビジネスパートナーシップを促進するなど、他の目標を促進するため）。
Denial of Service As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks. DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets.
サービスの拒否任意のネットワークサービス（実際、談話の領域におけるあらゆる種類のほとんどすべてのサービス）と同様に、DNSはサービス拒否攻撃に対して脆弱です。DNS応答パケットはDNSクエリパケットよりも大幅に長くなる傾向があるため、DNSサーバーはサービスアンプの拒否として使用されるリスクもあります。
Authenticated Denial of Domain Names The existence of RR types whose absence causes an action other than immediate failure (such as missing MX and SRV RRs, which fail over to A RRs) constitutes a real threat. In the specific case of ENUM, even the immediate failure of a missing RR can be considered a problem as a method for changing call routing policy.
ドメインの認証された拒否は、即時の障害（RRSに失敗するMXやSRV RRSなど）以外のアクションを引き起こすRRタイプの存在に名前を付けます。実際の脅威は構成されます。列挙の特定のケースでは、欠落しているRRの即時失敗でさえ、コールルーティングポリシーを変更する方法として問題と見なすことができます。
Because of these threats, a deployed ENUM service SHOULD include mechanisms which ameliorate these threats. Most of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC [8] once it is deployed. Others, such and Denial Of Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV and A records).
これらの脅威のため、展開された列挙サービスには、これらの脅威を改善するメカニズムを含める必要があります。これらの脅威のほとんどは、展開されたらDNSSEC [8]などのメカニズムを介してデータの信頼性を検証することで解決できます。その他のサービス攻撃や拒否攻撃は、データ認証によって解決することはできません。これらの脅威には、NAPTRルックアップ自体だけでなく、サービスに必要なさまざまなレコード（NS、MX、SRV、Aレコードなど）も含まれることを覚えておくことが重要です。
Even if DNSSEC is deployed, a service that uses ENUM for address translation should not blindly trust that the peer is the intended party as all kind of attacks against DNS can not be protected against with DNSSEC. A service should always authenticate the peers as part of the setup process for the service itself and never blindly trust any kind of addressing mechanism.
DNSSECが展開されたとしても、DNSに対するあらゆる種類の攻撃をDNSSECで保護できないため、アドレス変換に列挙を使用するサービスは、ピアが意図されたパーティーであることを盲目的に信頼するべきではありません。サービスは、サービス自体のセットアッププロセスの一部として常にピアを認証し、いかなる種類のアドレス指定メカニズムを盲目的に信頼しないでください。
Finally, as an ENUM service will be implementing some type of security mechanism, software which implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, unknown RRs, etc.
最後に、Enumサービスが何らかのタイプのセキュリティメカニズムを実装するため、列挙を実装するソフトウェアは、DNSSECおよびその他の標準化されたDNSセキュリティ応答を受信するために準備する必要があります。
The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [9]) must therefore be done very carefully.
DNSでのキャッシュは、変更の伝播時間を変更すると、変更されたゾーン内のNAPTRレコードの生活時間と同じ時間がかかります。したがって、IPアドレスが雇用のためのIPアドレスである環境でこれを使用することは、したがって、DHCP [9]を使用する場合）に非常に慎重に行う必要があります。
There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name-translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.
コールルーティングと番号/名前翻訳サービスの複数のプロバイダーがある国（およびその他の番号付け環境）があります。これらの領域では、ユーザーまたはユーザーの推定エージェントを許可するシステムは、ルーティングまたはサプライヤー情報を変更することを許可します。このような環境は、変更を要求するそれらを要求し、それらの変更を許可するための適切なメカニズムを備えて設計する必要があります。
A large amount of Security Issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the Enumservice used, as specified in Section 3.1.3.
大量のセキュリティ問題は、解像度プロセス自体、およびDDDSメカニズムによって生成されるURIの使用に関係しています。これらは、セクション3.1.3で指定されているように、使用されたEnumserviceの登録で指定する必要があります。
Support and ideas leading to RFC 2916 have come from people at Ericsson, Bjorn Larsson and the group which implemented this scheme in their lab to see that it worked. Input has also arrived from ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Enumservice Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh.
RFC 2916につながるサポートとアイデアは、エリクソン、ビョルンラーソン、およびこのスキームを実験室で実装して機能したことを確認したグループから生まれました。ITU-T SG2（番号付け、ルーティング、グローバルモビリティ、およびEnumservice定義）、IETFの列挙ワーキンググループであるJohn KlensinおよびLeif Sunnegardhのワーキングパーティー（ナンバリング、ルーティング、グローバルモビリティ、およびエインムサービス定義）からも入力が届きました。
This update of RFC 2916 is created with specific input from: Randy Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim Stralmark, Robert Walter and James Yu.
RFC 2916のこのアップデートは、ランディブッシュ、デビッドコンラッド、リチャードヒル、ジョンピーターソン、ジムリード、ジョアキムストラルマーク、ロバートウォルター、ジェームズユーの特定の入力で作成されています。
Part from clarifications in the text in this document, the major changes are two:
このドキュメントのテキストの説明からの部分、主要な変更は2つです。
The document uses an explicit DDDS algorithm, and not only NAPTR resource records in an "ad-hoc" mode. In reality this doesn't imply any changes in deployed base of applications, as the algorithm used for ENUM resolution is exactly the same.
このドキュメントは、「アドホック」モードでNAPTRリソースレコードだけでなく、明示的なDDDSアルゴリズムを使用します。実際には、これは、列挙解像度に使用されるアルゴリズムがまったく同じであるため、展開されたアプリケーションのベースの変更を意味するものではありません。
The format of the service field has changed. The old format was of the form "example+E2U", while the new format is "E2U+example". Reason for this change have to with the added subtypes in the enumservice, the ability to support more than one enumservice per NAPTR RR, and a general agreement in the IETF that the main selector between different NAPTR with the same owner (E2U in this case) should be first.
サービスフィールドの形式が変更されました。古い形式は「例E2Uの例」で、新しい形式は「E2Uの例」です。この変更の理由は、Enumserviceに追加されたサブタイプ、NAPTR RRごとに複数のEnumserviceをサポートする機能、およびIETFでの一般的な合意が必要です。最初にする必要があります。
[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] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[2] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[3] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）解像度アプリケーション」、RFC 3404、2002年10月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[5] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[5] ITU-T、「国際公開通信番号計画」、推奨事項E.164、1997年5月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] EastLake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[9] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
[10] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析」、2004年4月、進行中の作業。
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
EMail: paf@cisco.com
URI: http://www.cisco.com
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling Verisign 21345 Ridgetop Circle Sterling、VA 20166 US
Email: michael@verisignlabs.com
URI: http://www.verisignlabs.com
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。