Cloudflare

Google Domains が事業売却されるという話から約半年、重い腰をあげてついに我が家のドメインも Cloudflare に移行対応しました。 半年も経てば Cloudflare への移行手順は多くの記事で紹介されているので、今回は Cloudflare 移行に伴って発生した自宅ラボで使っている cert-manager の移行対応を記録しておきます。 なぜドメイン移行先を Cloudflare にしたのか このブログでも使っている nnstt1.dev というドメインは Google Domains で購入していましたが、ネームサーバーを設定してレコードの管理自体は Azure DNS でおこなっていました。 Azure DNS で管理しているなら Azure 自体でドメインを購入すればいいじゃないかと思ったのですが、Azure でドメインを購入するサービスの App Service ドメインでは com、net、co.uk、org、nl、in、biz、org.uk、co.in のトップレベルドメイン (TLD) しか対応していなかったため、.dev ドメインは別のサービスを利用するしかありませんでした。 （そもそも Google Domains にしたのも Azure が .dev に対応してなかったからなのに、今回も移行できないか確認してしまったという…） というわけで他のドメインサービスを探すことになったのですが、おネームドットコムは論外ということ以外は特にこだわりはありませんでした。 半年前でもそうでしたが、やっぱり Cloudflare が移行先として人気のようで、右にならえで自分も Cloudflare に移行することにしました。 移行自体はすんなり完了したのと、レコード自体の管理も Terraform を使うようにしました。 cert-manager の対応 自宅ラボの Kubernetes クラスタでは証明書管理のための cert-manager を使っています。 クラスタで（自宅内に閉じて）公開しているサービスの証明書を Let’s Encrypt で発行していますが、そのためにはドメインの検証が必要になります。 検証の方法は 2 つあって、Let’s Encrypt から対象ドメインを使っているサービスにアクセスする HTTP Validation と、DNS に指定の TXT レコードを作成する DNS Validation があります。 ...