123-regからGoDaddyに.netドメインを転送しようとしていますが、問題が発生しています。トップレベルドメインを転送するたびに、しばしばEPPコードと呼ばれるAUTHコードが必要なことを知っているように、私は123-regからAuthコードを要求し、GoDaddyのダッシュボードに入力しますが、この迷惑なエラーを迎えました:
GoDaddyと話す...
だから、論理的なことはGoDaddyまたは123-Regと話すことでしょうか?そうではないようです...両方の当事者と話したとき...私は問題を解決することに近づいていません。 GoDaddyは123 Regコードを主張していますが、これは悪いものであり、123 regはその愚かなダッシュボードだと主張しています...
少なくとも20回は別の認証コードを発行しましたが、まだ喜びはありません!だから、いくつかのアドバイスが必要です..コードが含まれるべき形式はありますか?たとえば、違法な文字はありますか?そしてそれはX桁でなければなりませんか?
-
EPP authInfo(仕様ごとの実際の名前)は、ドメイン名の作成時にレジストラによって定義されます(後で更新できます)。それは登録者の管理下にあると想定されていましたが、実際にはレジストラがすべてを行っています。
EPP標準(RFC5731)は、この要素の制約をXMLタイプeppcom:pwAuthInfoType
として定義します。これは、RFC5730で定義されており、XML normalizedString
であると要約しています。
基本的に、任意の長さおよび任意の文字列(3つを除く:改行、キャリッジリターン、およびタブ)です。
ただし、各レジストラは、各レジストリの仕様に基づいて、その構築方法とその中に必要なものとそうでないものを決定します(おそらく最大長を設定します)。ただし、明らかに、着信転送にサービスを提供するには、他のレジストラによって生成されたauthInfoコードを受け入れる必要があります。
ここであなたの問題を解決します:将来のレジストラがこのauthInfoが正しいものではないと考える理由を特定できない場合、おそらく技術レベルが十分に高くないため(および/またはサポートが不十分なため、他の場所に行く必要があります)チームは専門知識を欠いている);それどころか、このauthInfoを試行したときに表示されるregistryエラーメッセージを提供できる場合、これが正しいことを証明します。しかし、そうではありません。したがって、現在のレジストラにauthInfoを変更し、選択した新しいレジストラのルールとよりシンプルで互換性のあるものを提供するよう説得できれば、状況を解決できます。そうでない場合は、別の新しいレジストラを選択することをお勧めします。