piu lentoの日々 (piu lento days)

数日前に、僕が このブログのドメイン(piulento.net)の管理(ドメインの登録やDNSサーバ: 正式には「レジストラ」と言うのか)に使って居るGoogle domains(以下、Google)が終了するという記事を見た。年末辺りから、聞いたこともない別の会社(Squarespace)に自動的に移るそうだ。

最初は、Squarespaceに移管された後、価格や使い勝手を見て考えようと思って居た※が、頭に来るのと7/6がドメインの更新日でGoogleに支払いになるが、下記のようにCloudflare(以下、CF)なら(少し)安くなるので、間に合うなら移って無駄な出費と個人情報の流出とイライラを減らそうと考え、うまい具合に成功した。

※そもそも、(Googleを信用していないため、)Googleのサービスに依存していないので、どこに移行することになっても大きな問題はないから、遅かれ早かれ移行することは確実だった。

レジストラの移管作業

移転(移管)作業は難しくはないが、(僕が詳しくない)いろいろな要素が絡み合うため、とても面倒かつ神経を遣った。※ 携帯電話のMNPに似ているが、サクッとは行かない。全部手作業だ。以下、その流れを簡単に書く。

※想像だが、GoogleもCFも(英語版でなく)日本語版ページを見て作業するとしたら10倍くらい分かりにくい気がする。

全く関係ないが、たまたま見たGoDaddyの日本語のページは ひどくて、検討する気を失わせた・・・

1. 行き先の検討 → Cloudflareにした。
   • 検索すると価格比較ページが結構あるが、やっぱり広告記事のようで、最安と思われるCF(下を参照)については まず書いてなかった。
     • そのため、Googleに移った時は検討すらしなかった。
     • CFも検索で見付けたのだが、どういう検索だったかは覚えていない。「最安」とかで出て来たページに書いてあったのか、比較ページに書いてあったのか。
   • CFは自社での手数料を取らず原価でドメイン管理サービスを提供しているので、最安だと思われる。
     • 料金の比較 (.netドメインの更新料, 年額): 為替によるが、CFはGoogleより少し安そうだ。
       • Cloudflare: USD 9.95 (→ 約1500円)
         • 注: 上は以前の価格で、今はUSD 10.1になっている。また、上のレートは実際と異なる。 (詳細は後述)
       • Google domains: 1400円+消費税 → 1540円
   • CFの落とし穴を調べたが、特になさそうだった。
     • 検討時に参照したページ: 1, 2, 3
     • ※実際には、後述のように、通常の「プライバシー保護」と違って登録者の県と国が公開されるという、思い込みとの違いがあった。
2. Cloudflareの試用 → 分かりにくい・面倒なことはあるものの、悪くなさそうだった。
   1. アカウントの作成
   2. 「サイト」の登録
      • CFはドメイン管理だけをすることはできず、そのドメインで使うサイトを登録する必要がある。
        • ここがCFの面倒・分かりにくいところだと感じた。
      • 下のDNSの移行を完了しないと、サイトは有効にならない。
   3. DNS(ドメイン情報の大本のサーバ(権威DNSサーバ?, SOAやNSレコードに書かれるもの))を移行してみた。
      • この作業をしないと、ドメインがCFに移管可能にならない。
        • 作業後、CFでドメインが移管可能と表示されるようになった。
      • GoogleとCFの設定を同時に変更するので、面倒なうえに神経を遣った。
        • 失敗するとサイト(piulento.net)にアクセスできなくなる可能性があるため。
      • CFにDNSを設定開始すると、ほとんどの情報がGoogleからコピーされるが、されないものもあるので、チェックして手で追加する必要がある。
        • また、CFには不要な情報(_domainconnectレコード)もあるので、取捨選択する。
        • あと、CFではSOAとNSレコードは変更できないようだ(必ずCFのDNSが権威サーバになる)。
          • → CFのDNSの設定を確定後、GoogleのDNSのSOAとNSレコードをCFに変更する。
            • これを変更するまでは、大本(Google)のDNSとCF(1.1.1.1)が異なる状態なのだろうかと推測した。
      • また、DNSの移行前に移行元(Google)のDNSSECを解除する必要がある。
        • 普通に解除を要求しても反映されるのは約24時間後だが、"Unsign zone now"(→ 図)の操作をしたら即座に反映された。
          • DNSSECの設定時も24時間掛かるが、"publish"すると即座に反映される。
          • その代わり、一時的にサイトにアクセスできなくなる可能性があるようだ。
        • DNSをCFに移行後、改めてGoogleでDNSSECを有効にする必要がある。
          • この時点ではドメインはGoogleの管理のため、CFでなくGoogleにCFの情報を登録する。
      • CFの設定で重要なのは、proxyという機能(一般的なプロキシと同じかは不明)で、onにするとサイトへのアクセスがCFを経由するようになる。
        • ファイアウォールなど便利そうだが、問題が起こりそうなので ひとまずoffにした。 (→ 最終的なDNS設定の図, ドメイン設定の図)
      • この作業で便利だったのはdigコマンドで、例えば dig @1.1.1.1 piulento.net +trace を実行すると、通常では出ないSOAやNSレコードも出る。
        • CFのドキュメント(なかなか良い)で知った。

