Stephane Bortzmeyer AFNIC

Immeuble International 78181 Saint-Quentin-en-Yvelines France bortzmeyer@nic.fr

$Date: 2003-10-22 14:37:55 $ 2003 AFNIC $Id: HOWTO.db,v 1.7 2003-10-22 14:37:55 bortzmeyer Exp $ Distributed under the GNU Free Documentation License. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. This document is a very (the work has just begun) short HOWTO intended to help people to set up a domain registry, able to serve, for instance, a small ccTLD (Country Code Top Level Domain). The work is under progress: comments are welcome but take everything in the HOWTO with a pitch of salt.

This document is mostly intended for people faced with the task of setting up from scratch or redesigning heavily a domain registry. It tries to be comprehensive and to lists everything. On the other hand, it can give the feeling that creating a registry is a lot of work. It is not. Most of the items or tasks presented here are optional. Do not hesitate to start with only the most important (to you).

Only sketchy at this time A DNS registry is something special. It manages an unique resource, and therefore must do so in a neutral manner. Although there is no general consensus about the political or legal status of an Internet domain, we strongly believe that it is a public resource and should be handled accordingly. includes a very nice sentence about that, a sentence which is often quoted and very rarely obeyed: Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. Other attributes of a domain registry derives from this classification as a public resource: openness (the rules and procedures must be public), neutrality (the registry must not favor one party), reliability (the service must workWe will see in this HOWTO that it is much simpler than it seems: you do not need a multi-million dollar budget or an expensive software or a air-conditioned bomb-resistant bunker to manage a domain ), efficiency (procedures should be fast and simple, for instance, and lead to the actual registration of a domain). Another quote from the same RFC is worth reading: These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the top-level domain for both the nation, in the case of a country code, and the global Internet community.. Once you keep that in mind, questions like the legal status of the organization managing the domain become less important. Do not be surprised that this HOWTO emphasizes the results (having a neutral and dependable registry) over the process (choosing a Board).

This section tries to present several possible policies for a registry. There is not one and only proper policy. You will have to choose, we can only list policies, with their consequences.

Some constraints must be considered: Costs of the registration procedure (the more complex, the more costly), Costs associated with the maintenance of the domains, Human resources needed if your policies do not allow a full automatization. And your ambitions should be listed: Service to the local community and to the other users worldwide, Reliability and predictability (effective and non-discriminatory enforcement of the rules), Protection of innocent users against some forms of antisocial behavior (such as spamming, harassment, specualtive cybersquatting, etc), Technical excellence, Fast and simple administrative procedures, Easy introduction of new services (such as IDN). Inside this framework, some choices become much simpler: for instance, a policy-heavy domain (with complicated naming rules) cannot be fast and simple for its users. Or the complete selling of a ccTLD to a foreign company that will sell domain names with conditions (prices and priorities) that actually exclude local registrants will violate the rule of the service to the local community. The succes (or the failure) of the registry must be appreciated with respect to these ambitions. So, "selling as many domain names as possible" is not the only way to evaluate a registry.

In some TLD, you can register directly at the second level, right under the TLD. ".tv" or ".de" works that way. In others TLD, you can only register at the third level under a category-based second level. ".af" or ".uk" works that way. In ".uk", you can register only in subdomains like ".co.uk" (companies), ".ac.uk" (academic) or ".me.uk" (persons). It works like a sort of labelling system, allowing users to easily see the category of the registrant. The criteria for second-level categories are typically based on the legal status (registered corporation, etc). Sometimes, geographic criteria were used like in ".us" (which no longer does it, see for an historical point of view). Some ccTLD have a mixed policy. In ".jp", ".dz" or ".fr", you can register at the second or third level, depending on some criteria. Most users seem to prefer short and easy to remember domain names. Registration under third-level domains imply a knowledge of the naming rules by the users ("Are universities under .edu.example or under .ac.example?").

