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____________________________________________