3. Cloudflareへの移転 → 無事に終わった。
   1. ドメインの状態が移管可能(移管できない状態でないこと)か確認した。 → OKだった。
      • ドメインの状態はwhoisコマンドで分かる。: "Domain Status"で出る。
        • 通常は"clientTransferProhibited"(いわゆるロックされた状態)で、ロックを解除すれば移管可能なようだ。
        • 移管できないのは、例えば、レジストラントの連絡先の変更後(60日間不可)、更新日まで15日以下という場合である。
          • たまたま、少し前にドメインの連絡先を変更した(Squarespaceへの移管に備えた)ので移管できないかも知れないと思っていたが、大丈夫だった。ドメインのプライバシー設定をしているため、Google内だけの変更だったからだろうか。
          • 更新期限は偶然・ギリギリ間に合った。
   2. DNSSECを解除した。
      • DNSの移行後に有効にして居たが、CFの資料に従い、再度解除した。
        • 具体的には、(上で設定した)GoogleのDNSSECの設定を削除した。
   3. Googleでドメインロックを解除し、移管の認証コードを取得した。
      • なお、CFのドキュメントではドメインのプライバシー設定を解除する必要があるかも知れないとのことだったが(僕も、解除するのが普通と思って居た)、解除せずに試したら大丈夫だった。
        • その代わり、ドメインの連絡先はCFで改めて設定した。
   4. CFに支払い情報を登録した。
   5. CFで(CFに)ドメインが移管可能になるまで待ち、移管を開始し、認証コードを入力した。
      • 上のDNSSECの解除と支払い情報の登録を忘れて居たためか、移管可能になるまで少し(30分くらい?)時間が掛かった。
      • 移管のためか、料金が想定と若干異なり、ドメイン更新料と合わせてUSD 10.1 (1468円)だった。
        • 今は(移管でない)更新も同じ値段で、なぜか案内ページの料金表の画像(altが"Cloudflare Registrar Pricing")が表示できないので、近頃どこかが値上げしたのかも知れない。
          • ↑検討時に見た(USD 9.95)のは古い情報(2018)だったようで、今回の請求と比べると、卸値?(wholesale cost)がUSD 9.77から9.92に値上がりしている。
          • また、今年更新された参照ページでもUSD 9.95なので、わずかにタイミングが遅かったのかも知れない。まあ、1年だけの違いだ。
   6. CFにドメインの連絡先を設定した。
      • 上記のように、移管前にプライバシー設定を解除しなかったため。
        • 手間ではあるが、一時的にでもプライバシー情報が全世界に公開されるのが防げるので、これが良い。
   7. Googleから移管を受理するかの確認メールが来たので、受理した。
   8. CFから移管完了のメールが来た。
   9. CFでDNSSECを有効にした。
      • 意外にCFのドキュメントに説明がないので、忘れそうだ。
   10. Googleの支払いを止めた。
       • Google側のドメイン情報を「削除」していいのか不明だったが、移管後少ししたら自動的に削除されていた。
   11. PCやモバイルからサイトへのアクセスを確認し、問題なかった。
       • SPF(メールに関係)もチェックしたが、問題なかった。

作業のメモ・感想

• CFの試行とCFへの移管作業は4時間くらい(概ね半日)で終わった(意外に短かった)。
• CFがDomain Connect(_domainconnectレコード)に対応していれば、作業が もう少し楽だったのかも知れないが、詳しくないので、移管時に使えるのかは分からない。
• 以前の会社(お名前.com)からGoogleに移管した時は一時的にプライバシー設定を解除する必要があったが、今回は不要だったので随分安心だった。
• whoisを見ると、CFはプライバシー設定で隠している個人情報を"DATA REDACTED"と書いていて、Googleなどのように仮の情報(レジストラの連絡先)を書くより ずっと分かりやすくスマートな気がする。
  • と思って居たが、書いたあとで見直していたら、なぜか登録者の国と県が公開されていることに気付いた。このサイトでは どちらも非公開ではないので、それくらいは良いだろう。
    • ↑書いたあとで少し調べたら、CFのプライバシー保護と従来のもの(各レジストラが提供している)の仕組み・仕様が違うようで、CFのは近頃できたらしいWHOIS redactionというものに従っているようだ。
      • それで、"DATA REDACTED"と出る。
    • また、CFはICANNのポリシーに従って県(state/province)と国を公開しているとのこと。 (→ 参照: CFの資料; フォーラム: 1, 2(質問者はCFの資料・仕様を良く理解できていない?))
      • 結局、僕が使う前に良く確かめなかったために齟齬(?)が生じた。
      • 今考えると、試用のあとに いろいろ調べずに、(元々翌日にしようと思って居たのに)すぐに移管し出したのが良くなかった感じだ。 (いつもの、思い付きが失敗した例)
