Internet-Draft A.Sullivan Category: Informational Top Domain Registry Inc. Expires May 31, 1997 November 1996 Modifications to DNS iTLD Management Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifically proposes some ideas for making near term changes to DNS iTLD management. These ideas are formulated with goal of providing a fair and stable DNS environment in which commercial enterprises can operate. Although this proposal is incomplete, it serves as a basis to resolve near term issues related to iTLD and registry management. This document plagiarizes J.Postel , IANA , October 1996, "New Registries and the Delegation of International Top Level Domains", and B.Manning, ISI, P.Vixie, ISC, October 1996, RFC 2010, "Operational Criteria for Root Name Servers"., and D.Crocker, IMC, November 1996, "FRAMEWORK FOR MODIFICATIONS TO DNS ITLD MANAGEMENT". The philosophy of these documents represent well thought ideas for the operational requirements of new registries. This document directly answers the questions posed by D.Crocker in "FRAMEWORK FOR MODIFICATIONS TO DNS ITLD MANAGEMENT". 1 Introduction The motivation for creating this document was to present ideas that would lead to a succinct and well defined process modifying the management of iTLDS . The proposed process is: 1) Adopt Postel-Draft. 2) Have the committee determine the technical requirements necessary to run a registry - lots of good work done by Elz, Bush, Bradner, Patton, Vixie, and Manning. In fact with a little work we could probably turn RFC 2010 - Operational Criteria for Root Name Servers - into Operational Criteria for iTLD Name Servers. 3) Release a set of test tools that will be used to test the potential registry DNS servers. Something like a spray test comes to mind among others. Each registry should have at least 2 geographically distinct DNS servers. - a 2 week period during which potential applicants could get their systems ready for test. 4) Have a period of 2 weeks during which all iTLD registry applicants apply to run iTLD registries. 5) Test all applicants servers and accept the top 50 to be registries (this is as objective as you can get). 3 weeks 6) Announce the 50 new registries. 1 day 7) Have a lottery or draft - like that which exists in professional sports. Each of the 50 registries would get a number based upon a random selection. Then each registry would choose 3 domain names - 1 domain name at a time in serpentine sequence. 1-50 then 50-1 and finally 1-50. 8)Each registry would then announce their domains and policies. 2 weeks. 2. Choice of new iTLDs 2.1 How many iTLDs will be created, and at what rate? The number of iTLDS created will be determined by the demand for iTLDs. Any qualified registry is allowed to run 3 iTLDS. All approvals for new iTLDs will be done on a yearly basis. 2.2 What strings (names) for these iTLDs should be authorized? Any names shall be authorized which do not violate known trademarks. 2.3 How shall they be selected? The names for iTLDS shall be selected by the qualified registry applying to provide registration services for that iTLD . 2.4 What will the policies be for assigning second-level names under these iTLDs? That will be at the discretion of each registry serving that iTLD. All policies shall be published. However, the reselling of second-level names shall be prohibited. 2.5 How shall disputes among assignees for second-level names be resolved? These must be resolved by the registries which administer these names. Each registry must have a published dispute policy. 2.6 How should trademarks be preserved? If two companies hold trademarks for the same name, then the first holder owns the domain name. The proper courts always have authority over registries, and all registries shall comply. 3. Choice of new registries 3.1 How many new registries shall be created, and at what rate? All registries shall become qualified registries by meeting operational requirements. All qualified registries shall be allowed to operate a registry. 3.2 What are the requirements for a registry operator, in terms of skills, financial wherewithal, operational performance, etc.? All applications are judged on two criteria: Resources (Skills, Finances, and Infrastructure) and Performance (Registry Services and Operations). 3.2.1 Resources: 3.2.1.1 Skills - The registration organization shall demonstrate that there are people within the organization that have sufficient skills to operate a registry. 3.2.1.2 Finances - The registration organization shall demonstrate financial resources by providing a report ( to remain confidential) that indicates those resources necessary to provide registry services. This shall include all fees necessary to be paid to ISOC. 3.2.1.3 Infrastructure - 3.2.1.3.1 Domain Name Server software -The iTLD registry shall choose a name server package to run on all of the registry's servers. It is expected that the BIND server will be used, and new versions or other servers will be specified from time to time. Domain Name Server software upgrades will be specified and scheduled by the registry, and must occur on all of a registry's servers at the same time. These name servers shall run the latest release of the BIND code (4.9.x at present), and may include local enhancements, changes, or operational improvements. 3.2.1.3.2 Dedicated Host hardware - A name server host should have no other function, other than those related to registration, and no access other than for system or network administrators. Other network protocols should be served by secured port software. If login is permitted from other than the system console, then the login service must be by encrypted channel (e.g., Kerberized and encrypted rlogin/telnet, the secure shell (SSH), or an equivalent). The description of at least two name server hosts in geographically disperse locations for the iTLDs in question. The names and IP addresses of the hosts which are proposed to serve the iTLDs. 3.2.1.3.3 Physical environment for hardware - A name server host must be located in a secure space such as a locked computer room or a data center with restricted access. The power supply should be redundant, using batteries, generators or some other means to protect against utility power failures. Network connectivity should be redundant, so that a single wide area line failure cannot completely isolate the name server host from the rest of the network. 3.2.1.3.4 Offices - A help desk and staff to answer questions via electronic mail, fax and normal telephone during customary business hours as defined by theregistry. There shall be 24x7 response for name server hosts that go down. 3.1.2 Performance: 3.1.2.1 Registry Services 3.1.2.1.1 Access to Registration Services - All registry service shall be available 24X7 There shall be 24x7 response for name server hosts that go down. The administrators responsible for a name server will respond to e-mail trouble reports within 24 hours. Personnel issues such as vacations and illness will cause responsibilities to be delegated and/or reassigned rather than ignored. After hours telephone numbers must be made available to the zone master for non published use in emergencies. An escalation contact name, e-mail address, and telephone number will also be made available to the zone master in the event of non response through the normal channel. 3.1.2.1.2 Access to the Registration Database - The DNS database files and "Whois" databases maintained by any iTLD operator are deemed to be publicly available and public, non-protected, information. The intent is to allow easy access to the information needed to investigate and correct operational problems. A registry shall provide guaranteed availability of the registration data in a useful form should transfer of responsibility become necessary, e.g., regular publication of the information, or regular deposits of copies of the information with a reputable "escrow holder" instructed to release the information to the IANA. The IANA is authorized to designate an organizations as the escrow holder of said database information for the purposes keeping terminated registry iTLD accessible . The escrow holder will have to keep very up to date copies of the database probably through some automated system that makes a copy on a daily basis. There may be reasons(other than "transfer of responsibility" or "termination of registries") to provide controlled access to the data held by the escrow holder for special purposes, such as legal proceedings in trademark cases. The registry must provide a means, via the "Whois" protocol, to search the database of second-level domains maintained by this registry and return common directory information. This information shall include, but not necessarily be limited to: a) The "owner" of the second-level domain, including contact name(s), physical address(es), and telephone number(s) of the persons responsible for the operation of the second- level domain. b) The name server host names and IP addresses serving that second-level domain. c) The current status (operational, on hold, pending, etc.) of that second-level domain. iTLD registries are expected to provide their own directory service, and "rWhois" is designated as one of the operational choices which a registry may wish to utilize. However, no attempt is made to mandate any particular technical or organizational requirements from a registry to service requests for lookups of a domain holder in other, competing registries and iTLDs. Internal database and operational issues are to be decided by the registry. These issues, including pricing to customers of the registry, are properly free-market issues and are excluded from the control of the IETF, IANA, ISOC and other related organizations. 3.1.2.1.3 Help Desk- A help desk and staff to answer questions via electronic mail, fax and normal telephone during customary business hours. 3.1.2.1.4 Policies - Published policies on services offered, registration procedures, and fees. 3.1.2.1.5 Appeals mechanism -A clear description of the appeals mechanism within the registry, including the entry point for appeals and the expected response time. 3.1.2.1.6 Information - All of the public information identified above shall be made available via WWW, FTP, and automated email responder at an address associated with the organization. 3.1.2.2 Operations - 3.1.2.2.1 Internet Connectivity - A description of the Internet connectivity to the site where each name server for each iTLD will be located. 3.1.2.2.2 Name server Performance - The description of at least two name servers in geographically disperse locations for the iTLDs in question. 3.1.2.2.3 Network interfaces - Name servers must send UDP responses with an IP source address (and UDP source port number) equal to the IP destination address (and UDP destination port number) of the request. Also, a name server might have multiple real interfaces, but only the one with network performance and reliability to the largest number of destinations will be advertised. 3.1.2.2.4 Network security - The system and network administrators should educate themselves about potential threats, and stay current on CERT bulletins regarding network break ins. The system staff should periodically audit the name server host's activity logs and be able to detect break ins during or after the fact. 3.1.2.2.5 Host performance - As of the time of this writing, a name server must be able to answer 1,200 UDP transactions per second with less than 5 milliseconds of average latency. Because the network is still growing at a high rate, the ability to grow to 2,000 transactions per second and still support a 5 millisecond latency is highly desirable. Note that this requirement affects both the host and the network infrastructure to which that host is attached. 3.3 How shall disputes for registry assignment be prevented or resolved? All registries shall be qualified by objective criteria. A lottery and draft shall be held once a year - like that which exists in professional sports. Each of the qualified registries would get a number based upon random selection. Then each registry would choose 3 domain names (iTLDs) - 1 domain name (iTLD) at a time in serpentine sequence. 1-n then n-1 and finally 1-n. All names that the registries would like to use are submitted before the draft so that only qualified iTLD names may be chosen from the list of submitted qualified names. 3.4 How shall stability in registry operation be achieved if a registry operator ceases operation or is changed? iTLD registries may decide they no longer wish to operate their registry. Likely, the operation will not be profitable when this occurs, yet the registrants under the iTLD may need to be supported for a considerable time. Some portion of the fees in the ISOC-managed iTLD fund may be used to pay for some other organization to operate the failing iTLD or registry until it again becomes viable or until the registrants have safely migrated elsewhere. Succession issues related to the relationships between customers of a registry and that registry itself are properly contractual matters between the registry and its customers, and when properly attended to do not involve the IETF, ISOC, or the IANA. The IANA or its designee may operate an "escrow holder" to insure that the records contained in a registry will remain available in the event of intentional or accidental destruction due to a registry forfeiting a iTLD. Organizations providing registry services may elect to terminate their involvement in this program and release the iTLD name space delegated to their organization under the following circumstances: Transfer of Authority: Any organization may transfer the authority for, and registration services provided, for a iTLD to any other organization provided that the new registration authority complies with all provisions of this memorandum. The business and financial terms under which this transfer is conducted shall be properly between the old and new registry organizations and not under the jurisdiction of the IANA, the IETF or the ISOC. However, the IANA must be notified of such a transfer, and the charter of the registry for the management of these iTLDs shall be reviewed as a renewal of the charter at the next normal session of the ad hoc committee. Orphaned iTLDs: iTLDs which are "orphaned" by a registry that constructively abandons them or ceases business operations without first securing a successor organization to assume the authority and registration services for that name space shall be deemed "abandoned". Abandoned iTLD name space shall be auctioned to the highest bidder by an open, competitive bid process adjudicated by the IANA or its designees, which shall be conducted without undue delay. During the interim period in question the IANA shall be authorized to designate one or more firm(s) to hold the existing registration records to prevent the interruption of service. Recovered iTLDs: An organization that is found by the IANA to be in violation of the terms of this delegation memorandum shall be given notice by the IANA of intent to recover the iTLD domain space allocated under this policy via normal postal mail. Within 30 days, the organization against which the complaint has been lodged shall a) cure the violation(s) of this policy, (b) transfer authority to another organization under transfer of authority above, or (c) constructively abandon for public auction the name space under the provisions of orphaned iTLDs above. Where the facts are disputed regarding possible violations of this policy, the IANA is authorized to promulgate reasonable adjudication policies which should include an arbitration provision. 3.5 Shall multiple registries be allowed to share authority for a single iTLD and, if so, how? Multiple registries shall be prohibited from sharing authority for a single iTLD. 3.6 Is it useful to distinguish between sharing among members of a cooperative group, versus sharing among unrelated, and potentially hostile, organizations? Registries can contract out some services to other registries and cooperatives may be formed. However only one registry shall be the authority for an iTLD and shall enforce and maintain all the policies set forth for those iTLDS. 4. Assignment vs. Operation - What distinction should be made between operation of an iTLD assignment process, versus operation of the iTLD data base service? Assignment of iTLDs shall be made exclusively to only one registry. That registry is responsible for the operation of the data base service, but that registry may contract out any services including data base services. 5 IAHC Operation 5.1 What method should be used for selecting winners of new iTLD? A lottery and draft shall be held once a year - like that which exists in professional sports. Each of the qualified registries would get a number based upon random selection. Then each registry would choose 3 domain names (iTLDs) - 1 domain name (iTLD) at a time in serpentine sequence. 1-n then n-1 and finally 1-n. All names that the registries would like to use are submitted before the draft so that only qualified iTLD names may be chosen from the list of submitted qualified names. 5.2 What fees should the ISOC/IETF collect for the establishment of new iTLDs and registries? 5.2.1 The Application Fee A refundable application fee of USD 1000 payable to the "Internet Society" to be deposited in the "iTLD escrow fund". 5.2.2 The Annual Fee Registries shall pay to into the ISOC-managed iTLD fund an annual fee of USD 10,000. A percentage scheme does not take into account delinquent accounts, discounts, other business practices and schemes. The overhead of a royalty scheme would be prohibitive. Therefore, no percentage schemes will be used. Such fees are payable to the "Internet Society" and are to be paid on a yearly basis. 5.3 Due to the commercial concerns now present on the Internet, with respect to the DNS, any changes made are likely to engender dispute. How can the IAHC function effectively in creating these changes, and avoid or reduce its involvement in such disputes? By setting new policies that effectively define parallel competing iTLD registries - there will be no changes to the existing infrastructure to engender dispute. Any changes created by the IAHC shall be backward compatible with the existing DNS infrastructure. 6. Security Considerations There are no known security considerations beyond those already extant in the DNS. 7. Acknowledgments This document plagiarizes J.Postel , IANA , October 1996, "New Registries and the Delegation of International Top Level Domains", and B.Manning, ISI, P.Vixie, ISC, October 1996, RFC 2010, "Operational Criteria for Root Name Servers"., and D.Crocker, IMC, November 1996, "FRAMEWORK FOR MODIFICATIONS TO DNS ITLD MANAGEMENT". , and these in turn were contributed to by many others. 8. Author's Address Alan Sullivan Phone: +1 716 533-2387 Top Domain Registry Inc. Fax: +1 716 533-1410 1550 Rush-Scottsville Rd. Rush, NY 14543 Email: sully@frontiernet.net