INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT STLD Working Group K. Crispin Category: Informational November 1996 Technical Support for Shared Top Level Domain Registries Status of this Memo This document is a submission to the Internet Ad Hoc Committee. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This Internet-Draft briefly describes the central technical problems for supporting Shared Top-Level Domain Registries, and outlines a solution using the DNS Dynamic Update and DNS Security Extensions proposals currently under development. This draft is a companion to draft-iahc-stldla-crispin-00.txt. Introduction There are two technical problems that must be solved before shared registries can become a reality: first, and by far the more significant, guaranteeing atomic first-come-first-served semantics for domain name creation, and second, making "whois" style contact data available when it is spread across multiple distributed registries. Fortunately, both of these problems have already been essentially solved, though in slightly differing contexts. Background For a couple of months the mechanics of shared registries was debated in the shared-tld mailing list (shared-tld@higgs.net). One problem dominated the discussion: how to avoid synchronization problems when adding a domain name. To be concrete, suppose that registry A and registry B both server Top Level Domain .TLD. At about the same time, each registry is contacted by a customer that wants the domain name "foo.tld" (two different customers, one for each registry). Each registry does a DNS query and discovers that "foo.tld" is not in use, and so each proceeds with the transaction. This appears to be a classic distributed database update problem, with well-known and obvious solutions. However, the issue is how best to solve the problem within the context of DNS and the realities of competing registries. The easiest solution is when there is a central trusted database that manages all synchronization issues, and indeed, a popular implementation discussed on the mailing list was to just use a commercial database package, run by some trusted third party like the IANA, to handle inter-registry synchronization. However, independent work enhancing DNS functionality, in my opinion, makes that discussion moot. The obvious place to manage inter-registry synchronization is in DNS itself, and the protocols necessary have been almost completely defined in a series of recent Internet Drafts. This draft merely shows how to use those DNS extensions to implement the coordination needed between registries. The "whois" problem received little discussion on the mailing list, relatively speaking. However, that problem as well has been essentially solved. The "rwhois" protocol is designed to deal with distributed "whois" data, in almost exactly the manner required. Infrastructure The Shared TLD Licensing Authority grants Registry Licenses to each registry for a sTLD. The license requires the holder to maintain, either directly or through a sub-contract, DNS services for the TLD. One of the Licensees for the TLD has their nameserver configured as a Master Nameserver for the domain; the others are secondaries. Note that there is little extra work involved in running the Master Nameserver -- it is just configured differently and contains slightly different data from the secondaries. The Master Nameserver maintains the zone data for the TLD as a Secure DNS zone [DNSSEC][SECDNSUPD], and accepts updates for the zone from anyone who has the appropriate secret key. These updates use the UPDATE function described in [DNSUPD]. Each registry for the TLD possesses a shared (shared among all the registries) key that allows them to update the zone. Each registry also possesses a unique private key that enables them to sign individual RRs in the zone. The flags on the shared key for the zone are such that the possessor can only update current RRs that are signed by the private key attached to the RR. Thus, a registry can 1) add new records to the zone and 2) change records that it has added. [The current drafts are very close to these semantics, however, there are some differences in detail which may need to be worked out.] Operations The basic operations for supporting shared TLDs are RESERVE, CONFIRM, LOOKUP, and DELETE. Other supporting maintenance functions are necessary, but their precise definition is not important here. These four functions define an extremely simple database system. Each has a required argument of the domain name in question. RESERVE reserves the domain name for a short period of time, and returns an error if the name is already in use, either as an existing operational domain, or through a prior reservation. A "reserved" name is not functional, in the sense that no IP address or other information can be retrieved for it. CONFIRM changes the status of a reserved domain name to a functional domain name. Only the registry owning the name can CONFIRM it. LOOKUP returns the exact same information as RESERVE, but does not make a reservation. DELETE removes a name from DNS. Only the registry owning the name can delete it. These functions are implemented in DNS as follows: RESERVE is implemented with an UPDATE request that includes the zone key, the domain name, and a TEXT RR that includes the IP address of the registry, with a very short TTL, that is signed by the registry with the registry key. [It would be possible for a registry to cheat on the TTL. It would be easy to put in code to prevent it. Such cheating could result in a loss of registry license, however, and since the record is signed with the registry key, it would be hard to lie about it.] If the domain is already present [marked by a RR signed by some other registry], of course the reservation fails, and an appropriate error is returned. After the TTL expires the reservation is deleted automatically. [Which RR to use to contain this data is an issue. There would be advantages to defining a new RR specifically for the purpose of reserving a name. However, a TEXT RR will work. Note that only the nameservers directly supporting registries would have to know about a new RR type.] A CONFIRM is done by updating the domain with a longer timeout (a year or more -- basically a time reflecting the amount of time that has been paid for), adding NS records for the domains nameserver, and potentially other RRs. After the longer timeout expires the domain is eligible to be deleted from the primary nameserver. It is the responsibility of the end customer and the registry to renew the name. A LOOKUP is just a standard DNS query. A DELETE is an UPDATE request that removes the RRs for the domain. The whois data is maintained at the registry. The primary nameserver has resource records with the IP of the owning registry, where an rwhois server is running that will return the appropriate information. Implementation The protocols described in [DNSSEC] have been partially implemented in a version of BIND. The Dynamic Update protocols have not, to my knowledge, been implemented yet, and the protocols for combining Security Extensions and Dynamic Update are close to final. A reference implementation in BIND is probably less than a year away. An implementation of a registry interface could easily be completed in the same time frame. References [DNSSEC] "Domain Name System Security Extensions", D. Eastlake, C. Kaufman, 08/02/1996. [SECDNSUPD] "Secure Domain Name System Dynamic Update", D. Eastlake, 02/22/1996. [DNSUPD] "Dynamic Updates in the Domain Name System (DNS UPDATE)", P. Vixie, S. Thomson, Y. Rekhter,, 03/14/1996. Author's Address Kent Crispin L-61 Lawrence Livermore National Laboratory PO Box 808 Livermore, CA 94550 kc@llnl.gov kent@songbird.com +1 510 422 4273