James and all,

  Looks pretty good as far as it goes...  Unfortunately it doesn't go very far.
Please keep us informed as to the progress of this paper.  >;)

James Seng wrote:

> This is the unedited memo on a idea which we developed while working on
> multilingual domain names.
>
> The edited paper will be placed on the Asia Pacific Networking Group
> website at      http://www.apng.org/commission/idns/idomain/msoa.html
> when it is ready.
>
> Constructive feedback, flames, criticism will be welcome.
>
> James Seng
> Software Engineer
> BioInformatix Pte Ltd
>
> --- CUT HERE ---
> Title: Is it possible to de-monopolize DNS?
> Date : 3rd Jan 1998, draft-1
>
> Authors
> Mr James SENG Ching Hong <[EMAIL PROTECTED])
> Dr TAN Tin Wee <[EMAIL PROTECTED]>
>
> Contributors
>
> 1. Introduction
>
> Domain Name System or DNS is a distributed/hierarchy name spaces system,
> with hierarchy roughly corresponding to organizational structure and names
> using "." as the character to mark the boundary between hierarchy levels.
> (Readers are presumed to understand how DNS works. Please refer to RFC1034
> and RFC1035 for further information).
>
> The nature of DNS is that each organization is given a delegation of
> the start of authority (SOA) of its domain name space. It is the
> responsibility of each SOA to maintains the domain name space and
> they can sub-delegation part of its name space to another SOA.
>
> At the top-level domain (TLD) before the organization name space, similar
> delegation is been deployed. TLD is usually control by a network information
> center (NIC) at common level or at country NIC level. The root of the
> hierarchy of DNS is hold by ICANN. (Although the authority of ICANN is of
> dubious level, it is not the purpose of this memo to discuss this.)
>
> Hence, the nature of the DNS protocol encourages a monopoly structure.
> Each SOA is essentially a monopoly of its own domain name space. At a
> organization level, this is understandable since each organization would
> like to have control over its own name space. However, at the TLD each
> NIC is given monopoly of the whole branch of name space.  While this
> is technical sound, when a NIC commercializes, it become questionable
> that should such monopoly structure remains?
>
> This memo aims to de-monopolizing the DNS by proposing a Multiple Start
> of Authority system.
>
> 2. Multiple Start of Authority
>
> The basic concept of multiple start of authority (MSOA) is relatively
> simple. Instead of delegating one domain sub-space to one authority,
> the delegation is given to a few parties. Of course, this does not
> applies when delegating SOA for an organization.
>
> The implementation of MSOA can be done via two ways:
> 1. Organization changes
> 2. Technical implementations
>
> 2.1 Organization changes
>
> It is generally believe that the current DNS is unable to cope with more
> than one SOA. That is generally quite true from a technical point of view.
> Nevertheless, it is still possible for more than one party to hold authority
> of a domain space if some co-operation is been done.
>
> When delegating a SOA of a domain space, one more level of authority below
> the SOA is assigned known as registrar. Been a registrar of a SOA allows full
> access to the zone files of that domain space. A simple system like FTP could
> be use to grant such access. Alternatively, a more complex auditing system
> could be design via CGI/HTML such that each registrar would be able to create,
> modify and delete entries within its own control and the system would generate
> a new zone file after each updates.  The cost of operation of the SOA could
> be shared among the registrar.
>
> Thus, by doing so, all registrar would be granted equal opportunity and if
> domain space is been sold, free market will prevail thus breaking the
> monopoly enforced by the DNS protocols.
>
> 2.2 Technical implementations
>
> Alternative way of implementing MSOA could be done by modify DNS servers
> and perhaps its protocols. There are several ways which this could be
> done and we shall discuss a few method for consideration.
>
> Theoretically, the current DNS protocol is able to handle MSOA despite
> it was not actually designed for it. This could be done crudely by:
>
> 1. When delegating a MSOA for a domain space, list all the name servers of
>    all the multiple start of authority in the zone files. For example,
>
>    .COM         IN      NS      111.111.111.100         ; SOA 1
>                 IN      NS      111.111.111.101         ; SOA 1
>                 IN      NS      222.222.222.100         ; SOA 2
>                 IN      NS      222.222.222.101         ; SOA 2
>
> 2. The name servers of each MSOA has to modify such that when it receives
>    a DNS query within its own zone, it only replies to the query if it
>    hold an entry for the zone.
>
> Thus, when a resolver sends a query and there is no response from the
> server after a few retries, it will move onto the next server and so on
> until an answer is found.
>
> Of course, this is extremely inefficient and a long query time is expected
> as the resolver try one server and another. Nevertheless, this is
> compatibility with all the current resolvers.
>
> This could be improve if resolvers would send out multiple queries to
> all the name server at the same time.
>
> Alternatively, a new Response Code, RCODE could be implemented in the
> DNS protocol which is similar to RCODE 3 (Name Error) but contain
> additional information on where to find possible authoritative answer
> from.
>
> 3. Issue to be address in future drafts
> o Consistency of name space data
> o Name space poisoning
> o Multiple Authority
>
> __________________________________________________
> To receive the digest version instead, send a
> blank email to [EMAIL PROTECTED]
>
> To SUBSCRIBE forward this message to:
> [EMAIL PROTECTED]
>
> To UNSUBSCRIBE, forward this message to:
> [EMAIL PROTECTED]
>
> Problems/suggestions regarding this list? Email [EMAIL PROTECTED]
> ___END____________________________________________

Regards,

--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

S/MIME Cryptographic Signature

Reply via email to