You can decide to accept only some categories of registrants (in Europe, it was common to accept only registered corporations), or to accept any sort. It is clearly a political choice: do you want to favor one type of stakeholder? A more common restriction in ccTLD is to accept only registrants on the basis of a local presence. You require an address in the country. It is specially useful in the less rich countries: without such a restriction, many "interesting" domain names would be taken by rich foreigners quite rapidly, leaving nothing to the people in the countryAs often with policy rules, there are always other solutions. You can, for instance, give some sort of priority to local registrants in your dispute resolution procedure. .

You can decide to check the identity or not. (Obviously, if you have a restriction on the registrants you accept, then you need to check their identities.) Do note that this issue (checking the identity of the registrant) is not the same thing as restricting the domain names they can register, which is described in the next section. Such checking is often quite difficult to perform in practice. When everybody and every entity will have a cryptographic certficate, issues by a recognized authority, such a check will be both realistic and painless. But it is in a very distant future. Today, methods of checking are either slow and involve paper work or they are automatic but quite weak (sending a password by email, like when you subscribe to a maiing list).

In some TLD, like ".org", ".nl" or ".de", you can have almost any domain name you want, providing it is not already registered. In other TLD, your choices are restricted to names for which you can prove you have a right: a trademark, for instance, or the name of a company. In many TLD, there is also a blacklist of names that you cannot register at all: names that can create confusion (such as Internet organisms like NIC, ICANN or IETF), geographic names, or names that are illegal (heilhitler.example, because of the crimes of the nazis). Generic names (like "car.example") are sometimes excluded although it is very difficult to decide if a name is generic or not, short of prohibiting the entire dictionary. Blacklists are difficult to manage: either you define them extensively and you have the risk to forget something (if you forbid ku-klux-klan, people may register kukluxklan) or you define them by a few set of rules and then it becomes quite arbitrary ("hitler" is neutral but "heil-hitler" is political?) If you limit the choice of the registrants, you will have to check the rights to a name they claim to have. You can ask to the registrants a paper (which incurs time and manipulation) or an handle in a database. In many countries, such checks are quite difficult to perform because the databases that store the trademarks or company names are not public or are quite difficult to access (for instance a Web page that requires cookies, no Web service, etc).

Some registries like ".fr" or ".br" or the RIPE-NCC (which delegates ".in-addr.arpa" domains) requires the success of technical tests prior to the delegation. Some even make periodic tests to see if the configuration is still OK. These tests are very useful to improve the overall quality of the DNS. If, for instance, two out of three nameservers of a domain are not responding (a very common situation in ".com"), the client will need three DNS requests instead of one, slowing the software and loading the Internet for nothing. Also, it is always better to detect errors as soon as possible. One must understand that, besides some very obvious checks (testing that every nameserver replies in an authoritative way for the domain), there is no consensus on the actual testsThis is why the ZoneCheck tool takes its list of tests and their severuty (fatal or just warning) from a configuration file, thus separating the policy from the code. . So, be sure that they are developed with actual participation from the community. Some TLD do perform such tests but do not make them mandatory for the delegation. They just warn the contacts or flag the domain as invalid in the database. If you do periodic testing of the domains and if you remove domains when they fail N successive tests, be sure that the holders were warned in advance, before they actually buy the domain.

There are many ways to organize a registry. We do not intend to give the right one, because there is no such thing as the Only True Way. Instead, we will list here possible statutes, with their consequences Be also aware that the statutes alone does not tell everything. Associations can be for-profit corporations on disguise, they can be fronts for the governement, etc.

Many countries Centrafrican republic, Morocco, Niger, Mali. use or used such a system, where a set of employees of the traditional telco organization manages the domain name. Since the operator is also often an Internet provider, it is quite difficult to be truly neutral with such a status.

Since the national domain is a public resource, it may makes sense to have the government manage it. Very often in the past, the domain was managed by a public entity (typically an university) but not directly by the government. This is less common now.

