Subject: Re: [dnsext] DNS-like system for OID [WAS: Presentation and question]

From: Noel David Torres Taño <[email-masked]>
Date: Sun, 7 Apr 2013 13:53:31 +0100

On Martes, 19 de marzo de 2013 03:58:05 [email-masked] wrote:
>  my my.. Steve Hotz and I did this 20 years ago - when the DNS was much
> less ossified than it is today.  we started w/ new class, ended up
> anchoring in the int. tree (when we had emptied out arpa of everything but
> in-addr.... but that is another story).
> 
>  it didn't get much traction then, would be happy to work on it again.
> 
> /bill

Skeleton would be like this:

Rationale:
==========

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 2555.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.

8<-----------------------------------------------------------

This "skeleton proposal" uses class name OID throught it.

Notes:
======

Names and numbers are displayed from root to leaf, unlike in DNS IN class.

Resource Record Types:
======================

SOA: Similar to that of IN class, there will be two SOA registers to maintain, 
one for number-name conversion and one for name-number.

OID: Similar to A or AAAA of IN class, will be used only for name-number 
conversion.

NAME: Similar to PTR of IN class, will be used only for number-name 
conversion.

NS: Equivalent to that of IN class, will point to oid-capable nameservers 
which hold thata for the current zone, being this either number->name or name-
>number.

DNS: Available in number->name zone only (they can be reached from a name if 
you perform a name->number search first and an A search afterwards). They 
point to the canonical IN DNS hostname for the OID, however it is defined by 
OID owner.

TXT: These are available in name->number zone only (they can be reached from a 
number if you perform a number->name search first and a TXT search 
afterwards). They can include whichever information OID ownser deems 
necessary, much like IN class TXT records.

EQUIV: These are available in both zone types, and are similar to IN class 
CNAME. It indicates that all searches that may be conducted after one OID 
number or name are to be conducted after another OID number or name instead. 
No mixture of numbers and names allowed. This RR specifically claims that 
subtrees under the two OIDs are exactly equal.

Example resource records:
=========================

;--------------
;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

;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
;--------------

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.

Root of 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.

8<-----------------------------------------------------------

Please comment (yes, this is a request for comments but not a Request For 
Comments yet).
Noel Torres
er Envite
-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?

---

From: Noel David Torres Taño <[email-masked]>
Date: Mon, 15 Apr 2013 13:44:29 +0100

Does somebody with a bit of experience writing RFC Draft proposals want to 
help with this?

Thanks

On Domingo, 7 de abril de 2013 13:53:31 Noel David Torres Taño wrote:
> > anchoring in the int. tree (when we had emptied out arpa of everything
> > but in-addr.... but that is another story).
> > 
> 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 2555.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 ) .
> 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.
> SOA: Similar to that of IN class, there will be two SOA registers to
> maintain, one for number-name conversion and one for name-number.
> 
> DNS: Available in number->name zone only (they can be reached from a name
> if you perform a name->number search first and an A search afterwards).
> They point to the canonical IN DNS hostname for the OID, however it is
> defined by OID owner.
> 
> TXT: These are available in name->number zone only (they can be reached
> from a number if you perform a number->name search first and a TXT search
> number or name are to be conducted after another OID number or name
> instead. No mixture of numbers and names allowed. This RR specifically
> claims that subtrees under the two OIDs are exactly equal.
> 
> .iso.identified-organization.dod.internet.private.enterprise.rolamasao-org
> OID SOA (ns.rolamasao.org envite.rolamasao.org 2013040701 172800 86400
> 2419200 604800)
> 
> .1.3.6.1.4.1.41434 OID SOA (ns.rolamasao.org envite.rolamasao.org
> 2013040701 172800 86400 2419200 604800)
> 
> ".iso.identified-organization.dod.internet.private.enterprise.rolamasao-org
> " it is allowed to make short references like these:
> 
> INSTEAD OF
> the real roots are 0. 1. and 2. for numbers and itu-t. iso. and
> joint-iso-itu- t. for names.
>