[ draft-iahc-datta-meta-registrar.txt ] [ Author: Aveek Datta, adatta@ml.org ] [ Expires: March 1, 1997 ] Sample Meta Registrar Status This proposal has NO official status. History BETA November 21, 1996 Initial Document Written 1.0 January 16, 1997 Rewritten and submitted Abstract This document is intended to show AN implementation of a shared registry. It was not written to be _the_ system used by CORE as many improvements can be made. It is here for comparison and discussion purposes. Assumptions The meta-registrar described here is minimalistic and is intended to be the simplest way for both individual registrars and meta-registrar operation. Meta-Registrar Database The meta registrar main database consists of three parts, domain information, registrar ID, and administrator ID. Domain Information As a top level meta-registrar, a meta-registrar will only be serving subdomains. Hence in some format, the following data is stored as Domain Information: Full Second Level Domain Name (aka ml.org) Domain Name Servers (unlimited amount) For each server: (fully qualified domain name, glue record) glue record field ignored if nameserver is not under given SLD Unlike the Internic there will be no HOST database, simply because a given nameserver can have many names. Registrar ID This is a unique ID given to registrars using this meta-registrar. There will be a separate Registry Database that can contain more administrative info for lookup purposes. This database can be modeled after the contact databases used by the Internic. Administrator ID This is the actual administrator of the ID. Only one ID is stored -- this person is equivalent to the Administrative Contact in the current Internic System. The Technical Contact is considered to be the registrar itself; it should maintain its own more complete databases. The administrator ID refers to another database, similar to the registrar database. Technical Implementation For generality of use, I suggest using a socket based protocol. Assuming that, several options arise: 1) Using Email: It is a reasonable assumption that any registrar can easily setup email. 2) Using Web: In these days it is also possible to use the current web based interfaces (see my site). 3) Using Another Service: FTP or some of the RPC functions are a possibility. 4) Using a specific client/server program. 5) Using a combination of the above. This is preferred. The meta registrar will have "pre-parsers" which will convert sent data over any service into data which the final parser can use. These pre-parsers have to worry about security -- authentication and encryption of requests made by registries is a high priority. However, this problem has been dealt with separately in many fashions and one of those can be adapted for use here. (I know very little about Computer Security and hence I will not go into that here). Parsed Data A format like the Simple Registrar Protocol proposed by K. Crispin November 1996 can be used. In any case, this is more an administrative detail; the form should only ask for the data required for the meta registrar, no more, no less. Data Upload The simplest way to implement this is have one central server which recieves requests, timestamps them, and services them in order. Each request is authenticated, verified, and then dealt with appropiately. However, with any large system the load on such a central server would be tremendous. In addition, far away registries (on the Internet) will have a disadvantage in data travel time to the central server. To help resolve this problem, in addition to the central server there could be several well placed secondary servers. Registrars should send data to their nearest secondary server. The secondary server could then do some pre-pre-parsing, if necessary, and then create a "packet" of requests every X minutes, hours, etc. All secondary servers could more or less synchronize their clock and send this packet every X minutes, hours, etc. All secondaries would send their data to the central server, at about the same time, who would process packets one time period after they were sent, in order to give time for all secondaries to send data. After recieving the packets, it would merge them into one large packet, using random algorithms to settle "ties" on timestamps up to any given resolution (one minute, etc). After this merged packet is created, the server would simply linearly serve each packet. For optimization and security purposes, it might make sense to have two central servers -- one which recieves data but ONLY from the secondary servers, and then collates/merges this data. Then it sends the merged packet to a heavily protected central database server which processes them. The central database server when done sends another packet to the central communication server, who then proceeds to resend out the results of the processing either to secondary servers or directly to the registries. While having secondary servers helps solve some problems, it creates others -- the security on several secondary servers around the world is a hard problem to deal with. However that is partly an administrative issue and partly a programming issue of audits and logs. These issues can be dealt with. Data Update Registrars are allowed to send in update requests for any domain that is associated with their ID. The meta-registrar wants to only receive updates from registries, who it hopes it will operate in a simple, efficient, and ethical manner. By limiting updates to registries only, the meta-registrar has only to provide some limited tech support to the registrars. However there are situations when a registrar abuses the system. For this, creation of an oversight committee which will take and investigate requests directly from the user. This is only as a last resort and multiple complaints against any given registrar should be grounds to removal of registrar privileges. In any case a user may petition the committee to a) change the hostname administrator ID b) change the hostname registrar ID in cases where a registrar either 'illegally' removes a user from the administrator slot, or where a registrar refuses to relinquish rights to another registrar. Estimated Costs These are nothing more than my guesses. Hardware (Central Server(s)) $10,000 Connectivity (hopefully located with some major ISP, so minimal setup charge) Software Creation $30,000 Proposed: Two month creation period where one administrator/programmer and three programmers are hired to work full time to implement this software. Software Beta-Testing $10,000-$20,000 Proposed: Two-three month period where the above staff works part-time outside of the administrator to resolve bugs. Annual Personnel Charge $50,000 Proposed: All that is needed is one full time administrator, preferably the original one. Annual Connectivity and Plant Charge $10,000 Administrative Oversight Committee (per year) $40,000 Proposed: Open Internet process overseen part time by compensated Internet 'engineers'. Secondary Server Cost see below Etc $??,??? The organization should be a non-profit. Fees should be paid to cover the above costs. Registrars should be encouraged (by credit towards the fee) for providing secondary servers, both DNS and possibly the type outlined above. Legal Issues I am not a lawyer or even very knowledgeable about the law. The meta-registrar should just be considered a repository for data that is maintained by the registrar listed and owned by the ID listed. As such, a contract should be signed that the meta registrar only serves these names and assures that there are no conflicts. Outside of that, all policy is set by the registrats themselves and hence they should be held accountable for the data. Conclusion The meta-registrar modeled here is not applicable directly for what the IAHC needs. However I hope it stimulates some thought and provides some insight into how this *could* work. Comments and questions are welcome. Email is preferred. Contact Information This text written and copyright 1997 by Aveek Datta adatta@ml.org c/o Monolith Coalition http://datta.ml.org Box 8159 Phone 412-862-2661 Pittsburgh PA 15217 Pager 412-686-9742 Network Administrator Monolith Coalition Free Internet Services, including world's largest free 3rd level registry, http://www.ml.org Permission to copy this document as long as credit is given. Permission to place on IAHC website is given.