Preparation of a package of documents for the transfer of domains in the zone .RU and .SU

Anyone who has ever encountered the need to move a domain in the .RU zone or transfer it to another person knows that a complete mess reigns in this service sector. For example, I needed a month of painstaking study of a dozen different sets of documents in order to derive a certain system. Facing, rather, stumbling over this problem every day, we decided to somehow systematize the accumulated experience and turn it into a useful service.

A little about the essence of the problem. There are 26 registrars in the zone .RU and 13 registrars in the zone .SU . And each has its own application forms for the transfer and transfer of rights to the domain. The procedure of transfer and transfer is not always obvious from the documentation of the registrars, and many even do not have such documentation. On closer examination, it turns out that one written statement is enough for transfer, and three written statements for transfer with a change of administrator. Moreover, for individuals and legal entities - separate forms. Total 6 forms multiplied by 26 registrars (13 registrars of the .SU domain have a subset of registrars in the .RU zone) plus 26 postal addresses (try to find them, by the way, with some registrars of the Relcom type). Those. for a hoster, in general, it is required to navigate in 182 pieces of paper and keep them up-to-date (of course, half of the forms contain the names of directors and addresses of offices). This is if you understand the general sense of the procedures in which there are differences. For example, REG.RU wants to necessarily e-mail and telephone, otherwise it threatens to do nothing, and R01, when the administrator changes, wants the old administrator to first transfer the domain to his contract with R01 (in most cases, it turns out that he should enter it only for domain transfer). Or I don’t remember the description of the procedures of anyone implying a power of attorney for the registrar’s employee, I don’t know why.

Talk "let's simplify" as much time as I remember myself in hosting. Not that anyone was against it, but things are still there. The main argument is that customers will leave, and this is not profitable. I absolutely do not want to offend the recorders, but they are deceiving themselves. People do not like change, and if they decide to leave, the bureaucracy will not hold them back, and if they have not decided, they will not leave.
')
When questions about a registrar change began to flow to us every day and take a lot of working time, we, with the power of our grace given to us by ourselves, unified the procedures and forms for transferring a domain and transferring a domain with changing the administrator. Since the regulation RU-2 obliges registrars to transfer domains to another registrar, we made a willful decision and set our standards for a minimum informative statement. With the transfer of rights, everything is a little more vague and paragraph 8.3 can be interpreted quite freely. Therefore, we decided that only those registrars who openly declare this can transfer rights with transfer.

The result was the http://chreg.ru service, which allows you to generate a package of documents for the completed forms. The package of documents also includes a memo, a copy of what certification documents are required and that you need to be certified by a notary. Also, we put the paper with addresses on envelopes C5 / C6 / DL with a window. Each document is accompanied by a separate memo in shaded type. This is still an open question - do these memos directly in the document, or put them on the list. Thanks to the help of registrars already familiar with the service, support for the Cyrillic .SU domains was introduced (thanks to the master) and examples of document packages were made (thanks, Netfox).

If anyone is interested, the entire service is made on Python-2.7 (due to small “tweaks” like timeouts in httplib), the “muzzle” of the service with domain checking is done on the Twisted framework, the document generation is a WSGI application on modwsgi using pisa package (interface to reportlab).