Subject: Re: What are the chances for OID resource records in the DNS?

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Sep 2000 19:24:09 -0400

Around 04:52 PM 09/19/2000 -0500, rumor has it that Gunther Schadow said:
>Hi,
>
>I have a proposal for a careful DNS extension that I would love to have
>your opinion on.
>
>The ISO Object Identifier scheme becomes increasingly important. Particularly
>as the Internet adopts more and more OSI based protocols, such as X.509, we
>see a lot of use for OIDs. In addition, OIDs are a very useful identifier 
>scheme since they allow a fully distributed management with little technical
>overhead (unlike UUIDs or GUIDs).

You seem to misunderstand how UUID's work. While OID's are assigned like
domain names by a managing organization and the assignee is able to
"subdomain", by contrast UUID's are generated by the creator/developer, and
are guarenteed to be unique by the generator. UUID's have zero
technical/management overhead. The only disadvantage is that you wind up
having large, unordered lists of them, making them unwieldy to search
without a database.

As a matter of history, I thought OID's came from SNMP ;-)

As an SNMP user (MIB-Looker-Upper), I think your idea has some merit, but
I'm not sure DNS is the right protocol. I'd think an LDAP server would be
well suited to handle this kind of data. Rather, a publicly accessible LDAP
server...

		--Dean

