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

From: Gunther Schadow <[email-masked]>
Date: Tue, 19 Sep 2000 16:52:45 -0500

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

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.

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Sep 2000 09:57:06 +1100

Date:        Tue, 19 Sep 2000 16:52:45 -0500
    From:        Gunther Schadow <[email-masked]>
    Message-ID:  <[email-masked]>

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

Doing this would mean creating the new TLD ".ISO".   New TLDs is a
political quagmire that no-one here really wants to get involved in.

Once created (if ever) the administrator of .ISO gets to decide if
OID.ISO would get created or not, and if so, who would get to administer
it.   That last person gets to decide how it is used.

  | 2. The resource record type OID that assigns OIDs to DNS names.

I couldn't actually figure out what you were trying to do with that
record, it looks as if its purpose was to say X=X which doesn't really
seem like a useful thing to do.

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

You proposed 2 significant changes to the DNS specification.  One was
to allow OID records (assuming there is some reason for them at all) to
be allowed in the parent zone rather than in the zone where they belong.
I see no rational reason for that one at all.

The second was to allow CNAMES for non-terminal nodes.   That is unlikely
to ever happen (though at times it would make life easier) but there's
an alternate (but very new and just about invisible in the wild yet)
mechanism that has been proposed which would be an alternative.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Sep 2000 11:09:03 +1100

Date:        Tue, 19 Sep 2000 18:19:09 -0500
    From:        Gunther Schadow <[email-masked]>
    Message-ID:  <[email-masked]>

  | well, I suppose one could use an existing TLD, say .ARPA. to form OID.ARPA. 
  | :-)

That is something which (if enough real potential for use, as distinct
from just "it looks like a good fit", could be demonstrated) could
actually be accomplished before we're all dead...

  | hl7.org.	IN A    198.87.144.122
  | hl7.org.	IN OID  2.16.840.1.113883
  | hl7.org.	IN AAAA 3ffe:1ce0:123:1
  | 
  | here you have the same domain name hl7.org resolve to three different
  | address types. I couldn't do this if I had to use CNAMEs to assign
  | hl7.org. to the CNAME 113883.1.840.16.2.OID.ARPA.

That's true.   Is this something that has a use?

  | I suppose I can still use TXT records that by convention start with
  | OID for that purpose.

No, don't do that.   But you could use a PTR

	h17.org.	IN	PTR	113883.1.840.16.2.OID.ARPA.

(or whatever tree it ends up in).   Generating the OID out of that
is not difficult...

  | Are you saying that there is an alternative other than creating so many
  | zones? What is that alternative? Would you please drop some hint?

See rfc2672 ... but don't expect lots of support for it yet.

What you need to do next is to explain just what the real world uses
for having this information in the DNS tree will be (not could be, but
really will be).  Without that, there isn't going to be much enthusiasm.

kre

---

From: Gunther Schadow <[email-masked]>
Date: Tue, 19 Sep 2000 18:19:09 -0500

> it.   That last person gets to decide how it is used.

well, I suppose one could use an existing TLD, say .ARPA. to form OID.ARPA. 
:-) I guess what I want is to heavy-lift the entire OID train on the DNS 
rails. This may be a bit too ambitious. I just thought that if the IETF 
finds a DNS based global OID directory useful, it might be something one 
could do gradually.

> seem like a useful thing to do.

I agree that a record such as this:

113883.1.840.16.2.OID.ARPA. IN OID 2.16.840.1.113883

looks a lot like X=X. When we had CNAMEs for non-terminal nodes, we could
do all the OID symbol to numeric translation through CNAMEs?  But, look
at this:

hl7.org.	IN A    198.87.144.122
hl7.org.	IN OID  2.16.840.1.113883
hl7.org.	IN AAAA 3ffe:1ce0:123:1

here you have the same domain name hl7.org resolve to three different
address types. I couldn't do this if I had to use CNAMEs to assign
hl7.org. to the CNAME 113883.1.840.16.2.OID.ARPA.

