Independent Submission W. Kumari
Request for Comments: 7304 Google
Category: Informational July 2014
ISSN: 2070-1721
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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
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中的冲突以多种方式发生。一种常见情况是，组织将其主域（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.
缓解措施将在多个名称空间中查找名称。如果检测到冲突，它将为用户提供一种方法，以指示他们希望连接的冲突名称之一，并将消除歧义的答案返回给应用程序。缓解措施的另一个特点是缓存用户的选择和/或提供设置优先级的方法。
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.
作者希望感谢以下个人：弗雷德·贝克、鲍勃·布拉登、卡斯滕·鲍曼、内维尔·布朗利、埃里克·伯格、布赖恩·卡彭特、贝诺特·克莱斯、基思·德雷奇、马丁·杜尔斯、大卫·哈林顿、保罗·霍夫曼、约翰·莱文和特德·莱蒙。
Author's Address
作者地址
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043美国
EMail: warren@kumari.net
EMail: warren@kumari.net