A questionable method for mitigating namespace collisions
draft-wkumari-dnsop-defense-collision-mitigate-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-06-16
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
IETF conflict review conflict-review-wkumari-dnsop-defense-collision-mitigate
Additional URLs
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text