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