[要約] RFC 7304は、名前空間の衝突を軽減するための方法を提案している。目的は、異なるプロトコルやアプリケーション間での名前空間の競合を防ぎ、システムの互換性と拡張性を向上させることである。
Independent Submission W. Kumari
Request for Comments: 7304 Google
Category: Informational July 2014
ISSN: 2070-1721
A Method for Mitigating Namespace Collisions
名前空間の衝突を軽減する方法
Abstract
概要
This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.
このドキュメントでは、エンドユーザーが競合を明確化する手段を提供することにより、DNS名前空間での衝突の影響を軽減するための、可能ではあるが推奨されない方法について概説します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7304.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7304で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction/Background . . . . . . . . . . . . . . . . . . . 2
2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Implementation/Disclaimers . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
Collisions in the DNS occur in multiple ways. One common case is that an organization has used a subdomain (foo) of its primary domain (example.com) for corporate infrastructure, and then the string 'foo' is delegated as a Top-Level Domain (TLD). When an employee of the organization enters 'www.foo', is the goal to reach a machine in the internal namespace (www.foo.example.com) or the hostname 'www' in the 'foo' TLD?
DNSの衝突は複数の方法で発生します。よくあるケースの1つは、組織が企業インフラストラクチャにプライマリドメイン（example.com）のサブドメイン（foo）を使用しており、文字列 'foo'がトップレベルドメイン（TLD）として委任されている場合です。組織の従業員が「www.foo」と入力した場合、内部ネームスペース（www.foo.example.com）のマシンに到達することが目標ですか、それとも「foo」TLDのホスト名「www」ですか？
This document describes a means of disambiguating this and similar cases.
このドキュメントでは、このようなケースを明確にする方法について説明します。
Implementation of this method is not recommended; it is documented here to explain some of the pitfalls with such an approach.
このメソッドの実装は推奨されません。ここでは、そのようなアプローチの落とし穴のいくつかを説明するために文書化されています。
The mitigation described in this document involves presenting multiple options to the user and allowing them to indicate which of the names is the one they are trying to reach.
このドキュメントで説明する緩和策には、ユーザーに複数のオプションを提示し、それらが到達しようとしている名前を示すことができるようにすることが含まれます。
The mitigation would look up the name in multiple namespaces. If a conflict is detected, it would then provide a means for the user to indicate which one of the colliding names they wish to connect to, and return the disambiguated answer to the application. An additional feature of mitigation could be to cache the user's choice and/or provide a means to set priorities.
緩和策は、複数の名前空間で名前を検索します。競合が検出された場合、ユーザーは、衝突する名前の1つに接続することを示し、明確な回答をアプリケーションに返す手段を提供します。緩和策の追加機能は、ユーザーの選択をキャッシュすること、および/または優先順位を設定する手段を提供することです。
This could be accomplished in a number of ways, including:
これは、次のようないくつかの方法で実現できます。
o Intercepting the resolution requests from the application in a "shim" type library
o 「shim」タイプライブラリ内のアプリケーションからの解決要求のインターセプト
o Replacing the resolver library entirely
o リゾルバーライブラリを完全に置き換える
o Integrating this type of mitigation into applications (some web browsers already do something similar to this)
o このタイプの緩和策をアプリケーションに統合する（一部のWebブラウザーはすでにこれに似た処理を行っています）
o Proxying the request to a server that provides an interstitial page that allows the user to indicate the intended name (for applications such as HTTP)
o ユーザーが目的の名前を指定できるようにするインタースティシャルページを提供するサーバーにリクエストをプロキシする（HTTPなどのアプリケーションの場合）
There are a number of issues with this solution, including but not limited to:
このソリューションには、次のようないくつかの問題があります。
o There may not be a human available to disambiguate the answer (unattended machines, mail servers, etc.).
o 回答を明確にする人間がいない場合があります（無人マシン、メールサーバーなど）。
o The human/user may have no idea which is the correct choice, especially in the case of a phishing attack or other malicious intent.
o 人間/ユーザーは、特にフィッシング攻撃やその他の悪意のある場合には、どちらが正しい選択であるかわからない可能性があります。
o The additional latency introduced may cause the originating application to time out.
o 導入された追加の遅延により、元のアプリケーションがタイムアウトする場合があります。
o The experience would be time consuming for users as they must select each site and subsite intended (e.g., www.intranet, images.intranet, etc.).
o ユーザーが意図した各サイトとサブサイト（www.intranet、images.intranetなど）を選択する必要があるため、ユーザーにとってエクスペリエンスは時間がかかります。
o Caching the responses could lead to problems when the user changes location (internal sites would fail when offsite or otherwise lead to incorrect sites being loaded).
o 応答をキャッシュすると、ユーザーが場所を変更したときに問題が発生する可能性があります（オフサイトの場合、内部サイトは失敗するか、正しくないサイトが読み込まれる可能性があります）。
For these and other reasons, implementation of this technique is not recommended.
これらの理由およびその他の理由により、この手法の実装は推奨されません。
This document does not reference an implementation. Due to the numerous issues described above, we do not recommend that this solution be implemented. This is a very slight mitigation, and we do not recommend that it be viewed as a solution to the namespace collision problem.
このドキュメントは実装を参照していません。上記の多数の問題があるため、このソリューションを実装することはお勧めしません。これはごくわずかな緩和策であり、名前空間の衝突問題の解決策と見なすことはお勧めしません。
While this method may make some users more aware of which version of a name they are going to use (and so careful users may avoid some phishing attacks), the security risks described above outweigh this potential benefit.
この方法を使用すると、一部のユーザーが使用する名前のバージョンを認識しやすくなります（そのため、注意深いユーザーはフィッシング攻撃を避けることができます）が、上記のセキュリティリスクはこの潜在的な利点を上回ります。
There are numerous security implications in this approach, including leaking internal names (e.g., secret-project.corp.example.com), users being tricked into selecting the incorrect choice when trying to disambiguate answers, etc.
このアプローチには、内部名の漏えい（secret-project.corp.example.comなど）、ユーザーをだまして回答を明確化しようとする際に誤った選択肢を選択させるなど、多くのセキュリティ上の影響があります。
For these reasons, it is not recommended that this solution be deployed.
これらの理由により、このソリューションを展開することはお勧めしません。
The author wishes to thank the following individuals: Fred Baker, Bob Braden, Carsten Bormann, Nevil Brownlee, Eric Burger, Brian Carpenter, Benoit Claise, Keith Drage, Martin J. Duerst, David Harrington, Paul Hoffamn, John Levine, and Ted Lemon.
著者は、フレッドベイカー、ボブブレーデン、カーステンボルマン、ネビルブラウンリー、エリックバーガー、ブライアンカーペンター、ブノワクレイズ、キースドラジェ、マーティンJ.デュアスト、デビッドハリントン、ポールホファム、ジョンレバイン、テッドレモンに感謝します。 。
Author's Address
著者のアドレス
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US
ウォーレンクマリGoogle 1600 Amphitheatre Parkway Mountain View、CA 94043 US
EMail: warren@kumari.net