dnsop W. Kumari Internet-Draft Google Intended status: Informational June 16, 2013 Expires: December 18, 2013 A questionable method for mitigating namespace collisions draft-wkumari-dnsop-defense-collision-mitigate-00 Abstract This document outlines a method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 18, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kumari Expires December 18, 2013 [Page 1] Internet-Draft DNS Collision Mitigation June 2013 Table of Contents 1. Introduction / Background . . . . . . . . . . . . . . . . . . 2 2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Implementation / Disclaimers . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction / Background Collisions in the DNS occur in multiple ways; one common case is that an organization has used an sub-domain (foo) of their primary domain (example.com) for corporate infrastructure, and then the string "foo" is delegated as a TLD. When a employee of the organization enters 'www.foo', are they trying to reach a machine in the internal namespace (www.foo.example.com) or the hostname 'www' in the 'foo' TLD? This document describes a means of disambiguating these, and similar cases. 2. Mitigation The mitigation described in this document involves presenting the multiple options to the user, and allowing them to indicate which of the names is the one they were trying to reach, and then connecting to that. This could be accomplished in a number of ways, including: Intercepting the resolution requests from the application in a "shim" type library Replacing the resolver library entirely Integrating this type of mitigation into applications (some web browsers already do something similar to this) Running a resolver locally on the workstation / host that return the address of a proxy. The mitigation would lookup the name in multiple namespaces, and if a conflict is detected, it would then provide a means for the user to choose which one of the colliding names they wish to connect to, and Kumari Expires December 18, 2013 [Page 2] Internet-Draft DNS Collision Mitigation June 2013 return the unambiguated answer to the application. An additional feature could be for the described mitigation to cache the user's choice, and / or provide a means to set priorities. There are a nuamber of issues with this solution, including but not limited to: o There may not be a human avaialble to disambiguate the answer (unattended machines, ATMs, etc). o The human / user may have no idea which is the correct choice. o The additional latency introduced may cause the originating application to time out. o The user experiance may be horrid. 3. Implementation / Disclaimers This document does not reference an implementation as it is unclear if the idea is worth implementing - this document exists primarily so that searches for prior-art will find this, and to prevent nefarious deeds. The idea itself may be / probably is horrendous, but it anyone wants to give it a whirl, everyone should be able to give it a whirl. This is a very slight mitigation. It should not be viewed as a solution to the "namespace collision" issue. The author is not planning on revising this draft. 4. IANA Considerations This document contains no IANA considerations. 5. Security Considerations Yes, there probably are some. Don't do this then. 6. Acknowledgements The authors wish to thank some folk, including Tarquin F'tang-F'tang- Ole-Biscuitbarrel. Kumari Expires December 18, 2013 [Page 3] Internet-Draft DNS Collision Mitigation June 2013 7. References Appendix A. Changes / Author Notes. [RFC Editor: Please remove this section before publication.] From -00 to -01. o Nothing changed in the template! Author's Address Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: warren@kumari.net Kumari Expires December 18, 2013 [Page 4]