Some constraints must be considered:

And your ambitions should be listed:

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 RFC 1480 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 country^[2].

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 tests^[3]. 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.

Many countries 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 registrars, or it can have a wider consistuency.

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 way^[4].

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 registrar.

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 RFC 1591, 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.

"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:

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 (RFC 954) 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.

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:

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:

ICANN asks for a formal contract, TODO.

	Warning
	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