Network Working Group O. Gudmundsson Internet-Draft Shinkuro Inc. Intended status: Standards Track February 14, 2014 Expires: August 18, 2014 Providing support for multiple namespaces to Internet protocols. draft-ogud-appsawg-multiple-namespaces-00 Abstract Over the years there have been various proposals as to use namespaces other than the DNS/IN namespace that is under ICANN administration. Some of these were simple DNS competitors others use different lookup technologies. In addition it is hard to supply different character encodings to DNS as each application needs to provide the translation between the encoding used and the format expected by DNS. This draft proposes a new service layer to provide multiplexing of different namespaces into appropriate function calls. 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 August 18, 2014. 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 Gudmundsson Expires August 18, 2014 [Page 1] Internet-Draft Another way to use new namespaces February 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Not all Namespaces are equal . . . . . . . . . . . . . . . . 3 3. Illustrative Examples . . . . . . . . . . . . . . . . . . . . 3 3.1. Non DNS namespace . . . . . . . . . . . . . . . . . . . . 4 3.2. Different DNS class . . . . . . . . . . . . . . . . . . . 4 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Document history . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Most of us assume that there exists only one namespace on the Internet, the DNS in class IN [RFC1034]. But in practice there are multiple, in addition there are IPv4 and IPv6 address spaces, the Bonjor/MDNS local net namespace. Number of groups are proposing new namespaces that may or may not use DNS as underlying resolution protocol. The "state of the art" in identifying what namespace is used is by using a postfix on the domain name, for example "ogud.onion" is a lookup in a distributed hash table [GNU]. As identified in this draft ALT TLD [ALT], proposing that such new uses be placed in a "squatters TLD" called .alt there are many drawbacks to using what looks like a DNS name to express a different lookup mechanism. One effect is the overhead of trying to locally stop queries to go to the internet[RFC6303] and special use registry exists[RFC6761]. Recently a draft [ReserveTLD] requested a number of allocations some of which are for namespaces that are not normal global DNS namespaces. A further side effect of trying to fit new namespaces into the DNS namespace via TLD name or other trailing names is that developers then try to extend the resolution functions on the host OS to support multiple lookup mehcanisms. This draft proposes a radical solution of placing a "Namespace Identifier" at the front of the name and relies on new software to perform multiplexing between the different namespace lookup Gudmundsson Expires August 18, 2014 [Page 2] Internet-Draft Another way to use new namespaces February 2014 mechanisms available on an host. This technique allows the host itself to reject unsupported lookups rather than leak them to DNS resolvers, or to authoritative servers. This is similar to URI but places an explicit namespace identifier on the "name". At this point this is call for discussion rather than an proposed solution, all examples in this document are for illustration only. It is easy to get into adversarial discussions on this topic thus the draft tries to be non-confrontational, if the draft fails at that the editor apologizes. 1.1. Terminology None at this time. 2. Not all Namespaces are equal Right now the Internet has two universal namespace (DNS in class IN) and IPv4 addresses. There are number of minor namespaces in use such as .local for local networks, DNS class CHAOS for few applications. DNS class field has not been widely used due to perceived difficulties in setting up new set of root servers for each class and propagate the information to the clients. Using suffix TLD name on the other hand requires the hosts/ applications/resolvers to know the suffix string and have the capability to resolve using the resolution process specified for that suffix. It is not hard to imagine namespaces that work quite differently from DNS such as by creating long lived connections to the "servers" or exchange information via "modern" encodings like Json [RFC4627]. For these reasons it seems a better solution for multiple namespace existence to have OS's provide a Namespace Abstraction layer that applications call and each name space registers with the Abstraction layer the functions to use. 3. Illustrative Examples The proposal for the "Meta-TLD" .gnu [GNU]specifies a distributed hash table to avoid centralized control of the namespace. This resolution is nothing like the DNS resolution so trying to extend functions like gethostbyname() to support multiple different lookup techniques is likely to have adverse effects on the reliability of the base OS functions. Gudmundsson Expires August 18, 2014 [Page 3] Internet-Draft Another way to use new namespaces February 2014 3.1. Non DNS namespace For a new namespace MARGIR (Icelandic for many) names are expressed like this: https://MARGIR##ACDBU0OCABU0R1FEL7V75RQE1G2GSVQM application will call function ret = namepace_lookup( "MARGIR##ACDBU0OCABU0R1FEL7V75RQE1G2GSVQM", TYPE_ADDR, & answer) ; If the function returns error code "do not understand name space" the application knows this is something it can not use, there is no leak of information from the host. If the function returns success then the application can use the answer structure and proceed. Underneath the namespace_lookup() function there is are calls to various functions for each namespace, these functions are provided via libraries, and each namespace provides a binding to the standard calls such as: Margir = { TYPE_ADDR = margir_lookup(A1, A2, & A3); TYPE_TXT = margir_lookup(A1, 888, & A3); .... } 3.2. Different DNS class For a DNS lookups in a different class it is much easier to reuse the existing lookup functions but still a translation is useful. https://CLASS666##bad.lucifer. Translation table can be CLASS666 = { TYPE_ADDR = gethostname(A1, CLASS_666, TYPE_A, & A3); TYPE_TXT = query_by_type(A1, CLASS_666, TYPE_TXT, & A3); .... } 4. IANA considerations This document has no actions for IANA. Gudmundsson Expires August 18, 2014 [Page 4] Internet-Draft Another way to use new namespaces February 2014 5. Security considerations TBD. If the proposed work goes forward there are many difficult security issues that need to be addressed, the exact security issues depends on the actual proposal. 6. Acknowledgements 7. Informative References [ALT] Kumari, W. and A. Sullivan, "The ALT Special Use Top Level Domain", draft-wkumari-dnsop-alt-tld (work in progress), February 2014. [GNU] Grothoff, C., Wachs, M., Wolf, H., and J. Applebaum, "Special-Use Domain Names of Peer-to-Peer Systems", draft- iesg-special-use-p2p-names (work in progress), December 2013. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. [ReserveTLD] Chapin, L. and M. McFadden, "Additional Reserved Top Level Domains", draft-chapin-additional-reserved-tlds (work in progress), January 2014. Appendix A. Document history [RFC Editor: Please remove this section before publication ] 00 Initial version Author's Address Gudmundsson Expires August 18, 2014 [Page 5] Internet-Draft Another way to use new namespaces February 2014 Olafur Gudmundsson Shinkuro Inc. 4922 Fairmont Av, Suite 250 Bethesda, MD 20814 USA Email: ogud@ogud.com Gudmundsson Expires August 18, 2014 [Page 6]