North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: US Domain -- County Delegations

  • From: Michael Dillon
  • Date: Thu Jul 27 12:58:54 1995

On Thu, 27 Jul 1995, Paul A Vixie wrote:

> I think we're in violent agreement.  My old arguments against explicit paths
> are starting to hold true for what we are currently calling "addresses".  As
> I said in my last note, mapping of real-world objects to funny-world objects
> (that is, person/place names to host/network names) is a directory services
> problem and cannot be solved with DNS or anything like DNS.  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here I borth agree and disagree. It is fair to say that DNS is not an 
appropriate solution for the problems, however I disagree that something 
like DNS is also inappropriate. What DNS does is provide an arbitrary 
mapping between an individual and something related to that individual, 
namely a machine name at the place they do most of their net access. If 
we simply broaden things so that the arbitrary mapping can be chosen by 
the individual and the mapping can be portable, then I believe the 
problem is solved. 

By inserting another directory layer similar to DNS but with different 
top-level domains we can broaden the namespace as much as is needed. 
Suitable modifications could be made to tools like sendmail to query the 
directory layer either before or after querying DNS. The directory layer 
would then issue a DNS name for further lookup.

Therefore, VIXIE.BIND.HACKER.ROLE would resolve to VIXIE.SF.CA.US today 
and if you move to Australia you need only change the directory entry to 
map to VIXIE.COM.AU or whatever. Since we have 36 symbols to use for each 
level of naming, we should attempt to allow as many combinations as 
possible especially at the top levels.

The only reason I can see for using a different mapping layer is that the 
DNS system has other jobs to do and we should not overburden it with huge 
databases that do not help it carry out its primary function.

Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-542-4130
http://www.memra.com                             E-mail: [email protected]