I suppose I can still use TXT records that by convention start with
OID for that purpose. So, this OID RR type is not necessarily the one
that plagues me most.

What plagues me most is this:
 
> You proposed 2 significant changes to the DNS specification.  [...]

Are you saying that there is an alternative other than creating so many
zones? What is that alternative? Would you please drop some hint?

Thank you,
-Gunther

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Sep 2000 10:26:32 +0859 ()

Gunther;

> The only thing that needs to be in place is the OID.ISO.

Put it under some domain already owned by ISO or apply for one under
existing TLDs.

Given that ISO would be able to get ISO.INT, it is not an issue
that ISO.ORG is already taken by someone.

> And that doesn't even cover something like:

With BIND, you need exponentially (to the number of labels) lengthy
zone file.

You only have to write your own special name server which internally
converts symbolic names to numbers and looks up its internal database.
Then, the length of the database glows linearly.

There is some complexity upon delegation that name servers of child
zones must know symbolic labels in parent zones. There seems to be no
easy solution other than configuring child name servers with upper
level labels.

							Masataka Ohta

---

From: Gunther Schadow <[email-masked]>
Date: Tue, 19 Sep 2000 21:34:30 -0500

Robert,

I see your point, you want to know whether my suggestion is useful beyond
just a nice to have, so that it makes sense the trouble. Good point. Need
to think about that. 

In my standard organization we want to employ OIDs for most everything.
We will have thousands of oids. Including OID sub-domains delegated to
users around the world. We can decide to use some LDAP stuff that -- I 
believe -- is not proven to scale. Or, we may piggy back our needs on the
DNS that's proven to scale and that is ubiquitous.

Will have to make a stronger point to convince you, perhaps. But for
now I am after a working interim solution for us, since we do not 
have the time of one year or so that it takes to fight any extension
into the DNS (and seeing it implemented). For that reason alone I
am very conservative.

>         h17.org.        IN      PTR     113883.1.840.16.2.OID.ARPA.

Hmm, I like that, but what exactly would it mean? Right now the domain
OID.ARPA. doesn't exist, so I suppose that those PTRs would be invalid.
Can you explain why you think that PTR is a good fit? After all, I know
PTR only from reverse mapping of IN-ADDR.ARPA "domains" to domain names.
How come you suggest it for mapping domain names to OIDs? I could like
that approach if I understood it better.

Thanks for the DNAME hint. That sounds like exactly what I need. Though
it's not supported in my fairly recent version of BIND :-(

regards
-Gunther

---

From: Michael Mealling <[email-masked]>
Date: Tue, 19 Sep 2000 22:37:54 -0400

On Tue, Sep 19, 2000 at 04:52:45PM -0500, Gunther Schadow wrote:
> <snip>

Gunther, 
  Take a look at 
http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-02.txt
  And the DDDS drafts:
  http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-00.txt

For a way to do this the right way... The only issue to be resolved
is getting ISO to run the root of the thing....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Gunther Schadow <[email-masked]>
Date: Wed, 20 Sep 2000 00:11:43 -0500

Michael,

while I think that your DDDS idea contains one answer to the problem, I
submit that it is much more general and therefore, unfortunately, 
complicates things beyond what's necessary for a simple DNS based 
OID catalogue.

I will try to extract some good ideas out of your approach. For example,
I might find the NAPTR RRs useful. Also, I can use the same kind of
stepwise resolution algorithm that you are suggesting, though I was
hoping that I could use a simple resolver query to get to the whole
information at one shot.

regards
-Gunther

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Sep 2000 12:20:10 +0200

>that ISO.ORG is already taken by someone.

I agree.
And: If it is a function the world needs, piloting it under 
aurora.rg.iupui.edu will give you valuable experience, and does not have to 
wait for ISO to react.

(BTW, ISO currently lives at iso.ch)

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Sep 2000 22:54:26 +0859 ()

Harald;