• ドメインとは関係ないが、移管後はGoogle search consoleが無効になり、(CFで)ドメインアクセス(?)への再承認が必要だった。
  • 承認処理をしないと、他人が勝手に他人のサイトの検索統計を見ることができるからか。
  • 承認の時にCFのweb画面が出て来て、承認したら自動的にCFに承認のレコードが追加されたのには感心した。

余談・感情的な話

Googleに移る時、Googleらしく勝手に終了するかも知れないとは思ったが、Google自体が公開DNS(8.8.8.8)をやっているくらいなので本当にそうなるとは思っていなかったし※、予想外に早かった(移ってから4年しか経っていない)。

※公開DNSは お金になる(いろいろなサイトのアクセス情報が得られる)が、ドメイン管理は そうでないと見たのか。

そもそも、サービス終了という重要なことをニュースやサイト(FAQ)に書くだけで、ユーザーにメールで知らせないのはおかしい(それがGoogleのやり方?)し、簡単にユーザー情報を売り渡す(決定をする)のは意識が低いし余りにも勝手だ。どうせ規約には書いてあるんだろうけど、それも許せない。

だから、僕がGoogleで他に使って居るCloud Storageも、急に終わるとか変更とか値上げが あってもおかしくないので、その覚悟や準備を怠っては いけない。

とは言え、(最安で悪くなさそうなので)移転先にしたCFも信用し過ぎてはいけない。そのうち、「ぶっちゃけ、無料でドメイン管理にだけ使われても困る」とか言い出しそうだｗが、その時は また考えれば良い。CFに依存しなければ良いのだ。

無料でもファイアウォール(WAF)などが結構使えそうなものの、ちょっと高度なことは有料になって、(気になるものの、)高い(USD20/月から)から縁はなさそうだ。

それから、WAF(良く見る、「ブラウザをチェックしています」なのだろう)については、サイトのサーバがCFの中で動いていないため、ドメイン名でのアクセスは防御できるが、IPアドレスを直接指定して来る不正アクセス・攻撃は全く防御できない気がする。それでも、ないよりはずっと良いとは思う。

おまけ: Cloudflareのプロキシを少し試した。 (6/20 16:43)

本文に書いたように、CFのWAFなどの機能が気になったので試してみたが、予想どおり、今一つ使えない感じだった。有料版なら可能性はあるので、CFがこの機能を出している意図は そこへの誘導だろうか。一番の問題は以下である。

http(ポート80)とhttps(ポート443)しか通さない。 → sshなどや標準ポート以外のhttp/httpsは使えない。

※ただし、pingは応答が来る。

他の方が どう運用しているか分からないが、sshはプロキシを通さない別のホスト名かIPアドレスにしているのだろうか。標準ポート以外のhttp/httpsも同様だろうか。※ とすれば、結局、それらが穴になってしまい、元々のサーバでも不正アクセス対策が必要なので、CFのファイアウォール(WAF)のメリットは減る。本文に書いたように、サーバがCFにないための欠点である。

※標準ポート以外のhttp/httpsは止め、sshだけ開ける(サーバで直接受ける)のが現実的で、そうすればWAFも有効だろうけど、物足りない感じだ。例えば、メールも諦めるのだろうか。それもサーバで不正アクセス対策するのか。

不正アクセス対策をするのは当たり前のことだが、であれば、いろいろな我慢や設定変更をして わざわざCFのプロキシ(のWAF)を使うメリットが どこまであるのかという感じだ。

他に、プロキシなので、http/httpsのアクセス元のIPアドレスがCFのものになるため、サーバでアクセス制御・分析などをする時の対応・修正も必要だ。あと、WAFを有効に使うためには、本当にCFのプロキシからのアクセスであるかの確認が必要で、どこまでそれが確実にできるかも問題になるかも知れない。

↓

(6/21 19:50) その後、(例によって)寝て居る時の思い付きで気が変わり、ちょっと試して見て居る。というのは、CFのセキュリティ機能が ある程度使えるなら、脆弱なWPの保護に少しは役立つかも知れないと思ったからだ。

使ってみたら、無料でも思ったより多くの機能が使えることが分かった。ただ、それらが分散気味で結構分かりにくいのが惜しい。でも、ドキュメントは豊富なので、読んで試す気になれる。

設定には なかなか手間取ったが、ひとまず、概ね普通に使えるように できて、試している。

普通に使えないのは(上述のとおり)sshで、良い方法を思い付けなかったので、CFを通さないホスト名でアクセスするようにした。また、標準ポート以外のhttp/httpsも そうしていたのだが、調べているうちに、Origin rulesという書き換えルールで、指定した条件に合うものを別のポートに転送するようにできることが分かった。ただ、それで有用なのか(意味があるのか)今一つ分からないので、様子を見ている。

上に書いたように、さまざまな機能を試していて、すぐには効果や感想などを書けないので、少ししてから別途書くことにしたい。