The registry can be an association. This model is quite common in Europe. There are many subvarieties of this scheme: for instance, the association can be a consortium of registrarsGermany, or it can have a wider consistuencyFrance. Do note that "independant" is relative, some associations, theoritically independant, are quite connected to one of the actors. Also, "non profit" does not imply "honest" or "immune from appetite of power".

The registry can be a private, for-profit, company. Do note that it does not imply that this company "owns" the domain. It can be a contractant, managing the domain on a contract basis. In that case, it should be closely monitored by the domain holder because the desire to makes more money may influence the policy of the registry in an unwanted wayFor instance, by creating wildcards entries in the DNS, that create user confusion but allow the registry to attract more users to its Web site. .

People who want the creation of a domain name can request it directly from the registry. Or they can go through a registrar, a provider specialized in domain names. Most registries use only one of these two possibilities: either you sell directly or you require that creation and modification of domain names are performed by a registrarBrazil mixes.. Direct selling is more common in small ccTLDs. It simplifies the life of the users, by suppressing an intermediary. The registry-registrar model is more common in large ccTLDs. Almost everyone in Europe uses it, for instance. It shelters the registry from end users. Someone has to train them, to explain them and to reply to their calls. Most registries prefer to move this task to registrars. Also, it makes sometimes easier for the provider to sell a global service, including the domain name and other things, such as Web hosting. If you have registrars, the question of the accreditation criteria is an important one. Will you force registrars to be accredited? If so, on financial criteria (a given amount of money in a bank account)? On technical criteria (the ability to talk with your registration system, using the protocol you choosed)? On both?

As mentioned in , every registry works for its local Internet community: Internet access providers, Internet service providers, Web site developers, cybercenters managers, registrants of domain names and simple users. The way the opinions and expectations of these stakeholders, the people who are interested in the proper working of the registry, is taken into account, vary greatly. But, in the ideal, it should exist one way for them to decide on what interests them. It is not always easy to transform a stakeholder into an active and responsible participant to a process. Some categories are easy to organize (small and well-defined categories, like the ISP), some are much more blur (the users). Traditional democratic systems "one man, one vote" do not work well fo specialized matters like the domain name management.

The Internet being international, the registry will need relationships with many foreign organizations.

TODO http://ccnso.icann.org/

TODO http://www.wwtld.org/

TODO

TODO: RIPE-NCC, Afrinic, etc

CENTR, APTLD, TODO

Wether the registry is for-profit or not, it will need a bit of marketing. A registry works in a world of communication, since this is what the Internet is about. So, you will have to think about your communication: your Web site, your information letter etc. A small warning: it seems easy to communicate with the registrants, you have all their email addresses. But some may not like it if they were not warned in advance.

Like every other provider, you will need an user support. To maximize user satisfaction, keep in mind the following. Phone support is very costly (it requires more people and it makes collective work more difficult). For email support, every emailExcept, of course, spam and insults. must receive a replySoftware can help: email readers with thread support like mutt can help a lot to detect unanswered messages. Besides such simple tools, formal ticketing systems like Request Tracker become mandatory once you have more than a very small TLD. They allow to keep track of the questions and of the replies, to match the various messages related to the same case, etc. . Already-made sheets for the most common replies are very useful and you can gather them in a FAQ online, allowing you to reply, "Please see the FAQ, section X.Y". Collective work of the NIC team is specially useful for user support since nobody can know eveything: useful replies are sometimes made from two different contributors.

Even if you try to limit the paperwork to a bare minimum, you will need some administrative procedures. To comply with the openess and fairness principles, they have to be written and followed. If you have policy-heavy registration rules (such as restrictions on who can obtain a domain name), you will need procedures for the registration, poissibly lasting several days. As for the user support system, a ticketing software is of great help. If you have registrars and if there is some form of accreditation, you will need a procedure describing the steps for this accreditation.

Functions assumed by individuals in the registry should be documented. Even if, in a small registry, most people fulfill several different functions, it helps to identify the business tasks of the registry. Example: TODO