> (BTW, ISO currently lives at iso.ch)

I don't think someone in ISO seriously argue against ISO operate
under *BOTH* iso.ch and iso.int.

							Masataka Ohta

---

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

> aurora.rg.iupui.edu will give you valuable experience, and does not have to

O.K. I have set up a pilot for HL7. And have used Robert Elz's recommendation
to do the canonical OID mapping using PTR records. Thus we can say

hl7.org.	IN A    198.87.144.122
hl7.org.        IN AAAA 3ffe:1ce0:123:1
hl7.org.	IN PTR  113883.1.840.16.2.OID.ARPA.

which puts resolutions for one DNS name to IPv4, IPv6, and OIDs into the 
DNS without ammending the DNS spec. So that works nicely. The rule to resolve 
to an OID is now:

1. issue resolve query with qtype = PRT,
2. in the answers find the name in the OID.ARPA. domain
3. clip off .OID.ARPA.
4. reverse the number sequence

That's very easy to do. So, no new RR type "OID" would be needed.

Now the question: will I be put to into cyber-jail when I use the domain
OID.ARPA. here experimentally without this being a standard assignment?
I want to avoid using something in my own domains, such as hl7.org. or
regenstrief.org, since that would confuse the point. The resolution should
really go to absolute OIDs, not to OIDs in HL7's or Regenstrief's OID
domain.   

What can I do to somehow reserve the domain OID.ARPA. for such experimental
purpose? I will write an internet draft on this experiment, but at the 
same time I would like to deploy this function within our standard 
organization right away. And I know that the draft to RFC transition can
take a long time these days. I will have lots of difficulties explaining 
or selling this to our constituency (mostly legacy system vendors and
consultants) if I had to use a transient domain such as "root-oid.hl7.org."
or something.

thank you,
-Gunther

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Sep 2000 12:21:53 -0400

>really go to absolute OIDs, not to OIDs in HL7's or Regenstrief's OID

For testing the concepts and seeing what you can do with it, using 
oid.hl7.org would in fact be much better - the reason being that you 
clearly label this as an experiment done under the auspices of HL7, not an 
IETF-blessed or ISO-blessed operational service.

The reason you want control of the oid.arpa domain is to put information 
there (such as making HL7.OID.ARPA a CNAME to 113883.1.840.16.2.OID.ARPA, 
indicating that you are allowed to use HL7 as a top level symbolic name - 
something I think will be controversial, btw; less controversial is that 
ISO.OID.ARPA should be a CNAME pointing to 0.OID.ARPA).

If this ever becomes a standard, you are likely to be at the end of a LONG 
discussion on exactly what information to put into the oid.arpa tree, who 
is to be delegated the various subentries, and so on and so forth.

Again, using oid.hl7.org isolates your internal deployment from the hazards 
of the standards process, and guarantees that your applications will go on 
working no matter how many people disagree with you.

My recommendation should be clear....

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 21 Sep 2000 10:59:31 -0700

Sorry coming into this late.

In general, I am opposed to using DNS for directory-like functions, since
DNS does not provide directory features like authenticated-vs-anonymous
queries or key indexing/searching against attribute data. Neither of those
issues should be a problem here though, should they? I mean, do you need
to worry about any of the OIDs being returned for anonymous users (since
all DNS queries are anonymous by nature)?

> O.K. I have set up a pilot for HL7. And have used Robert Elz's
> recommendation to do the canonical OID mapping using PTR records.

Yeah, PTR should work just fine for reverse lookups.

> The rule to resolve to an OID is now:
> 

I don't know if that's the best approach. I think you were on the right
track with an explicit OID RR. For example,

  some.oid.osi.int.	OID	99.88.77.6.5.4.3.2.1

would require an explicit OID RR in order to properly encapsulate the OID
data. Standardized intepretations require standardized representations, so
using an explicit OID RR would ensure that the OID value were being
represented properly.

