From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7304.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc7304.txt (limited to 'doc/rfc/rfc7304.txt') diff --git a/doc/rfc/rfc7304.txt b/doc/rfc/rfc7304.txt new file mode 100644 index 0000000..5cc47b5 --- /dev/null +++ b/doc/rfc/rfc7304.txt @@ -0,0 +1,227 @@ + + + + + + +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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2014 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. + + + + + + + + + + +Kumari Informational [Page 1] + +RFC 7304 DNS Collision Mitigation July 2014 + + +Table of Contents + + 1. Introduction/Background . . . . . . . . . . . . . . . . . . . 2 + 2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Implementation/Disclaimers . . . . . . . . . . . . . . . . . 3 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 + +1. Introduction/Background + + 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? + + 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. + +2. Mitigation + + 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 Replacing the resolver library entirely + + o Integrating this type of mitigation into applications (some web + browsers already do something similar to this) + + + + + +Kumari Informational [Page 2] + +RFC 7304 DNS Collision Mitigation July 2014 + + + 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) + + 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 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 The additional latency introduced may cause the originating + application to time out. + + 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 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). + + For these and other reasons, implementation of this technique is not + recommended. + +3. Implementation/Disclaimers + + 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. + +4. Security Considerations + + 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. + + + + +Kumari Informational [Page 3] + +RFC 7304 DNS Collision Mitigation July 2014 + + + For these reasons, it is not recommended that this solution be + deployed. + +5. Acknowledgements + + 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 + + EMail: warren@kumari.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumari Informational [Page 4] + -- cgit v1.2.3