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)
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）インターネット協会（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）の使用について説明します。より具体的には、どのようにDNSは、一つE.164番号に接続された利用可能なサービスを識別するために使用することができます。それは具体的には、読まずに、この文書を読んで理解することは不可能であることに注意することが非常に重要であるRFC 3401で指定されたドキュメントシリーズで見られるダイナミックな委譲発見システム（DDDS）アプリケーションの仕様に沿ってそれを持って来るためにRFC 2916廃止します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）の使用について説明します。より具体的には、どのようにDNSは、一つE.164番号に接続された利用可能なサービスを識別するために使用することができます。それは、具体的には、RFC 3401で指定されたドキュメントシリーズに見られるダイナミックな委譲発見システム（DDDS）アプリケーション仕様に沿ってそれを持って来るためにRFC 2916を廃止[6]。 [6] RFC 3401で説明した文書を読まずに、この文書を読んで理解することは不可能であることに注意することが非常に重要です。
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.
国際フォーマットの国際公共電気通信番号の変換により、[5]、このドキュメントのE.164番号の範囲内と呼ばれる、DNS名および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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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に見出さDDDSアルゴリズム仕様に見られる語彙から取られる[2]。
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パケットの回答セクションで返されるレコードの順序を保証しないためです。典型的な正規表現がされるため、ほとんどのENUMの場合、これは問題ではありません「！^。* $！」以来、最初のクエリは、多くの場合、端末のルールになります。
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つの異なるルールが所与のアプリケーション固有の文字列に一致する両方の他の例（非末端規則）があります。各ルールは、アルゴリズム内で評価されたように、一方が他方よりもAUSのより重要な部分を一致させることができます。例えば、非ターミナルNAPTRを使用して渡された数値セットは、いくつかのプライベートダイヤルプラン - 特定のゾーンに送信されます。そのゾーン内で一致するものが全体の交換のためであり、サービスは、関連するSIPである場合、まず、SIP-特定のルールが使用されると述べている2つのルールがあります。しかし、他のルールは、ルールが部門レベルのサービスを意味していること、いくつかの他のサービス（インスタントメッセージング）のためにそれを指定して、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ホルダーからの提案です。 ENUMを実装したクライアントは、受注フィールドに従わなければなりませんが、単にクライアントコンテキスト固有の選択方法の一環として、「助言に」プリファレンス値を取ることができます。
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]に見られる規則および要件に従ってENUM 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番号で考えるもので終わることができます。これは、例えば、ユーザーがユーザーインターフェイスの数をmistypesとき、アプリケーションは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.
このアプリケーションのための第一のウェル既知のルールは、アイデンティティルールです。このルールの出力は、入力と同じです。 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の「absoluteURIでの生産に応じてその絶対形態[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データベースは、このアプリケーションのために指定されています。 「ダイナミックな委譲発見システム（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.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.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符号化するたびに、それがドメインの権威であるかどうかを決定しようとします。もしそうであれば、それは、パケットが許可された最大長さに達するまで、それは答えの追加情報セクションに、そのドメインの見つかったAレコードを挿入します。クライアントは、この追加情報を確認することがゆえ潜在的に有用です。サービスを提供しているNAPTRレコードの実際の内容を理解し、応答の追加情報セクションに、より適切な情報を挿入するENUM強化ネームサーバを熟考することも容易です。このように、DNSサーバは、フラグ値を解釈し、DNSパケットの追加情報部分に適切なリソースレコードを含めるようにその情報を使用することができます。クライアントは、追加情報を確認することをお勧めしますが、その必要はありません。 NAPTRレコードの詳細については、セクション4.2およびDNS応答パケットの追加情報セクション、[2] RFC 3403の追加情報の処理を参照してください。
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アルゴリズムが終了したときに信号旗が含まれているフィールドが含まれています。この時だけ1つのフラグ、「U」で、定義されています。これは、このルールが最後のものであるとルールの出力は、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.
新規フラグは、レコードは、所与の目標と一致したかどうかを決定することは不可能であるように、正規表現および/または置換フィールドの解釈を変えるかもしれません。
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).
このフラグが存在しない場合、このルールは、非末端です。ルールが非ターミナルであれば、クライアントは（つまり、クライアントは、この規則の結果であるドメイン名で新しいNAPTRレコードを照会させDDDSループで新しいキーとして、この書き換えルールによって生成キーを使用する必要があります）。
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以上以上Enumservices続い（レコードのみの衝突を緩和するためにルールを書き換えENUMを示すために使用されます）。各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リゾルバを返し、どのような最初のENUMリゾルバは、2つのルールを返すすることは可能かもしれないかのようにそれはそう読んでRFC 3402の「注1」のセクションを持っている関係を正確に何の上にいくつかの混乱がありました。
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内の相互運用性を確保するために必要なその他の情報が含まれます。テンプレートを含む登録ENUMサービス、明細書全体、であるために、RFCとしてEnumservice登録仕様のIESGと出版による承認を必要とします。
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から別のNAPTRリソースレコードを選択する際に選択機構として機能することができなければなりません。これは、登録は、非常にNAPTRレコードを使用して、それを使用することの結果であるURI時に期待されているものを指定しなければならないことを意味します。
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識別名、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.)
セキュリティ問題の分析は、すべての登録Enumservicesに必要です。 （これは、すべての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".
セキュリティ問題のすべての記述は、登録木にかかわらず、可能な限り正確でなければなりません。具体的には、「このEnumserviceに関連したセキュリティ上の問題が」存在しないという声明は「このEnumserviceに関連するセキュリティ上の問題が評価されていない」と混同してはいけません。
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は、ユーザーのリソースに対してアクションを提起ディレクティブの規定を含んでいてもよいです。多くの場合、引当金は、壊滅的な結果を有することができる無制限の方法で任意のアクションを指定するために行うことができます。そこに新しいENUM検索のリスクである、と理由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はRFCの公表自体に加えて、Enumserviceを登録し、地域社会へのEnumservice登録が利用できるようになります。
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の公表とその「意図された使用」フィールドへの変更によってOBSOLETEと宣言することができます。このようEnumserviceは明らかにIANAによって公表リストにマークされます。
Enumservice Type:
Enumserviceタイプ：
Enumservice Subtype(s):
Enumserviceサブタイプ（S）：
URI Scheme(s):
URIスキーム（S）：
Functional Specification:
機能仕様：
Security considerations:
セキュリティの考慮事項：
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
意図している用法：（COMMON、限定使用の一つまたはOBSOLETE）
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.
理にかなっていない可能性がありますEnumservicesが含まれている使用理論的なサービスを以下の例が、それはまだ、教育目的のために使用されています。例えば、使用されるプロトコルは、いくつかの場合にはURIスキームと全く同じ文字列です。これは、RFC 2916で仕様だったが、Enumserviceのこの「デフォルト」の指定はできなくなりました。すべてのEnumservicesは、セクションセクション3で指定された手順によって明示的に登録する必要があります。
$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 +一口" "^ * $一口：！。！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ことが記載されています。好ましくは、メッセージング用の音声のための、及び第三SMTPによって第二H.323を介して、SIPによって接触されます。トークン「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は、（この文書は置き換えられている）IABによって提供される指示に従って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.
第3節で指定されているIANAは新しいEnumserviceがIETFでRFCプロセスによって登録されるたびに、IANAはEnumserviceを登録し、RFC自体へのポインタを追加するRFCの発行時点のものでありEnumservicesのレジストリを作成しました。
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を使用するように、一方がバック取得データが真正であることを確保するためのメカニズムはありません。 ENUMは、グローバルなインターネット上で展開されているとして、攻撃の様々な種類の人気のある標的であることが予想され、基盤となるDNSインフラストラクチャを攻撃することはENUMサービス自体を攻撃する一つの方法です。
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]:
ENUMの実装が知っておくべきこと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.
パケット傍受DNSに対する最も簡単な脅威のいくつかは、パケット傍受の様々な形である：サル・イン・ミドル攻撃を、その前後リゾルバ本当の応答を破って、偽装されたレスポンスと組み合わせるリクエストに盗聴。これらのシナリオのいずれにおいても、攻撃者は、単にそれは当事者が信じるようにすることを望んでいるものは何でも、いずれかの当事者（通常リゾルバ）を伝えることができます。パケット傍受攻撃がはるかにDNSに固有のですが、単一の符号なし、暗号化されていないUDPパケットにクエリ全体または応答を送信するDNSの通常の動作は、共有またはトランジットネットワーク上のパケットを傍受する能力を持つ任意の悪い男のためのこれらの攻撃は特に簡単になります。
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.
DNSヘッダ内のIDフィールドは、わずか16ビットのフィールドであり、DNSに関連するサーバUDPポートはよく知られている値であるのでID推測とクエリー予測、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 RRを欠落など）不在即時故障以外のアクションを起こすRRタイプの存在が現実的な脅威を構成します。 ENUMの特定の場合には、不足している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).
そのため、これらの脅威のため、展開ENUMサービスは、これらの脅威を改善するメカニズムを含むべきです。これらの脅威のほとんどは、それが展開されると、このようなDNSSEC [8]などのメカニズムを介してデータの真正性を検証することによって解決することができます。その他、などと、サービス拒否攻撃は、データ認証によって解決することはできません。これらの脅威はNAPTRだけでなく、自分自身でなく、（例えばNS、MX、SRVレコード）に有用であることがサービスのために必要な様々なレコードをルックアップの含めることを覚えておくことが重要です。
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が展開されている場合でも、アドレス変換のためのENUMを使用するサービスは、盲目的にピアがDNSSECで保護することができないDNSに対する攻撃のすべての種類として意図された当事者であることを信用してはいけません。サービスは常にサービス自体のセットアッププロセスの一部としてピアを認証し、盲目的メカニズムに対処する任意の種類を信用してはいけません。
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となど大きな応答、EDNS0シグナリング、未知のRRを含む他の標準化されたDNSのセキュリティレスポンスを受信するように準備しなければなりませんENUMを実装し、いくつかのセキュリティメカニズムのタイプ、ソフトウェアを実装するように
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-アドレスが雇うためのものである（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、作業部会1/2（番号、ルーティング、グローバルモビリティとEnumservice定義）からIETF、ジョン・クレンシンとレイフSunnegardhにおけるENUMワーキンググループが到着しました。
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.
ランディブッシュ、デビッド・コンラッド、リチャード・ヒル、ジョン・ピーターソン、ジム・リード、ヨアキムStralmark、ロバート・ウォルターとジェームズゆう：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アルゴリズムを使用し、ではありません。 ENUM解決するために使用されるアルゴリズムが正確に同じであるように実際にはこれは、アプリケーションの展開ベースの変更を意味するものではありません。
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における一般的な合意が同じ所有者と異なるNAPTR間の主なセレクタ（E2Uこの場合）最初にする必要があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[2] Mealling、M.、 "ダイナミックな委譲発見システム（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）第四部：統一資源識別子（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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8]イーストレイク、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]アトキンス、D.とR. Austeinと、「ドメインネームシステムの脅威分析」、進歩、2004年4月に作業。
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
パトリックFaltstromシスコシステムズ社Ledasa 273 71 Lovestadスウェーデン
EMail: paf@cisco.com URI: http://www.cisco.com
電子メール：paf@cisco.com URI：http://www.cisco.com
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
マイケル・メオーリングベリサイン21345 Ridgetopサークルスターリング、バージニア州20166米国
Email: michael@verisignlabs.com URI: http://www.verisignlabs.com
メール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。