There are also distinct benefits to having explicit domain name entries,
such as being able to use CNAMEs and additonal RRs. You might want:

   some.other.oid.osi.int.	CNAME	some.oid.osi.int.
   some.oid.osi.int.		OID	99.88.77.6.5.4.3.2.1
				TXT	"OID for XYZ"
				RP	"[email-masked]"

Etcetera. Building a reverse name from the PTR data won't allow for any of
that to occur.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 21 Sep 2000 14:21:45 -0700

> The other thing is, it doesn't make sense to do backward lookup with
> OIDs, because OIDs are not addresses. OIDs are really simply names.

Yeah I know, OIDs have multiple aliases.

But there are multiple ways to delegate the management of the assignment
namespace using the different names. There are definitely multiple,
different namespaces. There are forward and reverse lookups of common
name(s) to numeric ID and vice versa.

Whatever. The principle benefit of an OID RR would be consistent
data-typing, so the best use would be OID on both namespaces, instead of
OID for one and PTR for the other. I'm not even sure that a data-type is
relevant given the OID syntax. It would likely just be a sequence of
labels so any label-based datatype would work since the attribute trees
are mostly isolated when they do actually exist. Given all of the above,
PTR and CNAME RRs should work fine.

As I also said, I'm generally opposed to using DNS for directories. It's a
naming service, not a directory. The more directory-like features and data
that creep into it, the harder it is to make a distinction.

---

From: Robert Elz <[email-masked]>
Date: Fri, 22 Sep 2000 06:46:01 +1100

Date:        Thu, 21 Sep 2000 10:59:31 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are also distinct benefits to having explicit domain name entries,
  | such as being able to use CNAMEs and additonal RRs. You might want:
  | 
  |    some.other.oid.osi.int.	CNAME	some.oid.osi.int.
  |    some.oid.osi.int.	OID	99.88.77.6.5.4.3.2.1
  | 				TXT	"OID for XYZ"
  | 				RP	"[email-masked]"
  | 
  | Etcetera. Building a reverse name from the PTR data won't allow for any of
  | that to occur.

What?

   some.other.oid.osi.int.	CNAME	some.oid.osi.int.
   some.oid.osi.int.		PTR	1.2.3.4.5.6.77.88.99.OID.ARPA.
				TXT	"OID for XYZ"
				RP	"[email-masked]"

What's the difference?

kre

---

From: Gunther Schadow <[email-masked]>
Date: Thu, 21 Sep 2000 13:54:16 -0500

Eric,

the reason why I moved away from explicit OID RRs is because I've got
the sense from the group that enthusiasm for this project is relatively
low. Also, what good is "my own RR" when it isn't widely implemented?
Since I wanted to deploy this project *widely* with an organization where
DNS, BIND and UNIX hackers are the utter minority, I have to use what
is there already. That's why using PTR records seems to work best, unless
of course, you have another idea.

I can now simply do this:

hl7.org.	IN PTR	113883.1.840.16.2.OID-ROOT.NET.

(Yes, I have registered OID-ROOT.NET. for this in order to start this 
project right away.)

Each known OID will have a "descriptive" RR (TXT, RP, etc.) underneath 
OID-ROOT.NET. This will include named OIDs (the idea of named OIDs is set
forth in the original ASN.1 spec.) Thus, for example, 

$ORIGIN OID-ROOT.NET.
ISO		IN PTR		0.OID-ROOT.NET.
0		IN TXT		"International Organization for Standardization"
CCITT		IN PTR		1.OID-ROOT.NET.
1		IN TXT		"International Telecommunication Union"
JOINT-ISO-CCITT	IN PTR		2.OID-ROOT.NET.
2		IN TXT		"Joint ISO and ITU-T assignments"

ISO.STANDARD	IN PTR		0.0.OID-ROOT.NET.
0.0		IN TXT		"ISO Standard"
4217.0.0	IN TXT		"ISO 4217 - Currency Codes"
;...
16.2		IN TXT		"Country Assignments"
840.16.2	IN TXT		"United States of America"
1.840.16.2	IN TXT		"U.S. Organizations"
113883.1.840.16.2 IN TXT	"Health Level-7"