TODO: quote Schneier :-) Not only computer security but also, authentication of holders (see sex.com or aljazeera.net). In some countries, as soon as you manage a database of individuals, you have the obligation to ensure its protection (against illegal harvesting, for instance, a common problem with the whois service).

Among the procedures, you will need rules for the technical management of the registry. For instance, that no work should be considered done as long as it is not documented. Or rules should said that any exceptional action (such as a direct UPDATE in the database) be logged in a proper place (such as a CVS-managed text file).

A registry has several technical components. Before trying to integrate them, let's enumerate what they are.

"database" does not imply that it runs on a DBMS. I just mean a way (may be even a simple text file with some procedures to edit it properly) to store the domains and their name servers.

Unless you run a "thin" registry, you will need to store the social information, which is the names and addresses of domain names holders and domain contacts (technical, administrative, etc). For both databases, writing the schema is not obvious and you can use the one in OpenReg as a starting point. Do note that the choice of a schema raises a lot of policy issues. It is highly recommended that this database is physically the same as the domain database before, in order to avoid inconsistencies. But some registries keep two separate databases, often for historical reasons. In that case, people often call it the "whois database" because of the protocol that historically served it.

You need to export the database in a format which is suitable for your name servers. Of course, you can always use the name server's zone file as a "low tech" database, which is possible for a small registry. Or you can plug your name server directly into the database which is possible with PowerDNS. But in all the other cases, you will need a (small) program to export the database.

You will need a way for the people working at the registry to read the database(s), and to update it. At the present time, it means a Web interface, usable from any Web browser. Die-hards users could still use the SQL command-line interface :-) Since it may be a complicated program, the use of a Web Application Server, such as Zope may be a good idea.

People outside of the registry will need to read and update the database, too. I see three cases, in order of ascending size: A very small registry can use low-tech interfaces (phone and paper) to receive domain updates and then use its internal interface. A small or medium-sized registry will have no "registrars", no intermediaries. It will provide directly the registrants with a set of Web pages to create and manage their domain names. The ease of use of this Web application is paramount to limit the load on the support team. A large registry will probably have registrars and will offer them an interface with a protocol like EPP or RRP () or a simple key-value template like the RIPE-NCC protocol or the CORE payload protocol.

Unless your domain is entirely hosted outside of the registry, either by friends or by a commercial company, you will need name servers and you will need to monitor and maintain them.

If the creation of a domain involves several steps (such as some manual checks), you may need a ticketing system, able to give an unique ID to each transaction, allowing easier referrals. This tool will give you the possibility to track work in progress. Such a tool is also useful to manage things like operational tasks to perform (software installation, for instance), and customer support requests. The recommended tool is Request Tracker but many other similar tools exist in free software.

It is highly recommended to have a whois server () to distribute social information (such as the technical contact) about your domains. In the future, other protocols may replace whois.

