Internet DRAFT - draft-torres-dnsext-oid
draft-torres-dnsext-oid
Internet Draft N. Torres
draft-torres-dnsext-oid-00.txt Independent
Category: Informational
Expires October 2013 April 24, 2013
DNS-like system for OID
draft-torres-dnsext-oid-00.txt
Status of this Memo
Distribution of this memo is unlimited.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 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.
Abstract
This file justifies and explains a DNS-like system for storing the
correspondence between OID names and numbers, as well as some
additional data that might be deemed useful. It is aimed to be
implemented as an extension to current DNS mechanisms by the addition of
some Resource Record and Query types.
Table of Contents
1. Introduction ....................................................2
2. Notes ...........................................................x
3. Classes .........................................................x
3.1. Types ......................................................x
3.2 Example RR's ................................................x
4. Recursive search ................................................x
5. Roots for the trees .............................................x
6. Security Considerations ........................................x
7. IANA Considerations ............................................x
8. References .....................................................x
1. Introduction
This document proposes a DNS extension to allow the DNS mechanism to
be used to store, ask for and retrieve OID information.
Current DNS IN class schemene intends to trace between a tree-like
structure (the domain names, rooted at . ) and a linear structure
(the IP addresses, between 0.0.0.0 and 255.255.255.255 ) . It has
been extended to include IPv6 addresses, but these are a linear
structure too (from :: to FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ) .
IN class also includes an inverse resolution (from linear IP to tree-
like Domain Names) which is a tweak which really resolves between IP-
like Domain Names and real Domain Names and also does not address
fully issues like IP delegation in non-8bit boundaries (See RFC 2317
) .
OID, instead, is a tree-like structure on its own, with (currently)
three roots (0, 1 and 2) which can be super-rooted at . so this
"skeleton proposal" intends to draw a way to map from tree-like
structure to tree-like structure, fully forward and backwards,
including also extra information that may be deemed useful.
Also, this proposal allows OID owners to publicily state about
canonical hostnames where information about their OIDs (or the
organizations holding them) can be found.
This document has been written taking into account [RFC5507].
2. Notes
OID names and numbers are displayed in this document from root to
leaf (from left to right), unlike the standard DNS IN class custom.
3. Classes
This memo creates a new class, named OID.
3. Resource Record Types
The new RR's proposed are those needed to store the mapping between
OID names and numbers, and those to map between them and the extra
info. Some of the IN class RR's are also used here without
modification, with just some minor meaning adjustment.
3.1 Types
SOA: Similar to that of IN class, there will be two parallel SOA
registers to maintain, one to start a number->name mapping zone and
one to start a name->number mapping zone.
OID: Similar to A or AAAA of IN class, will be used only on a
name->number zone for name->number mapping. In case of clash with
Class name, Class will be renamed OI.
NAME: Similar to PTR of IN class, will be used only on number->name
zone for number->name mapping.
NS: Equivalent to that of IN class, will be used both in number->name
mapping zones and in name->number mapping zones and points to OID-
capable nameservers which hold the data for the current zone, or a
delegated zone of the same kind of the current.
DNS: Available in number->name zones only (these RR's can be reached
from a name if you perform a name->number search first and a DNS
search afterwards). This RR points to the canonical IN Class DNS
hostname for the OID, whichever meaning is assigned to that concept
by the OID zone owner.
TXT: These are available in name->number zones only (these RR's can
be reached from a number if you perform a number->name search first
and a TXT search afterwards). These can include whichever information
the OID owner deems necessary, much like IN Class TXT records.
EQUIV: These are available in both kins of zones, and are similar to
IN Class CNAME. It indicates that all searches that may be conducted
after one OID number or name (depending on the zone kind) MUST be
conducted after target OID number or name instead. No mixture of
numbers and names allowed: a name can only EQUIV anothe name, and a
number can only EQUIV another number. This RR specifically claims
that subtrees under the two OIDs are exactly equal.
3.2 Example RR's
;This is ONE file ;NAME zone
.iso.identified-
organization.dod.internet.private.enterprise.rolamasao-org OID SOA
(ns.rolamasao.org envite.rolamasao.org 2013040701 172800 86400
2419200 604800)
@ OID NS ns.rolamasao.org @ OID NS ns2.rolamasao.org
@ OID TXT "Rolamasao.org related elements"
@ OID OID .1.3.6.1.4.1.41434
persona OID OID 1 individual OID OID 2 individual OID EQUIV persona
;This is ANOTHER FILE ;NUMBER zone
.1.3.6.1.4.1.41434 OID SOA (ns.rolamasao.org envite.rolamasao.org
2013040701 172800 86400 2419200 604800)
@ OID NS ns.rolamasao.org @ OID NS ns2.rolamasao.org
@ OID NAME
.iso.identified-
organization.dod.internet.private.enterprise.rolamasao-org
@ OID DNS www.rolamasao.org
1 OID NAME persona 2 OID NAME individual 2 OID EQUIV persona
4. Recursive search
Due to exact tree-to-tree mapping, and to avoid long strings like
".iso.identified-
organization.dod.internet.private.enterprise.rolamasao-org" it is
allowed to make short references like these:
;INSTEAD OF @ OID OID .1.3.6.1.4.1.41434 ;IT IS ALLOWED @ OID OID
41434
;INSTEAD OF @ OID NAME
.iso.identified-
organization.dod.internet.private.enterprise.rolamasao-org ;IT IS
ALLOWED @ OID NAME rolamasao-org
These not-starting-with-dot records will force recursive search.
Similar mechanisms may be created for Queries.
5. Roots for the trees
Nominally the root of both trees will be . but all clients SHOULD
know that the real roots are 0. 1. and 2. for numbers and itu-t. iso.
and joint-iso-itu-t. for names.
6. Security Considerations
There are no security considerations relevant to this document.
7. IANA Considerations
If this document were accepted by the IETF, IANA as result should
reserve numbers for the corresponding Class, Query and RR types.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC5507] Faltstrom, P., Austein, R. and Koch, P., "Design Choices
When Expanding the DNS", RFC 5507, April 2009.
Authors' Addresses
Noel David Torres Ta~no
EMail: envite@rolamasao.org
