Network Working Group P Faltstrom Internet-Draft Cisco Systems Expires: December 14, 2001 June 14, 2001 Explanation of the registry/registrar concept draft-faltstrom-registry-registrar-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsoleted 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 27, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract In discussions between IETF and ITU regarding administration of services specificed according to RFC 2916 [ENUM], it is observed that several documents talk about registries and registrars in a way which is not in accordance with normal use in the DNS. To help the discussions, IETF has via the ISOC Sector Membership in ITU-T submitted this text to the Q.1/2 Rapporteurs meeting in Oslo 25th - 29th June 2001. 1. Introduction Many documents that have been circulated regarding ENUM issues in the ITU-T have reflecte considerable confusion regarding DNS terminology. In particular, there appears to be confusion and inconsistent use of the terms "registry" and "registrar". Also, when DNS "zones" are hierarchically separated (at what is referred to as a "zone cut", using a process technically known as "delegation"), the and roles of these parties appear to be further confused. This document explains the terms, and argues that no attempt should be made to redefine them in an ENUM world relative to other DNS applications. 2. Zones and Delegations A domain name can exist in only one zone in the DNS. This is established in the definition of the DNS, where all domain names are found by querying first a server for the root zone, and then repeatedly querying servers in a recursive manner until the requested record is either found, or an authoritative "NO" is received. The recursion is based on a concept called delegations. The root zone contains delegations to the various top-level domains (TLDs) that exist. Each of those TLDs may (and usually does) have further delegations to servers that handle child (hierarchically subsidiary) domains of those TLD's. This relationship can be repeated at any place in the domain name hierarchy where a dot (".") is found: I.e., any domain may be structured to have one or more delegated subdomains, which may, in turn, have delegated subdomains, and so on, and each of those subdomains may be administered by a different individual or organization. For a given subdomain, the delegation itself consists of DNS records that identify the authoritative name servers for the subdomains. The examples below assume that DNS records have not been "cached": caching makes the process of finding a name more efficient (i.e., some steps may be bypassed since relevant information is already on hand), but does change the basic logic of the system. Example: The root zone contains a delegation for the domain INT, which points at the name servers for the INT domain. In the INT zone, delegations are present for subdomains of INT, such as ITU.INT. To find the IP address for WWW.ITU.INT, one first queries the root server. The root server gives back pointers to the name servers for INT. When queried, they, in turn, give back pointers to the name servers for ITU.INT. Those servers are then queried to obtain the IP address. 3. Registry and Registrar The organization that operates the DNS server(s) for a specific zone is called a registry. To get any kind of information into a zone, one has to contact that very registry. Given the way the DNS is designed (see above), the registry function for a given zone is necessarily a monopoly. To allow competition regarding registration services the market has introduced the concept of a "registrar". The registrar is an organization that can act, from a customer perspective, as a proxy for the registry. So the customer (registrant) who wants names registered in a specific zone does not approach the registry directly, but instead contacts a registrar. The registrar collects the necessary information, ensures that registrar-level conditions are adhered to, and then passes the information to the registry and verifies that the changes to the zone are performed. This way the registry can be extremely lightweight (not doing more than running a database and creating the zone file) while the registrars do all the work (which might include invoicing the registrant). The division of labor between registry and registrar is, however, not fixed by the DNS protocols. It differs somewhat among the various domain that use this scheme today (examples are the TLDs "COM", "UK" and "SE"). And, since the division of responsibilities between registrar and registry is, in general, a market-driven mechanism rather than fundamental to the DNS, many zones (especially deep in the hierarchy) do not use it. 5. Delegations When requesting a delegation, the administrator of the child domain becomes a registrant in the parent domain, and because of this, the registrant contacts the registrar for the parent domain and requests the delegation. The registrar passes information to the registry and sees that the delegation is performed. On the other hand, the delegation itself (at the zone file level) is from the registry in the parent zone directly to the registry for the child zone. In other words, the registry at one level in the DNS tree is the registrant of a domain name in the parent level. The chain of zones is only between registries (and the zone files they maintain), while the registrars (if they exist) only act on behalf of registries as an aid to competition and greater registrant administrative flexibility. 6. Services referenced by URIs according to RFC 2916 An end user (consumer) might have an email address at one email service provider, a SIP address at an IP-Telephony provider, and an E.164 number at a Telco. These might be three different service providers, providing three different services. Each one of these services can be identified by a URI (in a "NAPTR" DNS record). The protocol specified by RFC 2916 specifies that the necessary information to access each of the services, using only the customer's telco-based E.164 number, can be stored as URIs in the DNS. Given that one can only have one registry for each zone in DNS, one can only have one registry for the zone that holds the NAPTR records for all three services. At this level, as at every other level in the DNS tree, one can, of course, have multiple registrars if competition at that level and for those services is desired. 7. Tiers The term "tier" has been introduced into ENUM discussions in ITU-T. When that term is used together with the concepts of registry and registrar, there is confusion about roles, i.e., which entities perform which functions. We have understood that the Tier definition is more closely bound to functional layers than to names of particular entities or roles. Tier 0: Management of the e164.arpa zone Tier 1: Management of a CC Tier 2: Management of a full E.164 number Given this view on the specific Tiers, and the descriptions above, one can conclude the following. 7.1 Tier 0 RFC 2916 defines in its IANA considerations section the following: 4. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation. Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert. Through the IAB, the IETF has appointed RIPE-NCC as the operator of the e164.arpa zone. The IESG intends to appoint ITU, or an ITU-designated subdivision or entity, the designated expert for determining the contents and delegations of the top-level ("tier 0") E164.ARPA zone. The IAB and RIPE-NCC continue to wait for ITU to come with suggestions on how this root is to be administrated between the two organizations and how the registry of the zone (today RIPE-NCC) is to verify whether an application is authoritative or not. 7.2 Tier 1 The national level. As a national matter and choice, this level may be organized into several registries or may be only a single registry. Various examples of how Tier 1 can be organized for a given country are described in other contributions to this meeting, but it is important to remember that the selection of an organizational approach and structure, as well as the particular operators involved, are strictly national matters: the protocols, the DNS, and the structure at Tier 0 permit a very broad range of options. Also, whether there is single registry in Tier 1 for a telephony country code, or if have more than one is used (e.g., additional levels are introduced, such as one handling the CC, and then one for each NDC) then the registries in child zones for the CC can contact a registrar for the parent zone if competition is desired. I.e. as is described in section 5, delegations are done directly from parent registry to child registry, but the request for delegation goes potentially from child registry via a registrar for the parent zone to the parent registry. 7.3 Tier 2 At Tier 2 only the NAPTR resource records are stored in DNS. This means that a registry that operates at Tier 2 operates a zone that corresponds, according to RFC 2916, to the full subscriber number. The registry can, as is described above, be accessed through registrars if desired, but, most important, as is described in 6, there should be equal access for all service providers who provide services for the same customer in the zone. I.e. all service providers must be able to enter information in the zone. This can happen by having the consumer (registrant) take necessary information from the service provider and giving it to the registry of his choice, or a registrar for the same registry, or, in principle, by a range of other alternatives. As at Tier 1, how a given set of zones and the associated administrative and registration arrangements are structured is strictly a national matter. 8. Proposal It is proposed that ITU-T in its documents very carefully verifies that the terms "registry", "registrar", "domain" and "zone" are used consistently and according to definitions in this document and elsewhere in IETF standard definitions and specifications of the DNS. Altered use of these terms, and introduction of new terms such as "ENUM Service registry" with conflicting meanings, only adds confusion and misunderstandings. For example, the definition of "ENUM Service registry" has very little to do with the definition of the term "registry". References Authors' Address Patrik Faltstrom Cisco Systems Inc Arstaangsvagen 31J 117 43 Stockholm Sweden Email: firstname.lastname@example.org URI: http://www.cisco.se Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society.