Of course, you will need backups. The complete destruction of the database would be a catastrophe. Therefore, it is highly recommended, not only to make backups on permanent storage (one CD-ROM is more than enough for most domain registries), but also to store them in far away places, to guard against catastrophic failures such as fire or war. To do so, a disk-to-disk backup is often the simplest solution when the two machines are connected by the Internet. You can replicate your database automatically (this is very easy to set up with MySQL), or simply copy the data with a program like rsync (this can be automated, see for instance this documentation. It is easy to automate these operations.

A simple check_soa or a full ZoneCheck

If you want to register domain names in other character sets than US-ASCII, for instance with the Arabic alphabet, you will need some IDN tools.

TODO: mon, nagios, etc

It is recommended that all the components of the registry reads from and updates to the same repository. This will avoid inconsistencies. To achieve this goal, you can either: Use one database, which will be the authoritative source of information for everything. Use a client-server middleware, for instance with protocols like XML-RPC, that all your applications will use. You can have a common library, used by all your programs, to read and update the datanase(s).

The only available free software at the present time, to run a registry, is OpenReg. It provides an EPP interface, a middleware program (so you can add your own programs), a whois server, a database (PostgreSQL by default).

If you use a DBMS to store the data, you can use either PostgreSQL (which runs ".org" and ".info") or MySQL.

Today, there are three possible choices with free software: BIND nsd PowerDNS

You will need some programming skills, anyway, because all registries are different and it is likely you will have some specific requirments. "Scripting" languages like Perl or Python are necessary for a registry. Even if you limit your requirments, many software that are available will need some sort of glu to hold together. Here is a partial list of the components that are not, as far as I know, available as free software: The internal Web interface of a registry. The external Web interface of a registry, for the registries that have no registrars and therefore have to provide such an interface.

From Eric Barbry's blueprint for EUREG In many countries, legal issues can very quickly become intractable or simply too expensive to be solved in a "proper" way. The Internet itself was never built on a solid legal ground. Do not wait until all legal problems are completely solved before you build something. Legal problems are just technical problems, they are not an aim in theirselves.

Besides the physical damages (fire, for instance), the registry may have legal liabilities: check them.

ICANN asks for a formal contract, TODO. Before signing it, check the consequences.

What are the possible criteria to apply for the accreditation of registrars? What are proceedings to check that the criteria are met? When does the accreditation of registrars take place? Should the selection criteria be steady? You will specify things like TODO

TODO

A typical DNS registry is widely automated and uses only dematerialized exchanges. Check the consequences on your legal system.

This document assumes that you only use free software. In any case, do not forget that illegal copying of commercial software is... illegal and that a DNS registry, which is highly visible, is a tempting target for enforcers.

It is not purely a legal question: in many countries, the law is sufficiently lax that you can do almost what you want with the data. It does not mean that ou should. There are also policy choices here. TODO: European law?

TODO

TODO: registrar or direct sales. Pre-charged account or not. Structure of the price (flat for all the domains or not).

Manning/Abley A very good tour of the problems (mostly technical) faced by a new registry. A good set of resources about DNS management. Unfortunately apparently no longer maintained. Available on-line Country-Code Top Level Domain ccTLD A TLD which is linked to a country. They are described in and the list of country codes (two letters each) comes from ISO. Domain Name System DNS The distributed and hierachical information system that allows, among many other things names such as www.foobar.example to be translated into IP addresses and back. The general concepts of the DNS are described in . Generic Top Level Domain gTLD A TLD which is not linked to a country. In practice, some gTLD are indeed international in usage, like ".com" or ".org" but some, for historical reasons, are USA-specific like ".gov" or ".edu". Holder Synonym of registrant. Internet Assigned Numbers Authority IANA A function of ICANN: IANA records and publishes the use of the unique virtual resources such as IP addresses, domain names, protocol numbers, etc. Internet Corporation for Assigned Names and Numbers ICANN ICANN manages the allocation and change of the unique virtual resources of the Internet such as IP addresses, domain names, protocol numbers, etc. ICANN is a private corporation under the laws of the United States of America. Several functions it assumes depend on a delegation from the USA governement. Network Information Center NIC The organism in charge of a TLD. It manages the database of the domains registered under this TLD, as well as the associated information (name servers, contacts, etc). Registrant The entity (company, association, physical person) which registers a domain name. It is not an owner, because domain names are typically only rented, not bought. Registrar The entity (typically a company) which sells domain names to registrants. Unlike the simple reseller, the registrar has an access to the database of the registry, through a standard protocol like RRP or EPP. Registry The entity in charge of the TLD. For a ccTLD, NIC and registry are often used interchangeably. Sponsoring organization In IANA language, the registrant of a TLD. At the present time, it is often the administrative contact, because sponsoring organizations are a quite recent concept. But check ".tv" for an example where they are distinct. Top Level Domain TLD A domain which is right under the root of the DNS, like ".fr" or ".net".