>
>Looking at an OID in the format suggested by RFC 1778, the most impressing
>thing about OIDs is that they are very much like DNS domain names or IPv4
>addresses. I.e., OIDs are simple sequences of positive integer numbers
>separated by dots. Similar to IPv4 addresses the left side of an OID is more
>significant than the right side. Unlike IPv4 addresses, the range of the
>numbers between the dots is not constrained to 255 and the length of the OID
>is not constrained to four numbers. RFC 1778 also suggests the use of
>symbolic OID parts on the left side.
>
>Even though the OID scheme is in use since the late 80th, there has never
>been any attempt to somehow publicly account for the assignment of those 
>OIDs. Harald Alvestrand went through great pain to put up some OID
>registry at http://www.alvestrand.no/~hta/objectid/. Yet this registry
>is neither complete nor does it scale.
>
>LDAP is what remains today from the X.500 idea (that brought forth
>the OID too) While LDAP could support an OID directory architecture it
>seems as if LDAP directories are not really designed or used for a
>truly distributed structure.
>
>This is where I believe DNS comes in. The DNS is an existing infrastructure
>that can carry simple directory information. Basically what I would suggest 
>is the addition of some DNS resource records or, alternatively a new DNS 
>record class.
>
>There are two principal use cases:
>
>1) Given an OID one wants to understand what that OID means.
>
>2) Given a symbolic OID part (as of RFC 1778) one wants to find out
>   the numeric OID.
>
>The first use case occurs at human speed, the second use case occurs 
>at machine speed. That is, only humans are so curious as to searching
>for some "meaning" of an OID. A few TXT records are probably all they
>need. (Note: OIDs are not an addressing scheme, so there is no processing
>that depends on the resolution of OIDs.)
>
>If, as RFC 1778 suggests, one should use symbolic OID parts, then
>machines should be able to resolve those symbolic OID parts to return
>the numeric OID.
>
>Note that with OIDs only the numbers are canonical. Those symbolic OID
>parts may change over time, i.e., the ITU-T was formally called CCITT.  
>So, the backbone the OID system is those numbers, the names are merely
>aliases. For example, let's say my organization, Health Level-7 (HL7) has 
>been given the number 113883 from ANSI. ANSI maintains the branch 2.16.840.1,
>so HL7's OID is 2.16.840.1.113883. Write this in the reverse order, and
>put a toplevel domain at the end and you have a normal DNS domain name:
>
>113883.1.840.16.2.OID.ISO
>
>This is like the IN PTR records 122.31.68.134.IN-ADDR.ARPA. So, ANSI's
>DNS zone file could contain the following entry for this record:
>
>113883.1.840.16.2.OID.ISO  IN TXT "Health Level-7, Ann Arbor, MI"
>                           IN TXT "URL:http://www.hl7.org"
>
>alternatively, and more likely, HL7 would want to have authority over its
>OID namespace on the DNS and so the ANSI zone file would contain only
>
>113883.1.840.16.2.OID.ISO  IN NS dns.hl7.org.
>
>then HL7's zone file would be
>
>@         IN SOA 113883.1.840.16.2.OID.ISO. oidmaster ( ... )
>	  IN NS dns.hl7.org.
>	  IN TXT "Health Level-7, Ann Arbor, MI"
>          IN TXT "URL:http://www.hl7.org"
>oidmaster IN TXT "Gunther Schadow"
>          IN TXT "URL:tel:+13176307960"
>
>3	  IN TXT "HL7 Registered Organizations"
>4         IN TXT "HL7 Registered External Identifiers"
>5         IN TXT "HL7 Code Tables"
>6         IN TXT "HL7 Registered External Coding Systems"
>
>You see how the TXT records define the meaning of the OID branches
sufficiently
>for human consumption. You also see that nothing needs to be added to the DNS
>itself to make this zone file work.
>
>The only thing that needs to be in place is the OID.ISO. domain name
>and its maintenance. Given that there is not a very good relatioship
>between IETF and ISO, and most subtrees of ISO, the IANA could for 
>some time be a non-authoritative root for the OID DNS.  This could be
>bootstrapped from Harald Alvestrands database. In addition one could
>ask ISO whether they want to take this over. The idea of the "non-
>authoritative root" is that it would have all assignments that are
>known in the community but that noone else has claimed authority. At
>any time an organization such as ANSI or ISO could come and claim their
>branches and set up their own SOA.
>
>OID records would be allowed to act like "glue-records", that is the
>superordiante NS would make OID assignments. Thus the ANSI NS would
>contain
>
>@ SOA 1.840.16.2.oid.iso. ... ( ... )
>		...
>113883	IN OID 2.16.840.1.113883
>	IN NS  dns.hl7.org.
>hl7	IN CNAME 113883
>
>(Note: when I used TXT records to carry the OID I would receive zone
>errors from BIND because it doesn't allow TXT to be used in the 
>glus-record style. So I had to defer the OID assignment to the sub-
>domain zone.
>
>
>SYMBOLIC OID PARTS
>
>Basically, those symbolic OID parts are aliases for an OID. For example
>"HL7" could be an alias for the canonical oid "2.16.840.1.113883". Another
>alias for that OID could be "joint-iso-itu-t.country.us.org.hl7". Now,
>to comply with the spirit of the DNS we have to reverse these names and
>have to attach them to a top-level domain:
>
>hl7.org. being a valid DNS name could assign an OID record to itself:
>
>hl7.org.  IN OID 2.16.840.1.113883
>
>OID records would act similar as A records. The long winded symbolic
>name for HL7 would be:
>
>hl7.org.us.country.joint-iso-itu-t.iso. IN OID 2.16.840.1.113883
>
>Note that the canonical name of the OID is always the number form,
>so there is no need for reverse mapping PTR records. The ultimate
>resolution of the OID is at the most a TXT record that may include
>a URL reference or something.
>
>This aliasing could be done without a special resource record type
>by just using CNAMEs. Thus, for example we would have a 
>
>hl7.org.us.country.joint-iso-itu-t.iso. IN CNAME 113883.1.840.16.2.OID.ISO.
>
>However, this would not allow us to use HL7.org as a name for both
>an IP address and an OID. Therefore I think that an OID record type
>similar to the A or AAAA record types is in fact needed.
>
>
>COMBINATION OF NUMERIC AND SYMBOLIC OID PARTS
>
>There is a third extension to the DNS that we need to sensibly use
>the DNS for OID management, and I may be wrong here. That requirement
>is about the following problem. I want all of the following named
>OIDs to resolve to the same numeric OIDs:
>
>hl7.org.us.country.joint-iso-itu-t.oid.iso.
>113883.org.us.country.joint-iso-itu-t.oid.iso.
>113883.1.us.country.joint-iso-itu-t.oid.iso.
>113883.1.840.country.joint-iso-itu-t.oid.iso.
>113883.1.840.16.joint-iso-itu-t.oid.iso.
>113883.1.840.16.2.oid.iso.
>
>The only way I found I could do this with BIND was to define a zone for
>each of these 6 variants. When HL7 now delegates some of its sub-branches
>to someone else, that person would have to define 7, 8, 9, 10 or more
>zones just in order to map all combinations of numeric and symbolic forms.
>And that doesn't even cover something like:
>
>hl7.org.us.16.2.oid.iso.
>hl7.1.840.16.2.oid.iso.
>hl7.1.us.16.2.oid.iso.
>
>etc. So, the functional extension of the DNS system I would propose is
>that when the resource type of the DNS query is OID, then the DNS server
>should resolve as much of the symbolic OID parts as possible starting 
>from the most significant part. That way, zone files would only need
>to be defined for the numbered form and the DNS system would resolve
>the symbols from the most significant symbol down on its way through
>the NS graph.
>
>In the case of "hl7.1.us.16.2.oid.iso." it would take oid.iso. as one
>well known domain asking the OID root NS for 16.2.oid.iso.'s NS. That
>NS would be asked to resolve "us" and then to ask the NS of 1.840 for
>what "hl7" is. That cascade would return 113883.1.840.16.2.oid.iso.
>and eventually return that OID "2.16.840.1.113883".
>
>
>
>SUMMARY
>
>The DNS system seems very close to what would be needed to manage the 
>Object Identifier scheme that would support human understanding of OIDs
>as well as resolving symbolic OID parts or other DNS names to OIDs.
>Only three additional conventions need to be established:
>
>1. The root domain OID.ISO. that would be non-authoritatively managed by
>   IANA until other organizations claim authority for the DNS management
>   of their branches.
>
>2. The resource record type OID that assigns OIDs to DNS names.
>
>3. A special DNS name resolution where DNS names are resolved stepwise.
>   (This may actually just be a change to the BIND implementation of DNS.)
>
>I would be glad for any reactions as to whether this might make sense
>to you. Especially, if you think that nothing is needed, I would 
>appreciate your ideas on how to deal with the last problem (3) of the 
>combinatorial explosion of symbol/number variances.
>
>thank you,
>-Gunther
>
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc                  [email-masked]
           LAN/WAN/UNIX/NT/TCPIP          http://www.av8.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Gunther Schadow <[email-masked]>
Date: Wed, 20 Sep 2000 10:05:46 -0500

Dean Anderson wrote:

> >[...] In addition, OIDs are a very useful identifier

Well, the technical problem with UUIDs though is that you really need an
Ethernet card to assign those, since UUIDs piggy back on the unique ID
scheme of those Ethernet cards. What if you have no such basis? Second
technical problem is that there aren't that many UUID implementations 
around on platforms other than Windoze (where UUIDs are called GUIDs).
My perceptions is that UUIDs have never really taken off the ground as
poublicly shared identifiers. That's where OIDs seem to be much better
accepted. The technical requirements for assigning OIDs are absolutely
trivial, can do that manually or without special Ethernet card dependent
software.

> As a matter of history, I thought OID's came from SNMP ;-)

That is interesting. Can you back that up? I thought the the OSI stems 
even from the late 70's and early 80's. Was SNMP around already back
then?
 
> well suited to handle this kind of data. Rather, a publicly accessible LDAP

LDAP is what everyone keeps recommending me. And yet there are two defects
with LDAP: #1 is LDAP really designed to be so distributed as DNS? If we
would run LDAP in the same massive distribution, wouldn't we reinvent the
wheel? Wouldn't we have to solve all the DNSSEC issues once again for LDAP?
#2 LDAP is not nearly as ubiquitous as the DNS. People would have to spend
time and sweat to set up and maintain LDAP servers besides DNS. Most will
have access to some DNS server already, but few will do LDAP. We have been
setting up LDAP here, that's when I found how immature the implementation
is. I'd much rather use BIND or any DNS server around the globe. That's why
I am not actually eager to invent new DNS RR types. And it seems there isn't
any new RR type needed. A PTR to some OID.ARPA. domain will do.

Thank you,
-Gunther