Internet DRAFT - draft-ogud-appsawg-multiple-namespaces
draft-ogud-appsawg-multiple-namespaces
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]
