RFC3761 日本語訳
3761 The E.164 to Uniform Resource Identifiers (URI) DynamicDelegation Discovery System (DDDS) Application (ENUM). P. Faltstrom,M. Mealling. April 2004. (Format: TXT=41559 bytes) (Obsoletes RFC2916) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Faltstrom Request for Comments: 3761 Cisco Systems, Inc. Obsoletes: 2916 M. Mealling Category: Standards Track VeriSign April 2004
Faltstromがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3761 シスコシステムズInc.は以下を時代遅れにします。 2916年のM.食事カテゴリ: 標準化過程ベリサイン2004年4月
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーションへのE.164(ENUM)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントはドメインネームシステム(DNS)のE.164番号の格納の使用について議論します。 より明確に、1つのE.164番号に関連づけられた営業品目を特定するのにどのようにDNSを使用できるか。 それは、RFC3401で指定されたドキュメントシリーズで見つけられたDynamic DelegationディスカバリーSystem(DDDS)アプリケーション仕様に沿ってそれを持って来るために明確にRFC2916を時代遅れにします。 RFC3401で議論したドキュメントを読まないでこのドキュメントを読んで、理解しているのが不可能であることに注意するのは非常に重要です。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 個人的なダイヤルするこれらのメカニズムの使用は計画されています。 . . . 3 1.3. ローカルの方針. . . . . . . . . . . . . . . 3 2の適用。 ENUMアプリケーション仕様. . . . . . . . . . . . . 4 2.1。 アプリケーションのユニークなストリング. . . . . . . . . . . . . . . . 5 2.2。 最初に、よく知られている規則. . . . . . . . . . . . . . . . . . 5 2.3。 出力. . . . . . . . . . . . . . . . . . . . . 5 2.4を予想しました。 有効なデータベース. . . . . . . . . . . . . . . . . . . . . 5 2.4.1。 旗。 . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2. サービスパラメタ。 . . . . . . . . . . . . . . . 7 2.5. 'Enum Resolver'を構成すること--.8 3。 Enumservices. . . . . . . . . . . 8のための登録メカニズム
Faltstrom & Mealling Standards Track [Page 1] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[1ページ]RFC3761を荒びきにすること。
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
3.1. 登録要件. . . . . . . . . . . . . . . . 8 3.1.1。 機能性要件。 . . . . . . . . . . . . 8 3.1.2. 要件. . . . . . . . . . . . . . . . 9 3.1.3を命名します。 セキュリティ要件. . . . . . . . . . . . . . . 9 3.1.4。 公表要件. . . . . . . . . . . . . 10 3.2。 登録手順。 . . . . . . . . . . . . . . . . . 10 3.2.1. IANA登録。 . . . . . . . . . . . . . . . . 10 3.2.2. 登録テンプレート。 . . . . . . . . . . . . . . 11 4. 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1。 例. . . . . . . . . . . . . . . . . . . . . . . . . 11 5。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 12 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 6.1. DNSセキュリティ。 . . . . . . . . . . . . . . . . . . . . . . 12 6.2. セキュリティをキャッシュします。 . . . . . . . . . . . . . . . . . . . . 14 6.3. セキュリティ. . . . . . . . . . . . . . . . . . 14 6.4にルート設定に電話をしてください。 URI解決セキュリティ. . . . . . . . . . . . . . . . . 15 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 8。 RFC2916.159以来の変化。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1。 引用規格。 . . . . . . . . . . . . . . . . . . 16 9.2. 有益な参照。 . . . . . . . . . . . . . . . . . 16 10. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 18
1. Introduction
1. 序論
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].
このドキュメントはドメインネームシステム(DNS)のE.164番号の格納の使用について議論します。 より明確に、1つのE.164番号に関連づけられた営業品目を特定するのにどのようにDNSを使用できるか。 それは、RFC3401[6]で指定されたドキュメントシリーズで見つけられたDynamic DelegationディスカバリーSystem(DDDS)アプリケーション仕様に沿ってそれを持って来るために明確にRFC2916を時代遅れにします。 RFC3401[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.
このドキュメントの中に呼ばれた国際的な形式[5]の、国際Public Telecommunication民数記の変化で、NS記録を通した代表団とNAPTR記録のような既存のDNSサービスのDNS名と使用へのE.164番号であり、人はどんなサービスがルックアップの過程による異なったレベルの分散管理で分散方法で特定の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
ドメイン"e164.arpa"は、E.164番号の格納にDNSのインフラストラクチャを提供するために居住されています。 分配された操作を容易にするために、このドメインはサブドメインに分割されます。 E.164の所有者は記載されたコネになりたがっているべきDNSが適切なゾーンの管理者に連絡するはずであるものに付番します。
Faltstrom & Mealling Standards Track [Page 2] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[2ページ]RFC3761を荒びきにすること。
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.
ゾーンに付けられている方針。 ゾーンに関連しているSOAリソース記録を調べることによってこの情報を探し始めるべきです、まさしく通常のDNS操作などのように。
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.
もちろん、他のドメインなら、そのようなリストのための方針は、サブドメインベースで制御されて、世界のいろいろな地方で異なるかもしれません。
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC 3403 [2].
他のすべての大文字で書かれた用語がRFC3403[2]で見つけられたDDDSアルゴリズム仕様で見つけられたボキャブラリーからかかります。
1.2. Use for these mechanisms for private dialing plans
1.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であるはずがありません。 個人的なダイヤルするプランへの党は、これらのメカニズムの正しい操作にそれらの個人的なダイヤルするプランによって使用される接尾語を知る必要があるでしょう。アプリケーションのユニークなストリングの中古のSHOULDはさらに、指定されるとしての定員ですが、主な'+'、およびそのような私用なしで"ENUM"と呼ばれてはいけません。
1.3. Application of local policy
1.3. ローカルの方針の適用
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記録のOrder分野は、DNS記録がどんなオーダーで解釈されるかことであると指定します。 これはDNSがDNSパケットの答え部で返された記録の注文を保証しないからです。 '典型的な正規表現がこと'^*$!'であるので、最初の質問がしばしば端末のRuleをもたらすとき、ほとんどの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
しかし、他のケース(非端末Rules)が2異なったRulesがともに与えられたApplication Unique Stringに合っているところにあります。 各Ruleがアルゴリズムの中で評価されるとき、AUSのもう片方より重要な断片に合うかもしれません。 例えば、一連の数字を考えて、非端末のNAPTR aを使用するのを何らかの個人的なプラン詳細にダイヤルしているゾーンに送ります。 そのゾーンの中に、それがマッチが全体の交換のためのものであり、サービスがSIPであるならその時1番目を関係づけて、SIP特有の規則が使用されていると述べる2Rulesがあります。 しかし、Ruleがそれを指定するAUSの、より長い断片に合っているもう片方
Faltstrom & Mealling Standards Track [Page 3] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[3ページ]RFC3761を荒びきにすること。
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.
(インスタントメッセージング)を修理してください。ある他のRuleは部門のレベルサービスを指示します。 より短い合っているRuleが、より長いマッチに優先するなら、それは他の規則に'マスクをかけることができます'。 したがって、各Ruleが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.
そして、その2Rulesを述べるというゾーン権威願望は同じ効果を持っているか、または用法が同じである場合では、それらの記録のためのOrderが同じ値に用意ができています。 その場合、Preferenceは、1Ruleが別のものより単にある理由で良いかもしれないというゾーン権威による局所的に過剰乗ることができる提案を指定するのに使用されます。
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のOrder分野はE.164番号の所有者からの記録が特定の方法で扱われるという要求です。 Preference分野は単にそのE.164所有者からの1つの記録が別のものより良いかもしれないという提案です。 さばきますが、実行ENUM MUSTがOrderに付着させるクライアントは単に「熟考」のクライアントの文脈の特定の選択方法の一部としてのPreference値を取ることができます。
2. The ENUM Application Specifications
2. 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 Applicationを定義します。 このApplicationによって使用されたDDDSデータベースはNAPTR DNS Resource Recordタイプを定義するドキュメントである[2]で見つけられます。
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.
E.164番号だけに、ENUMは適切です。 ENUM対応することのアプリケーションはそれがE.164番号であると信じていることのためにDNSについて質問するだけでよいです。 時間がたつにつれて変化できる多数のダイヤルするプランがあるので、クライアントアプリケーションにはあらゆる有効、そして、dialable E.164番号に関する完全な知識があるのは、たぶん不可能です。 したがって、パワーの中ですべてをして、クライアントアプリケーションは、それが実際にほんとうは有効でないシンタクス上適度のE.164番号であると考えることで終わるか、または「ダイヤル-可能」されることができます。 これは、例えば、アプリケーションがDNS質問にいつを送るかもしれないかを含意して、ユーザmistypesはユーザーインタフェースの数です。 これのために、E.164番号と非E.164番号との衝突が起こることができるというリスクがあります。 この危険を緩和するために、非E.164番号にサービス分野のE2U部分を使用してはいけません。
Faltstrom & Mealling Standards Track [Page 4] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[4ページ]RFC3761を荒びきにすること。
2.1. Application Unique String
2.1. アプリケーションのユニークなストリング
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.
Application Unique Stringは数の始めに現れる'+'キャラクタ以外のどんな非ケタキャラクタを引いた完全に適切な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」をもたらして。
2.2. First Well Known Rule
2.2. 最初のよく知られている規則
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.
このApplicationのためのFirst Well Known Ruleはアイデンティティ規則です。 この規則の出力は入力と同じです。 これはE.164名前空間とこのApplicationsデータベースが直接名前自体から直接名前から最も小さい名前空間の粒状まで行くのが可能であるような方法で組織化されるからです。
Take the previous example, the AUS is "+441164960348". Applying the First Well Known Rule produces the exact same string, "+441164960348".
前の例を取ってください、そして、AUSによる「+441164960348」ということです。 First Well Known Ruleを適用すると、全く同じストリング、「+441164960348」は生産されます。
2.3. Expected Output
2.3. 予想された出力
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[4]で見つけられたCollected ABNFでの'absoluteURI'生産に従って絶対フォームでのUniform Resource Identifierです。
2.4. Valid Databases
2.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.
現在のところ、1DDDS DatabaseだけがこのApplicationに指定されます。 「ダイナミックな代表団発見システム(DDDS)パートThree:」 「DNS Database」(RFC3403)[2]は書換規則を含むのにNAPTR DNSリソース記録を使用するDDDS Databaseを指定します。 このデータベースのためのキーズはドメイン名としてコード化されます。
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 ApplicationのためのFirst Well Known Ruleの出力は+を除いたすべての非ケタキャラクタを引いたE.164番号です。このDatabaseのユニークキーにこれを変換するために、このアルゴリズムによると、ストリングはドメイン名に変換されます:
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. ケタ以外のすべてのキャラクタを外してください。 例えば、First Well Known RuleはKey「+442079460148」を生産しました。 「442079460148」を生産して、このステップは単に主な「+」を取り除くでしょう。
Faltstrom & Mealling Standards Track [Page 5] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[5ページ]RFC3761を荒びきにすること。
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記録も答えの追加情報部に挿入するでしょう。 したがって、クライアントがこの追加情報がないかどうかチェックするのは、潜在的に役に立ちます。 ENUMを熟考するのがたやすくも、NAPTR記録の実際のコンテンツが役立つのを理解しているネームサーバを高めて、応答の追加情報部により適切な情報を挿入するということです。 したがって、DNSサーバは、DNSパケットのAdditional情報部分に適切なリソース記録を含むのにFlag値を解釈して、その情報を使用するかもしれません。 クライアントは、追加情報がないかどうかチェックするよう奨励されますが、そうする必要はありません。 RFC3403[2]のAdditional情報Processing部、NAPTR記録に関する詳しい情報のためのセクション4.2、およびDNS応答パケットのAdditional情報部を見てください。
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.
代替表現をコード化するのに使用される文字の組はUTF8です。 許容入力キャラクタは皆E.164番号でどこでも許容されているそれらのキャラクタです。 Keyにあることができたキャラクタは現在DNSドメイン名のために定義されるものです。
2.4.1. Flags
2.4.1. 旗
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].
このDatabaseはDDDSアルゴリズムが終わったとき合図する旗を含む分野を含んでいます。 このとき、「U」という1個の旗だけが定義されます。 これはこのRuleが最後のものであり、Ruleの出力がURI[4]であることを意味します。 RFC3404[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.
未知の旗でクライアントが記録に遭遇するなら、それは、それを無視して、次のRuleに動かなければなりません。 旗がフィールドに置かれた解釈を制御できるので、このテストはどんな注文の上でも優先します。
Faltstrom & Mealling Standards Track [Page 6] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[6ページ]RFC3761を荒びきにすること。
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).
この旗が存在していないなら、この規則は非端末です。 Ruleが非端末であるなら、クライアントはDDDSの新しいKeyが輪にするので(すなわち、クライアントが新しいNAPTRのためにこのRuleの結果であるドメイン名で記録について質問することを引き起こします)このRewrite Ruleによって生産されたKeyを使用しなければなりません。
2.4.2. Services Parameters
2.4.2. サービスパラメタ
Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record.
このApplicationのためのサービスParametersは以下の形を取って、NAPTR記録のService野原で発見されます。
service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT)
「サービス分野=「E2U」1*(servicespec)servicespecは「タイプ0*(subtypespec)+ 」 enumservice enumservice=subtypespec=」と等しいです」 「副-タイプ」タイプ=1*32(アルファー/DIGIT)「副-タイプ」=1*32(アルファー/ケタ)
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」(以前は、よく書き直しだけが記録的な衝突を緩和するために統治するENUMを指示していた)は与えられたエンドポイントがどんなクラスの機能性を提供するかを示す1Enumservicesで続きました。 各Enumserviceは初期の'+'キャラクタによって示されます。
2.4.2.1. ENUM Services
2.4.2.1. ENUMサービス
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自身のための仕様で明白にしなければなりません。 特定のTypeの登録も許容されたSubtypesを指定しなければなりません。
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.
登録規則への唯一の例外が実験目的に使用されるTypesとSubtypesのためのものです、そして、それらはまず第一に一面「X」です。 これらの要素は、登録されていなくて、実験的であり、彼らを交換するパーティーの活発な協定だけと共に使用されるべきです。
The registration mechanism is specified in Section 3.
登録メカニズムはセクション3で指定されます。
Faltstrom & Mealling Standards Track [Page 7] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[7ページ]RFC3761を荒びきにすること。
2.5. What constitutes an 'Enum Resolver'?
2.5. 何が'Enum Resolver'を構成しますか?
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がいったい何を返すか、そして、それがRFC3402の'注意1'セクションにどんな関係を持っているかの上に何らかの混乱がありました。 最初に読書すると、まるでENUM Resolverが2Rulesを返すのが、可能であるかもしれないかのように見えます。
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アルゴリズムはいつもただ一つの規則を返します。 特定のアプリケーションはアプリケーション特有の知識かそれらが複数個の答か速度選択を提示できる施設を持っているかもしれませんが、これらはアルゴリズムの操作を決して変えるべきではありません。
3. Registration mechanism for Enumservices
3. Enumservicesのための登録メカニズム
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 Registryの中で'タイプ'を使用します。 それぞれのタイプの組み合わせと血液型亜型のすべてが'enumservice'分野に許容値を構成しますが、単にそれらの値を記録するのは十分ではありません。 また、完全な登録はENUMの中で相互運用性を考慮するのに必要である許容URI計画、機能的な仕様、セキュリティ問題、意図している用法、およびいかなる他の情報も含むでしょう。 登録されたENUM Serviceになるように、テンプレートを含む全体の仕様で、RFCとしてEnumservice登録仕様のIESGと公表の承認を要します。
3.1. Registration Requirements
3.1. 登録要件
Service registration proposals are all expected to conform to various requirements laid out in the following sections.
サービス登録提案が以下のセクションで広げられた様々な要件に従うとすべて予想されます。
3.1.1. Functionality Requirement
3.1.1. 機能性要件
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.
別のものからの1つのNAPTRリソース記録を選ぶとき、登録されたEnumserviceは選択メカニズムとして機能できなければなりません。 それは、登録が、まさしくその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 Distinguished Names、結果として起こるURIにAUSを移しますなど)を指定しなければなりません。
Faltstrom & Mealling Standards Track [Page 8] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[8ページ]RFC3761を荒びきにすること。
3.1.2. Naming requirement
3.1.2. 要件を命名します。
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つのタイプのための「副-タイプ」は異なった登録されたタイプのための「副-タイプ」と同じであるかもしれませんが、それは別のタイプの単に参照「副-タイプ」に十分ではありません。 登録されていて、タイプの文脈でそれぞれの「副-タイプ」の機能を指定しなければなりません。
3.1.3. Security requirement
3.1.3. セキュリティ要件
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の総合的な解決の過程にあれば。
Faltstrom & Mealling Standards Track [Page 9] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[9ページ]RFC3761を荒びきにすること。
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はある種の安全保証を必要としますが、必要なセキュリティー対策自体を提供しないアプリケーションのために狙うかもしれません。 例えば、システムを驚かせるような秘密のセキュリティー・サービス情報かメッセージサービスpasscodesの格納とEnumserviceを定義できました。(順番に、passcodesは外部の秘密性サービスを必要とします)。
3.1.4. Publication Requirements
3.1.4. 公表要件
Proposals for Enumservices registrations MUST be published as one of the following documents; RFC on the Standards Track, Experimental RFC, or as a BCP.
以下のドキュメントの1つとして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 Registration木自体の一部としてそれらを「発行するでしょう」。
3.2. Registration procedure
3.2. 登録手順
3.2.1. IANA Registration
3.2.1. IANA登録
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登録を共同体に利用可能にするでしょう。
3.2.1.1. Location of Enumservice Registrations
3.2.1.1. 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/ "。
3.2.1.2. Change Control
3.2.1.2. 変化コントロール
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.
RFC公表プロセスを通したIETFと共にEnumservices滞在のコントロールを変えてください。 特に、Enumservice登録証明書は削除されないかもしれません。 もう使用に適切であることは信じられていないEnumservicesが新しいRFCの公表による宣言しているOBSOLETEであるかもしれなく、それらの「意図している使用」への変化は分野です。 そのようなEnumserviceはIANAによって発表されたリストで明確にマークされるでしょう。
Faltstrom & Mealling Standards Track [Page 10] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[10ページ]RFC3761を荒びきにすること。
3.2.2. Registration Template
3.2.2. 登録テンプレート
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.
以下に注意してください。 特定の分野が値を全く持っていない場合では、その野原は完全に空白のままにされます、特に与えられたタイプが血液型亜型を全く持っていない場合で。
4. Examples
4. 例
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体系と同じストリングです。 それはRFC2916の仕様でしたが、Enumserviceのこの'デフォルト'仕様はもう許容されていません。 すべてのEnumservicesが、セクションセクション3で指定された手順で明らかに登録される必要があります。
4.1. Example
4.1. 例
$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!" .
$発生源3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+一口!」」 ^* info@example.com! 」 . 「$!h323: NAPTR10 101「u」「E2U+h323!」」 ^* info@example.com! 」 . 「$!mailto: NAPTR10 102「u」「E2U+msg!」」 ^* 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望ましくは、三番目に、メッセージングのために第二に声のためのH.323を通してSMTPによってSIPによって連絡されます。 トークン「一口」、"h323"、および"msg"がIANAに登録されたTypesであり、彼らにはプロトコルかURI体系との暗黙接続が全く同じ名前と共にいないことに注意してください。
Faltstrom & Mealling Standards Track [Page 11] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[11ページ]RFC3761を荒びきにすること。
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、h323によって指定されmailto)のプロトコルに解決メカニズムを使用することです。
5. IANA Considerations
5. IANA問題
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.
RFC2916(このドキュメントが取り替える)は、指示に従うE164.ARPAドメインがIABによって提供されるのを代表として派遣するようIANAに要求しました。 それらの指示に応じて、ドメインを代表として派遣しました。 このゾーンの中の名前はITU-T Recommendation E.164に応じてパーティーへ代表として派遣することです。 ITU-T Recommendation E.164によると、割り当てられた名前は階層的であるべきです、そして、そのRecommendationによると、コードは割り当てられるべきです。
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.
ドメインe164.arpaの技術連絡担当者が変化するつもりであるなら、IABはITU-T TSBと共に調整することになっています、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.
Expert Reviewの後にゾーン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のための登録を作成しました。 新しいEnumserviceがIETFのRFCプロセスによって登録されるときはいつも、RFCの公表時点で、RFC自身にEnumserviceを登録して、指針を加えるために、IANAはあります。
6. Security Considerations
6. セキュリティ問題
6.1. DNS Security
6.1. DNSセキュリティ
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(現在のフォームでは、不安定なプロトコルである)を使用するとき、1つが取り戻すデータが確実に正統になるようにするためのメカニズムが全くありません。 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に対して起こることができる複数のタイプの攻撃があります。 Threat Analysis Ofドメインネームシステム[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
DNSに対する最も簡単な脅威のパケットInterception Someは様々な形式のパケット妨害です: 中央の猿攻撃、要求を立ち聞きするのはレゾルバへの本当の応答後部などを打つ偽造している応答に結合しました。 これらのいずれでも
Faltstrom & Mealling Standards Track [Page 12] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[12ページ]RFC3761を荒びきにすること。
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の未署名の単一のunencrypted 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.
GuessingとQuery Prediction Since 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.
名前ベースのAttacks Nameベースの攻撃は悪いデータを犠牲者のキャッシュに挿入するためにツールとして振舞いをキャッシュする実際のDNSを使用します、その結果、潜在的に、DNS名に基づくその後の決定を打倒します。 彼らがもう1つの位置に犠牲者の質問を向け直すとき、ほとんどの例がCNAME、NS、およびDNAME Resource Recordsと共に現れます。 これらの攻撃のすべての一般的なスレッドは攻撃者が応答メッセージで攻撃者の選ぶことの任意の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).
パケット妨害攻撃の裏切りBy A Trusted Server Another変化はそれほど信頼できないと判明する信じられたサーバです、偶然にか故意にであることにかかわらず。 多くのクライアントマシンが、彼らのDNS質問のすべてをそれらの利益に実行するのにスタッブレゾルバによって構成されるだけであり、信じられたサーバを使用します。 多くの場合、信じられたサーバをユーザのISPで提供して、DHCPかPPPオプションでクライアントに広告を出します。 この信頼関係(サーババグ、うまくいっているサーバ不法侵入などを通した)の偶然の裏切り以外に、サーバ自体は、ユーザが予想することでない答えを返すために構成されるかもしれません(ユーザを助けるか、またはISPと第三者との事業提携を促進などなどのある他の目標を促進する正直な試みでか否かに関係なく)。
Faltstrom & Mealling Standards Track [Page 13] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[13ページ]RFC3761を荒びきにすること。
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.
どんなネットワーク・サービス(本当に会話のどんなドメインでのどんな種類のほとんどどんなサービス)があるサービス妨害As、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.
不在が即座の失敗(MXとSRV RRsがいなくて寂しいA RRsへのどのフェイルオーバーなどの)以外の動作を引き起こすRRの存在がタイプするDomain Namesの認証されたDenialは本当の脅威を構成します。 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サービスSHOULDはこれらの脅威を改善するメカニズムを含んでいます。 [8] それがいったん配布されるとDNSSECなどのメカニズムでデータの信憑性について確かめることによって、これらの脅威の大部分を解決できます。 データ認証で他のもの(そのようなものとDenial Of Service攻撃)を解決できません。 これらの脅威が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が配布されても、アドレス変換に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と大きい応答を含む他の標準化されたDNSセキュリティ応答を受け取るために最終的にタイプのセキュリティー対策、準備されていて、ENUM MUSTを実装するソフトウェアを実装することであるので、EDNS0シグナリング、RRsですなど未知の。
6.2. Caching Security
6.2. セキュリティをキャッシュします。
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])をしなければならないか。
6.3. Call Routing Security
6.3. セキュリティにルート設定に電話をしてください。
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,
呼び出しルーティングと数/名前翻訳、通訳のサービスの複数のプロバイダーがある多くの国(そして、他の付番環境)があります。 これらの領域、ユーザを可能にするどんなシステムでも
Faltstrom & Mealling Standards Track [Page 14] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[14ページ]RFC3761を荒びきにすること。
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.
または、ユーザのための推定のエージェント、ルーティングか供給者情報を変えるのは実際に権限がない(そして正統の変更要求の否定のためのいくつかの場合で)変化のために動機を与えるかもしれません。 そのような環境はそれらの識別と認証のための変化を要求する適切なメカニズムとそれらの変化の承認のために設計されるべきです。
6.4. URI Resolution Security
6.4. URI解決セキュリティ
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.
多量のSecurity Issuesは解決プロセス自体と関係があります、そして、URIの使用はDDDSメカニズムによって生産されました。 それらはセクション3.1.3で指定されるように使用されるEnumserviceの登録で指定されなければなりません。
7. Acknowledgements
7. 承認
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.
RFC2916に通じるサポートと考えが人々からそれが働いたことを確認するために彼らの研究室でこの体系を実装したエリクソン、ビヨン・ラーソン、およびグループで来ました。 また、入力はITU-T SG2、Workingパーティ1/2(付番、ルート設定、Global Mobility、およびEnumservice Definition)、IETF、ジョンKlensin、およびリーフ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.
RFC2916のこのアップデートは特定の入力で以下から作成されます。 ランディ・ブッシュ、デヴィッド・コンラッド、リチャード・ヒル、ジョン・ピーターソン、ジム・リード、Joakim Stralmark、ロバート・ウォルター、およびジェームス・ユー。
8. Changes since RFC 2916
8. RFC2916以来の変化
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」のものでしたが、新しい形式は「Eの2U+例」です。 この変化の理由は中に加えられた血液型亜型があるenumserviceにそうしました、最初に1NAPTR RRあたり1enumservice、およびIETFの同じ所有者(この場合、E2U)がいる異なったNAPTRの間のメインセレクタがそうであるべきである一般協定をサポートする能力。
Faltstrom & Mealling Standards Track [Page 15] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[15ページ]RFC3761を荒びきにすること。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[2] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[5] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[5] ITU-T(「国際公共の電気通信数のプラン」、推薦E.164)は1997がそうするかもしれません。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。
9.2. Informative References
9.2. 有益な参照
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[9]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、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月に働いています。
Faltstrom & Mealling Standards Track [Page 16] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[16ページ]RFC3761を荒びきにすること。
10. Authors' Addresses
10. 作者のアドレス
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
パトリク・FaltstromシスコシステムズInc Ledasa273 71Lovestadスウェーデン
EMail: paf@cisco.com URI: http://www.cisco.com
メール: paf@cisco.com ユリ: http://www.cisco.com
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル
Email: michael@verisignlabs.com URI: http://www.verisignlabs.com
メール: michael@verisignlabs.com ユリ: http://www.verisignlabs.com
Faltstrom & Mealling Standards Track [Page 17] RFC 3761 ENUM April 2004
FaltstromとENUM2004年4月に標準化過程[17ページ]RFC3761を荒びきにすること。
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Faltstrom & Mealling Standards Track [Page 18]
Faltstromと標準化過程を荒びきにすること。[18ページ]
一覧
スポンサーリンク