ゾーン.RUおよび.SUでのドメイン移管のためのドキュメントパッケージの準備

.RUゾーンでドメインを移動したり、他の人にドメインを移したりする必要性に遭遇したことがある人なら、このサービスセクターが完全に混乱していることを知っています。 たとえば、特定のシステムを引き出すために、1ダースのさまざまなドキュメントセットを綿密に調査するのに1か月かかりました。 毎日、この問題に直面するか、またはつまずいて、私たちは蓄積された経験を何らかの形で体系化し、有用なサービスに変えることにしました。



問題の本質について少し。 .RUゾーンに26のレジストラがあり、.SUゾーンには13のレジストラがあります 。 また、それぞれにドメインへの権利の譲渡と譲渡のための独自の申請書があります。 移管および移管の手順は、レジストラの文書から常に明らかとはほど遠いものであり、多くの場合、そのような文書さえありません。 慎重に検討すると、1つの記述されたアプリケーションで転送するのに十分であり、3つの記述されたステートメントで管理者を変更して転送することがわかります。 さらに、個人および法人の場合-個別のフォーム。 合計6つのフォームに26のレジストラ(.SUドメインの13のレジストラには.RUゾーンのレジストラのサブセットがあります)と26のメールアドレス(Relcomなどの一部のレジストラでそれらを見つけてみてください) つまり ホスティング事業者の場合、一般的な場合、182枚の紙でナビゲートし、それらの関連性を維持する必要があります(当然、フォームの半分にはディレクターの名前とオフィスの住所が含まれています)。 これは、違いがある手順の一般的な意味を理解している場合です。 たとえば、REG.RUは常に電子メールと電話を必要としますが、そうでない場合は何もしないと脅します。管理者を変更するとき、R01は古い管理者に最初にR01との契約にドメインを移してもらいます(ほとんどの場合、ドメイン移管)。 または、レジストラの従業員の委任状を意味する手順の説明を覚えていません。その理由はわかりません。



「簡単にしましょう」の会話は、私がホスティングで自分自身を覚えているのと同じくらい行われます。 誰もがそれに反対したわけではありませんが、物事はまだそこにありました。 主な議論-顧客は去りますが、これは有益ではありません。 私は絶対にレジストラを怒らせたくありませんが、彼らは自分自身を欺いています。 人々は変化を好まないし、たとえ彼らが去ることを決めたとしても、官僚主義は彼らを抑制しません、そして、彼らが決定しなければ、彼らは去りません。



レジストラの変更に関する質問が毎日寄せられ、多くの作業時間を費やすようになったとき、私たちは私たちに与えられた恵みにより、ドメインを移行し、管理者を変更してドメインを移行するための手順とフォームを統一しました。 RU-2規制により、レジストラはドメインを別のレジストラに移管することが義務付けられているため、私たちは強い意思決定を行い、最小限の情報提供のための独自の基準を設定しました。 権利の移転により、すべてが少し曖昧になり、 8.3項はまったく自由に解釈できます。 したがって、これを公然と宣言しているレジストラのみが、譲渡とともに権利を譲渡できると判断しました。



その結果、サービスhttp://chreg.ruが完成しました。これにより、完成したフォームに従ってドキュメントのパッケージを生成できます。 文書のパッケージにはメモも含まれており、そのコピーは認証文書が必要であり、公証人によって認証されるべきものです。 また、封筒C5 / C6 / DLにアドレス付きのリーフレットをウィンドウで囲みました。 各ドキュメントには、影付きフォントで個別のメモが添付されています。 これはまだ未解決の質問です-これらのメモをドキュメントで直接実行するか、リストに追加します。 レジストラサービスにすでに精通している人々の助けのおかげで、キリル文字.SUドメインのサポートが導入され(感謝、マスターホスト)、ドキュメントパッケージの例が作成されました(感謝、Netfox)。



誰かが興味を持っている場合、サービス全体がPython-2.7で作成され(httplibのタイムアウトなどの小さな「トリック」のため)、ドメインチェック付きのサービスの「顔」はTwistedフレームワークで作成され、ドキュメント生成はmodwsgiを使用するWSGIアプリケーションですpisaパッケージ(reportlabへのインターフェース)。



All Articles