So, you see that the OID-ROOT.NET. zone will contain all OIDs, numbered 
and named. This data could all be generated from Harald Alvestrand's database. 
If someone claims authority over his DNS OID space, that person can get a 
normal DNS assignment, i.e.,

113883.1.840.16.2 NS	dns.hl7.org.

However, this would only be possible if the claiming entity makes sure
that it takes over DNS maintenance of the subordinate OIDs. For example, if
ANSI comes and wants

840.16.2	NS	oid.ansi.org.

they would have to make sure they maintain 1.840... and 113883.1.840...
assignments. Alternatively, they could map an NS record back to the
root.  The idea is that if this project flies, more and more zones 
will be taken over by their rightful owners until the entire OID system
is on the DNS track.

The problem with named OIDs and CNAMEs is that the DNS was not designed
for allowing synonymy of symbols and a canonical number for each step
independently. Thus, symbolic OID resolution is somewhat of a hassle.
As much as I understand the DNAME proposal (which just got its 
first implementation in brand-new BIND9), even DNAMEs will not be able
to handle all that variance sufficiently well. 

I have two algorithms to resolve symbolic and mixed numeric/symbolic 
OIDs so far. Will bounce this back off you to get criticism.

One question I have before I leave: are there any worries that the 
DNS system may be overloaded through such new uses outside simple
name-to-A* record mapping? Are there any worries the system would
be overloaded by resolution algorithms that retry various combinations
of names and numbers, and resolve each OID representation in multiple
steps until a pure canonical form is found? I mean, I don't want to
abuse a precious infrastructure.

any opinions on that?
-Gunther

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 21 Sep 2000 12:59:51 -0700

> What's the difference?

There is no difference if the forward-lookup domain name is defined in
both cases. Maybe I read the first message wrong, but it looked like
things were leaning towards PTRs without matching forward lookups, which
would have only allowed a number-to-name match without any supplemental
data being associated with the name.

---

From: Gunther Schadow <[email-masked]>
Date: Thu, 21 Sep 2000 16:03:41 -0500

> data being associated with the name.

Forward/backward lookup, hmm. If I read the DNS spec. right, PTR is simply
a pointer to another name in the DNS space. As such, there is nothing
in the PTR definition that limits it to "backward lookup" of IP names.

The other thing is, it doesn't make sense to do backward lookup with OIDs,
because OIDs are not addresses. OIDs are really simply names. There are 
canonical OIDs -- numbers and dots only --, and there are OIDs with some
symbolic components. The main use of the DNS is to resolve

1 general DNS names to OIDs
2 OIDs with symbolic components to canonical OIDs
3 canonical OIDs to TXT and RP records, mostly for human consumption. 

There is not a single backward mapping from a canonical OID to a symbolic
OID or general domain name, therefore the kind of backward lookup we have
with PTR from the IN-ADDR.ARPA. domain into normal domains does not exists
for OIDs.

regards
-Gunther

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 21 Sep 2000 15:20:29 -0400

> Etcetera. Building a reverse name from the PTR data won't allow for any of

CNAMEs can point to PTR-owning names (cf. RFC 2317). PTR's can co-exist with
other record types. I think PTR works just fine as a generic, non-aliasing,
name-to-name mapping type. It is only tradition/convention which limits PTR's
to reverse lookups.

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Fri, 22 Sep 2000 02:31:39 -0400

Be warned that US Patent 6,003,077 (probably, I'm not a lawyer) covers
some of the territory you're talking about.  To the best of my
knowledge the rights to that patent are held by Wind River Systems.

I hereby request that the namedroppers moderator rule the inevitable
flamage about software patents out of scope.  For the record, in a
probably futile attempt to save the moderator some work: I tried and
failed to talk my former employer out of patenting this.

[ will do   -- rb ]