Our customer, a domain name registrar, explained: “I want to create a service to automate operations on domain names for my clients—large domain name owners; registering 1000 domain names should not be a problem for them.”
The customer is a broker between a top-level domain registry operator and domain name owners. He wanted to automate registrar–client and registrar–registry operator communication for different types of operations regarding domain names: registration, payment, prolongation, change of owner, and so on.
The main feature of this system is that it needed to be oriented to large domain name owners working with more than 1000 names at the same time. We realized that with so-called “batch processing,” the domain owner forms its request for a large number of domain names at the same time in the form of a “package.” For instance, once contact data changing occurs, the user chooses the domain names that will be changed. He then indicates what information should be changed and, after that, a batch of changes list for every name is formed in the system and sent for processing. Once the processing is finished, the owner receives a report about the changes made to every name in the batch, or about the impossibility of performing an operation for some reason. This technology avoids restricting the number of transactions from the same user, problems with lengthy processing demanding a constant internet connection, and conflicts associated with the users’ action sequence.
All popular systems that provide different types of operations with domain names are integrated with the API of every registry operator (.com, .net, .us, etc.). In the absence of unified specification, the same situations can be processed by the system in different ways. That is the main problem.
Many actions can be made with a domain name (up to 20). Every operation type has its own types of errors, and each error should be caught. An action model for every possible situation should be carefully designed, implemented, and tested over and over again.
The behavior of registry operator systems may change from time to time (for example, terms of prolongation, change of owner, etc.). That is why it is necessary to provide constant support to the registrar system.